RE: Proposed Document Changes

["Liu, Hong" <Hong.Liu@neustar.biz>]

Scott,

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.

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.

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

Thanks in advance!

--Hong

-----Original Message-----
From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com]
Sent: Wednesday, July 17, 2002 5:57 PM
To: ietf-provreg@cafax.se
Subject: Proposed Document Changes


[snip...]

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

[snip...]

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

[snip...]

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