Subject: Proposed Document Changes

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 17 Jul 2002 17:56:33 -0400

While in Yokohama Ed, Jaap, Patrik, and I had a chance to talk through the
questions and answers [1] that we need to resolve before Patrik would feel
comfortable taking the provreg protocol documents to the IESG.  Here's a
summary of the changes that we think need to be made before the IESG will
approve the documents:

The core (epp-06) document:
- All text describing "asynchronous" operation needs to be removed/reworded.
Instead, text describing the protocol's operating mode as "client-initiated
command, server response" needs to be reinforced.  Without this change we'd
need to define our own "congestion control/ack" service to handle the loss
of instances that may be queued in the application queue-space (as when a
server goes down).

- Some ASCII art illustrating this operating mode should be added for
clarity.

- The description of the <status> command should be changed to describe the
server's caching responsibilities.  We agreed that the server should only be
responsible for caching the identifier for the last command processed, thus
if a response isn't received the client should send a <status> command
before sending any subsequent commands.  This should make <status>
processing a lot easier for the server, and it's consistent with the
protocol's command-response operating mode.  It might also make sense to
make the client transaction identifier mandatory instead of optional if the
server doesn't have to cache identifiers for "a long time".

- Fixing the authInfo data structure to make it extensible such that new
authInfo mechanisms can be added in the future without having to change the
core protocol document.

The TCP transport (tcp-04) document:
- Add some ASCII art describing the state machine for the protocol when
carried over TCP.

- Eliminate/reword all of the text describing "asynchronous" operation.
Instead, it's OK to mention here that the client might be able to gain some
performance efficiencies by pipelining commands, but that pipelining doesn't
change the protocol's basic ping-pong operating mode.

- Explicitly note that the length field in the header is in network byte
order.

I've also captured several editorial comments since we completed last call,
and I'll get those in as well.

If anyone has any issues or concerns with the above, speak up!

-Scott-

[1]
http://www.cafax.se/ietf-provreg/maillist/2002-06/msg00015.html

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 23 Jul 2002 07:05:26 -0400

Roger,

I think the answer to your question could be found further down in the
message you quoted the text from.  Here's what it says about changes to the
TCP draft:

"- Eliminate/reword all of the text describing "asynchronous" operation.
Instead, it's OK to mention here that the client might be able to gain some
performance efficiencies by pipelining commands, but that pipelining doesn't
change the protocol's basic ping-pong operating mode."

The core protocol is and remains a command-response protocol, though TCP
(and maybe some other transports) have built-in features that would allow a
client to send more than one command before the first has been completed.
SMTP, for example, can work the same way: the client can buffer and send
multiple commands, anticipating that each will be performed correctly, but
the basic protocol is still command-response.

The <status> command can't return any information for a command that hasn't
been completed.  Nothing has changed about that.

-Scott- 

> -----Original Message-----
> From: Roger Castillo Cortazar [mailto:[email-masked]]
> Sent: Monday, July 22, 2002 10:00 PM
> To: Hollenbeck, Scott; [email-masked]
> Subject: Re: Proposed Document Changes
> 
> 
> 
> Hi everybody, I have a few questions about this changes 
> proposed by Scott 
> that could be interesting
> 
> So, the "synchronous" operation mode is going to be mandatory ?
> 
> How is the command-response operating mode going to be reinforced ?
> - Is it that the client cannot send a command until he gets 
> the response to 
> the previous one ?
> - In other words: What happens if a client issues a command, 
> before he gets 
> a response to a previous one ?
> - Which response could he get if he issues a <status> for a 
> command, and 
> that command is not yet completed?
> 
> I think this could be somehow linked  to the <status> command and the 
> server's caching responsabilities.
> 
> Any comments ?
> 
> Greetings.
> 
> 
> Roger Castillo Cortazar
> NIC-Mexico http://www.nic.mx
> Top Level Domain .MX
>