To:
Robert Burbidge <robert.burbidge@poptel.coop>
cc:
"Ietf-Provreg (E-mail)" <ietf-provreg@cafax.se>, brunner@nic-naa.net
From:
Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>
Date:
Mon, 08 Apr 2002 07:44:21 -0400
In-Reply-To:
Your message of "Mon, 08 Apr 2002 10:44:07 BST." <F9151633A30CD4118C9D00062939A7F19A3FD0@popintlonex.poptel.org.uk>
Sender:
owner-ietf-provreg@cafax.se
Subject:
Re: Session and session-less commands in EPP
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> 3 C: <command><creds>...</creds><login>...</login></command> 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. > after a <logout> command. A similar comment is found in the BEEP protocol > mapping. > > 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