Subject: [AAA-WG]: RE: API, latest draft

From: Cain Brian-BCAIN1 <[email-masked]>
Date: Mon, 23 Apr 2001 13:03:05 -0500

James,

	Inlined comments below.

...
> >the Base protocol's dictionary.  And it would probably be 
> necessary to have
> >the other dictionaries in order to distinguish between a 
> case where the
> >library should reject a message with response 
> "EXTENSION_NOT_SUPPORTED" or
> >"UNKNOWN_COMMAND".  
> >
> 
> I agree that all sessions will need to use the base 
> protocol's dictionary.
> 
> So it sounds like the issue is the following. If a command shows up
> for a given session but the command is known in a dictionary of
> another session, this design will return an UNKNOWN_COMMAND when
> it should return an EXTENSION_NOT_SUPPORTED, is that it? 

Perhaps.  It would certainly depend on the implementation of the API (despite the passed in Dictionary, the implementation could always make all of the dictionaries global, and still conform to the API).  

> The intent of including the dictionary in this fashion was to allow
> Diameter applications to running in the same virtual machine
> to handle separate applications, and so that they could define
> their commands in separate configuration files. I'm not strongly
> tied to this design, but I had thought it might be simpler from
> the application's perspective. It sounds like you would rather
> simply have a global command dictionary?

I'm not opposed to having separate configuration files, or separate command dictionaries, as long as the library knows about all of them, and is told about them only once.  If we could setup all of the dictionaries at initialization time (while still allowing for runtime updates to the dictionaries), it would probably be even simpler for the application.  

Would it be possible to use some term other than "session" for methods like startSession(), etc.?  The overloading of this term is responsible for quite a bit of confusion (on my part), I seem to always get this confused with the "User" sessions described in 11.0 of the Base draft.  

Each application would probably confine itself to messaging regarding one extension, which I think is why we can get away with one dictionary, right?  I guess I'm assuming that only one extension could be present in one dictionary, which may not be the case?  I was just trying to think of a situation where one dictionary would not suffice.  Also, I just figured that since AAAExtensionDescriptor has a copy of all the registered extensions (and their registered commands & AVPs), the library already has access to all the dictionaries it needs.

I don't think that the library would be able to determine which session an incoming command belongs to without parsing it first.  Of course, to parse it, the library would need a dictionary, but they would all be associated with their particular session, right?

> >(from 4.3.6.4)
> >>      public AAACommandDescriptor
> >>        registerCommand(long code,
> >>                        long vendorCode,
> >>                        java.lang.String name,
> >>                        java.util.Map AVPDictionary,
> >>                        java.util.Map disallowedAVPDictionary)
> >
> >Hmm..This is the only place I could see an AVP dictionary 
> being input into
> >the library.  I saw no mention of a property for the AVP 
> dictionary file.
> 
> Typically, the AVP dictionary is defined as part of the 
> command definition
> configuration file. I believe there has been agreement by the group

Okay, this answers several questions, including the AVP code->type resolution issue below.  

> that AVPs are standardized as part of extensions, not 
> separately. Thus,
> it seems to make sense to include them as part of the commands.
> 
> In addition, the API has to provide a way for programmatic definition
> of commands, separate from parsing the command definition file. This
> method is defined for the latter. The Java code implementing an
> extension that wants to build up a dictionary would do it by
> building up the AVP dictionary programmaticaly, then building up
> the command, etc.

I guess I didn't consider that as an option.  You're right, there could be good reasons for someone to not want a static configuration file.

> >I've got a couple of issues with this.  First, there is no 
> correlation
> >between AVP code and type.  This is the bare minimum 
> requirement for an AVP
> 
> I guess I don't understand. The AVPs and AVPDescriptors are 
> indexed by name, and 
> the AVPDescriptor object contains a type indicator 
> (AVPDescriptor.getType()). 
> Would you rather have them indexed by code?

You have answered my question on this already, but I'll clarify what I was trying to get across.  From the library's perspective, there must be some fundamental correlation between an AVP and its code.  Its code is the only key that the library should really care about (all others are a usability bonus), as this will be a required component of parsing AVPs (and Commands, for that matter).  As you can see above, I thought that there were distinct AVP and command dictionary files, and the AVP dictionary had been omitted, so I saw no way for the library to get the information that it needed to resolve an AVP from its code.  The issue is moot now.

...
> >(I see that as pretty unsatisfactory).  That much aside, I 
> really prefer
> >configuration files for AVP and Command dictionaries over 
> methods.  I think
> >that having both serves only confusion.  In place of methods like
> >"registerXxxxx()", a hierarchy of files could be established 
> to register
> >Extensions, Commands, and AVPs.
> >
> 
> I agree that configuration files are preferable, but I think we need
> to keep open the possibility of programmatic update. In addition,
> the library implementation itself can use the programmatic 
> interface when 
> parsing the configuration files.

Okay, sure.  I was thinking "if we don't need both, we can eliminate one", but if we need both, then we need both.

-Brian