Subject: Re: Proposed Document Changes

From: Jaap Akkerhuis <[email-masked]>
Date: Wed, 24 Jul 2002 13:38:58 +0200

> I assume you resend this to see if there are more comments. I 
    > don't mean to
    > beat up the dead horse, but I would like you to clarify the 
    > two paragraphs
    > quoted below.
    
    I didn't resend it.  Take a look at the message headers -- it looks like
    Jaap might have manually approved it for distribution to the list, or
    something like that.
    
Yes, I recent it by accident. Sorry about that.

	jaap

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 24 Jul 2002 07:13:46 -0400

> The first quoted paragraph, could you explain a bit why "congestion
> control/ack" need to be defined if the proposed change is not 
> made? Do you
> mean application level framing for flow control (windowing 
> mechanism)? I
> just want to understand it.

This gets back to the "delayed execution" discussion.  If commands don't get
immediate responses, we'd have to have some mechanism in place to let the
client know that commands have been received, but not processed.

> The second quoted paragraph, could you clarify:
> (1) What is the last command processed? Is it the last 
> command per registrar
> (client) or the last command per session of the client? I 
> assume that a
> client is allowed to established multiple sessions with the server.

Last command completed, which might not have anything to do with a session.
Remember, the session concept tends to be specific to connection-oriented
transports, and we shouldn't have transport dependencies on generic commands
if they can be avoided.

> (2) Why is <status> command ever needed if its use is so 
> restricted? The
> client can simply resend the command if it does not hear from 
> the server
> after a timeout. EPP ensures idempotency for each command, so 
> there is no
> harm to resend it.

To be perfectly honest I don't think the <status> command is needed at all.
It got added rather late in the review process when someone asked for the
ability to check on the completion status of a previously executed command
[1].  No one objected when it was discussed on this list back in September
of last year.  I would very much like to ditch the command for the very
reasons you cited.

This is a good time to agree or disagree, folks.  Is the <status> command
really needed or not?

-Scott-

[1]
The thread:
http://www.cafax.se/ietf-provreg/maillist/2001-09/msg00071.html

http://www.cafax.se/ietf-provreg/maillist/2001-09/msg00072.html

http://www.cafax.se/ietf-provreg/maillist/2001-09/msg00074.html

Plus other messages from September 2001, all visible in the archives.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 24 Jul 2002 08:15:40 -0400

> Last command completed, which might not have anything to do with a session.

[. . .]

> This is a good time to agree or disagree, folks.  Is the <status> command

It seems to me that the apparent confusion over sessions and the
<status> command shows that the command is going to be of limited
value.  I don't have strong feelings about it, but I now suspect it's
going to be confusing to a lot of people who will discover that it
won't work as they expect.

Andrew

-- 
----
Andrew Sullivan                               87 Mowat Avenue 
Liberty RMS                           Toronto, Ontario Canada
<[email-masked]>                              M6K 3E3
                                         +1 416 646 3304 x110