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