Subject: [AAA-WG]: Sessions in API specification

From: [email-masked]
Date: Wed, 31 Oct 2001 17:43:57 +0200

Hi!

I know that the API specification is not synchronized with the latest base
protocol (BP) spec., but it would be very useful to clarify few things
related to the session, as it is defined in API doc.

1. Some features of the API-session make it look more like BP user sessions
(section 8 - diameter-07):
	- C API uses the userName as a parameter of the AAAStartSession()
	- Java API has a method AAASessionManager::getNetworkSessionId()
which makes the relationship between API-session and BP-session 1-1.

2. Other features make the API-session look more like an identifier of the
peer connection.
	- Java API uses the server address (I understand it as the peer
address, because that's the only information that the base protocol keeps)
for starting a session. This ties the session to the peer which makes a
failover procedure very complicated.

3. Who keeps the user session state machine and who generates the Session-Id
AVP? 

Because the information affecting the session state machine is in the
application domain (the application generates and understands the
corresponding messages) it seems more natural that the application
implementation also keeps the session state. If so, it is also the
responsibility of the application to generate the Session-Id AVP and add it
to the message.

If the base protocol library keeps the session state machine (as suggested
in Java API) then the library would have to take the info related to this
state machine from the application messages. This means that the library
should check each message sent and extract the information related to the
session.

Regards,

Adrian

---

From: David Frascone <[email-masked]>
Date: Wed, 31 Oct 2001 10:07:44 -0600

Since it's now a WG document, I'm not cross-posting this response to 
[email-masked].

> 	- C API uses the userName as a parameter of the AAAStartSession()

The sessions in the API are *completely* out of date.  They need to be
re-done.  Currently, the sessions in the API do *not* correspond to sessions
in the Diameter protocol.  They were instituted before Diameter sessions
were formalized.

In the API, it was a way to match up requests and responses at the API
layer, not at the protocol layer.

So, I guess the answer to your question, in short, is: The API draft is
badly out of date :(

I'll be working on updating it soon.

-Dave