RE: Session and session-less commands in EPP

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

> -----Original Message-----
> From: Robert Burbidge [mailto:robert.burbidge@poptel.coop]
> Sent: Monday, April 08, 2002 5:44 AM
> To: Ietf-Provreg (E-mail)
> Subject: Session and session-less commands in EPP
> 
> 
> draft-ietf-provreg-epp-06.txt, Section 2.8.1
> 
> Session and session-less operation
> ==================================
> 
> "Session-oriented and session-less operating modes MUST NOT be mixed".
> Intuitively I think you mean that the two modes cannot be 
> mixed within the
> same "session" (to use the term "session" in its most generic sense).
> However, consider the following outline sequence of EPP commands and
> responses
> 
> 1 C: <hello>....
>   S: <greeting>...
> 2 C: <command><creds>...</creds><check>...</check></command>
>   S: <response>...</response>
> 3 C: <command><creds>...</creds><login>...</login></command>
>   S: <response>...</response>
> 4 C: <command><check>...</check></command>
>   S: <response>...</response>
> 5 C: <command><logout></logout></command>
>   S: <response>...</response>
> 
> In this sequence, the <check> command [2] contains its own 
> credentials and
> it has not logged in, which seems fair. The <login> command [3] then
> provides credentials, and these are used by the second check 
> command [4]. As
> far as I can see, this is completely in accordance with the 
> specification.
> But as you can see it mixes "sessioned" and "session-free" 
> operations. We
> might stipulate that a <login> command MUST be the first command after
> <hello> if a client wants to use session operations. But I don't think
> that's particularly desirable.

I agree with your last sentence, and that's why the text currently reads the
way it does.  I don't see a problem with creds-containing commands preceding
a <login> if the server supports such behavior.  Perhaps changing the
"Session-oriented and session-less operating modes MUST NOT be mixed"
sentence to something like "Session-less operating mode MUST NOT be used
within the bounds of an established <login> ... <logout> session" would make
this more clear.

> <logout> command
> ================
> 
> "Commands other than the login command MUST NOT include 
> identity credentials
> when submitted after successfully processing a <login> 
> command". This is
> reasonable. However, what happens AFTER a <logout> command? 
> The presumably
> releases the credential set at the server end. Would it be 
> possible to send
> a <command> that includes <creds> after a successful <logout>? If the
> command sequence outlined above is valid, then a sense of 
> symmetry would
> suggest that the answer is "yes", but this would be in 
> conflict with the
> quoted statement above. 
> 
> According to draft-ietf-provreg-epp-tcp-04.txt, "an EPP 
> session is nominally
> ended by the client issuing an EPP <logout> command. A server 
> receiving an
> EPP <logout> command  MUST end the EPP session and close the TCP
> session...". This would seem to preclude <command> elements 
> with <creds>
> after a <logout> command. A similar comment is found in the 
> BEEP protocol
> mapping.

What happens after a <logout> is processed depends on the transport.  That's
why the base specs doesn't say anything specific, and the TCP and BEEP
documents specifically do address the topic.  It might be possible to add a
sentence to the base spec that says "what happens after logout is
transport-dependent", but I wouldn't want to say much more than that because
of the number of transport-related variables.

-Scott-