Subject: Session and session-less commands in EPP

From: Robert Burbidge <[email-masked]>
Date: Mon, 8 Apr 2002 10:44:07 +0100

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.

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

Does anyone have any thoughts on this?

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Mon, 08 Apr 2002 07:44:21 -0400

Morning Robert,

The session-less model we'd (or we've) in mind is epp/smtp.

draft-ietf-provreg-epp-06.txt is (nomially, pardon the abuse of language)
transport-independent, so it must contain guidance (manditory to implement)
on generic session-full and generic session-less transports.

Assume generic session-full transport
1 C: <hello>....
  S: <greeting>...
2 C: <command><creds>...</creds><check>...</check></command>
  ...

Assume generic session-less transport
1 C: <hello>....
2 C: <command><creds>...</creds><check>...</check></command>
...

The difference is in the <greeting> reply, which is manditory for the server
to return when prompted if the service is over a connection, and manditory to
prompt for (but not necessarily get) if the service is connection-less.

Since the client may request a <greeting> at any time by sending a <hello>,
making a requirement as to the next command, e.g., <login> if session is
desired, seems problematic.

1 C: <hello>
  S: <greeting>
2 C: <hello>
  S: <greeting>

Assuming one were implementing an error test case, then you've suggested
that at 3 an error is returned.

I thought the text in section 2.4, Command Format, at lines 539-544 were
clear, <login> and <logout> define server session, repeated in section
2.8.1, Session Management Commands, at lines 1055-1062, was clear.

> But as you can see it mixes "sessioned" and "session-free" operations.

I guess I don't see this. Maybe another cup of coffee would help.

> Does anyone have any thoughts on this?

The first thought that went through my mind was "Oh joy! A careful reader
of the BEEP draft!"

I think that what you are doing is (understandibly) missing the bits written
in invisible, or archived mailing list ink, that said anything over tcp is
session-full, epp/tcp or epp/beep/tcp, and that epp/smtp is session-less.

I'm really pleased to see implementor-esque comments from someone at Poptel,
my regards to Stu and Cazz.

Cheers,
Eric