push

[Rick Wesson <[e-mail]>]

Hong,

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

thanks,

-rick





Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5UFvGo2017429 for <[e-mail]>; Sun, 30 Jun 2002 17:57:16 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g5UFvGDB017428 for ietf-provreg-outgoing; Sun, 30 Jun 2002 17:57:16 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bean.ar.com ([66.123.187.68]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5UFvEo2017423 for <[e-mail]>; Sun, 30 Jun 2002 17:57:15 +0200 (MEST)
Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.2/8.12.0) with ESMTP id g5UFv6Th016721; Sun, 30 Jun 2002 08:57:06 -0700 (PDT)
Date: Sun, 30 Jun 2002 08:57:10 -0700 (PDT)
From: Rick Wesson <[e-mail]>
To: "Liu, Hong" <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>
Subject: RE: TCP Mapping 
In-Reply-To: <5E42C1C85C5D064A947CF92FADE6D82E084006@STNTEXCH1>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

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




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5UFHqo2017238 for <[e-mail]>; Sun, 30 Jun 2002 17:17:52 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g5UFHqSS017237 for ietf-provreg-outgoing; Sun, 30 Jun 2002 17:17:52 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5UFHpo2017232 for <[e-mail]>; Sun, 30 Jun 2002 17:17:51 +0200 (MEST)
Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g5UFHot01079 for <[e-mail]>; Sun, 30 Jun 2002 10:17:50 -0500
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <NJXKGGFQ>; Sun, 30 Jun 2002 10:17:45 -0500
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E084006@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: TCP Mapping 
Date: Sun, 30 Jun 2002 10:16:42 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
Sent: Sunday, June 30, 2002 1:57 AM
To: Liu, Hong
Cc: '[e-mail]'
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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5UEcGo2017080 for <[e-mail]>; Sun, 30 Jun 2002 16:38:16 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g5UEcGAe017079 for ietf-provreg-outgoing; Sun, 30 Jun 2002 16:38:16 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5UEcFo2017074 for <[e-mail]>; Sun, 30 Jun 2002 16:38:15 +0200 (MEST)
Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g5UEcEt32201 for <[e-mail]>; Sun, 30 Jun 2002 09:38:14 -0500
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <NJXKGF8V>; Sun, 30 Jun 2002 09:38:09 -0500
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E084005@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: TCP Mapping 
Date: Sun, 30 Jun 2002 09:37:04 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
Sent: Sunday, June 30, 2002 7:06 AM
To: Liu, Hong
Cc: '[e-mail]'; [e-mail]
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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5UB7Zo2016558 for <[e-mail]>; Sun, 30 Jun 2002 13:07:35 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g5UB7Z43016557 for ietf-provreg-outgoing; Sun, 30 Jun 2002 13:07:35 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5UB7Xo2016552 for <[e-mail]>; Sun, 30 Jun 2002 13:07:34 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.4/8.11.6) with ESMTP id g5UB6ABZ024539; Sun, 30 Jun 2002 07:06:10 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Liu, Hong" <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: TCP Mapping 
In-Reply-To: Your message of "Sat, 29 Jun 2002 20:27:09 CDT." <5E42C1C85C5D064A947CF92FADE6D82E084004@STNTEXCH1> 
Date: Sun, 30 Jun 2002 07:06:10 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5U5vQo2015720 for <[e-mail]>; Sun, 30 Jun 2002 07:57:26 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g5U5vQnc015719 for ietf-provreg-outgoing; Sun, 30 Jun 2002 07:57:26 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bean.ar.com ([66.123.187.68]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5U5vOo2015714 for <[e-mail]>; Sun, 30 Jun 2002 07:57:25 +0200 (MEST)
Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.2/8.12.0) with ESMTP id g5U5vGTh016611; Sat, 29 Jun 2002 22:57:16 -0700 (PDT)
Date: Sat, 29 Jun 2002 22:57:20 -0700 (PDT)
From: Rick Wesson <[e-mail]>
To: "Liu, Hong" <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>
Subject: RE: TCP Mapping 
In-Reply-To: <5E42C1C85C5D064A947CF92FADE6D82E084004@STNTEXCH1>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

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




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5U1TVo2014869 for <[e-mail]>; Sun, 30 Jun 2002 03:29:31 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g5U1TVSS014868 for ietf-provreg-outgoing; Sun, 30 Jun 2002 03:29:31 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5U1TTo2014863 for <[e-mail]>; Sun, 30 Jun 2002 03:29:30 +0200 (MEST)
Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g5U1SX220444 for <[e-mail]>; Sat, 29 Jun 2002 21:29:13 -0400
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <NJXKG13P>; Sat, 29 Jun 2002 20:28:11 -0500
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E084004@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: TCP Mapping 
Date: Sat, 29 Jun 2002 20:27:09 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
Sent: Saturday, June 29, 2002 7:40 PM
To: Hollenbeck, Scott
Cc: 'Eric Brunner-Williams in Portland Maine'; Liu, Hong;
'[e-mail]'
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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5U19vo2013910 for <[e-mail]>; Sun, 30 Jun 2002 03:09:57 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g5U19v36013909 for ietf-provreg-outgoing; Sun, 30 Jun 2002 03:09:57 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5U19uo2013904 for <[e-mail]>; Sun, 30 Jun 2002 03:09:56 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id VAA05302; Sat, 29 Jun 2002 21:10:28 -0400 (EDT)
Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <NJVFV0YP>; Sat, 29 Jun 2002 21:09:50 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Liu, Hong'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: TCP Mapping 
Date: Sat, 29 Jun 2002 21:09:43 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5U0dqo2013784 for <[e-mail]>; Sun, 30 Jun 2002 02:39:52 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g5U0dqGl013783 for ietf-provreg-outgoing; Sun, 30 Jun 2002 02:39:52 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5U0dpo2013778 for <[e-mail]>; Sun, 30 Jun 2002 02:39:51 +0200 (MEST)
Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g5U0dot15103 for <[e-mail]>; Sat, 29 Jun 2002 19:39:50 -0500
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <NJXKG1L8>; Sat, 29 Jun 2002 19:39:45 -0500
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E084003@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: TCP Mapping 
Date: Sat, 29 Jun 2002 19:38:42 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
Sent: Saturday, June 29, 2002 5:47 PM
To: 'Eric Brunner-Williams in Portland Maine'; Liu, Hong
Cc: '[e-mail]'
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-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5U0Hoo2013687 for <[e-mail]>; Sun, 30 Jun 2002 02:17:50 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g5U0HocN013686 for ietf-provreg-outgoing; Sun, 30 Jun 2002 02:17:50 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5U0Hno2013681 for <[e-mail]>; Sun, 30 Jun 2002 02:17:49 +0200 (MEST)
Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g5U0H8219627 for <[e-mail]>; Sat, 29 Jun 2002 20:17:32 -0400
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <NJXKG1LF>; Sat, 29 Jun 2002 19:16:47 -0500
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E084002@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: TCP Mapping 
Date: Sat, 29 Jun 2002 19:15:43 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
Sent: Saturday, June 29, 2002 6:59 PM
To: Hollenbeck, Scott
Cc: 'Eric Brunner-Williams in Portland Maine'; Liu, Hong;
'[e-mail]'; [e-mail]
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.


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5U08Vo2013656 for <[e-mail]>; Sun, 30 Jun 2002 02:08:31 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g5U08Vhi013655 for ietf-provreg-outgoing; Sun, 30 Jun 2002 02:08:31 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5U08Uo2013650 for <[e-mail]>; Sun, 30 Jun 2002 02:08:30 +0200 (MEST)
Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g5U07X219538 for <[e-mail]>; Sat, 29 Jun 2002 20:08:13 -0400
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <NJXKG1KZ>; Sat, 29 Jun 2002 19:07:12 -0500
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E084001@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: TCP Mapping 
Date: Sat, 29 Jun 2002 19:06:09 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
Sent: Saturday, June 29, 2002 1:46 PM
To: Liu, Hong
Cc: '[e-mail]'; [e-mail]
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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5TNeMo2013515 for <[e-mail]>; Sun, 30 Jun 2002 01:40:22 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g5TNeMKB013514 for ietf-provreg-outgoing; Sun, 30 Jun 2002 01:40:22 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bean.ar.com ([66.123.187.68]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5TNeLo2013509 for <[e-mail]>; Sun, 30 Jun 2002 01:40:21 +0200 (MEST)
Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.2/8.12.0) with ESMTP id g5TNeETh008544; Sat, 29 Jun 2002 16:40:14 -0700 (PDT)
Date: Sat, 29 Jun 2002 16:40:18 -0700 (PDT)
From: Rick Wesson <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
cc: "'Eric Brunner-Williams in Portland Maine'" <[e-mail]>, "Liu, Hong" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: TCP Mapping 
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5TN0co2013230 for <[e-mail]>; Sun, 30 Jun 2002 01:00:38 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g5TN0cEE013229 for ietf-provreg-outgoing; Sun, 30 Jun 2002 01:00:38 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5TN0ao2013224 for <[e-mail]>; Sun, 30 Jun 2002 01:00:37 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.4/8.11.6) with ESMTP id g5TMxJBZ022800; Sat, 29 Jun 2002 18:59:20 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
cc: "'Eric Brunner-Williams in Portland Maine'" <[e-mail]>, "Liu, Hong" <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: TCP Mapping 
In-Reply-To: Your message of "Sat, 29 Jun 2002 17:47:10 EDT." <[e-mail]> 
Date: Sat, 29 Jun 2002 18:59:19 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

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.



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5TLlOo2012962 for <[e-mail]>; Sat, 29 Jun 2002 23:47:24 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g5TLlOUu012961 for ietf-provreg-outgoing; Sat, 29 Jun 2002 23:47:24 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5TLlMo2012956 for <[e-mail]>; Sat, 29 Jun 2002 23:47:22 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id RAA03577; Sat, 29 Jun 2002 17:47:49 -0400 (EDT)
Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id <M6WRTPWZ>; Sat, 29 Jun 2002 17:47:11 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Eric Brunner-Williams in Portland Maine'" <[e-mail]>, "Liu, Hong" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: TCP Mapping 
Date: Sat, 29 Jun 2002 17:47:10 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5THkjo2012201 for <[e-mail]>; Sat, 29 Jun 2002 19:46:45 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g5THkjjW012200 for ietf-provreg-outgoing; Sat, 29 Jun 2002 19:46:45 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5THkio2012195 for <[e-mail]>; Sat, 29 Jun 2002 19:46:44 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.4/8.11.6) with ESMTP id g5THjUBZ022154; Sat, 29 Jun 2002 13:45:30 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Liu, Hong" <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: TCP Mapping 
In-Reply-To: Your message of "Sat, 29 Jun 2002 10:31:49 CDT." <5E42C1C85C5D064A947CF92FADE6D82E083FFF@STNTEXCH1> 
Date: Sat, 29 Jun 2002 13:45:30 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5THcvo2012175 for <[e-mail]>; Sat, 29 Jun 2002 19:38:57 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g5THcv6w012174 for ietf-provreg-outgoing; Sat, 29 Jun 2002 19:38:57 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5THcuo2012169 for <[e-mail]>; Sat, 29 Jun 2002 19:38:56 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id NAA00810; Sat, 29 Jun 2002 13:39:27 -0400 (EDT)
Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id <M6WRT3MW>; Sat, 29 Jun 2002 13:38:49 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Liu, Hong'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: TCP Mapping 
Date: Sat, 29 Jun 2002 13:38:48 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5TFX1o2011763 for <[e-mail]>; Sat, 29 Jun 2002 17:33:01 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g5TFX14e011762 for ietf-provreg-outgoing; Sat, 29 Jun 2002 17:33:01 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5TFWvo2011757 for <[e-mail]>; Sat, 29 Jun 2002 17:33:00 +0200 (MEST)
Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g5TFWut05799 for <[e-mail]>; Sat, 29 Jun 2002 10:32:57 -0500
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <NJXKGD2V>; Sat, 29 Jun 2002 10:32:51 -0500
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E083FFF@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: TCP Mapping 
Date: Sat, 29 Jun 2002 10:31:49 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
Sent: Saturday, June 29, 2002 8:31 AM
To: Liu, Hong
Cc: '[e-mail]'; [e-mail]
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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5T3LUo2009397 for <[e-mail]>; Sat, 29 Jun 2002 05:21:30 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g5T3LU9W009396 for ietf-provreg-outgoing; Sat, 29 Jun 2002 05:21:30 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5T3LTo2009391 for <[e-mail]>; Sat, 29 Jun 2002 05:21:29 +0200 (MEST)
Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g5T3LRB04219 for <[e-mail]>; Fri, 28 Jun 2002 23:21:27 -0400
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <NJXKGB9J>; Fri, 28 Jun 2002 22:21:22 -0500
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E083FFE@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: TCP Mapping 
Date: Fri, 28 Jun 2002 22:20:20 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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>



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5T2Kio2009165 for <[e-mail]>; Sat, 29 Jun 2002 04:20:44 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g5T2KiW0009164 for ietf-provreg-outgoing; Sat, 29 Jun 2002 04:20:44 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5T2Kgo2009154 for <[e-mail]>; Sat, 29 Jun 2002 04:20:43 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.4/8.11.6) with ESMTP id g5T2JYBZ017466; Fri, 28 Jun 2002 22:19:34 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
cc: "'Liu, Hong'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: TCP Mapping 
In-Reply-To: Your message of "Fri, 28 Jun 2002 19:48:55 EDT." <[e-mail]> 
Date: Fri, 28 Jun 2002 22:19:34 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> 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-
> 
> > -----Original Message-----
> > From: Liu, Hong [mailto:[e-mail]]
> > Sent: Friday, June 28, 2002 5:55 PM
> > To: '[e-mail]'
> > 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
> > 


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5SNn4o2007739 for <[e-mail]>; Sat, 29 Jun 2002 01:49:04 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g5SNn4Ec007738 for ietf-provreg-outgoing; Sat, 29 Jun 2002 01:49:04 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5SNn2o2007733 for <[e-mail]>; Sat, 29 Jun 2002 01:49:03 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id TAA17225; Fri, 28 Jun 2002 19:49:34 -0400 (EDT)
Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id <M6WRTGHV>; Fri, 28 Jun 2002 19:48:56 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Liu, Hong'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: TCP Mapping
Date: Fri, 28 Jun 2002 19:48:55 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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-

> -----Original Message-----
> From: Liu, Hong [mailto:[e-mail]]
> Sent: Friday, June 28, 2002 5:55 PM
> To: '[e-mail]'
> 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
> 


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5SLu4o2007385 for <[e-mail]>; Fri, 28 Jun 2002 23:56:04 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g5SLu4Hr007384 for ietf-provreg-outgoing; Fri, 28 Jun 2002 23:56:04 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5SLu3o2007379 for <[e-mail]>; Fri, 28 Jun 2002 23:56:03 +0200 (MEST)
Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g5SLu2t18879 for <[e-mail]>; Fri, 28 Jun 2002 16:56:02 -0500
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <NJXKGAWK>; Fri, 28 Jun 2002 16:55:57 -0500
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E083FFD@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: TCP Mapping
Date: Fri, 28 Jun 2002 16:54:48 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5SK5no2006912 for <[e-mail]>; Fri, 28 Jun 2002 22:05:49 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g5SK5nvR006911 for ietf-provreg-outgoing; Fri, 28 Jun 2002 22:05:49 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5SK5lo2006906 for <[e-mail]>; Fri, 28 Jun 2002 22:05:48 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.4/8.11.6) with ESMTP id g5SK3TBZ016693; Fri, 28 Jun 2002 16:03:29 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Edward Lewis <[e-mail]>
cc: [e-mail], [e-mail], [e-mail]
Subject: Re: Document changes 
In-Reply-To: Your message of "Fri, 28 Jun 2002 15:33:39 EDT." <a05111b05b94268a96851@[192.149.252.225]> 
Date: Fri, 28 Jun 2002 16:03:29 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

These changes have my complete support.


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5SJXmo2006718 for <[e-mail]>; Fri, 28 Jun 2002 21:33:48 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g5SJXmlZ006717 for ietf-provreg-outgoing; Fri, 28 Jun 2002 21:33:48 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5SJXlo2006712 for <[e-mail]>; Fri, 28 Jun 2002 21:33:47 +0200 (MEST)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id PAA08516; Fri, 28 Jun 2002 15:33:42 -0400 (EDT)
Received: from [192.149.252.225] (lead.arin.net.arin.net [192.149.252.225]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id PAA29386; Fri, 28 Jun 2002 15:33:42 -0400 (EDT)
Mime-Version: 1.0
X-Sender: edlewis@ops
Message-Id: <a05111b05b94268a96851@[192.149.252.225]>
Date: Fri, 28 Jun 2002 15:33:39 -0400
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: Document changes
Cc: [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

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                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5SHBko2005877 for <[e-mail]>; Fri, 28 Jun 2002 19:11:46 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g5SHBk6k005876 for ietf-provreg-outgoing; Fri, 28 Jun 2002 19:11:46 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5SHBjo2005871 for <[e-mail]>; Fri, 28 Jun 2002 19:11:45 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.4/8.11.6) with ESMTP id g5SHAjBZ016119; Fri, 28 Jun 2002 13:10:45 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: Requirements Approved! 
In-Reply-To: Your message of "Fri, 28 Jun 2002 11:23:44 EDT." <[e-mail]> 
Date: Fri, 28 Jun 2002 13:10:45 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

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

its been a longish hump since what, pittsburg?

congrats++


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5SFaLo2005199 for <[e-mail]>; Fri, 28 Jun 2002 17:36:21 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g5SFaLZf005198 for ietf-provreg-outgoing; Fri, 28 Jun 2002 17:36:21 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5SFaKo2005193 for <[e-mail]>; Fri, 28 Jun 2002 17:36:20 +0200 (MEST)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id LAA13379; Fri, 28 Jun 2002 11:36:19 -0400 (EDT)
Received: from [192.149.252.225] (lead.arin.net.arin.net [192.149.252.225]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA09176; Fri, 28 Jun 2002 11:36:18 -0400 (EDT)
Mime-Version: 1.0
X-Sender: edlewis@ops
Message-Id: <a05111b01b94232179e14@[192.149.252.225]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Fri, 28 Jun 2002 11:33:19 -0400
To: "Hollenbeck, Scott" <[e-mail]>, "'[e-mail]'" <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: Re: Requirements Approved!
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

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                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5SFNlo2005109 for <[e-mail]>; Fri, 28 Jun 2002 17:23:47 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g5SFNlW0005108 for ietf-provreg-outgoing; Fri, 28 Jun 2002 17:23:47 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5SFNko2005103 for <[e-mail]>; Fri, 28 Jun 2002 17:23:46 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id LAA21749 for <[e-mail]>; Fri, 28 Jun 2002 11:24:22 -0400 (EDT)
Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id <M6WRSZX8>; Fri, 28 Jun 2002 11:23:45 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Requirements Approved!
Date: Fri, 28 Jun 2002 11:23:44 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5S94Go2002153 for <[e-mail]>; Fri, 28 Jun 2002 11:04:16 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g5S94GPV002152 for ietf-provreg-outgoing; Fri, 28 Jun 2002 11:04:16 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from popintmanex.poptel.org.uk (popintmanex.poptel.org.uk [213.55.9.22]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5S94Eo2002147 for <[e-mail]>; Fri, 28 Jun 2002 11:04:15 +0200 (MEST)
Received: by exchange.poptel.net with Internet Mail Service (5.5.2653.19) id <NWQK73FA>; Fri, 28 Jun 2002 10:04:07 +0100
Message-ID: <[e-mail]>
From: Robert Burbidge <[e-mail]>
To: "Ietf-Provreg (E-mail)" <[e-mail]>
Subject: Idempotency
Date: Fri, 28 Jun 2002 10:04:08 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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

Rob Burbidge



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5S6j3o2001508 for <[e-mail]>; Fri, 28 Jun 2002 08:45:03 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g5S6j3ND001507 for ietf-provreg-outgoing; Fri, 28 Jun 2002 08:45:03 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from beth.uniforum.org.za (beth.coza.net.za [206.223.136.193]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5S6iuo2001502 for <[e-mail]>; Fri, 28 Jun 2002 08:45:00 +0200 (MEST)
Received: from beth.uniforum.org.za (mixo.coza.net.za [206.223.136.225]) by beth.uniforum.org.za (8.11.6/8.11.2) with ESMTP id g5S6imj05417 for <[e-mail]>; Fri, 28 Jun 2002 08:44:52 +0200
Message-ID: <[e-mail]>
Date: Fri, 28 Jun 2002 08:44:01 +0200
From: mixo <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012
X-Accept-Language: en-us
MIME-Version: 1.0
To: [e-mail]
Subject: Server implementation of EPP
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5RKJuo2027140 for <[e-mail]>; Thu, 27 Jun 2002 22:19:57 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g5RKJuAI027139 for ietf-provreg-outgoing; Thu, 27 Jun 2002 22:19:56 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5RKJto2027134 for <[e-mail]>; Thu, 27 Jun 2002 22:19:55 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.4/8.11.6) with ESMTP id g5RKJ7BZ012955; Thu, 27 Jun 2002 16:19:07 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Robert Burbidge <[e-mail]>
cc: "Ietf-Provreg (E-mail)" <[e-mail]>, [e-mail]
Subject: Re: Idempotency in EPP 
In-Reply-To: Your message of "Thu, 27 Jun 2002 15:11:56 BST." <[e-mail]> 
Date: Thu, 27 Jun 2002 16:19:07 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5RErWo2024403 for <[e-mail]>; Thu, 27 Jun 2002 16:53:32 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g5RErWMf024402 for ietf-provreg-outgoing; Thu, 27 Jun 2002 16:53:32 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5RErVo2024397 for <[e-mail]>; Thu, 27 Jun 2002 16:53:31 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id KAA01725; Thu, 27 Jun 2002 10:54:06 -0400 (EDT)
Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id <M6WRR6GZ>; Thu, 27 Jun 2002 10:53:29 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Robert Burbidge'" <[e-mail]>, "Ietf-Provreg (E-mail)" <[e-mail]>
Subject: RE: Idempotency in EPP
Date: Thu, 27 Jun 2002 10:53:27 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> 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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5REC2o2024010 for <[e-mail]>; Thu, 27 Jun 2002 16:12:02 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g5REC22j024009 for ietf-provreg-outgoing; Thu, 27 Jun 2002 16:12:02 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from popintmanex.poptel.org.uk (popintmanex.poptel.org.uk [213.55.9.22]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5REC1o2024004 for <[e-mail]>; Thu, 27 Jun 2002 16:12:01 +0200 (MEST)
Received: by exchange.poptel.net with Internet Mail Service (5.5.2653.19) id <NWQK7M3T>; Thu, 27 Jun 2002 15:11:57 +0100
Message-ID: <[e-mail]>
From: Robert Burbidge <[e-mail]>
To: "Ietf-Provreg (E-mail)" <[e-mail]>
Subject: Idempotency in EPP
Date: Thu, 27 Jun 2002 15:11:56 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.4/8.12.4) with ESMTP id g5OCEF8C014162 for <[e-mail]>; Mon, 24 Jun 2002 14:14:15 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.4/8.12.4/Submit) id g5OCEFtM014161 for ietf-provreg-outgoing; Mon, 24 Jun 2002 14:14:15 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.4/8.12.4) with ESMTP id g5OCED8C014156 for <[e-mail]>; Mon, 24 Jun 2002 14:14:14 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id IAA02225; Mon, 24 Jun 2002 08:14:35 -0400 (EDT)
Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id <M6WR3YDG>; Mon, 24 Jun 2002 08:13:58 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= <[e-mail]>
Cc: Randy Bush <[e-mail]>, Ned Freed <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: draft-ietf-provreg-epp-06.txt
Date: Mon, 24 Jun 2002 08:13:56 -0400
Importance: high
X-Priority: 1
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id g5OCEE8C014157
Sender: [e-mail]
Precedence: bulk

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-

> -----Original Message-----
> From: Patrik Fältström [mailto:[e-mail]]
> 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-



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.4/8.12.4) with ESMTP id g5CBGA8C010930 for <[e-mail]>; Wed, 12 Jun 2002 13:16:10 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.4/8.12.4/Submit) id g5CBGAMA010929 for ietf-provreg-outgoing; Wed, 12 Jun 2002 13:16:10 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from TheWorld.com (pcls2.std.com [199.172.62.104]) by nic.cafax.se (8.12.4/8.12.4) with ESMTP id g5CBG78C010924 for <[e-mail]>; Wed, 12 Jun 2002 13:16:08 +0200 (MEST)
Received: from world.std.com ([e-mail] [199.172.62.5]) by TheWorld.com (8.9.3/8.9.3) with ESMTP id HAA21408; Wed, 12 Jun 2002 07:16:05 -0400
Received: from localhost (brunner@localhost) by world.std.com (8.9.3/8.9.3) with SMTP id HAA06953; Wed, 12 Jun 2002 07:16:04 -0400 (EDT)
Message-Id: <[e-mail]>
X-Authentication-Warning: world.std.com: brunner@localhost didn't use HELO protocol
To: Bruce Tonkin <[e-mail]>
cc: "Jordyn A. Buchanan" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: EPP implementations (what versions?) 
In-reply-to: Your message of "Wed, 12 Jun 2002 12:25:26 EDT." <[e-mail]> 
Date: Wed, 12 Jun 2002 07:16:04 -0400
From: Eric Brunner <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Bruce,

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

Eric


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.4/8.12.4) with ESMTP id g5C2Pa8C008566 for <[e-mail]>; Wed, 12 Jun 2002 04:25:36 +0200 (MEST)
Received: by nic.cafax.se (8.12.4/8.12.4/Submit) id g5C2Pa2R008565 for ietf-provreg-outgoing; Wed, 12 Jun 2002 04:25:36 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from leda.mit (king22.MelbourneIT.com.au [203.31.198.22]) by nic.cafax.se (8.12.4/8.12.4) with ESMTP id g5C2PX8C008560 for <[e-mail]>; Wed, 12 Jun 2002 04:25:34 +0200 (MEST)
Received: from mercury.mit (mercury.mit [192.168.80.36]) by leda.mit (8.9.3/8.9.3) with ESMTP id MAA08902; Wed, 12 Jun 2002 12:25:27 +1000
Received: by mercury.mit with Internet Mail Service (5.5.2653.19) id <FPPGB1RT>; Wed, 12 Jun 2002 12:25:26 +1000
Message-ID: <[e-mail]>
From: Bruce Tonkin <[e-mail]>
To: "Jordyn A. Buchanan" <[e-mail]>
Cc: [e-mail]
Subject: RE: EPP implementations (what versions?)
Date: Wed, 12 Jun 2002 12:25:26 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="ISO-8859-1"
Sender: [e-mail]
Precedence: bulk

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



> -----Original Message-----
> From: Jordyn A. Buchanan [mailto:[e-mail]]
> Sent: Tuesday, June 11, 2002 7:48 AM
> To: [e-mail]
> 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  
> 


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.4/8.12.4) with ESMTP id g5BI0H8C005165 for <[e-mail]>; Tue, 11 Jun 2002 20:00:17 +0200 (MEST)
Received: by nic.cafax.se (8.12.4/8.12.4/Submit) id g5BI0Hmt005164 for ietf-provreg-outgoing; Tue, 11 Jun 2002 20:00:17 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by nic.cafax.se (8.12.4/8.12.4) with ESMTP id g5BI0F8C005159 for <[e-mail]>; Tue, 11 Jun 2002 20:00:16 +0200 (MEST)
Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g5BI0BB32439 for <[e-mail]>; Tue, 11 Jun 2002 14:00:14 -0400
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <J25ZYA6M>; Tue, 11 Jun 2002 13:00:06 -0500
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E083F95@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: [e-mail]
Subject: RE: EPP implementations (what versions?)
Date: Tue, 11 Jun 2002 12:59:21 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

We implemented EPP 04/02.

--Hong

-----Original Message-----
From: Jordyn A. Buchanan [mailto:[e-mail]]
Sent: Monday, June 10, 2002 5:48 PM
To: [e-mail]
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  


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.4/8.12.4) with ESMTP id g5BEDB8C003783 for <[e-mail]>; Tue, 11 Jun 2002 16:13:11 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.4/8.12.4/Submit) id g5BEDBqE003782 for ietf-provreg-outgoing; Tue, 11 Jun 2002 16:13:11 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nohope.patoche.org (nohope.patoche.org [80.67.173.199]) by nic.cafax.se (8.12.4/8.12.4) with ESMTP id g5BEDA8C003777 for <[e-mail]>; Tue, 11 Jun 2002 16:13:11 +0200 (MEST)
Received: from nohope.patoche.org (localhost.gandi.net [127.0.0.1]) by nohope.patoche.org (8.12.1/8.12.1/Debian -5) with ESMTP id g5BEDAk1032442 for <[e-mail]>; Tue, 11 Jun 2002 16:13:10 +0200
Received: (from patrick@localhost) by nohope.patoche.org (8.12.1/8.12.1/Debian -5) id g5BEDAIn032440 for [e-mail]; Tue, 11 Jun 2002 16:13:10 +0200
Date: Tue, 11 Jun 2002 16:13:10 +0200
From: Patrick <[e-mail]>
To: [e-mail]
Subject: Re: EPP implementations (what versions?)
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.24i
X-PGP-KeyID: A241FB6B
X-Request-PGP: http://www.keyserver.net:11371/pks/lookup?op=vindex&search=0xA241FB6B
Organization: Gandi
Sender: [e-mail]
Precedence: bulk

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.


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.4/8.12.4) with ESMTP id g5BDea8C003515 for <[e-mail]>; Tue, 11 Jun 2002 15:40:36 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.4/8.12.4/Submit) id g5BDeZs9003514 for ietf-provreg-outgoing; Tue, 11 Jun 2002 15:40:35 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from TheWorld.com (pcls4.std.com [199.172.62.106]) by nic.cafax.se (8.12.4/8.12.4) with ESMTP id g5BDeY8C003509 for <[e-mail]>; Tue, 11 Jun 2002 15:40:34 +0200 (MEST)
Received: from world.std.com ([e-mail] [199.172.62.5]) by TheWorld.com (8.9.3/8.9.3) with ESMTP id JAA22498; Tue, 11 Jun 2002 09:40:30 -0400
Received: from localhost (brunner@localhost) by world.std.com (8.9.3/8.9.3) with SMTP id JAA21828; Tue, 11 Jun 2002 09:40:29 -0400 (EDT)
Message-Id: <[e-mail]>
X-Authentication-Warning: world.std.com: brunner@localhost didn't use HELO protocol
To: Joel Rowbottom <[e-mail]>
cc: "Jordyn A. Buchanan" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: EPP implementations (what versions?) 
In-Reply-To: Your message of "Tue, 11 Jun 2002 11:10:58 BST." <[e-mail]> 
Date: Tue, 11 Jun 2002 09:40:28 -0400
From: Eric Brunner <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> 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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.4/8.12.4) with ESMTP id g5BABB8C002394 for <[e-mail]>; Tue, 11 Jun 2002 12:11:11 +0200 (MEST)
Received: by nic.cafax.se (8.12.4/8.12.4/Submit) id g5BABA1t002393 for ietf-provreg-outgoing; Tue, 11 Jun 2002 12:11:10 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from courgette.jml.net (courgette.jml.net [195.149.39.78]) by nic.cafax.se (8.12.4/8.12.4) with ESMTP id g5BABA8C002388 for <[e-mail]>; Tue, 11 Jun 2002 12:11:10 +0200 (MEST)
Received: from [212.18.224.150] (helo=fluffy.centralnic.com) by courgette.jml.net with esmtp (Exim 3.22 #1) id 17HicY-0005rB-00; Tue, 11 Jun 2002 11:11:26 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 11 Jun 2002 11:10:58 +0100
To: "Jordyn A. Buchanan" <[e-mail]>, <[e-mail]>
From: Joel Rowbottom <[e-mail]>
Subject: Re: EPP implementations (what versions?)
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk

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> [phone]   <f> [phone]   <e> [e-mail]
  One good thing about repeating your mistakes is that you know when to cringe.
  # Note: Contents may not necessarily represent the opinions of CentralNic.



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.4/8.12.4) with ESMTP id g5BA538C002342 for <[e-mail]>; Tue, 11 Jun 2002 12:05:03 +0200 (MEST)
Received: by nic.cafax.se (8.12.4/8.12.4/Submit) id g5BA53QR002341 for ietf-provreg-outgoing; Tue, 11 Jun 2002 12:05:03 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nohope.patoche.org (nohope.patoche.org [80.67.173.199]) by nic.cafax.se (8.12.4/8.12.4) with ESMTP id g5BA528C002336 for <[e-mail]>; Tue, 11 Jun 2002 12:05:03 +0200 (MEST)
Received: from nohope.patoche.org (localhost.gandi.net [127.0.0.1]) by nohope.patoche.org (8.12.1/8.12.1/Debian -5) with ESMTP id g5BA50k1026391; Tue, 11 Jun 2002 12:05:00 +0200
Received: (from patrick@localhost) by nohope.patoche.org (8.12.1/8.12.1/Debian -5) id g5BA50tn026389; Tue, 11 Jun 2002 12:05:00 +0200
Date: Tue, 11 Jun 2002 12:05:00 +0200
From: Patrick <[e-mail]>
To: [e-mail]
Subject: Re: EPP implementations (what versions?)
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.24i
X-PGP-KeyID: A241FB6B
X-Request-PGP: http://www.keyserver.net:11371/pks/lookup?op=vindex&search=0xA241FB6B
Organization: Gandi
Sender: [e-mail]
Precedence: bulk

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.


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.4/8.12.4) with ESMTP id g5B9gL8C002234 for <[e-mail]>; Tue, 11 Jun 2002 11:42:21 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.4/8.12.4/Submit) id g5B9gLGB002233 for ietf-provreg-outgoing; Tue, 11 Jun 2002 11:42:21 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ns01.afilias.info (ns01.afilias.info [66.45.25.225]) by nic.cafax.se (8.12.4/8.12.4) with ESMTP id g5B9gK8C002228 for <[e-mail]>; Tue, 11 Jun 2002 11:42:20 +0200 (MEST)
Received: from RAMLAPTOP (ATHM-216-217-xxx-252.newedgenetworks.com [216.217.55.252]) (authenticated) by ns01.afilias.info (8.11.2/8.11.2) with ESMTP id g5B9gGX12519; Tue, 11 Jun 2002 05:42:16 -0400
Message-ID: <00ec01c2112c$61e53640$[e-mail]>
From: "Ram Mohan" <[e-mail]>
To: "Jordyn A. Buchanan" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: EPP implementations (what versions?)
Date: Tue, 11 Jun 2002 05:23:07 -0400
Organization: Afilias
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk

we're moving to 06 from 02

-ram
----- Original Message -----
From: "Jordyn A. Buchanan" <[e-mail]>
To: <[e-mail]>
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
>



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.4/8.12.4) with ESMTP id g5ANtK8C028995 for <[e-mail]>; Tue, 11 Jun 2002 01:55:20 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.4/8.12.4/Submit) id g5ANtKLY028994 for ietf-provreg-outgoing; Tue, 11 Jun 2002 01:55:20 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from TheWorld.com (pcls4.std.com [199.172.62.106]) by nic.cafax.se (8.12.4/8.12.4) with ESMTP id g5ANtJ8C028989 for <[e-mail]>; Tue, 11 Jun 2002 01:55:19 +0200 (MEST)
Received: from world.std.com ([e-mail] [199.172.62.5]) by TheWorld.com (8.9.3/8.9.3) with ESMTP id TAA04711; Mon, 10 Jun 2002 19:55:18 -0400
Received: from localhost (brunner@localhost) by world.std.com (8.9.3/8.9.3) with SMTP id TAA14548; Mon, 10 Jun 2002 19:55:18 -0400 (EDT)
Message-Id: <[e-mail]>
X-Authentication-Warning: world.std.com: brunner@localhost didn't use HELO protocol
To: Daniel Manley <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: EPP implementations (what versions?) 
In-reply-to: Your message of "Mon, 10 Jun 2002 18:48:55 EDT." <[e-mail]> 
Date: Mon, 10 Jun 2002 19:55:17 -0400
From: Eric Brunner <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Dan,

02 refers to transport (beep).

Eric


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.4/8.12.4) with ESMTP id g5AMnW8C028729 for <[e-mail]>; Tue, 11 Jun 2002 00:49:32 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.4/8.12.4/Submit) id g5AMnWUQ028728 for ietf-provreg-outgoing; Tue, 11 Jun 2002 00:49:32 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp-send.myrealbox.com (smtp-send.myrealbox.com [192.108.102.143]) by nic.cafax.se (8.12.4/8.12.4) with ESMTP id g5AMnV8C028723 for <[e-mail]>; Tue, 11 Jun 2002 00:49:31 +0200 (MEST)
Received: from tucows.com [e-mail] [24.157.140.141] by smtp-send.myrealbox.com with NetMail SMTP Agent $Revision:   3.9  $ on Novell NetWare via secured & encrypted transport (TLS); Mon, 10 Jun 2002 16:49:20 -0600
Message-ID: <[e-mail]>
Date: Mon, 10 Jun 2002 18:48:55 -0400
From: Daniel Manley <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020607
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: EPP implementations (what versions?)
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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





Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.4/8.12.4) with ESMTP id g5AMTC8C028629 for <[e-mail]>; Tue, 11 Jun 2002 00:29:12 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.4/8.12.4/Submit) id g5AMTCYc028628 for ietf-provreg-outgoing; Tue, 11 Jun 2002 00:29:12 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from TheWorld.com (pcls2.std.com [199.172.62.104]) by nic.cafax.se (8.12.4/8.12.4) with ESMTP id g5AMTB8C028623 for <[e-mail]>; Tue, 11 Jun 2002 00:29:11 +0200 (MEST)
Received: from world.std.com ([e-mail] [199.172.62.5]) by TheWorld.com (8.9.3/8.9.3) with ESMTP id SAA28233; Mon, 10 Jun 2002 18:29:09 -0400
Received: from localhost (brunner@localhost) by world.std.com (8.9.3/8.9.3) with SMTP id SAA12268; Mon, 10 Jun 2002 18:29:09 -0400 (EDT)
Message-Id: <[e-mail]>
X-Authentication-Warning: world.std.com: brunner@localhost didn't use HELO protocol
To: "Jordyn A. Buchanan" <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: EPP implementations (what versions?) 
In-reply-to: Your message of "Mon, 10 Jun 2002 17:47:45 EDT." <[e-mail]> 
Date: Mon, 10 Jun 2002 18:29:09 -0400
From: Eric Brunner <[e-mail]>
Sender: [e-mail]
Precedence: bulk

06/04/02.


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.4/8.12.4) with ESMTP id g5ALlf8C028393 for <[e-mail]>; Mon, 10 Jun 2002 23:47:41 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.4/8.12.4/Submit) id g5ALlfqA028392 for ietf-provreg-outgoing; Mon, 10 Jun 2002 23:47:41 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from total.confusion.net (buchanan.nac.net [209.123.121.74]) by nic.cafax.se (8.12.4/8.12.4) with ESMTP id g5ALld8C028387 for <[e-mail]>; Mon, 10 Jun 2002 23:47:40 +0200 (MEST)
Received: from [216.21.238.2] (helo=[10.10.20.157]) by total.confusion.net with asmtp (Exim 3.34 #1) id 17HX0X-0003VH-00 for [e-mail]; Mon, 10 Jun 2002 17:47:25 -0400
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Mon, 10 Jun 2002 17:47:45 -0400
Subject: EPP implementations (what versions?)
From: "Jordyn A. Buchanan" <[e-mail]>
To: <[e-mail]>
Message-ID: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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  



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.4/8.12.4) with ESMTP id g55MMt8C024463 for <[e-mail]>; Thu, 6 Jun 2002 00:22:55 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.4/8.12.4/Submit) id g55MMtDd024462 for ietf-provreg-outgoing; Thu, 6 Jun 2002 00:22:55 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bean.ar.com ([66.123.187.68]) by nic.cafax.se (8.12.4/8.12.4) with ESMTP id g55MMs8C024457 for <[e-mail]>; Thu, 6 Jun 2002 00:22:54 +0200 (MEST)
Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.2/8.12.0) with ESMTP id g55MMI9m001731; Wed, 5 Jun 2002 15:22:18 -0700 (PDT)
Date: Wed, 5 Jun 2002 15:22:19 -0700 (PDT)
From: Rick Wesson <[e-mail]>
To: Edward Lewis <[e-mail]>
cc: Daniel Manley <[e-mail]>, <[e-mail]>
Subject: Re: Yokohama?
In-Reply-To: <a05111b00b92438bf544d@[192.149.252.235]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

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                                          [phone]
> ARIN Research Engineer
>



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.4/8.12.4) with ESMTP id g55Lxb8C024336 for <[e-mail]>; Wed, 5 Jun 2002 23:59:37 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.4/8.12.4/Submit) id g55LxaN5024335 for ietf-provreg-outgoing; Wed, 5 Jun 2002 23:59:36 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by nic.cafax.se (8.12.4/8.12.4) with ESMTP id g55LxZ8C024330 for <[e-mail]>; Wed, 5 Jun 2002 23:59:36 +0200 (MEST)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id RAA11021; Wed, 5 Jun 2002 17:59:34 -0400 (EDT)
Received: from [192.149.252.235] (lead.arin.net.arin.net [192.149.252.235]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id RAA13480; Wed, 5 Jun 2002 17:59:34 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <a05111b00b92438bf544d@[192.149.252.235]>
In-Reply-To: <[e-mail]>
References: <[e-mail]6> <[e-mail]>
Date: Wed, 5 Jun 2002 17:59:31 -0400
To: Daniel Manley <[e-mail]>, [e-mail]
From: Edward Lewis <[e-mail]>
Subject: Re: Yokohama?
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

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                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.4/8.12.4) with ESMTP id g55Lnq8C024298 for <[e-mail]>; Wed, 5 Jun 2002 23:49:52 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.4/8.12.4/Submit) id g55LnpgI024297 for ietf-provreg-outgoing; Wed, 5 Jun 2002 23:49:51 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp-send.myrealbox.com (smtp-send.myrealbox.com [192.108.102.143]) by nic.cafax.se (8.12.4/8.12.4) with ESMTP id g55Lno8C024292 for <[e-mail]>; Wed, 5 Jun 2002 23:49:50 +0200 (MEST)
Received: from tucows.com [e-mail] [24.43.153.39] by smtp-send.myrealbox.com with NetMail SMTP Agent $Revision:   3.9  $ on Novell NetWare via secured & encrypted transport (TLS); Wed, 05 Jun 2002 15:49:44 -0600
Message-ID: <[e-mail]>
Date: Wed, 05 Jun 2002 17:49:42 -0400
From: Daniel Manley <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020513 Netscape/7.0b1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Yokohama?
References: <[e-mail]6>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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-
>
>  
>
>>-----Original Message-----
>>From: Ed Lewis [mailto:[e-mail]]
>>Sent: Wednesday, May 22, 2002 3:18 PM
>>To: [e-mail]
>>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.
>>    
>>