Subject: TCP Mapping

From: "Liu, Hong" <[email-masked]>
Date: Sun, 30 Jun 2002 21:34:27 -0500

Eric,

I would like to give a high level answer to your two questions. For details,
please see our draft coming up...

As you may have mentioned, there are two aspects of "EPP PUSH" (I am using
the term in a broad sense here):

First, the semantics of EPP PUSH, which is your second question. My
definition is the server pushing unsolicited data to the client during an
EPP session. By that, I mean a counterpart of <poll>. So conceptually, this
is very simple. Procedurally, it involves three steps:

o Negotiation of PUSH capability between the server and the client during
session establishment.
o Server-pushed message exchange after the session is setup as
"push-enabled".
o Session teardown post-processing (if required).

I have explained the first step in my previous email to you. The last step
may or may not be necessary, depending on whether we allow concurrent PUSH
over multiple sessions, and whether we allow changing session property on
the fly (e.g., from not push-enabled to push-enabled and vice versa). 

When I say "server" and "client", they are defined in the context of base
EPP and its TCP mapping. In the BEEP mapping, they may be better labeled as
peering receiver and sender. If they are to be defined in a transport
neutral manner, we may need to either redefine the two terms or come up with
new terms for them. I would prefer to keep them as defined in the base EPP,
but your suggestion is welcome.

Second, the syntax of EPP PUSH extension, which is your first questoin. This
is the topic I brought up to the list for discussion. The key question is
how to tag the server-pushed message. Using the "P"-bit in the Total Length
field is one way, defining a new <push> command and corresponding response
and some new result codes is another. Suppose we proceed with the second
approach. Then a new XML schema will define their syntax as extension,
referred to by an EPP PUSH URI. The <push> command at the minimum will carry
the data elements of a <poll> response. The EPP PUSH URI will also be used
in the session establishment step for the server to advertise this extension
and for the client to subscribe to the extension.

Of course, there are other details that need to be iron out. I hope that I
have answered your questions on a high level.

--Hong

-----Original Message-----
From: Eric Brunner-Williams in Portland Maine
[mailto:[email-masked]]
Sent: Sunday, June 30, 2002 6:24 PM
To: Liu, Hong
Cc: [email-masked]'; [email-masked]
Subject: Re: TCP Mapping

Hong,

How is your extension supposed to work?

Exactly what do you mean by "EPP PUSH"?

Eric

---

From: Rick Wesson <[email-masked]>
Date: Sun, 30 Jun 2002 20:38:06 -0700 (PDT)

Hong,

could you please restate your case for pushing data, specificly stating
your reasoning for updating the tcp transport for epp.

thanks,

-rick

Date: Sun, 30 Jun 2002 08:57:10 -0700 (PDT)
From: Rick Wesson <[email-masked]>
To: "Liu, Hong" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: RE: TCP Mapping 
Sender: [email-masked]

Hong,

> I see the WG (from those who spoke out) seems to lean towards
> developing this capability independent of the underlying transport. If
> that is the way to go, we will do it.

yes, I agree with you here.

-rick

From: "Liu, Hong" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: TCP Mapping 
Date: Sun, 30 Jun 2002 10:16:42 -0500
Sender: [email-masked]

Rick,

I would like to clarify a couple of points here:

First, the work on EPP PUSH over TCP is complimentary to that for BEEP. I
like BEEP and we all agree it is easier to use BEEP for EPP PUSH. But that
by itself should not exclude others from using the same capability over TCP.
Are you insisting that if one wants to support PUSH, s/he MUST use BEEP?
Please clarify. I personally prefer to leave it open and let the market
decide what to use in real life operations.

Second, if your objection to this work is about making changes to the Total
Length field in TCP mapping to support EPP PUSH, I hear your point and I am
open to it. The whole objective for me bringing this topic to the list is to
get feedback from you and others on what the best technical solution is to
support EPP PUSH over TCP. So far, I see the WG (from those who spoke out)
seems to lean towards developing this capability independent of the
underlying transport. If that is the way to go, we will do it.

So, do you support developing the EPP PUSH extension without changing the
Total Length field in the TCP mapping? I just need to confirm your opinion.

Cheers,

--Hong

-----Original Message-----
From: Rick Wesson [mailto:[email-masked]]
Sent: Sunday, June 30, 2002 1:57 AM
To: Liu, Hong
Cc: [email-masked]'
Subject: RE: TCP Mapping 

[snip...]

> I don't think EPP PUSH should be exclusively tied to BEEP. BEEP makes EPP
> PUSH easier, and that is it.

nor do I, however beep supports a push model where as our EPP over TCP
doesn't.

> I am not sure about smtp since I have not seen the draft yet...
>
> Two questions need to be addressed separately in the discussion:
> 1. Can EPP PUSH be used for EPP over TCP?

we have learned we shouldn't be altering the EPP over TCP transport to
make it work.

> 2. How to do the EPP PUSH extension properly for EPP over TCP (or over any
> transport)?

over any transport is the preferable objective.

-rick

From: "Liu, Hong" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: TCP Mapping 
Date: Sun, 30 Jun 2002 09:37:04 -0500
Sender: [email-masked]

Eric,

I have a suggestion to you, and I will say it only once: please focus on the
technical issues. This is the IETF mailing list for discussing EPP. It is
NOT the list to release your resentment. 

If you want to make a technical point, please do and let's debate the pros
and cons. Otherwise, it is just noise.

Please respect yourself and others on the list.

--Hong

-----Original Message-----
From: Eric Brunner-Williams in Portland Maine
[mailto:[email-masked]]
Sent: Sunday, June 30, 2002 7:06 AM
To: Liu, Hong
Cc: [email-masked]'; [email-masked]
Subject: Re: TCP Mapping 

Hong,

You wrote:

> Most (if not all) EPP implementations today use TCP and will stay that way
> for a long time.

I'm don't doubt the correctness of your statement concerning the NeuStar
registry and client. I don't do business with NeuStar, or follow it with
any particular interest, so other than what NeuStar contributors disclose
on this list, concerning its implementation or plan of record, I wouldn't
know (and don't care).

I do know that I'm not the sole implementor who has, or is working on, an
implementation of EPP using a BEEP channel profile. I'm surprised to learn
of NeuStar's long-term de-committment from EPP over BEEP -- this month in
particular.

You wrote:
> ... we want to make PUSH work using TCP. It is
> not a requirement, it is an extension with which we can use PUSH for EPP
> over TCP.

Your initial note to this list, and Scott's careful recitation, reflect
that your desire is to modify a transport draft that has no options, and
which itself is not optional in the protocol draft. 

Just how is the NeuStar extension supposed to work?

This way?

	o client implementations communicating with the NeuStar registry
	  MUST NOT ignore the P-BIT,
and
	o client implementations communicating with another registry
          MAY ignore the P-BIT?

Or this way?

	o client implementations communicating with any registry
          MUST NOT ignore the P-BIT?

You wrote:
> 1. Can EPP PUSH be used for EPP over TCP?

Could you suggest a definition for "EPP PUSH" please? I seem to have missed
it.

Eric

To: "Liu, Hong" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: TCP Mapping 
Date: Sun, 30 Jun 2002 07:06:10 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Hong,

You wrote:

> Most (if not all) EPP implementations today use TCP and will stay that way
> for a long time.

I'm don't doubt the correctness of your statement concerning the NeuStar
registry and client. I don't do business with NeuStar, or follow it with
any particular interest, so other than what NeuStar contributors disclose
on this list, concerning its implementation or plan of record, I wouldn't
know (and don't care).

I do know that I'm not the sole implementor who has, or is working on, an
implementation of EPP using a BEEP channel profile. I'm surprised to learn
of NeuStar's long-term de-committment from EPP over BEEP -- this month in
particular.

You wrote:
> ... we want to make PUSH work using TCP. It is
> not a requirement, it is an extension with which we can use PUSH for EPP
> over TCP.

Your initial note to this list, and Scott's careful recitation, reflect
that your desire is to modify a transport draft that has no options, and
which itself is not optional in the protocol draft. 

Just how is the NeuStar extension supposed to work?

This way?

	o client implementations communicating with the NeuStar registry
	  MUST NOT ignore the P-BIT,
and
	o client implementations communicating with another registry
          MAY ignore the P-BIT?

Or this way?

	o client implementations communicating with any registry
          MUST NOT ignore the P-BIT?

You wrote:
> 1. Can EPP PUSH be used for EPP over TCP?

Could you suggest a definition for "EPP PUSH" please? I seem to have missed
it.

Eric

Date: Sat, 29 Jun 2002 22:57:20 -0700 (PDT)
From: Rick Wesson <[email-masked]>
To: "Liu, Hong" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: RE: TCP Mapping 
Sender: [email-masked]

On Sat, 29 Jun 2002, Liu, Hong wrote:

> Rick,
>
> Most (if not all) EPP implementations today use TCP and will stay that way
> for a long time.

ok, we disagree.

> For this matter, we want to make PUSH work using TCP. It is
> not a requirement, it is an extension with which we can use PUSH for EPP
> over TCP.

why, whats the use case, and why is it worth altering each and every
transport to enable push. we all agreeded along time ago that push work
better in beep.

It would help us all if you gave us some reasoning behind your wishes.

> I don't think EPP PUSH should be exclusively tied to BEEP. BEEP makes EPP
> PUSH easier, and that is it.

nor do I, however beep supports a push model where as our EPP over TCP
doesn't.

> I am not sure about smtp since I have not seen the draft yet...
>
> Two questions need to be addressed separately in the discussion:
> 1. Can EPP PUSH be used for EPP over TCP?

we have learned we shouldn't be altering the EPP over TCP transport to
make it work.

> 2. How to do the EPP PUSH extension properly for EPP over TCP (or over any
> transport)?

over any transport is the preferable objective.

-rick

From: "Liu, Hong" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: TCP Mapping 
Date: Sat, 29 Jun 2002 20:27:09 -0500
Sender: [email-masked]

Rick,

Most (if not all) EPP implementations today use TCP and will stay that way
for a long time. For this matter, we want to make PUSH work using TCP. It is
not a requirement, it is an extension with which we can use PUSH for EPP
over TCP.

I don't think EPP PUSH should be exclusively tied to BEEP. BEEP makes EPP
PUSH easier, and that is it.

I am not sure about smtp since I have not seen the draft yet...

Two questions need to be addressed separately in the discussion:
1. Can EPP PUSH be used for EPP over TCP?
2. How to do the EPP PUSH extension properly for EPP over TCP (or over any
transport)?

I hope we can agree on 1 and focus on 2.  

--Hong

-----Original Message-----
From: Rick Wesson [mailto:[email-masked]]
Sent: Saturday, June 29, 2002 7:40 PM
To: Hollenbeck, Scott
Cc: 'Eric Brunner-Williams in Portland Maine'; Liu, Hong;
[email-masked]'
Subject: RE: TCP Mapping 

I understand how push can work with beep, but why is it a requirement to
work with the tcp transport? also isn't push with smtp only require a
corrdinated mbox?

I'd prefer we not muck with the tcp transport and find a method to get
push to work with all transports or settle on using beep because it is
already prepaired for push style messaging.

-rick

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Liu, Hong'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: TCP Mapping 
Date: Sat, 29 Jun 2002 21:09:43 -0400
Sender: [email-masked]

> Just want to make sure that I understand correctly. Strictly 
> speaking, BEEP
> is not a transport protocol like TCP. It is a shim layer 
> protocol that makes
> application framing easier. BEEP by itself also needs to be 
> mapped to a
> transport protocol. RFC3081 defines the TCP mapping for BEEP, 
> and I assume
> that when we define EPP over BEEP over TCP, it is RFC3081 
> that is used for
> TCP mapping, not draft-ietf-provreg-epp-tcp-04.txt. So I do 
> not see any
> problem here.

If you put _any_ push semantics into the EPP TCP mapping, those semantics
will _not_ be available to any transport mapping (like BEEP, email, SCTP,
whatever) that doesn't use the EPP TCP mapping.  You'll end up having to
reinvent those semantics for each new transport -- that's the problem.

Well, that's all for me for now -- later!

-Scott-

From: "Liu, Hong" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: TCP Mapping 
Date: Sat, 29 Jun 2002 19:38:42 -0500
Sender: [email-masked]

First, I am guilty of making everyone work over the weekend...

Scott, please see my comments in line.

--Hong

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: Saturday, June 29, 2002 5:47 PM
To: 'Eric Brunner-Williams in Portland Maine'; Liu, Hong
Cc: [email-masked]'
Subject: RE: TCP Mapping 

> (from draft-ietf-provreg-epp-tcp-04.txt)
> 4. Datagram Format
> 
>   The data field of a TCP datagram MUST contain an EPP datagram.  The
>   EPP datagram contains two fields: a 32-bit header that describes
> >	the P-bit (is the message "PUSH" or "PULL")

One big bug with this approach: putting _anything_ specific to this
push/pull thing in the TCP draft is going to cause a problem with BEEP
transport (or any transport other than streaming TCP) because the BEEP draft
(for example) depends on standard BEEP profiles -- not the EPP TCP draft.
If this gets put into the TCP draft, just how is it going to work with BEEP
transport, email transport, or whatever other transport someone might define
in the future?

<HL>
Just want to make sure that I understand correctly. Strictly speaking, BEEP
is not a transport protocol like TCP. It is a shim layer protocol that makes
application framing easier. BEEP by itself also needs to be mapped to a
transport protocol. RFC3081 defines the TCP mapping for BEEP, and I assume
that when we define EPP over BEEP over TCP, it is RFC3081 that is used for
TCP mapping, not draft-ietf-provreg-epp-tcp-04.txt. So I do not see any
problem here.

Later on, we may also define EPP over SCTP. But by the same principle, EPP
over BEEP over SCTP should use the SCTP mapping for BEEP, not the SCTP
mapping for EPP. Not that we want to do so, just another example.
</HL>

Hong has already said (and I'm paraphrasing) that a goal is to make the push
thing work without BEEP.  Well, if it's going to work with any transport the
mechanics can't be put into one of the transport drafts.  It has to be
defined at a higher layer.

<HL>
Yes, indeed. We want to make PUSH work for TCP since this is what we have
today. I see your point here: it would be best if we can define a transport
independent PUSH for EPP. I am still exploring this on the list, using TCP
as a starting point.
</HL>
 
FWIW, assuming this discussion carries past tonight I'm going to have to
pick it up after 8 July; silence != concurrence.  It's time for a little
R&R...

<HL>
Have a good vacation next week. I will be out for the later part of next
week, too. 
</HL>

-Scott-

From: "Liu, Hong" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: TCP Mapping 
Date: Sat, 29 Jun 2002 19:15:43 -0500
Sender: [email-masked]

In short, the "P"-bit is not set for any message other than those
server-push data AFTER the session is established.

In order for both the server and the client to agree on using PUSH
extension, it has to be negotiated when setting up the EPP session.
Basically, the server in the <greeting> message announces its intent to use
the PUSH extension. The client, if it agrees to support PUSH, acknowledges
that in the <login> message. Both can be done by including a PUSH URI as an
<extURI> value within the <svcExtension> field. 

-----Original Message-----
From: Eric Brunner-Williams in Portland Maine
[mailto:[email-masked]]
Sent: Saturday, June 29, 2002 6:59 PM
To: Hollenbeck, Scott
Cc: 'Eric Brunner-Williams in Portland Maine'; Liu, Hong;
[email-masked]'; [email-masked]
Subject: Re: TCP Mapping 

I'm still trying to figure out what the P-bit is in the <greeting>.

I wouldn't expect the editors of the WG beep draft to pay any attention
to anything but the consensus of the WG, and I don't expect the WG to 
stuff signaling into the length field.

From: "Liu, Hong" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: TCP Mapping 
Date: Sat, 29 Jun 2002 19:06:09 -0500
Sender: [email-masked]

Eric,

The simple answer to both your questions at the end of your email is "yes"
and the "P" bit is set as shown in your diagram. 

The semantics of the "P" bit is subtlely different than yours (as I
interpret it). I envision that the "P" bit is set only for server-pushed
unsolicited data, _after_ the EPP session has been established. So it does
not apply to the <greeting> message sent by the server during session setup.
(See my response to your other email.)

The handling of server message queue is a tricky issue if the "server" and
the "client" engage in both "push" and "poll". But that is orthogonal to the
current topic. I would defer that discussion in a later time...

Thanks for coming up with the text to illustrate the case.

--Hong

-----Original Message-----
From: Eric Brunner-Williams in Portland Maine
[mailto:[email-masked]]
Sent: Saturday, June 29, 2002 1:46 PM
To: Liu, Hong
Cc: [email-masked]'; [email-masked]
Subject: Re: TCP Mapping 

Hong,

State-transition occurs in the registry,
the "server" initiates an event,
either
	o enqueueing a message for delivery via a registrar-initiated
	  instance of communication (which might have session semantics,
	  and which might be via tcp transport),
or
	o enqueueing a message for delivery via a registry-initiated
	  instance of communication (which might have session semantics,
          and which might be via tcp transport).

The first mechanism has found expression in the core drafts, the second
has not.

The proposal to put directionality (the initiator (the event)) into an
application PDU (your private pun on a header bit) puts directionality
discovery in the application.

Just to be sure I got your proposal, is this what you have in mind?
I've given lines that have changes "wedgies".

(from draft-ietf-provreg-epp-tcp-04.txt)
4. Datagram Format

  The data field of a TCP datagram MUST contain an EPP datagram.  The
  EPP datagram contains two fields: a 32-bit header that describes
>	the P-bit (is the message "PUSH" or "PULL")
> and
>	the 31 bits indicating the total length of the datagram,
  and the EPP XML instance.

  EPP Datagram Format (one tick mark represents one bit position):

     0                   1                   2                   3      
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |P                          Total Length                        |   
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         EPP XML Instance                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

> Push Bit (1 bit): When set, the message was not initiated by the 
> initiator of the connection.
> Total Length (31 bits): The total length of the EPP datagram measured
  in octets.  The octets contained in this field MUST be included in the
  total length calculation.

(end of excerpt from -04)

Is the octet in network byte order? Which bit is the P-bit?

Eric

Date: Sat, 29 Jun 2002 16:40:18 -0700 (PDT)
From: Rick Wesson <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
cc: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>, "Liu, Hong" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: TCP Mapping 
Sender: [email-masked]

I understand how push can work with beep, but why is it a requirement to
work with the tcp transport? also isn't push with smtp only require a
corrdinated mbox?

I'd prefer we not muck with the tcp transport and find a method to get
push to work with all transports or settle on using beep because it is
already prepaired for push style messaging.

-rick

On Sat, 29 Jun 2002, Hollenbeck, Scott wrote:

> > (from draft-ietf-provreg-epp-tcp-04.txt)
> > 4. Datagram Format
> >
> >   The data field of a TCP datagram MUST contain an EPP datagram.  The
> >   EPP datagram contains two fields: a 32-bit header that describes
> > >	the P-bit (is the message "PUSH" or "PULL")
>
> One big bug with this approach: putting _anything_ specific to this
> push/pull thing in the TCP draft is going to cause a problem with BEEP
> transport (or any transport other than streaming TCP) because the BEEP draft
> (for example) depends on standard BEEP profiles -- not the EPP TCP draft.
> If this gets put into the TCP draft, just how is it going to work with BEEP
> transport, email transport, or whatever other transport someone might define
> in the future?
>
> Hong has already said (and I'm paraphrasing) that a goal is to make the push
> thing work without BEEP.  Well, if it's going to work with any transport the
> mechanics can't be put into one of the transport drafts.  It has to be
> defined at a higher layer.
>
> FWIW, assuming this discussion carries past tonight I'm going to have to
> pick it up after 8 July; silence != concurrence.  It's time for a little
> R&R...
>
> -Scott-
>

To: "Hollenbeck, Scott" <[email-masked]>
cc: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>, "Liu, Hong" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: TCP Mapping 
Date: Sat, 29 Jun 2002 18:59:19 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

I'm still trying to figure out what the P-bit is in the <greeting>.

I wouldn't expect the editors of the WG beep draft to pay any attention
to anything but the consensus of the WG, and I don't expect the WG to 
stuff signaling into the length field.

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>, "Liu, Hong" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: TCP Mapping 
Date: Sat, 29 Jun 2002 17:47:10 -0400
Sender: [email-masked]

> (from draft-ietf-provreg-epp-tcp-04.txt)
> 4. Datagram Format
> 
>   The data field of a TCP datagram MUST contain an EPP datagram.  The
>   EPP datagram contains two fields: a 32-bit header that describes
> >	the P-bit (is the message "PUSH" or "PULL")

One big bug with this approach: putting _anything_ specific to this
push/pull thing in the TCP draft is going to cause a problem with BEEP
transport (or any transport other than streaming TCP) because the BEEP draft
(for example) depends on standard BEEP profiles -- not the EPP TCP draft.
If this gets put into the TCP draft, just how is it going to work with BEEP
transport, email transport, or whatever other transport someone might define
in the future?

Hong has already said (and I'm paraphrasing) that a goal is to make the push
thing work without BEEP.  Well, if it's going to work with any transport the
mechanics can't be put into one of the transport drafts.  It has to be
defined at a higher layer.

FWIW, assuming this discussion carries past tonight I'm going to have to
pick it up after 8 July; silence != concurrence.  It's time for a little
R&R...

-Scott-

To: "Liu, Hong" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: TCP Mapping 
Date: Sat, 29 Jun 2002 13:45:30 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Hong,

State-transition occurs in the registry,
the "server" initiates an event,
either
	o enqueueing a message for delivery via a registrar-initiated
	  instance of communication (which might have session semantics,
	  and which might be via tcp transport),
or
	o enqueueing a message for delivery via a registry-initiated
	  instance of communication (which might have session semantics,
          and which might be via tcp transport).

The first mechanism has found expression in the core drafts, the second
has not.

The proposal to put directionality (the initiator (the event)) into an
application PDU (your private pun on a header bit) puts directionality
discovery in the application.

Just to be sure I got your proposal, is this what you have in mind?
I've given lines that have changes "wedgies".

(from draft-ietf-provreg-epp-tcp-04.txt)
4. Datagram Format

  The data field of a TCP datagram MUST contain an EPP datagram.  The
  EPP datagram contains two fields: a 32-bit header that describes
>	the P-bit (is the message "PUSH" or "PULL")
> and
>	the 31 bits indicating the total length of the datagram,
  and the EPP XML instance.

  EPP Datagram Format (one tick mark represents one bit position):

     0                   1                   2                   3      
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |P                          Total Length                        |   
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         EPP XML Instance                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

> Push Bit (1 bit): When set, the message was not initiated by the 
> initiator of the connection.
> Total Length (31 bits): The total length of the EPP datagram measured
  in octets.  The octets contained in this field MUST be included in the
  total length calculation.

(end of excerpt from -04)

Is the octet in network byte order? Which bit is the P-bit?

Eric

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Liu, Hong'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: TCP Mapping 
Date: Sat, 29 Jun 2002 13:38:48 -0400
Sender: [email-masked]

> <HL> 
> So Eric, you are for Scott's proposal to use the <extension> 
> child element
> for defining the PUSH. Am I getting it right? Maybe you could 
> expand on this
> topic a bit more... Indeed, this is the most important choice 
> to make for
> our draft at the moment: how to tag a server-pushed message? 
> Other issues
> will follow once we get this straightened out.
> 
> If we adopt Scott's proposal, we may just define a new <push> 
> command, a
> response, and possibly a few new respond code. The new 
> command will be from
> the server to a client, which will break the base EPP model a 
> bit. Are we
> going in this direction?
> </HL>

It doesn't "break the base EPP model" at all.  The extension mechanisms
exist for this very purpose; they just need to be used properly.  One hint:
if you have to change _anything_ in an existing schema, you're not defining
an extension properly -- you're modifying part of the protocol.

-Scott-

From: "Liu, Hong" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: TCP Mapping 
Date: Sat, 29 Jun 2002 10:31:49 -0500
Sender: [email-masked]

I would like to stay focused on the issue I raised in this thread. If I was
not clear in previous emails, here we go again:

Issue: what would be the proper way to tag server-pushed messages from the
server?

Option 1: Use one bit in the Total Length header in the EPP datagram. This
is specific to the TCP transport mapping.

Option 2: Use <extension> child element of <epp>. This is transport neutral.

There may be other options, but those two are what I've seen so far.

I initially suggested option 1, and Scott has suggested option 2. I still
don't know what Eric's opinion is.

I want to hear what others on the list think.

Cheers,

--Hong

-----Original Message-----
From: Eric Brunner-Williams in Portland Maine
[mailto:[email-masked]]
Sent: Saturday, June 29, 2002 8:31 AM
To: Liu, Hong
Cc: [email-masked]'; [email-masked]
Subject: Re: TCP Mapping 

> That was my understanding. The issue is of general interest, and I would
> like to get more feedback on the list.

Which issue?

[snip...]
> So Eric, you are for Scott's proposal to use the <extension> child element
> for defining the PUSH.

I don't think I've seen it.

[snip...]

That said, the selection of tcp as transport has no relation to where
state is held, or which end of a stream was the stream's initiator.

These are (possibly gratuitous) design choices.

Eric

From: "Liu, Hong" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: TCP Mapping 
Date: Fri, 28 Jun 2002 22:20:20 -0500
Sender: [email-masked]

Scott, Eric,

Thanks to both for contributing. That is exactly what I am looking for, -:)

Please see my comments below, tagged with <HL/>. I don't know how to make my
outlook produced a unix-like response with embedded > for preceding email
text.

> Hong and I have already exchanged private messages on this topic.  I'll
> repeat what I said here.

So ... Did you decide mutually to re-conduct the prior private exchange
on an IETF list?

<HL>
That was my understanding. The issue is of general interest, and I would
like to get more feedback on the list.
</HL>

[snip...]

> Second, I'm very much against putting application-layer semantics into the
> layer above TCP -- it smells like a layering violation to me.  I
explicitly
> added an <extension> element as a child of the <epp> element to support
> adding features like data pushing from the "server" -- that's where I
think
> such extensions belong.  Plus, it's not wise to believe that EPP messages
> aren't likely to exceed a certain length based on experiences with domain
> name provisioning.  There may well be other operating environments where
all
> 32 bits (and maybe even more -- I gave some serious thought to a 64-bit
> length field in the header) are needed.  Being short-sighted now means
we're
> going to have issues in the future.

The proposal was vague, no delta of schema, no delta of text. That said, the
proposal revisited the Ethernet vs 802.3 overloading of type-as-length. 

No thanks.

<HL> 
So Eric, you are for Scott's proposal to use the <extension> child element
for defining the PUSH. Am I getting it right? Maybe you could expand on this
topic a bit more... Indeed, this is the most important choice to make for
our draft at the moment: how to tag a server-pushed message? Other issues
will follow once we get this straightened out.

If we adopt Scott's proposal, we may just define a new <push> command, a
response, and possibly a few new respond code. The new command will be from
the server to a client, which will break the base EPP model a bit. Are we
going in this direction?
</HL>

> Third, this whole pushing thing may be a better candidate for
implementation
> using BEEP.  If that's true, it doesn't belong in the TCP draft at all.

Actually, the peer- vs client- (event model) isn't dependent upon the
transport protocol (tcp or beep/{tcp,...}, but ... pragmatically, it doesn't
belong in any draft grounded on working group consensus -- unless most
everyone actually contributing have had a profound change of mind.

<HL> 
I don't think PUSH should be tied to BEEP exclusively either, though BEEP
makes it easier to implement PUSH. Since most of the EPP implementation
today are built upon TCP, we choose to tackle this problem with TCP in mind.
Ideally, we should try to separate the PUSH mechanics from the underlying
transport, as Eric said. Then we address how PUSH can be realized on top of
TCP, BEEP or other transports yet to be defined for EPP, just like what we
have done with the base EPP protocol. This may turn out to be the case in
our draft, but right now we use TCP as a starting point.
</HL>

> I've already started work on a draft document describing how to properly
> extend the protocol, and I expect -00 to be ready some time after the
> Yokohama meeting.  I think it will be far easier to deal with extension
> drafts _after_ we have the mechanics documented a bit better.

Good.

<HL> Yes, this certainly will help! </HL>

To: "Hollenbeck, Scott" <[email-masked]>
cc: "'Liu, Hong'" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: TCP Mapping 
Date: Fri, 28 Jun 2002 22:19:34 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> Hong and I have already exchanged private messages on this topic.  I'll
> repeat what I said here.

So ... Did you decide mutually to re-conduct the prior private exchange
on an IETF list?

> First, I do expect to have to edit the TCP draft slightly to address some
> comments I received from members of the IESG.  That won't happen until after
> IETF-54.

If the comments from non-contributor IESG reviewers are editorial in nature,
then the editorial delta is a non-event. If they are substantive in nature,
say replace tcp with sctp (example of substantive proposed change), then the
contributors need to determine if there is consensus to adopt any of the
changes.

> Second, I'm very much against putting application-layer semantics into the
> layer above TCP -- it smells like a layering violation to me.  I explicitly
> added an <extension> element as a child of the <epp> element to support
> adding features like data pushing from the "server" -- that's where I think
> such extensions belong.  Plus, it's not wise to believe that EPP messages
> aren't likely to exceed a certain length based on experiences with domain
> name provisioning.  There may well be other operating environments where all
> 32 bits (and maybe even more -- I gave some serious thought to a 64-bit
> length field in the header) are needed.  Being short-sighted now means we're
> going to have issues in the future.

The proposal was vague, no delta of schema, no delta of text. That said, the
proposal revisited the Ethernet vs 802.3 overloading of type-as-length. 

No thanks.

> Third, this whole pushing thing may be a better candidate for implementation
> using BEEP.  If that's true, it doesn't belong in the TCP draft at all.

Actually, the peer- vs client- (event model) isn't dependent upon the
transport protocol (tcp or beep/{tcp,...}, but ... pragmatically, it doesn't
belong in any draft grounded on working group consensus -- unless most
everyone actually contributing have had a profound change of mind.

> I've already started work on a draft document describing how to properly
> extend the protocol, and I expect -00 to be ready some time after the
> Yokohama meeting.  I think it will be far easier to deal with extension
> drafts _after_ we have the mechanics documented a bit better.

Good.

Cheers,
Eric
> -Scott-
> > From: Liu, Hong [mailto:[email-masked]]
> > Sent: Friday, June 28, 2002 5:55 PM
> > To: [email-masked]'
> > Subject: TCP Mapping
> > 
> > 
> > Scott,
> > 
> > I would like to know whether it is still possible to make 
> > changes to the TCP
> > mapping document at this point. We have been working on a 
> > draft for EPP TCP
> > PUSH extension, as we promised before. Sorry, we missed the 
> > -00 deadline
> > this time...
> > 
> > There are a number of ways to do it, but we find it the 
> > simplest to use the
> > Total Length header of the EPP datagram in the TCP mapping to 
> > differentiate
> > the server-pushed message from other messages. We are 
> > considering using only
> > the highest bit in the header, but maybe a better way is to 
> > reserve the
> > highest octet for other extensions. EPP messages do not need 
> > 2^32-1 octects,
> > 2^24-1 should be sufficiently large. What do you think?
> > 
> > We would also like to hear from you and others on the list about other
> > alternatives. Thanks!
> > 
> > --Hong
> > 

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Liu, Hong'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: TCP Mapping
Date: Fri, 28 Jun 2002 19:48:55 -0400
Sender: [email-masked]

Hong and I have already exchanged private messages on this topic.  I'll
repeat what I said here.

First, I do expect to have to edit the TCP draft slightly to address some
comments I received from members of the IESG.  That won't happen until after
IETF-54.

Second, I'm very much against putting application-layer semantics into the
layer above TCP -- it smells like a layering violation to me.  I explicitly
added an <extension> element as a child of the <epp> element to support
adding features like data pushing from the "server" -- that's where I think
such extensions belong.  Plus, it's not wise to believe that EPP messages
aren't likely to exceed a certain length based on experiences with domain
name provisioning.  There may well be other operating environments where all
32 bits (and maybe even more -- I gave some serious thought to a 64-bit
length field in the header) are needed.  Being short-sighted now means we're
going to have issues in the future.

Third, this whole pushing thing may be a better candidate for implementation
using BEEP.  If that's true, it doesn't belong in the TCP draft at all.

I've already started work on a draft document describing how to properly
extend the protocol, and I expect -00 to be ready some time after the
Yokohama meeting.  I think it will be far easier to deal with extension
drafts _after_ we have the mechanics documented a bit better.

-Scott-

> From: Liu, Hong [mailto:[email-masked]]
> Sent: Friday, June 28, 2002 5:55 PM
> To: [email-masked]'
> Subject: TCP Mapping
> 
> 
> Scott,
> 
> I would like to know whether it is still possible to make 
> changes to the TCP
> mapping document at this point. We have been working on a 
> draft for EPP TCP
> PUSH extension, as we promised before. Sorry, we missed the 
> -00 deadline
> this time...
> 
> There are a number of ways to do it, but we find it the 
> simplest to use the
> Total Length header of the EPP datagram in the TCP mapping to 
> differentiate
> the server-pushed message from other messages. We are 
> considering using only
> the highest bit in the header, but maybe a better way is to 
> reserve the
> highest octet for other extensions. EPP messages do not need 
> 2^32-1 octects,
> 2^24-1 should be sufficiently large. What do you think?
> 
> We would also like to hear from you and others on the list about other
> alternatives. Thanks!
> 
> --Hong
> 

From: "Liu, Hong" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: TCP Mapping
Date: Fri, 28 Jun 2002 16:54:48 -0500
Sender: [email-masked]

Scott,

I would like to know whether it is still possible to make changes to the TCP
mapping document at this point. We have been working on a draft for EPP TCP
PUSH extension, as we promised before. Sorry, we missed the -00 deadline
this time...

There are a number of ways to do it, but we find it the simplest to use the
Total Length header of the EPP datagram in the TCP mapping to differentiate
the server-pushed message from other messages. We are considering using only
the highest bit in the header, but maybe a better way is to reserve the
highest octet for other extensions. EPP messages do not need 2^32-1 octects,
2^24-1 should be sufficiently large. What do you think?

We would also like to hear from you and others on the list about other
alternatives. Thanks!

--Hong

To: Edward Lewis <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Document changes 
Date: Fri, 28 Jun 2002 16:03:29 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

These changes have my complete support.

Date: Fri, 28 Jun 2002 15:33:39 -0400
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: Document changes
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Changes to two of the drafts have been made.  Of course, if the WG 
objects to these changes, the chairs will listen to the objections 
and respond accordingly.

The Containers draft:
   http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-container-02.txt
is no longer a WG document.  (The document may reside on our website 
for a while though, just because of the mechanics to remove it will 
be delayed by the upcoming IETF.)  There has been little to no 
discussion about this draft, and there's been lukewarm support for 
the idea in the past.

The BEEP transport draft:
   http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-beep-02.txt
has a new set of editors.  Rick Wesson has volunteered to be an 
editor and will join Ning Zhang (as a continuing editor).

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

To: "Hollenbeck, Scott" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: Requirements Approved! 
Date: Fri, 28 Jun 2002 13:10:45 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

data mining at its best (rummaging in the iesg's drawers)

its been a longish hump since what, pittsburg?

congrats++

Date: Fri, 28 Jun 2002 11:33:19 -0400
To: "Hollenbeck, Scott" <[email-masked]>, "[email-masked]'" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: Requirements Approved!
Sender: [email-masked]

Somewhere, your chairs are smiling.

We all owe you one (so far)...

At 11:23 AM -0400 6/28/02, Hollenbeck, Scott wrote:
>While snooping through the archived 13 June IESG meeting minutes [1] I saw
>this:
>
>"10. The IESG approved publication of Generic Registry-Registrar
>Protocol Requirements <draft-ietf-provreg-grrp-reqs-06.txt> as an
>Informational RFC. Steve to send announcement."
>
>Woo hoo!  One down...
>
>-Scott-
>
>[1]
>http://www.ietf.org/iesg/iesg.2002-06-13

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Requirements Approved!
Date: Fri, 28 Jun 2002 11:23:44 -0400
Sender: [email-masked]

While snooping through the archived 13 June IESG meeting minutes [1] I saw
this:

"10. The IESG approved publication of Generic Registry-Registrar 
Protocol Requirements <draft-ietf-provreg-grrp-reqs-06.txt> as an 
Informational RFC. Steve to send announcement."

Woo hoo!  One down...

-Scott-

[1]
http://www.ietf.org/iesg/iesg.2002-06-13

From: Robert Burbidge <[email-masked]>
To: "Ietf-Provreg (E-mail)" <[email-masked]>
Subject: Idempotency
Date: Fri, 28 Jun 2002 10:04:08 +0100
Sender: [email-masked]

Thanks for all your replies, and for being so swift.

Rob Burbidge

Date: Fri, 28 Jun 2002 08:44:01 +0200
From: mixo <[email-masked]>
To: [email-masked]
Subject: Server implementation of EPP
Sender: [email-masked]

Does anyone have or kown of a working server implenmentation of EPP working
that I can download with the source?

To: Robert Burbidge <[email-masked]>
cc: "Ietf-Provreg (E-mail)" <[email-masked]>, [email-masked]
Subject: Re: Idempotency in EPP 
Date: Thu, 27 Jun 2002 16:19:07 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

The subject has come up a few times. You can look at the following:

03/02 "Hollenbeck, Scot  Updated EPP Specification with Examples<<This me
08/15 Mark Nottingham    PROVREG and XML Protocol<<[ I'm posting this mes
08/15 Rick H Wesson      Re: PROVREG and XML Protocol<<Mark, I looked at 
08/15 Mark Nottingham    Re: PROVREG and XML Protocol<<Rick, So, if the w
08/15 Rick H Wesson      Re: PROVREG and XML Protocol<<Mark, frankly when
09/05 Edward Lewis       Provreg minutes from London<<--============_-121
09/07 Jaap Akkerhuis     Provreg minutes from London, repost<<Yester>>
09/17 Sheer El-Showk     RE: interpretation of 'EPP idempotency'<<> Comma
09/18 Thomas Corte       RE: interpretation of 'EPP idempotency'<<Hello, 
09/18 "Hollenbeck, Scot  RE: interpretation of 'EPP idempotency'<<It's ap
09/18 Thomas Corte       RE: interpretation of 'EPP idempotency'<<Hello, 
09/18 "Hollenbeck, Scot  RE: interpretation of 'EPP idempotency'<<>-----O
09/18 Daniel Manley      Re: interpretation of 'EPP idempotency'<<Thomas,
09/18 "Hollenbeck, Scot  RE: interpretation of 'EPP idempotency'<<<Scott/
09/19 "Hollenbeck, Scot  Command Recovery (was RE: interpretation of 'EPP
09/19 Daniel Manley      Re: interpretation of 'EPP idempotency'<<Hollenb
09/19 Dave Crocker       Re: Command Recovery (was RE: interpretation of 
09/21 Sheer El-Showk     Re: interpretation of 'EPP idempotency'<<Hi Scot

Eric

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Robert Burbidge'" <[email-masked]>, "Ietf-Provreg (E-mail)" <[email-masked]>
Subject: RE: Idempotency in EPP
Date: Thu, 27 Jun 2002 10:53:27 -0400
Sender: [email-masked]

> Can I just get confirmation of a small point regarding idempotency?
> 
> My understanding of idempotency is that if the server 
> received two identical
> commands from a registrar then it should produce the same 
> results for each
> identical command. This is to ensure, for example, that if 
> the server is
> hanging off a session-less protocol that cannot guarantee 
> unique delivery of
> datagrams it's OK to action the same command twice. There 
> seems to be two
> aspects to this - that both commands have the same effect, 
> and that both
> commands return the same results to the client.
> 
> First question: Is that a correct interpretation?

No, it's not.  Idempotency isn't about ensuring that you get the same
results for each command, it's about ensuring that the net effect on
something (an object in the case of EPP) is the same.  If you send two
identical <create> commands and the first one succeeds, the second one is
going to fail, and the net effect after each is that there is a domain
object in some identical state.

> So for example, if registrar X creates domain Y with an appropriate
> <domain:create> command and follows that with an identical 
> epp command, both
> commands have the same effect (either both succeed or both 
> fail) and with
> exactly the same result epp response.
> 
> Second question: Is that example correct?

Again, no.  If we assume that the first command succeeds, the second command
MUST fail because the domain object can't be created twice.

> If the above are true, it follows for example that the EPP 
> server needs to
> keep a certain degree of history. For example if registrar X 
> deletes domain
> Y, and actions the same command again, the server needs to 
> remember that
> domain Y used to belong to registrar X in order have the same 
> effect and
> return identical responses each time. This is not necessarily 
> a problem; we
> do that kind of thing anyway.
> 
> If all the above are correct interpretations of idempotency in EPP, it
> follows that it also applies to changing passwords, so for example if
> registrar X changes its password from Y to Z, the server 
> needs to store not
> only the current password but also the previous password for 
> each registrar.
> 
> Can someone confirm or deny this interpretation for me? Thanks.

Having to maintain some sort of history as you described above implies
maintaining state information at the transaction level, which can get ugly.
As things are now each command is atomic and isolated so the server can act
on each command independently.

There's a book titled "Transaction Processing: Concepts and Techniques" by
Jim Gray and Andreas Reuter, ISBN 1-55860-190-2 [1], that describes
idempotency in great detail.  Anyone writing a transaction processing server
really ought to consider this book to be required reading.

-Scott-

[1] Info from amazon.com (sorry if the URL gets broken across two lines):
http://www.amazon.com/exec/obidos/ASIN/1558601902/qid=1025189383/sr=2-1/ref=
sr_2_1/002-0024993-1270444

From: Robert Burbidge <[email-masked]>
To: "Ietf-Provreg (E-mail)" <[email-masked]>
Subject: Idempotency in EPP
Date: Thu, 27 Jun 2002 15:11:56 +0100
Sender: [email-masked]

Can I just get confirmation of a small point regarding idempotency?

My understanding of idempotency is that if the server received two identical
commands from a registrar then it should produce the same results for each
identical command. This is to ensure, for example, that if the server is
hanging off a session-less protocol that cannot guarantee unique delivery of
datagrams it's OK to action the same command twice. There seems to be two
aspects to this - that both commands have the same effect, and that both
commands return the same results to the client.

First question: Is that a correct interpretation?

So for example, if registrar X creates domain Y with an appropriate
<domain:create> command and follows that with an identical epp command, both
commands have the same effect (either both succeed or both fail) and with
exactly the same result epp response.

Second question: Is that example correct?

If the above are true, it follows for example that the EPP server needs to
keep a certain degree of history. For example if registrar X deletes domain
Y, and actions the same command again, the server needs to remember that
domain Y used to belong to registrar X in order have the same effect and
return identical responses each time. This is not necessarily a problem; we
do that kind of thing anyway.

If all the above are correct interpretations of idempotency in EPP, it
follows that it also applies to changing passwords, so for example if
registrar X changes its password from Y to Z, the server needs to store not
only the current password but also the previous password for each registrar.

Can someone confirm or deny this interpretation for me? Thanks.

Rob Burbidge

From: "Hollenbeck, Scott" <[email-masked]>
To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= <[email-masked]>
Cc: Randy Bush <[email-masked]>, Ned Freed <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: draft-ietf-provreg-epp-06.txt
Date: Mon, 24 Jun 2002 08:13:56 -0400
Importance: high
Sender: [email-masked]

Patrik,

Since you said it was OK to respond to this message to the provreg mailing
list so that everyone can see your questions and concerns, here we go.
Thanks for the feedback.

To the WG:
Patrik, Randy, Ned, and I have been talking about Patrik's questions a bit
over this past weekend.  One topic raised concerned allowing clients and
servers to send/receive multiple commands/responses in a single TCP
read/write operation.  Folks who've been following the WG for a while may
well remember that the earliest protocol drafts were written such that each
TCP read/write operation moved a single protocol command or response.
During the course of WG discussion the WG decided that this wasn't
acceptable from a performance perspective, and so the drafts were changed
such that multiple commands or responses could be moved in a single TCP
read/write.  Some of the IESG reviewers have said that they have concerns
(command synchronization and filling pipelines resulting in deadlock were
specifically mentioned) with this approach.  My use of the term
"asynchronous" (which can imply timing delays between commands and
responses) to describe this operational form might also be misleading, so
that might need to be changed.

Questions and my responses below.

-Scott-

> From: Patrik Fältström [mailto:[email-masked]]
> Sent: Friday, June 21, 2002 9:43 PM
> To: Scott Hollenbeck
> Cc: Jaap Akkerhuis; Edward Lewis; Randy Bush; Ned Freed
> Subject: draft-ietf-provreg-epp-06.txt
> 
> 
> I have a number of things which I must ask you about.
> 
> The overall protocol seems to be stable and sound, but, I can 
> not from the
> document understand how the asynchronous handling of commands is made.
> 
> Here are a number of statments, and I want to know if they 
> are true or not.
> It _might_ be that clearfications should be made -- if you think other
> people are as confused as I after reading the document.
> 
> (1) It seems that the client is always master. The server can 
> not send any
> message to the client except as a response to a client command.

This is true per the first paragraph in section 2:

"Protected using lower-layer security protocols, clients exchange
identification, authentication, and option information, and then engage in a
series of client-initiated command-response exchanges".

There was a lengthy WG debate on allowing the server to push unsolicited
data to the client, but we eventually agreed to go with the simpler model in
the base protocol, and that unsolicited server pushing can be defined as a
protocol extension if needed.

> (2) When the client send a command, it is always tagged with 
> a clientID, so
> the client later on understand what command a response belong to.

Client transaction identifiers are OPTIONAL per section 2.4, so commands
aren't always tagged.  Admittedly this might not help the client associate a
response with a given command, but it's done this way because of the
tracking requirements imposed by the <status> command (described below).
The vast majority of the commands issued by a client are query commands that
don't really need to be logged for future <status> checking, so we allow the
client to leave off the client transaction identifier for commands that it
doesn't care to check for status in the future.

I'd be OK with making client transaction identifiers mandatory iff we can
ditch the <status> command.  Given that there is no harm in retrying any
command, the need to see if a command was received and processed seems
dubious to me -- if the client isn't sure that a command was received and
processed, all they have to do is try it again.

> (3) A server must not acknowledge that it has received a 
> command. Should it
> not always do that? I.e. that the command was sound, syntax 
> correct etc.

A server MUST always provide a response to a command.  The response confirms
that the command was received and processed.  It can also return information
requested by the client depending on the command itself.

> (4) All requests from clients (except commands which handle the status
> queue itself) are executed in the server in order.

Yes, but I'm not sure of what you mean by "the status queue".  Each and
every command is processed in order, and the server MUST produce a response
for each command.  There is a <status> command that can be used to confirm
that some earlier command was received and processed, but it gets executed
just like any other command.  There are server queues for client service
messages that can be retrieved using the <poll> command, but these queues
have nothing to do with command execution order.

> (5) Any response from a server can include responses from any client
> command which have resulted in positive or negative responses 
> since the
> last "chance" the server had to send responses. I.e. a message from a
> server can include zero or more response objects.

A server MUST produce an immediate response for each command.  The TCP
transport draft currently allows the client to move multiple commands in one
TCP write operation (which the server can retrieve in one TCP read), and the
server can return multiple responses with one TCP write (which the client
can retrieve in one TCP read).  The earliest TCP transport draft document
allowed only one command or response per TCP operation, but WG discussion
led to the behavior you see described now.  There should never be an empty
response.

> (6) A client can poll the server, and explicitly fetch result objects.

Not exactly.  The client can poll the server, but what they get are queued
service messages (such as "we're going down for maintenance at 0200UTC").
Results are only returned in response to a command, and they can't be
retrieved again at a later date.  However, a client _can_ determine if an
earlier command was received and processed (see response to your next
question) using the <status> command.  If they don't like the answer they
get from the <status> command they can retry the original command, and an
appropriate response will be generated.  The <status> command depends on
archived client transaction identifiers to work properly, so support for
this command can put a significant archival burden on a high-volume server.

> (7) A client can check explicitly what the status of a 
> command is. My view
> is that result can be either (a) still queued, (b) executing 
> or (c) done
> (and the result is in the result queue) + of course substates.

Again, not exactly.  A client can check the status of a command that
completed in the past, but this is limited to "was it received and
processed".  There is no concept of delayed responses or pending execution.
Each command is processed in real time, producing an immediate response.

However, some commands can have back-end coordination dependencies that
delay completion of the requested action.  For example, a <delete> operation
might not actually remove an object immediately, though the server will
respond to the client immediately to note that the command has been received
and processed.  Likewise, a <transfer> command might require approval from a
second client to be fully completed; in between the time that the command is
received and the second client acts the transfer action is indeed "pending".
In this case, there is a query command to check on the status of the
transfer, and when the transfer is completed both clients are notified (the
active client receives a response to their command, the passive client gets
a message added to their service message queue for retrieval via the <poll>
command.

> (8) The term "Available" is a bit weird. You seem to show 
> that "available"
> means that the object does _NOT_ exists, which for me means 
> that it is not
> available. Should it be that way? If you ask if an object is 
> available, and
> the result is "no", then for me it is ok to do a "registration" and
> allocate the object.

Hmm, I though I'd cleaned up all of the "available" language.  I do see some
in section 2.8.2.1; that needs to be cleaned up.  I tried to change all of
those "available" descriptions to "can be provisioned or not".  A positive
response means "yes, it can be provisioned".  A negative response means "no,
it can't be provisioned".  Looks like I missed at least one spot.

> Now, personally I think the following is a bit weird (part 
> from 8 which I
> talk about above):
> 
> Regarding (3) I think the server should _always_ send an ack 
> back. Either
> with a result immediately, or a message that the command is queued.

Agreed that the server should always respond to a command.

> If (5) is true, why is (6) needed?

(6) isn't needed as you described it.  Hopefully my clarification for (5)
explains why.

> When doing (7), can a result object be included, or must the 
> client always
> do a poll?

I hope it's now clear that the <poll> command doesn't return command results
as the <status> command also doesn't return command results.  It returns a
simple yes/no type of response to let the client know if some older command
was received and processed by the server.  If the client is unsure of the
results for any command (say because of a network or server failure or poor
client record keeping), they can always try the command again.  If the
second attempt "works", the proper results are returned.  If the second
attempt fails, the first attempt succeeded and the results can typically be
retrieved using one of the query commands.

> My view is that it should help if
> 
> [A] You had some ascii-art which show a state diagram for 
> actual commands

OK, this would make sense in the transport document since the state machine
tends to depend on the type of transport protocol.  The state machine for a
connection-oriented protocol would likely be a little different than the
state machine for a connectionless transport protocol.

> [B] You divided more clearly between the different kind of commands:
>    - Session management, negotiation of extensions etc
>        Login / Logout ...
>    - Status/command management
>        Poll / Status ...
>    - Actual commands
>        Create / Transfer / Delete ...

That's certainly easy to do.

> [C] You change what you mean by "available" (or change term 
> from available
> to something else)

Definitely agreed.  This came up in the WG some time ago, and any existing
confusing language is still there only because I missed it during WG review.

> The questions I have are so substantial that I want to have 
> them answered
> before I send the document to IESG, so unfortunately this set 
> of documents
> will slip to after Yokohama. The requirements document will 
> be discussed
> next week though.
> 
> I have absolutely no problem if you bring up these issues on 
> the mailing
> list, and say I have questions. This so the wg see that something is
> happening.
> 
>     paf

Thanks -- we're all looking forward to progress!

-Scott-

To: Bruce Tonkin <[email-masked]>
cc: "Jordyn A. Buchanan" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: EPP implementations (what versions?) 
Date: Wed, 12 Jun 2002 07:16:04 -0400
From: Eric Brunner <[email-masked]>
Sender: [email-masked]

Bruce,

Could you share the syntax of the .au extension? TiA.

Eric

From: Bruce Tonkin <[email-masked]>
To: "Jordyn A. Buchanan" <[email-masked]>
Cc: [email-masked]
Subject: RE: EPP implementations (what versions?)
Date: Wed, 12 Jun 2002 12:25:26 +1000
Sender: [email-masked]

Hello Jordyn,

AusRegistry have been implementing a new registry for ".au" using the latest
versions of the drafts:
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-06.txt
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-contact-04.txt
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-domain-04.txt
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-host-04.txt
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-tcp-04.txt

There are also some ".au" specific extensions that have been added for
policy information, in a similar way to the information added for ".us".

Regards,
Bruce Tonkin

> From: Jordyn A. Buchanan [mailto:[email-masked]]
> Sent: Tuesday, June 11, 2002 7:48 AM
> To: [email-masked]
> Subject: EPP implementations (what versions?)
> 
> 
> I'm curious to find out what versions of the EPP drafts 
> various registries
> have implemented.
> 
> We've implemented 06/04 for our ccTLD registry customers.  
> Has anyone else?
> Are there any two registry operators implementing a single 
> version of the
> drafts?
> 
> Thanks,
> 
> Jordyn  
> 

From: "Liu, Hong" <[email-masked]>
To: [email-masked]
Subject: RE: EPP implementations (what versions?)
Date: Tue, 11 Jun 2002 12:59:21 -0500
Sender: [email-masked]

We implemented EPP 04/02.

--Hong

-----Original Message-----
From: Jordyn A. Buchanan [mailto:[email-masked]]
Sent: Monday, June 10, 2002 5:48 PM
To: [email-masked]
Subject: EPP implementations (what versions?)

I'm curious to find out what versions of the EPP drafts various registries
have implemented.

We've implemented 06/04 for our ccTLD registry customers.  Has anyone else?
Are there any two registry operators implementing a single version of the
drafts?

Thanks,

Jordyn  

Date: Tue, 11 Jun 2002 16:13:10 +0200
From: Patrick <[email-masked]>
To: [email-masked]
Subject: Re: EPP implementations (what versions?)
Organization: Gandi
Sender: [email-masked]

On Tue, Jun 11, 2002 at 09:40:28AM -0400, Eric Brunner took time to write:
> November has IETF-55 in Atlanta, and ICANN usually has a MdR meet in November,

FYI,
If nothing changes, there will be no MdR for ICANN this year.
Only Shanghaï in October.

Patrick.

To: Joel Rowbottom <[email-masked]>
cc: "Jordyn A. Buchanan" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: EPP implementations (what versions?) 
Date: Tue, 11 Jun 2002 09:40:28 -0400
From: Eric Brunner <[email-masked]>
Sender: [email-masked]

> Yep, we have too. We haven't got users registering domain names "in anger" 
> yet though.

Thanks for the chuckle. "Anger" fits the trademark and speculator weenies
to a "T".

November has IETF-55 in Atlanta, and ICANN usually has a MdR meet in November,
so one, or both, are possible for attending implementors to interoperate on
their common 06/04, and any extensions that have two implementations (or are
ready for show and tell).

Eric

Date: Tue, 11 Jun 2002 11:10:58 +0100
To: "Jordyn A. Buchanan" <[email-masked]>, <[email-masked]>
From: Joel Rowbottom <[email-masked]>
Subject: Re: EPP implementations (what versions?)
Sender: [email-masked]

At 17:47 10/06/2002 -0400, Jordyn A. Buchanan wrote:

>I'm curious to find out what versions of the EPP drafts various registries 
>have implemented. We've implemented 06/04 for our ccTLD registry 
>customers.  Has anyone else?

Yep, we have too. We haven't got users registering domain names "in anger" 
yet though.

--
  Joel Rowbottom, http://www.centralnic.com - CTO and self-confessed Unix geek
  <t> +44 (0)20 7751 9000   <f> +44 (0)20 7736 9253   <e> [email-masked]
  One good thing about repeating your mistakes is that you know when to cringe.
  # Note: Contents may not necessarily represent the opinions of CentralNic.

Date: Tue, 11 Jun 2002 12:05:00 +0200
From: Patrick <[email-masked]>
To: [email-masked]
Subject: Re: EPP implementations (what versions?)
Organization: Gandi
Sender: [email-masked]

On Mon, Jun 10, 2002 at 05:47:45PM -0400, Jordyn A. Buchanan took time to write:
> I'm curious to find out what versions of the EPP drafts various registries
> have implemented.

AFAIK:
Afilias (.INFO) : 2
Neulevel (.BIZ) : 4
GNR     (.NAME) : 5

> We've implemented 06/04 for our ccTLD registry customers.  Has anyone else?

We are upgrading our software to handle new drafts (as used by GNR),
which means the same code interfaces with 3 Registries, with 3
distinct draft level. The application using this software does not
see any difference in the API.

This code will be made open source in a few days/weeks (as soon as we
start using it with GNR, to check that it is running correctly).

It is made of object-oriented Perl modules. The idea is close to the
one of DBI/DBD: being as much as possible independant from the
protocol (we have RRP and 3 version of EPP), the transport (only TLS
and soon TCP for now), and the Registry (its policies).

It will be available at http://open.gandi.net/

Sorry for the plug, but it may be of interest to others ;-)

When it will be available I will announce it there.

Patrick.

From: "Ram Mohan" <[email-masked]>
To: "Jordyn A. Buchanan" <[email-masked]>, <[email-masked]>
Subject: Re: EPP implementations (what versions?)
Date: Tue, 11 Jun 2002 05:23:07 -0400
Organization: Afilias
Sender: [email-masked]

we're moving to 06 from 02

-ram
----- Original Message -----
From: "Jordyn A. Buchanan" <[email-masked]>
To: <[email-masked]>
Sent: Monday, June 10, 2002 5:47 PM
Subject: EPP implementations (what versions?)

> I'm curious to find out what versions of the EPP drafts various registries
> have implemented.
>
> We've implemented 06/04 for our ccTLD registry customers.  Has anyone
else?
> Are there any two registry operators implementing a single version of the
> drafts?
>
> Thanks,
>
> Jordyn
>

To: Daniel Manley <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: EPP implementations (what versions?) 
Date: Mon, 10 Jun 2002 19:55:17 -0400
From: Eric Brunner <[email-masked]>
Sender: [email-masked]

Dan,

02 refers to transport (beep).

Eric

Date: Mon, 10 Jun 2002 18:48:55 -0400
From: Daniel Manley <[email-masked]>
To: [email-masked]
Subject: Re: EPP implementations (what versions?)
Sender: [email-masked]

You've implemented EPPs 06, 04 and 02, Eric? (assuming that's what your 
short cryptic response means)  For who?  Or are you saying that you've 
implemented EPP 06 with Domain/Contact/Host 04 and BEEP/Containers 02? 
 Again, for my own curiosity, for who?

Dan

Eric Brunner wrote:

>06/04/02.

To: "Jordyn A. Buchanan" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: EPP implementations (what versions?) 
Date: Mon, 10 Jun 2002 18:29:09 -0400
From: Eric Brunner <[email-masked]>
Sender: [email-masked]

06/04/02.

Date: Mon, 10 Jun 2002 17:47:45 -0400
Subject: EPP implementations (what versions?)
From: "Jordyn A. Buchanan" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

I'm curious to find out what versions of the EPP drafts various registries
have implemented.

We've implemented 06/04 for our ccTLD registry customers.  Has anyone else?
Are there any two registry operators implementing a single version of the
drafts?

Thanks,

Jordyn  

Date: Wed, 5 Jun 2002 15:22:19 -0700 (PDT)
From: Rick Wesson <[email-masked]>
To: Edward Lewis <[email-masked]>
cc: Daniel Manley <[email-masked]>, <[email-masked]>
Subject: Re: Yokohama?
Sender: [email-masked]

Ed,

I totally agree that there is no need for a meeting in Yokohama. I'll
attempt to read the recent documents over the next.

-rick

On Wed, 5 Jun 2002, Edward Lewis wrote:

> At 5:49 PM -0400 6/5/02, Daniel Manley wrote:
> >So what's the scoop?  Are we anticipating having a meeting in
> >Yokohama? What's >the timing on the feedback from the IESG?  Is it
> >worth meeting for the recent >draft releases?
>
> My mind is changeable, but looks like there won't be a meeting
> scheduled.  The state is that 6 documents are in front of the IESG.
> There's no predicting when any of them will move, as 5 of them are
> waiting for referenced documents to advance.  We do have two
> refreshed documents and a volunteer for a third (which I need to dig
> up).
>
> The two new documents haven't generated any discussion on the list.
> Without at least some activity on the list, there's no reason to have
> a meeting - because the list is what defines the WG, not the meeting.
>
> So, unless there are some threads soon, there isn't justification to
> reserve a time slot.  And the agenda closes in about 2 weeks, if I'm
> not mistaken.  I won't mind putting in for a time slot - the sense of
> the list to date is that it isn't worth it.
>
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                          +1-703-227-9854
> ARIN Research Engineer
>

Date: Wed, 5 Jun 2002 17:59:31 -0400
To: Daniel Manley <[email-masked]>, [email-masked]
From: Edward Lewis <[email-masked]>
Subject: Re: Yokohama?
Sender: [email-masked]

At 5:49 PM -0400 6/5/02, Daniel Manley wrote:
>So what's the scoop?  Are we anticipating having a meeting in 
>Yokohama? What's >the timing on the feedback from the IESG?  Is it 
>worth meeting for the recent >draft releases?

My mind is changeable, but looks like there won't be a meeting 
scheduled.  The state is that 6 documents are in front of the IESG. 
There's no predicting when any of them will move, as 5 of them are 
waiting for referenced documents to advance.  We do have two 
refreshed documents and a volunteer for a third (which I need to dig 
up).

The two new documents haven't generated any discussion on the list. 
Without at least some activity on the list, there's no reason to have 
a meeting - because the list is what defines the WG, not the meeting.

So, unless there are some threads soon, there isn't justification to 
reserve a time slot.  And the agenda closes in about 2 weeks, if I'm 
not mistaken.  I won't mind putting in for a time slot - the sense of 
the list to date is that it isn't worth it.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

Date: Wed, 05 Jun 2002 17:49:42 -0400
From: Daniel Manley <[email-masked]>
To: [email-masked]
Subject: Yokohama?
Sender: [email-masked]

So what's the scoop?  Are we anticipating having a meeting in Yokohama? 
 What's the timing on the feedback from the IESG?  Is it worth meeting 
for the recent draft releases?

Dan

Hollenbeck, Scott wrote:

>Ed,
>
>The first draft of EPP-BEEP has been out for some time.  A better question
>relates to when it might be updated.
>
>At the Minneapolis meeting Hong mentioned that the original authors of the
>containers draft had decided to not pursue it further.  Have no editors been
>found, or have the original authors changed their minds?
>
>Has anyone stepped up to write an EPP-over-email I-D?
>
>I see little reason to meet in the absence of feedback from them IESG on the
>documents that have been through WG and IETF last calls, and the lack of
>activity on the other drafts.
>
>-Scott-
>
>  
>
>>From: Ed Lewis [mailto:[email-masked]]
>>Sent: Wednesday, May 22, 2002 3:18 PM
>>To: [email-masked]
>>Subject: Lack of activity in the group...
>>
>>
>>
>>Eyeing the IETF meeting in Yokohama, its about time to decide 
>>on whether
>>we should meet.  It would be good to have a meeting there to at least
>>bring EPP to the region, but there's no sense "forcing" a meeting.
>>
>>There's been a lack of activity in the group.  We have three
>>milestones to meet this month:
>> MAY 02 Second draft of Containers
>> MAY 02 First draft of EPP over BEEP
>> MAY 02 First draft of EPP over SMTP
>>
>>I'd like to hear WG comments on meeting/not meeting.
>>    
>>