Subject: RE: [diameter] Re: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft

From: "Mark Jones" <[email-masked]>
Date: Thu, 3 May 2001 17:58:38 -0400

I wanted to exclude expressing the command format simply because I was
struggling with how it could be expressed without using XML Schema. Last
time I looked, it was difficult to find a C++ parsing library that
supported XML Schema.

Without using XML schema, the XML for:

      Example-Command ::= < Diameter-Header: 9999999 >
                          { User-Name }
                        * { Origin-FQDN }
                        * [ AVP ]

would be:

	<DiameterMessage name="Example-Command" code="9999999">
		<RequiredAVP avpName="User-Name">
		<RequiredAVP avpName="Origin-FQDN" occurance="Many">
		<ArbitraryAVP occurance="Many">
	</DiameterMessage>

using the following DTD:

<!ELEMENT DiameterMessage (FixedAVP | RequiredAVP | OptionalAVP |
ArbitraryAVP)+>
<!ATTLIST DiameterMessage
	name CDATA #REQUIRED
	code CDATA #REQUIRED

<!ELEMENT FixedAVP EMPTY>
<!ATTLIST FixedAVP
	avpName IDREFS #REQUIRED
	occurance (One | Many) "One"
	minOccurs CDATA #IMPLIED
	maxOccurs CDATA #IMPLIED
<!ELEMENT RequiredAVP EMPTY>
<!ATTLIST RequiredAVP
	avpName IDREFS #REQUIRED
	occurance (One | Many) "One"
	minOccurs CDATA #IMPLIED
	maxOccurs CDATA #IMPLIED
<!ELEMENT OptionalAVP EMPTY>
<!ATTLIST OptionalAVP
	avpName IDREFS #REQUIRED
	occurance (One | Many) "One"
	minOccurs CDATA #IMPLIED
	maxOccurs CDATA #IMPLIED

<!ELEMENT ArbitraryAVP EMPTY>
<!ATTLIST OptionalAVP
	occurance (One | Many) "One"
	minOccurs CDATA #IMPLIED
	maxOccurs CDATA #IMPLIED

Comments?

Regards,
       Mark

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 3 May 2001 15:10:29 -0700

The DTD below needs to be fixed to allow one to specify that an AVP MUST 
come first, and last.

PatC

---

From: James Kempf <[email-masked]>
Date: Thu, 3 May 2001 13:40:59 -0700 (PDT)

>...
>> >> wouldn't be able to describe it.  Does the information not 
>> architecturally
>> >> belong in a dictionary?
>...
>> >My inclination is to leave that information out of the dictionary.
>> >
>> 
>> Actually, if construction of the Java command parser is to be 
>> completely
>> driven by the dictionary, then this information will have to 
>> be in the 
>> dictionary. Otherwise, the parser won't be able to flag when 
>> a command arrives
>> with an error. 
>
>If all that Pat's asking for is that it (it being the command format) be 
defined in a file that is not the dictionary, then it's probably a non-issue.  
Just add another configuration file, right?
>
>I don't see any reason why the command format information should not be in a 
file, but I can see why it might not belong with certain other types of 
information.

Sure, we could put it in another file. It's just easier programmatically to 
define the whole thing in one file. The parser can step through it
in one chunk, rather than  having to open a separate file and step
through that too. And, as mentioned, if extensions are standardized along
with commands and AVPs, then it sort of makes sense to me to define
the extension in one place.

Is there any reason why it shouldn't be in one file, except for the
fact that that is the way Radius did it?

		jak