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

From: James Kempf <[email-masked]>
Date: Wed, 2 May 2001 07:54:05 -0700 (PDT)

Yiwen,

>I read some thread in the mailing list earlier that the configuration file
>was taken out of the I-D on purpose to allow flexible user defined
>configuration. The end result, from my interpretation to the thread, was
>that the configuration file was going to be put back in again, but only one
>file is. Could you verify this for me please?
>

In the current draft, there is no requirement for configuration files
for the C library. This is because different operating system platforms
may have different requirements. 

However, in the case of Java, it is very likely that people will write
portable modules that can be used on a variety of different platforms.
Since command and AVP parsing is driven by the command configuration file,
a standardized configuration file is required for cross-platform
compatibility.

		jak

---

From: Yiwen Jiang <[email-masked]>
Date: Wed, 2 May 2001 11:08:37 -0400

Hi James,

> may have different requirements. 
I can see for the general aaa.conf file, the different OS may have different
way of describing the file path, but I would argue that the dictionary file
should exist regardless of the OS.  It is up to the implementor to ensure
the AVP types are actually supported. This is because there are already
well-defined AVPs and its types and for some, possible values. 

Or am I missing something here?

---

From: Yiwen Jiang <[email-masked]>
Date: Wed, 2 May 2001 16:41:17 -0400

Hi Pat,

> > Now, my question is, wouldn't this be the same functionality as
> > AAANewMessage with the request message (last parameter in 
> its signature)
> > provided at the time of call?
> 
> Sure but they have different functinality. AAANewMessage will 
> allocate a 
> new AAAMessage, while AAARespondToMessage will prep a 
> received AAAMessage
> to be used as a response message.
> 
> If AAAMessage is to be used instead, you would have to allocate a new 
> AAAMessage, copy all of the AVPs over, and delete the request 
> AAAMessage.
> 
> Hope this helps,
Yes it does help. Thank you very much.. Could we have this sort of
explaination added in the ID though? Because my initial understanding from
reading the draft for AAARespondToMessage is completely different from the
above clarification.

Thanks again, everyone.. :)

---

From: Yiwen Jiang <[email-masked]>
Date: Wed, 2 May 2001 16:48:05 -0400

> > Sure but they have different functinality. AAANewMessage 
> will allocate a 
> > AAAMessage, copy all of the AVPs over, and delete the 
> request AAAMessage.
> > 
> 
> And set all the flags, which is not currently possible with 
> the API, since
> AAARespondToMessage is there.
> 

If this is the case, why is the request message required at all for
AAANewMessage()? shouldn't everyone be using AAARespondToMessage() when
sending a reply to a response, and using AAANewMessage() when creating a
brand new message?

---

From: Cain Brian-BCAIN1 <[email-masked]>
Date: Wed, 2 May 2001 17:18:16 -0500

> OK, it sounds like you are in favor of having a dictionary 
> file regardless
> of the language.
> 
> Any other comments from WG members? 

I concur.  A standardized dictionary file syntax could only aid an
implementor.  Is there any reason why the C API couldn't use an XML
dictionary file, like the Java portion?  I would imagine there is probably
no lack of publically available C XML parsers.

-Brian

---

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

That's the intent.

		jak
		
>From: "Mark Jones" <[email-masked]>
>To: "James Kempf" <[email-masked]>, <[email-masked]>, 
<[email-masked]>, <[email-masked]>
>Subject: RE: [diameter] Re: [AAA-WG]: Re: questions and comments regarding the 
Diameter A  PI draft
>Date: Thu, 3 May 2001 14:29:00 -0400
>X-Priority: 3 (Normal)
>X-MSMail-Priority: Normal
>Importance: Normal
>X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
>
>If the goal is to define a DTD for Diameter dictionaries purely for the
>purpose of attribute encoding/decoding (and NOT for validating the message
>format) then I'm up for it.
>
>Regards,
>       Mark
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]On Behalf
>> Of James Kempf
>> Sent: May 3, 2001 1:32 PM
>> To: [email-masked]; [email-masked]; [email-masked]
>> Subject: Re: [diameter] Re: [AAA-WG]: Re: questions and comments
>> regarding the Diameter A PI draft
>>
>>
>> So do we have any volunteers who want to push this separate draft
>forward?
>>
>> 		jak
>>
>> >Delivered-To: [email-masked]
>> >Date: Thu, 3 May 2001 12:27:35 -0500
>> >From: David Frascone <[email-masked]>
>> >To: [email-masked], [email-masked]
>> >Subject: Re: [diameter] Re: [AAA-WG]: Re: questions and comments
>> regarding the
>> Diameter A  PI draft
>> >Mail-Followup-To: [email-masked], [email-masked]
>> >Content-Disposition: inline
>> >User-Agent: Mutt/1.2.5i
>> >X-encrypt-payload: no
>> >
>> >I agree.
>> >
>> >On Thu, May 03, 2001 at 10:01:10AM -0700, Pat Calhoun wrote:
>> >> On Thu, May 03, 2001 at 10:02:11AM -0700, James Kempf wrote:
>> >> >
>> >> > >
>> >> > >Did you have a spec in mind for your DTD? Base/API?
>> >> > >
>> >> >
>> >> > If the working group agrees, we could put it into the API draft as
>> >> > the basis for the command/AVP dictionary format, like we had the
>> >> > previous one.
>> >>
>> >> I would prefer that the dictionary be its own separate
>> informational RFC. It
>> >> is independent of the API.
>> >>
>> >> PatC
>> >>
>> >
>>
>>
>>

---

From: Cain Brian-BCAIN1 <[email-masked]>
Date: Thu, 3 May 2001 15:23:51 -0500

> From: Pat Calhoun [mailto:[email-masked]]
> 
> On Thu, May 03, 2001 at 02:53:29PM -0500, Cain Brian-BCAIN1 wrote:
...
> > wouldn't be able to describe it.  Does the information not 
> architecturally
> > belong in a dictionary?
> 
> Well, not dictionary in the historical sense. If a Diameter 
> dictionary is more
> than just a list of AVPs, then perhaps it should.
> 
> My inclination is to leave that information out of the dictionary.

I skimmed through the API, and I couldn't find mention of a non-dictionary file (or other parameter) that specifies message formats.  Is this because message format validation isn't intended to occur within the library, or is this the first time that the issue of where message format should be defined is being addressed, and everyone was assuming (like me) that the dictionary would define message format?  Or did I overlook something in the API?

-Brian

---

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

>
>After taking a quick look at Erik's DTD, it seems to not include any
>information about position/number/inclusion/exclusion of AVPs within
>commands.  This would probably line up with your desire not to have the
>message's format validated by the DTD.  What I don't understand is why it's
>desirable for this information to be absent.  Is there another file format
>that is recommended for describing message formats?  I don't see why XML
>wouldn't be able to describe it.  Does the information not architecturally
>belong in a dictionary?
>
>

As a practical matter, I'd like to see commands and AVPs defined in the
same file. I believe the working group has decided to recommend
standardizing AVPs and commands together in extensions, and not
allow separate standardization (someone please correct me if I'm wrong),
so it seems to make sense. I'd rather avoid having a separate file
with commands and AVPs. I know that's not how Radius did it, but
Radius really didn't have extensions.

		jak

---

From: Cain Brian-BCAIN1 <[email-masked]>
Date: Thu, 3 May 2001 15:34:50 -0500

> From: James Kempf [mailto:[email-masked]]
> 
> 
...
...
> 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.

-Brian

---

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

>Well, not dictionary in the historical sense. If a Diameter dictionary is more

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. 

It is, of course, possible to programmatically insert that information
into the command dictionary, but this would require the application
extension code to deal with syntax instead of just semantics. Currently,
the Java API allows the application extension code to just deal with
the semantics of the command, and not have to set up the command dictionary
for syntax. 

		jak