bug in RC
[anna.git] / include / anna / diameter / codec / message.dtd
1 <?xml version="1.0" encoding="UTF-8"?>
2 <!-- Diameter message DTD -->
3
4 <!ELEMENT message (avp*)>
5 <!ELEMENT avp (avp*)>
6
7 <!ATTLIST message version CDATA #IMPLIED name CDATA #IMPLIED code CDATA #IMPLIED flags CDATA #IMPLIED p-bit (yes | no) #IMPLIED e-bit (yes | no) #IMPLIED t-bit (yes | no) #IMPLIED application-id CDATA #REQUIRED hop-by-hop-id CDATA #IMPLIED end-by-end-id CDATA #IMPLIED>
8 <!--
9    version: Diameter version. Sets '1' by default
10    name:    Command name within working stack (dictionary identifier)
11    p-bit:   (P)roxiable bit flag (yes, no). By default is 'no'
12    e-bit:   (E)rror bit flag (yes, no). By default is 'no'
13    t-bit:   Potentially re-(T)ransmitted bit flag (yes, no). By default is 'no'
14    
15    In order to get more coding capabilities, command code and flags could be established instead of former fields,
16     but neither of them are allowed if the other are present (and vice versa):
17    
18    code:    Command code
19    flags:   Command flags byte value (0-255) where standard bit set for flags is 'RPET rrrr': (R)equest, (P)roxiable, (E)rror, Potentially re-(T)ransmitted message and (r)eserved
20
21    application-id:   Message application id
22    hop-by-hop-id:    Message hop by hop id. Sets '0' by default
23    end-by-end-id:    Message end by end id. Sets '0' by default
24 -->
25
26 <!ATTLIST avp name CDATA #IMPLIED code CDATA #IMPLIED vendor-code CDATA #IMPLIED flags CDATA #IMPLIED data CDATA #IMPLIED hex-data CDATA #IMPLIED alias CDATA #IMPLIED>
27 <!--
28    name:   Avp name within working stack (dictionary identifier)
29    
30    In order to get more coding capabilities, avp code, vendor-id and flags could be established instead of former avp name,
31     but neither of them are allowed if 'name' is provided (and vice versa), excepting 'flags' when 'may' or 'shouldnot' is
32     present in dictionary avp (actually bit P is deprecated by standard group, then, 'may' or 'shouldnot' won't be taken
33     into account for this bit: it someone uses it, our xml representation will differ from reality. At least with this
34     sacrifice in return, we will have nicer xml layouts in most of the cases):
35    
36    code:          Avp code
37    vendor-code:   Avp vendor code
38    flags:         Avp flags byte value (0-255) where standard bit set for flags is 'VMPr rrrr': (V)endor-specific, (M)andatory, end to end encry(P)tion and r(eserved)
39    alias:         Descriptive/helper field for certain numeric data values. Aliases are defined at diameter dictionary, but are ignored (not checked) at xml message parsing
40                   The reason to include it in dtd definition, is because xml messages traced by the diameter codec could add alias field for some Avps
41
42
43    data:          Natural string representation for avp data. Specially applicable with numbers and printable strings, but also
44                    useful for certain formats which could be easily understandable in such friendly/smart representation. We will
45                    achieve different human-readable strings depending on data format:
46
47                      [ OctetString ] (if printable, but not recommended)
48                      [ Integer32, Integer64, Unsigned32, Unsigned64, Float32, Float64 ] (normal number representation)
49                      [ Time ] (NTP timestamp, normal number representation)
50                      [ Address ] ('<type (IANA Address Family Number)>|<value>' representation; i.e. '1|192.168.0.1'(IPv4), '8|34616279266'(E164), etc.
51                                  Type (and pipe) field could be avoided for IPv4 and IPv6 address types (a light parse checking is done: one colon for
52                                  IPv6, one dot for IPv4). Internal engine always includes type on data field, which is also recommended for inputs.
53                                  Currently, only IPv4, IPv6 and E164 address types have a known printable presentation, anyway using printable format
54                                  for another types will encode the address value directly as E164 does)
55                      [ UTF8String, DiameterIdentity, DiameterURI ] (printable)
56                      [ IPFilterRule, QoSFilterRule ] (uses ASCII charset, printable)
57                      
58                      New application formats must define specific natural representation for internal raw data
59    
60    hex-data:      Hexadecimal octet sequence representation (i.e. 'af012fb3', with even number of digits). Suitable for whatever kind
61                    of diameter format, but mandatory for non printable information. OctetString usually transport non human-readable
62                    data and should better be encoded within this field although being printable. Unknown avps (which fails identifying
63                    provided name or code/vendor-code) must always use this representation.
64    
65    Xml representation for decoded messages shows natural content except for 'OctetString' format and unknown avps. Anyway, when printable,
66     OctetString could show such information at data field apart from hex-data, because many implementations use this format to transport
67     readable-string data. In general, one of the data fields is mandatory except for 'Grouped' type (its data is another level of avps).
68    Application-specific formats must decide the way to represent its contents, being recommended to use a natural representation if possible,
69     because xml is read by humans with testing and monitoring purposes.
70 -->
71