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

From: James Kempf <[email-masked]>
Date: Mon, 23 Apr 2001 11:21:44 -0700 (PDT)

Hi Brian,

Again, thanx for your comments, they have been most helpful in refining
the design.

>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.  

I think it would probably be easier in that case to just have a single
command file. The whole point of having separate files is so that
separate applications that don't know about each other can set up
their command sets. This purpose would be defeated by requiring all
the command sets to be registered at initialization time.

>
>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. 

The sessions managed by the session manager *are* exactly
the user sessions in Chapter 11.0 of the Base draft. The only difference is
that they are being identified in the VM by a small integer identifer rather
than a session name. In fact, in the latest draft of the API, there is even a 
method,  SessionManager.getNetworkSessionId(), that is used to get the Section 
11.2 network session identifier corresponding to a Diameter User session.

>
>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?

Let's just go back to a single dictionary. It's simpler.

>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.

But I still think you have made a point. The spec currently requires
the AVPDescriptor dictionary for a command to be indexed by the
AVP name. As you have pointed out, it would be better to index
it by code, so that it can be retrieved with a single hash when
parsing a command. The command dictionary is already defined so
that it can be indexed by code (actually, the interface is a method
so it can be indexed however you want, but by code would probably
be the most efficient).

		jak