<!ELEMENT message (avp*)>
<!ELEMENT avp (avp*)>
-<!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>
+<!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-to-end-id CDATA #IMPLIED>
<!--
version: Diameter version. Sets '1' by default
name: Command name within working stack (dictionary identifier)
application-id: Message application id
hop-by-hop-id: Message hop by hop id. Sets '0' by default
- end-by-end-id: Message end by end id. Sets '0' by default
+ end-to-end-id: Message end to end id. Sets '0' by default
-->
<!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>
name: Avp name within working stack (dictionary identifier)
In order to get more coding capabilities, avp code, vendor-id and flags could be established instead of former avp name,
- but neither of them are allowed if 'name' is provided (and vice versa):
+ but neither of them are allowed if 'name' is provided (and vice versa), excepting 'flags' when 'may' or 'shouldnot' is
+ present in dictionary avp (actually bit P is deprecated by standard group, then, 'may' or 'shouldnot' won't be taken
+ into account for this bit: it someone uses it, our xml representation will differ from reality. At least with this
+ sacrifice in return, we will have nicer xml layouts in most of the cases):
code: Avp code
vendor-code: Avp vendor code