Subject: RE: I-D on Uniform Treatment of Pending Action Notification in EP P

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 30 Jul 2002 14:27:09 -0400

>  http://epp-ver-04.sourceforge.net/IETF/draft-liu-epp-pa-notify-00.txt

[snip]

> This is a strawman proposal intended to summarize the recent 
> discussions on
> related topics and to bring more focused discussion to bring 
> this issue to a
> conlusion. Your comments are greatly appreciated.

I like the way the document explores the issues of service message
notification, and it provides rational arguments (except for one*) to
explain why a service message convention might be useful.  I do have two
specific concerns:

- * Statements like "current EPP core specifications do not address the
notification messaging in a generic way" are incorrect and misleading.  If
anything, the current <msg> element is _too_ generic -- there are no
specific formatting "rules" for what constitutes a service message.  That's
about as generic as things can get.  This sort of statement would be
accurate if reworded to something like "to provide maximum flexibility for
server operators, current EPP core specifications do not define specific
service message formats".

- The proposed <paNotify> element doesn't have to be added to the core
schema at all.  Everything that's being suggested can be done within the
current (well, the soon-to-be-modified) <msg> element.  To hack Hong's
example a bit, here's how what's being proposed can be done within the scope
of the changes we've already talked about on the list:

  S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
  S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
  S:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  S:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
  S:     epp-1.0.xsd">
  S:  <response>
  S:    <result code="1301">
  S:      <msg>Command completed successfully; ack to dequeue</msg>
  S:    </result>
  S:    <msgQ count="5" id="12345">
  S:      <qDate>2000-06-08T22:00:00.0Z</qDate>
  S:      <msg>Pending action completed successfully.
  S:        <paNotify paResult="1">
  S:          <paTRID>54321-XYZ</paTRID>
  S:        </paNotify>
  S:      </msg>
  S:    </msgQ>
  S:    <trID>
  S:      <clTRID>BCD-23456</clTRID>
  S:      <svTRID>65432-WXY</svTRID>
  S:    </trID>
  S:  </response>
  S:</epp>

Note how the <paNotify> element can be carried in the <msg> element.  No
fuss, no muss.  Here's what the changed <msg> element data type is going to
look like to support mixed content:

  <complexType name="mixedMsgType" mixed="true">
    <sequence>
      <any processContents="skip"
       minOccurs="0" maxOccurs="unbounded"/>
    </sequence>
    <attribute name="lang" type="language" default="en"/>
  </complexType>

The 'processContents="skip"' attribute tells the parser to skip schema
validation for any XML found within the element, which means that validation
(if needed) should be done in a software layer that consumes the message and
we have complete flexibility in describing service message formats.

One might argue that the content of the <msg> element _should_ be
schema-specified and validatable.  This could be accomplished by changing
the value of processContents to either "lax" (validate the content if at all
possible, but don't choke if it can't) or "strict" (validate the content).
I might be convinced to go with "lax", but "strict" causes the same concerns
for me about being too restrictive in what an operator can put in a service
message.

I'm not trying to put the kibosh on this idea.  If anything, I think it's a
_good_ idea to get some operator agreement on the format of service messages
used in specific operating environments.  My objection is that the format
should NOT be part of the core schema because what fits in one environment
may be constraining in another, and I truly believe that the core schema
should be generic in this regard.

Since Hong hasn't yet seen all of the changes that are going into the core
schema I can understand how we might not be in synch.  If this document were
positioned as a suggestion for an informational "implementers agreement"
(with the modifications I've suggested above), I'd support it 100%.  I can
not support adding another element to the core schema to carry service
message information when there's already an element present for that
purpose.

-Scott-

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 30 Jul 2002 20:27:40 -0400

OK, call me fickle, but after thinking about this for a few more hours,
reading the draft again, and getting away from the office I think I know of
a way to make this action completion notice thing work while making everyone
happy.  We're already doing something similar when <transfer> command
actions are completed; consistency would be a good thing.  I'll work up an
example and send it to the list tomorrow morning.

-Scott-

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 31 Jul 2002 08:50:16 -0400

Hong et al:

Having spent some more time thinking about the suggestions presented in your
I-D, I now have a better feel for what you need and why I didn't
particularly care for the suggestion to add a <paNotify> element.  It's not
the "what" that concerned me, it was the "how", and my concern was driven
largely by a desire to use existing facilities and to treat notification
actions consistently.

We're already doing something similar when transfer actions are completed,
so I spent some time thinking about one of the options described in your
proposal -- use of the <resData> element.  I also thought it might be OK to
be a bit more verbose in the notification so that there can't be any
confusion when the client tries to synchronize the notification with their
own queue of pending activity.

Given that these pending actions operate on objects, just like transfers,
I'd like to suggest that we can do the notifications in the same way that
clients are notified of completed transfer activities.  That is, the
<resData> element can contain the information to identify the object, and
the few new elements needed to make this work get defined in the object
mappings.  A polled message could thus look like this:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
     epp-1.0.xsd">
  <response>
    <result code="1301">
      <msg>Command completed successfully; ack to dequeue</msg>
    </result>
    <msgQ count="5" id="12345">
      <qDate>2000-06-08T22:00:00.0Z</qDate>
      <msg>Pending action completed successfully.</msg>
    </msgQ>
    <resData>
      <domain:paData
       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
       xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
       domain-1.0.xsd">
        <domain:name paResult="1">example.tld</domain:name>
        <domain:clTRID>ABC-12345</domain:clTRID>
        <domain:svTRID>54321-XYZ</domain:svTRID>
        <domain:paDate>2000-06-08T21:59:00.0Z</domain:paDate>
      </domain:paData>
    </resData>
    <trID>
      <clTRID>BCD-23456</clTRID>
      <svTRID>65432-WXY</svTRID>
    </trID>
  </response>
</epp>

Note that the <msg> element in the <msgQ> tells the client what happened,
and everything the client needs to figure out which object is involved is
carried in the <domain:paData> element.  I thought it best to include both
TRIDs (with an optional clTRID) to exactly mirror the TRIDs returned in the
server's response to the original request.  The <paDate> element notes when
the action was actually completed, just as we note dates and times related
to transfers.

OK, hack away.  We might be able to get by with less info to identify the
client's transaction, but doing it this way is consistent with the transfer
notification mechanism and it provides some detail that might make client
reconciliation easier.

-Scott-

---

From: "Liu, Hong" <[email-masked]>
Date: Wed, 31 Jul 2002 16:30:58 -0400

Scott,

Thanks for taking the time to look at the draft and for being receptive to
our suggestion. Your idea of being consistent with transfer handling is well
taken. I would like to carry this discussion further along your line of
thinking.

When I wrote the draft at the beginning, I was actually thinking exactly
your way since the pending action is performed on a specific object mapping.
But after I finished the writing, I realized that I have to add <paData> to
every object mapping (i.e., domain, contact, and host) that may need this
feature. The advantage for doing so, as you explained, is that more object
specific information can be added in. The downside is that <paData> will
have to be defined in every object mapping (existing and to-be-defined).
Since my main goal is to minimize the changes to existing schemas, after
some struggle myself, I took the approach to extract the basic elements for
notification that are object independent. But this may be just my personal
preference in schema design. Both your suggestion and mine should work. I
will leave it to the WG to decide which way to go.

Just to be complete, taking your input, <paNotify> can be defined as
follows:

<complexType name="paNotify">
  <sequence>
    <element name="paTRID" type="epp:trIDType"/>
    <element name="paDate" type="dateTime"/>
  </sequence>
  <attribute name="paResult" type="boolean" use="required"/>
</complexType>

The <paTRID> will consist of the OPTIONAL clTRID and the svTRID.

I fully agree with you regarding the usage of <msg> in <msgQ>. I also
support your idea to allow more structural information to be included in
<msg> for service messaging. For example, <paNotify> (or <paData>) just says
that the pending action has failed. The <msg> element in <msgQ> may be used
to construct more specific error code and text explaining why it failed.
These error codes and accompanying texts can be defined by each registry.

Cheers, 

--Hong

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: Wednesday, July 31, 2002 8:50 AM
To: [email-masked]'
Subject: RE: I-D on Uniform Treatment of Pending Action Notification in
EP P

Hong et al:

-Scott-

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 31 Jul 2002 18:03:38 -0400

> will leave it to the WG to decide which way to go.

Given that I firmly believe that we should be consistent in our approach
(and I don't want to try to explain to Patrik why we weren't consistent), I
would strongly urge anyone who objects to my suggested compromise to speak
up sooner rather than later.  I'm trying to get the document edits finished
in short order.

>   <attribute name="paResult" type="boolean" use="required"/>

Yup, that's pretty much it.

-Scott-

From: "Liu, Hong" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: I-D on Uniform Treatment of Pending Action Notification in EP P
Date: Wed, 31 Jul 2002 16:30:58 -0400
Sender: [email-masked]

Scott,

Cheers, 

--Hong

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: Wednesday, July 31, 2002 8:50 AM
To: [email-masked]'
Subject: RE: I-D on Uniform Treatment of Pending Action Notification in
EP P

Hong et al:

-Scott-

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: I-D on Uniform Treatment of Pending Action Notification in EP P
Date: Wed, 31 Jul 2002 08:50:16 -0400
Sender: [email-masked]

Hong et al:

-Scott-

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: I-D on Uniform Treatment of Pending Action Notification in EP P
Date: Tue, 30 Jul 2002 20:27:40 -0400
Sender: [email-masked]

-Scott-

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: I-D on Uniform Treatment of Pending Action Notification in EP P
Date: Tue, 30 Jul 2002 14:27:09 -0400
Sender: [email-masked]

[snip]

-Scott-

From: "Liu, Hong" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: I-D on Uniform Treatment of Pending Action Notification in EPP
Date: Tue, 30 Jul 2002 12:41:59 -0400
Sender: [email-masked]

Hi, all,

As promised, I have submitted the I-D to IETF. Until it appears in the IETF
repository, you can access the I-D from the following URL:

The gut of the proposal is to add a new OPTIONAL element in <response> to
(1) identify the transaction ID that triggers the pending action;  and (2)
to indicate the outcome of the pending action. This is the minimum
information necessary for enabling the pending action notification mechanism
in EPP.

This is a strawman proposal intended to summarize the recent discussions on
related topics and to bring more focused discussion to bring this issue to a
conlusion. Your comments are greatly appreciated.

--Hong

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Stateless vs. Stateful
Date: Mon, 29 Jul 2002 11:04:48 -0400
Sender: [email-masked]

As part of the ongoing discussion of our IETF last call comments, Jaap, Ed,
Patrik and I have been talking about the issue of a stateless vs. stateful
protocol.  Right now EPP has some provisions to operate both ways (see the
description of "sessionless" operation in the core spec).  Patrik, our AD,
has suggested that the protocol needs to be either stateful or stateless,
but not both, and after thinking about things some more I agree with him.
Believing that we agreed long ago that a stateful session-oriented protocol
is the more desirable operating mode, the stateless "sessionless" stuff is
the candidate for extraction.

I originally put the "sessionless" stuff in the protocol thinking that it
might be useful for a low bandwidth, high latency transport like email.
However, it would also be possible to keep the core protocol completely
stateful and session-oriented (and thus a bit simpler) while still working
in such an environment if the transport mapping were defined appropriately.
With email, for example, a transport mapping could be written to say that
all of the needed commands must be sent in one message/session.

Anyway, to get back to the point I think we need to remove the "sessionless"
features from the core protocol to get the documents ready for the IESG.
What that would mean is the removal of the optional credentials elements
from the commands, and changing the corresponding text.

Does this cause any issues for anyone?

-Scott-

From: "Liu, Hong" <[email-masked]>
To: [email-masked]
Subject: RE: July milestones
Date: Sun, 28 Jul 2002 21:52:33 -0400
Sender: [email-masked]

Ed and Jaap,

I would also like to bring up the EPP "push". I understand that this is not
part of the core, but it is also a desirable feature. We have been working
on the "push" draft for a while. I am holding it off for the moment, pending
the outcome of "pending operation" notification solution in EPP. 

Cheers,

--Hong

-----Original Message-----
From: Edward Lewis [mailto:[email-masked]]
Sent: Friday, July 26, 2002 9:48 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: July milestones

Fortunately, addressing the IESG comments on the core drafts isn't a 
July milestone.  But these are:

JUL 02	  	First draft of EPP over SMTP
JUL 02	  	Decision on need for a EPP Guidelines draft

The first has had some volunteers, but I don't know it much progress 
has been made.  The second has been a weak "go ahead" on it, but that 
has taken a back seat to the core drafts and the IESG comments.

There is only one other milestone on the charter - "scheduling 
interoperability tests" which is a misnomer.  It should read 
"Interoperability Report" (since the IETF doesn't conduct/endorse 
testing of implementations - this is a political correctness 
distinction).

I mention the "one other" milestone because, IMHO, there is a need to 
have more in there.  Such as progress on the BEEP transport draft, 
SMTP work, and revisiting the core drafts based on implementation 
experience and trying for the next level of standardization.

So, any comments on the above and future milestones?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

From: "Zhang, Ning" <[email-masked]>
To: [email-masked]
Subject: RE: BEEP Document Comments (was RE: July milestones)
Date: Fri, 26 Jul 2002 14:12:22 -0400
Sender: [email-masked]

Scott,

Thanks for the comments. 

>> Well, we do have some current comments on the document...but Rick's 
>> question is still germane, what community is forming around a BEEP 
>> transport for EPP?

> There are also some old comments that haven't been completely addressed:
>
> http://www.cafax.se/ietf-provreg/maillist/2001-09/msg00010.html
> 
> Specifically, the TCP transport clarification and "Content-Type: text/xml"
> comments.  Also, the IESG is getting picky about splitting references into
> normative and informative subsections, so that should be done in the
> document.

We are aware of this. It just did not get changed in the last draft.

> New comment/thought: would it be wise to consider Marshall's transient
> profile identifier ideas, described here:?
> 
> http://www.ietf.org/internet-drafts/draft-mrose-beep-transientid-02.txt

I think that it would be good idea to following this practice. 

Thanks,
-Ning

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: BEEP Document Comments (was RE: July milestones)
Date: Fri, 26 Jul 2002 12:34:26 -0400
Sender: [email-masked]

> Well, we do have some current comments on the document...but Rick's 
> question is still germane, what community is forming around a BEEP 
> transport for EPP?

There are also some old comments that haven't been completely addressed:

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

Specifically, the TCP transport clarification and "Content-Type: text/xml"
comments.  Also, the IESG is getting picky about splitting references into
normative and informative subsections, so that should be done in the
document.

New comment/thought: would it be wise to consider Marshall's transient
profile identifier ideas, described here:?

http://www.ietf.org/internet-drafts/draft-mrose-beep-transientid-02.txt

-Scott-

Date: Fri, 26 Jul 2002 11:45:48 -0400
To: Rick Wesson <[email-masked]>, Edward Lewis <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: July milestones
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Well, we do have some current comments on the document...but Rick's 
question is still germane, what community is forming around a BEEP 
transport for EPP?

At 8:31 AM -0700 7/26/02, Rick Wesson wrote:
>On Fri, 26 Jul 2002, Edward Lewis wrote:
>
>>  I mention the "one other" milestone because, IMHO, there is a need to
>>  have more in there.  Such as progress on the BEEP transport draft,
>
>I'd like to hear from anyone who is interested in a BEEP transport moving
>forward. I've always been an advocate but is there anyone interested in
>using a BEEP transport?
>
>-rick

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

Date: Fri, 26 Jul 2002 08:31:45 -0700 (PDT)
From: Rick Wesson <[email-masked]>
To: Edward Lewis <[email-masked]>
cc: <[email-masked]>, <[email-masked]>
Subject: Re: July milestones
Sender: [email-masked]

On Fri, 26 Jul 2002, Edward Lewis wrote:

> I mention the "one other" milestone because, IMHO, there is a need to
> have more in there.  Such as progress on the BEEP transport draft,

I'd like to hear from anyone who is interested in a BEEP transport moving
forward. I've always been an advocate but is there anyone interested in
using a BEEP transport?

-rick

Date: Fri, 26 Jul 2002 09:47:38 -0400
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: July milestones
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Fortunately, addressing the IESG comments on the core drafts isn't a 
July milestone.  But these are:

JUL 02	  	First draft of EPP over SMTP
JUL 02	  	Decision on need for a EPP Guidelines draft

The first has had some volunteers, but I don't know it much progress 
has been made.  The second has been a weak "go ahead" on it, but that 
has taken a back seat to the core drafts and the IESG comments.

There is only one other milestone on the charter - "scheduling 
interoperability tests" which is a misnomer.  It should read 
"Interoperability Report" (since the IETF doesn't conduct/endorse 
testing of implementations - this is a political correctness 
distinction).

I mention the "one other" milestone because, IMHO, there is a need to 
have more in there.  Such as progress on the BEEP transport draft, 
SMTP work, and revisiting the core drafts based on implementation 
experience and trying for the next level of standardization.

So, any comments on the above and future milestones?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: <status> command  - one more opinion
Date: Fri, 26 Jul 2002 07:06:05 -0400
Sender: [email-masked]

> I support the idea to remove the <status> command from EPP.

Given that no one has provided any reason at all to leave it in, plan on it
being gone in the next edition of the specification.  I'll leave the client
TRID stuff optional, as it is now.

-Scott-

From: "Liu, Hong" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: <status> command  - one more opinion
Date: Thu, 25 Jul 2002 21:36:28 -0500
Sender: [email-masked]

I support the idea to remove the <status> command from EPP.

-----Original Message-----
From: Robert Burbidge [mailto:[email-masked]]
Sent: Thursday, July 25, 2002 4:33 AM
To: [email-masked]'
Subject: <status> command - one more opinion

On the whole, I think that <status> command could be removed from the
specification without causing major problems.

Rob Burbidge
Poptel Limited

From: "Liu, Hong" <[email-masked]>
To: [email-masked]
Subject: RE: Proposed Document Changes - Pending Operations
Date: Thu, 25 Jul 2002 16:56:07 -0400
Sender: [email-masked]

Janusz,

That is exactly the problem I had when I first raised the issue on the list.
I fully understand your concerns about complexity. In my upcoming draft, I
will present a few options, and hopefully the WG will choose one with
minimum impacts on the core documents. 

Cheers,

--Hong

-----Original Message-----
From: janusz sienkiewicz [mailto:[email-masked]]
Sent: Thursday, July 25, 2002 4:32 PM
To: Hollenbeck, Scott
Cc: Daniel Manley; [email-masked]; Liu, Hong
Subject: Re: Proposed Document Changes - Pending Operations

Scott, Liu,

It is true that a trace of 'the concept of offline verification before
provisioning an object ' can be found in domain mapping document. The
problem
is the part of the document that deals with the subject is very vague. There
is
not much guidance have to use the concept. Such a concept does not exist at
XML
schema definition level. I think more work is required on definition and
refinement of the concept. New result codes and errror conditions could be a
result of the process.

I assume such a definition is a nontrivial task. That's why I suggested  a
solution based on generic extension mechanism. It could be a quick
potentially
temporary solution. From Liu's note I assume he is going to prepare
something
in the matter. I hope it will fill the gaps I can see in domain mapping
document.

Janusz Sienkiewicz

"Hollenbeck, Scott" wrote:

> > If we have such 'an extension mechanism' what is purpose of
> > this thread? Why
> > are we introducing new return codes and messages? The are
> > several extension
> > mechanisms (<extension>, <value>) available but for some
> > reason none of them
> > can be used when there is a need for protocol extension. Is
> > this protocol
> > really extensible?
>
> The whole question is ultimately one of "does this belong in the core
> protocol" or "does this belong in an extension".  It seems to me, based on
> list discussion over the last two years, that the concept might be of
> general enough interest to be in the core protocol.
>
> I haven't seen anyone (other than you above) suggest that the existing
> extension mechanisms can't be used.  I disagreed with your assertion of
the
> <value> element being an appropriate place to park "pending" information
> because the <value> element isn't part of the existing extension
framework.
> In truth it would be quite easy to define an extension, but given that we
> already have the concept of offline verification before provisioning an
> object in the domain mapping document (and have had it in there for a
while)
> it seems logical to be consistent when dealing with updates that require
> offline verification.
>
> If you disagree with the premise of Hong's suggestion being generally
> useful, thus being something that should be punted to an extension, please
> explain why.
>
> The answer to your last question is an unqualified "yes".
>
> -Scott-

From: "Liu, Hong" <[email-masked]>
To: [email-masked]
Subject: RE: Proposed Document Changes - Pending Operations
Date: Thu, 25 Jul 2002 15:09:18 -0500
Sender: [email-masked]

Scott,

Another couple of questions for clarification. It seems that the <status>
command will be removed from EPP. 

Do you still plan to make the clTRID mandatory for all EPP commands? 

Is clTRID required to be unique, if present, per client? It seems so in the
spec, but I heard people say otherwise.

Thanks!

--Hong

From: "Liu, Hong" <[email-masked]>
To: [email-masked]
Subject: RE: Proposed Document Changes - Pending Operations
Date: Thu, 25 Jul 2002 14:52:38 -0500
Sender: [email-masked]

Scott,

I have a couple of questions for clarification regarding object with pending
action:

Does EPP stipulate that at most one pending action is allowed per object?

To go a bit further, does EPP prohibit any transformation operation on an
object with a pending action? 

Of course, query-type of operations should be allowed.

Thanks!

--Hong

From: "Liu, Hong" <[email-masked]>
To: [email-masked]
Subject: RE: Proposed Document Changes - Pending Operations
Date: Thu, 25 Jul 2002 14:19:57 -0500
Sender: [email-masked]

Janusz,

I agree with Scott on this. Overloading an EPP field is bad for
interoperability. But I do agree with you that the changes required to
handle pending action should be kept minimum. 

On a very high level, there are two separate aspects at hand:

(1) Indicating to the client in the initial response that the requested
action is pending.
(2) Notifying the client of the result of the pending action when it is
done.

I considered (1) already resolved by introducing a new result code. This
thread is about is (2), which also have a number of issues:

(a) provide a hook in <response> to house the notification information
(b) format of the notification message (minimum set of information)
(c) whether (b) should be defined in the core or as an extension

What you have suggested is about (a). I disagree that we overload <value>
for this purpose. Besides, you still need to resolve (b) and (c). My
argument is that (b) should be defined in the core. 

I realize that Scott and I are crossing responses. I apologize that my
response is somewhat overlapped with Scott's.

I am also jumping the gun here since these issues are addressed in the draft
I am writing.

--Hong

-----Original Message-----
From: janusz sienkiewicz [mailto:[email-masked]]
Sent: Thursday, July 25, 2002 2:46 PM
To: Hollenbeck, Scott
Cc: 'janusz sienkiewicz'; Daniel Manley; [email-masked]; Liu,
Hong
Subject: Re: Proposed Document Changes - Pending Operations

If we have such 'an extension mechanism' what is purpose of this thread? Why
are we introducing new return codes and messages? The are several extension
mechanisms (<extension>, <value>) available but for some reason none of them
can be used when there is a need for protocol extension. Is this protocol
really extensible?

Janusz Sienkiewicz

"Hollenbeck, Scott" wrote:

> > The usage of <value> element could be extended.  According to
> > the epp06 spec
> > the element is used only if there is an error condition. It
> > could be also used
> > in case of success condition for passing additional
> > information. This approach
> > would allow more flexibility in the future.
>
> The "flexibility" you describe is bad for interoperability.  We already
have
> an extension mechanism to support return of additional information, and
the
> <value> element isn't part of it.
>
> -Scott-

From: "Hollenbeck, Scott" <[email-masked]>
To: "'janusz sienkiewicz'" <[email-masked]>
Cc: Daniel Manley <[email-masked]>, [email-masked], "Liu, Hong" <[email-masked]>
Subject: RE: Proposed Document Changes - Pending Operations
Date: Thu, 25 Jul 2002 15:05:00 -0400
Sender: [email-masked]

> If we have such 'an extension mechanism' what is purpose of 
> this thread? Why
> are we introducing new return codes and messages? The are 
> several extension
> mechanisms (<extension>, <value>) available but for some 
> reason none of them
> can be used when there is a need for protocol extension. Is 
> this protocol
> really extensible?

The whole question is ultimately one of "does this belong in the core
protocol" or "does this belong in an extension".  It seems to me, based on
list discussion over the last two years, that the concept might be of
general enough interest to be in the core protocol.

I haven't seen anyone (other than you above) suggest that the existing
extension mechanisms can't be used.  I disagreed with your assertion of the
<value> element being an appropriate place to park "pending" information
because the <value> element isn't part of the existing extension framework.
In truth it would be quite easy to define an extension, but given that we
already have the concept of offline verification before provisioning an
object in the domain mapping document (and have had it in there for a while)
it seems logical to be consistent when dealing with updates that require
offline verification.

If you disagree with the premise of Hong's suggestion being generally
useful, thus being something that should be punted to an extension, please
explain why.

The answer to your last question is an unqualified "yes".

-Scott-

From: "Zhang, Ning" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Re: Comments on draft-ietf-provreg-epp-beep-02.txt 
Date: Thu, 25 Jul 2002 13:37:08 -0500
Sender: [email-masked]

Darren,

Thanks for your comments. 

> 2.
>   "Fully processes?" Note that some sort of
>   answer needs to be returned for every BEEP
>   message. You might want to make this clear,
>   or perhaps it's already implicit in the 
>   description of <logout> in the other documents.

This <logout> response has been described in the EPP base spec. 

> 2.1.2 
>   Consider service "epp_beep" since EPP runs over
>   other TCP-based transports as well.
> 
>   In the example, the second L: should be I:
>
>
> 2.1.4 
>   Text "EPP" is duplicated. "Sent over the EPP EPP session"
>

We are aware of various typos and unforunately they did not get fixed in the
last draft. It will be fixed in the next draft.

>   I'm not sure you should specify that piggyback data must
>   be piggybacked. This is more an optimization than a semantic
>   difference. Perhaps "MAY be piggybacked" is better. Note that
>   some toolkits don't even tell you whether the data was
>   piggybacked or not.

You are right on this. "MAY be" is better.

> 2.1.7
>   You might want to mention what the semantics of a single EPP 
>   channel being closed without a <logout> is supposed to do.
>   Something like "this is equivalent to a <logout> with no
>   attributes or child elements." You might also want to mention
>   explicitly that it's OK to close the BEEP channel after the
>   <logout> has been fully processed, in order that resources
>   could be reclaimed.

We will make it clear on this in the next draft.

Thanks,
-Ning

From: "Hollenbeck, Scott" <[email-masked]>
To: "'janusz sienkiewicz'" <[email-masked]>
Cc: Daniel Manley <[email-masked]>, [email-masked], "Liu, Hong" <[email-masked]>
Subject: RE: Proposed Document Changes - Pending Operations
Date: Thu, 25 Jul 2002 14:24:02 -0400
Sender: [email-masked]

> The usage of <value> element could be extended.  According to 
> the epp06 spec
> the element is used only if there is an error condition. It 
> could be also used
> in case of success condition for passing additional 
> information. This approach
> would allow more flexibility in the future.

The "flexibility" you describe is bad for interoperability.  We already have
an extension mechanism to support return of additional information, and the
<value> element isn't part of it.

-Scott-

Date: Thu, 25 Jul 2002 13:57:20 -0400
From: janusz sienkiewicz <[email-masked]>
Organization: LibertyRMS Co.
To: "Hollenbeck, Scott" <[email-masked]>
CC: Daniel Manley <[email-masked]>, [email-masked], "Liu, Hong" <[email-masked]>
Subject: Re: Proposed Document Changes - Pending Operations
Sender: [email-masked]

The usage of <value> element could be extended.  According to the epp06 spec
the element is used only if there is an error condition. It could be also used
in case of success condition for passing additional information. This approach
would allow more flexibility in the future.

The initial approach (adding new result code and message) would provide a
solution for pending situations only and it could result in adding additional
status codes and error conditions.

Janusz Sienkiewicz

"Hollenbeck, Scott" wrote:

> > I don't think any particular changes are required tp epp
> > protocol to acomplish
> > Hong's objective. In epp06 <result> element has child
> > <value> element. The
> > definition of <value> element in epp06 is more flexible than
> > in epp02 (it allows
> > xml extensions). I think <value> element could be used to
> > indicate that the last
> > operation is pending.
>
> Not really -- the purpose of allowing XML in the <value> element is so that
> the server can identify and return any XML that might have caused an error
> condition -- it's not there for extension purposes.  From section 2.5 of
> epp-06:
>
> "- Zero or more OPTIONAL <value> elements that echo client-provided
> elements (including XML tag and value) that caused server error
> conditions."
>
> -Scott-

From: "Liu, Hong" <[email-masked]>
To: [email-masked]
Subject: RE: Proposed Document Changes - Pending Operations
Date: Thu, 25 Jul 2002 12:56:07 -0500
Sender: [email-masked]

Janusz,

I understand what you suggested, but I would like to have Scott comment on
the use of <value> element within <result>. On page 12 of epp-06, it states
that:

 " - Zero or more OPTIONAL <value> elements that echo client-provided
  elements (including XML tag and value) that caused server error
  conditions."

In syntax, it can be used as a hook for what I want, but in semantics, this
element is not defined for that purpose. Do we really want to overload the
use of this element? I would prefer to add another OPTIONAL element such as
<notify> in <result> instead.

I am writing a draft for the uniform treatment of pending action in EPP,
hopefully to get it done by this weekend. So stay tuned...

--Hong

-----Original Message-----
From: janusz sienkiewicz [mailto:[email-masked]]
Sent: Thursday, July 25, 2002 1:18 PM
To: Daniel Manley
Cc: [email-masked]; Liu, Hong
Subject: Re: Proposed Document Changes - Pending Operations

I don't think any particular changes are required tp epp protocol to
acomplish
Hong's objective. In epp06 <result> element has child  <value> element. The
definition of <value> element in epp06 is more flexible than in epp02 (it
allows
xml extensions). I think <value> element could be used to indicate that the
last
operation is pending.

Janusz

Daniel Manley wrote:

> Just to chime in here...
>
> I like the steps described by Hong here -- a very natual use of the poll
> mechanism.  I understand from recent postings by Scott and Hong that a
> new "Command completed successfully; action pending" response code/text
> will be added to the base draft.  I believe this is crutial for the
> steps described below.  It allows the registrar to reliable pass the
> message on to the registrant that the registry is not quite finished the
> operation.
>
> I think Hong was also looking for a well-defined and reliable schema for
> poll responses.  IMHO, the typical notification messages would look like
> responses to <transfer op="query">, <renew>, <delete> and <info>
> commands.  I do see that sending an <info> response and leaving it up to
> the registrar to figure out what changed isn't the greatest idea.
>  Though registrars could build their systems to expect "predictable"
> change to an object based on the "...action pending" response to the
> previous command on that object.  Otherwise, we'd have to build a
> notification message shema to describe a change on an object (removal of
> a status, addition of another property, etc...).
>
> Dan
>
> Liu, Hong wrote:
>
> >Patrik,
> >
> >Rick Wesson has suggested that I reword my response to you to clarify the
> >issue. So here is my second try. This time, I will use an example to make
it
> >more concrete.
> >
> >Suppose the registry policy requires that every name registered go over a
> >formal review before the request for registration is granted. So here is
the
> >typical flow of client (C, registrar) and server (S, registry)
interactions,
> >in the context of the four steps you outlined:
> >
> >(1) C sends a <create> command to the server, requesting for a name X.
> >(2) S accepts X, changes its status to "pendingVerification", and sends a
> >response back to C indicating command success.
> >At this point, X is not registered, but is reserved so that no one else
can
> >take it while it is under review.
> >(3) The registry completes the review and grants the registration. S
removes
> >the "pendingVerification" status and puts a notification into the message
> >queue.
> >(4) C polls and gets the notification from S that registration for X has
> >been approved.
> >
> >What I meant by pending operation (or delayed operation in your word) is
> >that at step (2), the response from S merely says that the request for
> >registering X by C is received and the review process has started. The
> >decision on whether the request will be eventually granted is pending for
> >further review. So from EPP perspective, the command-response transaction
> >may be regarded as completed by the end of step (2). However, from
> >operations perspective, neither C nor S considers that the request for
> >registering X is completed. I think that is where the misunderstanding
kicks
> >in.
> >
> >I hope this example explains what I meant by "pending operation". And I
hope
> >that you would not object to allowing EPP to do things like this. Of
course,
> >I am open to using any term that helps to avoid the confusion.
> >
> >What Scott and I were discussing is about ways to format the notification
in
> >step (3). Scott has already started another thread on this issue [1]...
> >
> >--Hong
> >
> >[1] http://www.cafax.se/ietf-provreg/maillist/2002-07/msg00038.html
> >
> >From: Patrik Fältström [mailto:[email-masked]]
> >Sent: Monday, July 22, 2002 1:32 AM
> >To: Liu, Hong; [email-masked]
> >Subject: RE: Proposed Document Changes - Pending Operations
> >
> >
> >--On 2002-07-18 22.35 -0400 "Liu, Hong" <[email-masked]> wrote:
> >
> >
> >
> >>I guess we had different definition for "delayed execution". Please
refer
> >>to my response to Scott's email. In short, pending operation does not
> >>call for delayed response. In fact, it calls for additional information
> >>once the pending operation is completed.
> >>
> >>
> >
> >This is exactly what I mean by "delayed execution".
> >
> >I.e.:
> >
> >(1) Client send a command to server
> >(2) Server respond that it has received command
> >(3) Server execute the command
> >(4) Client fetches the result code
> >
> >This is what I urge this wg to _not_ do.
> >
> >If you really need asynchronous execution like this (i.e. even delayed
> >execution like this), you have to (a) convince the IESG that is needed
and
> >(b) redesign the protocol quite extensively, because what you want to do
is
> >not possible with what you have on the table today.
> >
> >    paf
> >
> >
> >
>
> --
> Daniel Manley
> Tucows, Inc.
> Toronto, Canada
> [email-masked]

From: "Hollenbeck, Scott" <[email-masked]>
To: "'janusz sienkiewicz'" <[email-masked]>, Daniel Manley <[email-masked]>
Cc: [email-masked], "Liu, Hong" <[email-masked]>
Subject: RE: Proposed Document Changes - Pending Operations
Date: Thu, 25 Jul 2002 13:42:49 -0400
Sender: [email-masked]

> I don't think any particular changes are required tp epp 
> protocol to acomplish
> Hong's objective. In epp06 <result> element has child  
> <value> element. The
> definition of <value> element in epp06 is more flexible than 
> in epp02 (it allows
> xml extensions). I think <value> element could be used to 
> indicate that the last
> operation is pending.

Not really -- the purpose of allowing XML in the <value> element is so that
the server can identify and return any XML that might have caused an error
condition -- it's not there for extension purposes.  From section 2.5 of
epp-06:

"- Zero or more OPTIONAL <value> elements that echo client-provided
elements (including XML tag and value) that caused server error
conditions."

-Scott-

Date: Thu, 25 Jul 2002 13:17:40 -0400
From: janusz sienkiewicz <[email-masked]>
Organization: LibertyRMS Co.
To: Daniel Manley <[email-masked]>
CC: [email-masked], "Liu, Hong" <[email-masked]>
Subject: Re: Proposed Document Changes - Pending Operations
Sender: [email-masked]

I don't think any particular changes are required tp epp protocol to acomplish
Hong's objective. In epp06 <result> element has child  <value> element. The
definition of <value> element in epp06 is more flexible than in epp02 (it allows
xml extensions). I think <value> element could be used to indicate that the last
operation is pending.

Janusz

Daniel Manley wrote:

> Just to chime in here...
>
> I like the steps described by Hong here -- a very natual use of the poll
> mechanism.  I understand from recent postings by Scott and Hong that a
> new "Command completed successfully; action pending" response code/text
> will be added to the base draft.  I believe this is crutial for the
> steps described below.  It allows the registrar to reliable pass the
> message on to the registrant that the registry is not quite finished the
> operation.
>
> I think Hong was also looking for a well-defined and reliable schema for
> poll responses.  IMHO, the typical notification messages would look like
> responses to <transfer op="query">, <renew>, <delete> and <info>
> commands.  I do see that sending an <info> response and leaving it up to
> the registrar to figure out what changed isn't the greatest idea.
>  Though registrars could build their systems to expect "predictable"
> change to an object based on the "...action pending" response to the
> previous command on that object.  Otherwise, we'd have to build a
> notification message shema to describe a change on an object (removal of
> a status, addition of another property, etc...).
>
> Dan
>
> Liu, Hong wrote:
>
> >Patrik,
> >
> >Rick Wesson has suggested that I reword my response to you to clarify the
> >issue. So here is my second try. This time, I will use an example to make it
> >more concrete.
> >
> >Suppose the registry policy requires that every name registered go over a
> >formal review before the request for registration is granted. So here is the
> >typical flow of client (C, registrar) and server (S, registry) interactions,
> >in the context of the four steps you outlined:
> >
> >(1) C sends a <create> command to the server, requesting for a name X.
> >(2) S accepts X, changes its status to "pendingVerification", and sends a
> >response back to C indicating command success.
> >At this point, X is not registered, but is reserved so that no one else can
> >take it while it is under review.
> >(3) The registry completes the review and grants the registration. S removes
> >the "pendingVerification" status and puts a notification into the message
> >queue.
> >(4) C polls and gets the notification from S that registration for X has
> >been approved.
> >
> >What I meant by pending operation (or delayed operation in your word) is
> >that at step (2), the response from S merely says that the request for
> >registering X by C is received and the review process has started. The
> >decision on whether the request will be eventually granted is pending for
> >further review. So from EPP perspective, the command-response transaction
> >may be regarded as completed by the end of step (2). However, from
> >operations perspective, neither C nor S considers that the request for
> >registering X is completed. I think that is where the misunderstanding kicks
> >in.
> >
> >I hope this example explains what I meant by "pending operation". And I hope
> >that you would not object to allowing EPP to do things like this. Of course,
> >I am open to using any term that helps to avoid the confusion.
> >
> >What Scott and I were discussing is about ways to format the notification in
> >step (3). Scott has already started another thread on this issue [1]...
> >
> >--Hong
> >
> >[1] http://www.cafax.se/ietf-provreg/maillist/2002-07/msg00038.html
> >
> >From: Patrik Fältström [mailto:[email-masked]]
> >Sent: Monday, July 22, 2002 1:32 AM
> >To: Liu, Hong; [email-masked]
> >Subject: RE: Proposed Document Changes - Pending Operations
> >
> >
> >--On 2002-07-18 22.35 -0400 "Liu, Hong" <[email-masked]> wrote:
> >
> >
> >
> >>I guess we had different definition for "delayed execution". Please refer
> >>to my response to Scott's email. In short, pending operation does not
> >>call for delayed response. In fact, it calls for additional information
> >>once the pending operation is completed.
> >>
> >>
> >
> >This is exactly what I mean by "delayed execution".
> >
> >I.e.:
> >
> >(1) Client send a command to server
> >(2) Server respond that it has received command
> >(3) Server execute the command
> >(4) Client fetches the result code
> >
> >This is what I urge this wg to _not_ do.
> >
> >If you really need asynchronous execution like this (i.e. even delayed
> >execution like this), you have to (a) convince the IESG that is needed and
> >(b) redesign the protocol quite extensively, because what you want to do is
> >not possible with what you have on the table today.
> >
> >    paf
> >
> >
> >
>
> --
> Daniel Manley
> Tucows, Inc.
> Toronto, Canada
> [email-masked]

Date: Thu, 25 Jul 2002 12:02:00 -0400
From: Daniel Manley <[email-masked]>
To: [email-masked]
CC: "Liu, Hong" <[email-masked]>
Subject: Re: Proposed Document Changes - Pending Operations
Sender: [email-masked]

Just to chime in here...

I like the steps described by Hong here -- a very natual use of the poll 
mechanism.  I understand from recent postings by Scott and Hong that a 
new "Command completed successfully; action pending" response code/text 
will be added to the base draft.  I believe this is crutial for the 
steps described below.  It allows the registrar to reliable pass the 
message on to the registrant that the registry is not quite finished the 
operation.

I think Hong was also looking for a well-defined and reliable schema for 
poll responses.  IMHO, the typical notification messages would look like 
responses to <transfer op="query">, <renew>, <delete> and <info> 
commands.  I do see that sending an <info> response and leaving it up to 
the registrar to figure out what changed isn't the greatest idea. 
 Though registrars could build their systems to expect "predictable" 
change to an object based on the "...action pending" response to the 
previous command on that object.  Otherwise, we'd have to build a 
notification message shema to describe a change on an object (removal of 
a status, addition of another property, etc...).

Dan

Liu, Hong wrote:

>Patrik,
>
>Rick Wesson has suggested that I reword my response to you to clarify the
>issue. So here is my second try. This time, I will use an example to make it
>more concrete.
>
>Suppose the registry policy requires that every name registered go over a
>formal review before the request for registration is granted. So here is the
>typical flow of client (C, registrar) and server (S, registry) interactions,
>in the context of the four steps you outlined:
>
>(1) C sends a <create> command to the server, requesting for a name X.
>(2) S accepts X, changes its status to "pendingVerification", and sends a
>response back to C indicating command success.
>At this point, X is not registered, but is reserved so that no one else can
>take it while it is under review.
>(3) The registry completes the review and grants the registration. S removes
>the "pendingVerification" status and puts a notification into the message
>queue.
>(4) C polls and gets the notification from S that registration for X has
>been approved.
>
>What I meant by pending operation (or delayed operation in your word) is
>that at step (2), the response from S merely says that the request for
>registering X by C is received and the review process has started. The
>decision on whether the request will be eventually granted is pending for
>further review. So from EPP perspective, the command-response transaction
>may be regarded as completed by the end of step (2). However, from
>operations perspective, neither C nor S considers that the request for
>registering X is completed. I think that is where the misunderstanding kicks
>in.
>
>I hope this example explains what I meant by "pending operation". And I hope
>that you would not object to allowing EPP to do things like this. Of course,
>I am open to using any term that helps to avoid the confusion.
>
>What Scott and I were discussing is about ways to format the notification in
>step (3). Scott has already started another thread on this issue [1]...
>
>--Hong
>
>[1] http://www.cafax.se/ietf-provreg/maillist/2002-07/msg00038.html
>
>From: Patrik Fältström [mailto:[email-masked]]
>Sent: Monday, July 22, 2002 1:32 AM
>To: Liu, Hong; [email-masked]
>Subject: RE: Proposed Document Changes - Pending Operations
>
>
>--On 2002-07-18 22.35 -0400 "Liu, Hong" <[email-masked]> wrote:
>
>  
>
>>I guess we had different definition for "delayed execution". Please refer
>>to my response to Scott's email. In short, pending operation does not
>>call for delayed response. In fact, it calls for additional information
>>once the pending operation is completed.
>>    
>>
>
>This is exactly what I mean by "delayed execution".
>
>I.e.:
>
>(1) Client send a command to server
>(2) Server respond that it has received command
>(3) Server execute the command
>(4) Client fetches the result code
>
>This is what I urge this wg to _not_ do.
>
>If you really need asynchronous execution like this (i.e. even delayed
>execution like this), you have to (a) convince the IESG that is needed and
>(b) redesign the protocol quite extensively, because what you want to do is
>not possible with what you have on the table today.
>
>    paf
>
>  
>

-- 
Daniel Manley
Tucows, Inc.
Toronto, Canada
[email-masked]

From: Robert Burbidge <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: <status> command  - one more opinion
Date: Thu, 25 Jul 2002 09:32:48 +0100
Sender: [email-masked]

On the whole, I think that <status> command could be removed from the
specification without causing major problems.

Rob Burbidge
Poptel Limited

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Liu, Hong'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Result code for "Command completed successfully; action pendi ng"
Date: Wed, 24 Jul 2002 15:58:13 -0400
Sender: [email-masked]

> Have you decide on what value of this result code would be? Thanks!

No, I haven't gotten that far yet -- I'm still working through other
comments received some time ago.  It'll probably be either 1001 or 1302,
though.  Please don't make any assumptions until the updated document is
published... ;-)

-Scott-

From: "Liu, Hong" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Result code for "Command completed successfully; action pending"
Date: Wed, 24 Jul 2002 15:34:45 -0400
Sender: [email-masked]

Scott,

Have you decide on what value of this result code would be? Thanks!

--Hong

From: "Hollenbeck, Scott" <[email-masked]>
To: "'janusz sienkiewicz'" <[email-masked]>, [email-masked]
Subject: RE: Service Message Format
Date: Wed, 24 Jul 2002 13:50:49 -0400
Sender: [email-masked]

> If we allow XML for '<result><msg>' for some epp implementations it
> can be quite a significant change. It may affect all command responses.

Indeed, and that's why it's not part of the proposal -- we're only talking
about service messages that may be retrieved via the <poll> command.  You
correctly noticed that the current schema uses the same data type for both
<msg> elements; that will have to change.  I was planning on creating a new
type to allow the use of mixed content only within the service message <msg>
element.

-Scott-

Date: Wed, 24 Jul 2002 13:19:09 -0400
From: janusz sienkiewicz <[email-masked]>
Organization: LibertyRMS Co.
To: [email-masked]
Subject: RE: Service Message Format
Sender: [email-masked]

--------------CFC1E6C4A6EDC85CC78F4512
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

This message is related to <msg> element in Poll command (adding XML to <msg> element).

I think one thing seems to be forgotten in the discussion. <msg> element is a child element for both <result> and <msgQ>
elements. I think the change proposal should be more specific. It should describe proposed behaviour of <msg> element in both <msgQ> and <result> cases.

If we allow XML for '<result><msg>' for some epp implementations it can be quite a significant change. It may affect all command responses.

Janusz Sienkiewicz

--------------CFC1E6C4A6EDC85CC78F4512
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>

<pre>This message is related to &lt;msg> element in Poll command (adding XML to &lt;msg> element).

I think one thing seems to be forgotten in the discussion. &lt;msg> element is a child element for both &lt;result> and &lt;msgQ>
elements. I think the change proposal should be more specific. It should describe proposed behaviour of &lt;msg> element in both &lt;msgQ> and &lt;result> cases.</pre>

<pre>If we allow XML for '&lt;result>&lt;msg>' for some epp implementations it can be quite a significant change. It may affect all command responses.</pre>

<pre>Janusz Sienkiewicz

</pre>
&nbsp;</html>

--------------CFC1E6C4A6EDC85CC78F4512--

Date: Wed, 24 Jul 2002 09:22:54 -0700
From: Darren New <[email-masked]>
Organization: Boxes!
To: [email-masked]
Subject: Comments on draft-ietf-provreg-epp-beep-02.txt
Sender: [email-masked]

I looked over draft-ietf-provreg-epp-beep-02.txt briefly. I noticed a few
minor items I thought would be worth addressing...

2.
  "Fully processes?" Note that some sort of
  answer needs to be returned for every BEEP
  message. You might want to make this clear,
  or perhaps it's already implicit in the 
  description of <logout> in the other documents.

2.1.2 
  Consider service "epp_beep" since EPP runs over
  other TCP-based transports as well.

  In the example, the second L: should be I:

2.1.4 
  Text "EPP" is duplicated. "Sent over the EPP EPP session"

  I'm not sure you should specify that piggyback data must
  be piggybacked. This is more an optimization than a semantic
  difference. Perhaps "MAY be piggybacked" is better. Note that
  some toolkits don't even tell you whether the data was
  piggybacked or not.

2.1.7
  You might want to mention what the semantics of a single EPP 
  channel being closed without a <logout> is supposed to do.
  Something like "this is equivalent to a <logout> with no
  attributes or child elements." You might also want to mention
  explicitly that it's OK to close the BEEP channel after the
  <logout> has been fully processed, in order that resources
  could be reclaimed.

Thanks for your attention!

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.

From: "Gould, James" <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>, "'Liu, Hong'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Proposed Document Changes
Date: Wed, 24 Jul 2002 09:43:06 -0400
Sender: [email-masked]

Scott,

I really don't see the value in the <status> command.  In its proposed form,
it doesn't provide any value to the client, since the client will most
likely have a pool of sessions and finding the status of the last command
processed on any one of the sessions doesn't provide any valuable
information.  There is even more of an issue of supporting the <status>
command for non-transform commands, where determining if a <check> was
successfully processed is pointless and represents huge overhead for the
server.  Non-transform commands should simply be re-transmitted.  Transform
commands can also be re-transmitted or the client can use the <info> command
to determine the current state of the object.  

Jim  

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: Wednesday, July 24, 2002 7:14 AM
To: 'Liu, Hong'
Cc: [email-masked]'
Subject: RE: Proposed Document Changes

> I assume you resend this to see if there are more comments. I 
> don't mean to
> beat up the dead horse, but I would like you to clarify the 
> two paragraphs
> quoted below.

I didn't resend it.  Take a look at the message headers -- it looks like
Jaap might have manually approved it for distribution to the list, or
something like that.

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

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

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

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

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

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

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

-Scott-

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

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

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

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

Date: Wed, 24 Jul 2002 08:15:40 -0400
From: Andrew Sullivan <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Re: Proposed Document Changes
Mail-Followup-To: Andrew Sullivan <[email-masked]>, "[email-masked]'" <[email-masked]>
Sender: [email-masked]

On Wed, Jul 24, 2002 at 07:13:46AM -0400, Hollenbeck, Scott wrote:
> 
> Last command completed, which might not have anything to do with a session.

[. . .]

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

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

Andrew

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

To: "Hollenbeck, Scott" <[email-masked]>
cc: "'Liu, Hong'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Proposed Document Changes 
Date: Wed, 24 Jul 2002 13:38:58 +0200
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

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

	jaap

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Liu, Hong'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Proposed Document Changes
Date: Wed, 24 Jul 2002 07:13:46 -0400
Sender: [email-masked]

> I assume you resend this to see if there are more comments. I 
> don't mean to
> beat up the dead horse, but I would like you to clarify the 
> two paragraphs
> quoted below.

I didn't resend it.  Take a look at the message headers -- it looks like
Jaap might have manually approved it for distribution to the list, or
something like that.

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

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

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

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

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

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

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

-Scott-

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

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

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

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

From: "Liu, Hong" <[email-masked]>
To: [email-masked]
Subject: RE: Proposed Document Changes
Date: Tue, 23 Jul 2002 23:40:52 -0400
Sender: [email-masked]

Scott,

I assume you resend this to see if there are more comments. I don't mean to
beat up the dead horse, but I would like you to clarify the two paragraphs
quoted below.

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

The second quoted paragraph, could you clarify:
(1) What is the last command processed? Is it the last command per registrar
(client) or the last command per session of the client? I assume that a
client is allowed to established multiple sessions with the server.
(2) Why is <status> command ever needed if its use is so restricted? The
client can simply resend the command if it does not hear from the server
after a timeout. EPP ensures idempotency for each command, so there is no
harm to resend it.

Thanks in advance!

--Hong

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: Wednesday, July 17, 2002 5:57 PM
To: [email-masked]
Subject: Proposed Document Changes

[snip...]

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

[snip...]

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

[snip...]

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

-Scott-

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

From: "Hollenbeck, Scott" <[email-masked]>
To: <[email-masked]>
Subject: Proposed Document Changes
Date: Wed, 17 Jul 2002 17:56:33 -0400
Sender: [email-masked]

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

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

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

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

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

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

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

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

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

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

-Scott-

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

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Roger Castillo Cortazar'" <[email-masked]>, [email-masked]
Subject: RE: Proposed Document Changes
Date: Tue, 23 Jul 2002 07:05:26 -0400
Sender: [email-masked]

Roger,

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

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

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

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

-Scott- 

> From: Roger Castillo Cortazar [mailto:[email-masked]]
> Sent: Monday, July 22, 2002 10:00 PM
> To: Hollenbeck, Scott; [email-masked]
> Subject: Re: Proposed Document Changes
> 
> 
> 
> Hi everybody, I have a few questions about this changes 
> proposed by Scott 
> that could be interesting
> 
> >- All text describing "asynchronous" operation needs to be 
> removed/reworded.
> >Instead, text describing the protocol's operating mode as 
> "client-initiated
> >command, server response" needs to be reinforced.  Without 
> this change we'd
> >need to define our own "congestion control/ack" service to 
> handle the loss
> >of instances that may be queued in the application 
> queue-space (as when a
> >server goes down).
> 
> So, the "synchronous" operation mode is going to be mandatory ?
> 
> How is the command-response operating mode going to be reinforced ?
> - Is it that the client cannot send a command until he gets 
> the response to 
> the previous one ?
> - In other words: What happens if a client issues a command, 
> before he gets 
> a response to a previous one ?
> - Which response could he get if he issues a <status> for a 
> command, and 
> that command is not yet completed?
> 
> I think this could be somehow linked  to the <status> command and the 
> server's caching responsabilities.
> 
> Any comments ?
> 
> Greetings.
> 
> 
> Roger Castillo Cortazar
> NIC-Mexico http://www.nic.mx
> Top Level Domain .MX
> 

Date: Mon, 22 Jul 2002 20:59:51 -0500
To: "Hollenbeck, Scott" <[email-masked]>, <[email-masked]>
From: Roger Castillo Cortazar <[email-masked]>
Subject: Re: Proposed Document Changes
Sender: [email-masked]

Hi everybody, I have a few questions about this changes proposed by Scott 
that could be interesting

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

So, the "synchronous" operation mode is going to be mandatory ?

How is the command-response operating mode going to be reinforced ?
- Is it that the client cannot send a command until he gets the response to 
the previous one ?
- In other words: What happens if a client issues a command, before he gets 
a response to a previous one ?
- Which response could he get if he issues a <status> for a command, and 
that command is not yet completed?

I think this could be somehow linked  to the <status> command and the 
server's caching responsabilities.

Any comments ?

Greetings.

Roger Castillo Cortazar
NIC-Mexico http://www.nic.mx
Top Level Domain .MX

From: "Gould, James" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>
Subject: RE: Service Message Format
Date: Mon, 22 Jul 2002 18:09:52 -0400
Sender: [email-masked]

I further discussed this issue with Scott, and I don't see an issue with
allowing for mixed XML in the <msg> element.  This allows for the current
behavior of the use of plain text messages, does not require a new extension
mechanism, and provides additional flexibility in the poll messages.  This
assumes that the <msg> element contains well-formed XML that is not
validated.

Jim

> ----------
> From: 	Gould, James
> Sent: 	Monday, July 22, 2002 1:39 PM
> To: 	[email-masked]'; Hollenbeck, Scott
> Subject: 	RE: Service Message Format
> 
> Scott,
> 
> I believe the <msg> element is fine the way it is, since it is contained
> within an EPP response which is already extensible (i.e. <transfer> query
> response for transfer messages).  The <msg> element provides the
> contextual
> information related to the message, which can be plain text, and the type
> of
> response contains the data. By making the <msg> a holder for message
> specific content, it would duplicate the use of the EPP response
> extensions.
> 
> 
> Jim
> 
> > ----------
> > From: 	Hollenbeck, Scott
> > Sent: 	Monday, July 22, 2002 1:08 PM
> > Subject: 	Service Message Format
> > 
> > Something Hong mentioned in one of his recent notes got me thinking
> about
> > service messages (the kind that can be retrieved using the <poll>
> command)
> > and how their format is currently (un)specified.  The current specs use
> > the
> > XML Schema "normalizedString" type for the <msg> element; this allows
> for
> > text messages, but no additional XML.  I was wondering if folks might
> find
> > it useful to allow XML in the <msg> element so that it would be possible
> > for
> > a server operator to define parsable message structures.
> > 
> > -Scott- 
> > 
> > 
> 
> 

From: "Liu, Hong" <[email-masked]>
To: [email-masked]
Subject: RE: Proposed Document Changes - Pending Operations
Date: Mon, 22 Jul 2002 16:42:07 -0400
Sender: [email-masked]

Patrik,

Rick Wesson has suggested that I reword my response to you to clarify the
issue. So here is my second try. This time, I will use an example to make it
more concrete.

Suppose the registry policy requires that every name registered go over a
formal review before the request for registration is granted. So here is the
typical flow of client (C, registrar) and server (S, registry) interactions,
in the context of the four steps you outlined:

(1) C sends a <create> command to the server, requesting for a name X.
(2) S accepts X, changes its status to "pendingVerification", and sends a
response back to C indicating command success.
At this point, X is not registered, but is reserved so that no one else can
take it while it is under review.
(3) The registry completes the review and grants the registration. S removes
the "pendingVerification" status and puts a notification into the message
queue.
(4) C polls and gets the notification from S that registration for X has
been approved.

What I meant by pending operation (or delayed operation in your word) is
that at step (2), the response from S merely says that the request for
registering X by C is received and the review process has started. The
decision on whether the request will be eventually granted is pending for
further review. So from EPP perspective, the command-response transaction
may be regarded as completed by the end of step (2). However, from
operations perspective, neither C nor S considers that the request for
registering X is completed. I think that is where the misunderstanding kicks
in.

I hope this example explains what I meant by "pending operation". And I hope
that you would not object to allowing EPP to do things like this. Of course,
I am open to using any term that helps to avoid the confusion.

What Scott and I were discussing is about ways to format the notification in
step (3). Scott has already started another thread on this issue [1]...

--Hong

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

-----Original Message-----
From: Patrik Fältström [mailto:[email-masked]]
Sent: Monday, July 22, 2002 1:32 AM
To: Liu, Hong; [email-masked]
Subject: RE: Proposed Document Changes - Pending Operations

--On 2002-07-18 22.35 -0400 "Liu, Hong" <[email-masked]> wrote:

> I guess we had different definition for "delayed execution". Please refer
> to my response to Scott's email. In short, pending operation does not
> call for delayed response. In fact, it calls for additional information
> once the pending operation is completed.

This is exactly what I mean by "delayed execution".

I.e.:

(1) Client send a command to server
(2) Server respond that it has received command
(3) Server execute the command
(4) Client fetches the result code

This is what I urge this wg to _not_ do.

If you really need asynchronous execution like this (i.e. even delayed
execution like this), you have to (a) convince the IESG that is needed and
(b) redesign the protocol quite extensively, because what you want to do is
not possible with what you have on the table today.

    paf

From: "Edmon Chung" <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>, <[email-masked]>
Subject: Re: Service Message Format
Date: Mon, 22 Jul 2002 14:20:21 -0400
Sender: [email-masked]

I think "allow" but not "force" would be good.
Edmon

----- Original Message -----
From: "Hollenbeck, Scott" <[email-masked]>
To: <[email-masked]>
Sent: Monday, July 22, 2002 1:08 PM
Subject: Service Message Format

> Something Hong mentioned in one of his recent notes got me thinking about
> service messages (the kind that can be retrieved using the <poll> command)
> and how their format is currently (un)specified.  The current specs use
the
> XML Schema "normalizedString" type for the <msg> element; this allows for
> text messages, but no additional XML.  I was wondering if folks might find
> it useful to allow XML in the <msg> element so that it would be possible
for
> a server operator to define parsable message structures.
>
> -Scott-
>

From: "Liu, Hong" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Service Message Format
Date: Mon, 22 Jul 2002 12:44:20 -0500
Sender: [email-masked]

Scott,

I think this is in the right direction to resolving the notification
problem. I am for it. Thanks!

--Hong

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: Monday, July 22, 2002 1:08 PM
To: [email-masked]'
Subject: Service Message Format

Something Hong mentioned in one of his recent notes got me thinking about
service messages (the kind that can be retrieved using the <poll> command)
and how their format is currently (un)specified.  The current specs use the
XML Schema "normalizedString" type for the <msg> element; this allows for
text messages, but no additional XML.  I was wondering if folks might find
it useful to allow XML in the <msg> element so that it would be possible for
a server operator to define parsable message structures.

-Scott- 

From: "Gould, James" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>
Subject: RE: Service Message Format
Date: Mon, 22 Jul 2002 13:39:17 -0400
Sender: [email-masked]

Scott,

I believe the <msg> element is fine the way it is, since it is contained
within an EPP response which is already extensible (i.e. <transfer> query
response for transfer messages).  The <msg> element provides the contextual
information related to the message, which can be plain text, and the type of
response contains the data. By making the <msg> a holder for message
specific content, it would duplicate the use of the EPP response extensions.

Jim

> ----------
> From: 	Hollenbeck, Scott
> Sent: 	Monday, July 22, 2002 1:08 PM
> Subject: 	Service Message Format
> 
> Something Hong mentioned in one of his recent notes got me thinking about
> service messages (the kind that can be retrieved using the <poll> command)
> and how their format is currently (un)specified.  The current specs use
> the
> XML Schema "normalizedString" type for the <msg> element; this allows for
> text messages, but no additional XML.  I was wondering if folks might find
> it useful to allow XML in the <msg> element so that it would be possible
> for
> a server operator to define parsable message structures.
> 
> -Scott- 
> 
> 

Date: Mon, 22 Jul 2002 10:35:04 -0700 (PDT)
From: Rick Wesson <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: Re: Service Message Format
Sender: [email-masked]

agreed, allow xml in the <msg> element.

-rick

On Mon, 22 Jul 2002, Hollenbeck, Scott wrote:

> Something Hong mentioned in one of his recent notes got me thinking about
> service messages (the kind that can be retrieved using the <poll> command)
> and how their format is currently (un)specified.  The current specs use the
> XML Schema "normalizedString" type for the <msg> element; this allows for
> text messages, but no additional XML.  I was wondering if folks might find
> it useful to allow XML in the <msg> element so that it would be possible for
> a server operator to define parsable message structures.
>
> -Scott-
>

Date: Mon, 22 Jul 2002 19:30:31 +0200
From: Patrick <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Re: Service Message Format
Organization: Gandi
Sender: [email-masked]

On Mon, Jul 22, 2002 at 01:08:29PM -0400, Hollenbeck, Scott took time to write:
> text messages, but no additional XML.  I was wondering if folks might find
> it useful to allow XML in the <msg> element so that it would be possible for
> a server operator to define parsable message structures.

If we really want to be extensible, I think we should not force
non-XML strings in poll messages, thus we should make everything
possible so that XML strings in poll messages will work.

I do not think that this makes big changes, so I am for this idea.

Patrick.

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Service Message Format
Date: Mon, 22 Jul 2002 13:08:29 -0400
Sender: [email-masked]

Something Hong mentioned in one of his recent notes got me thinking about
service messages (the kind that can be retrieved using the <poll> command)
and how their format is currently (un)specified.  The current specs use the
XML Schema "normalizedString" type for the <msg> element; this allows for
text messages, but no additional XML.  I was wondering if folks might find
it useful to allow XML in the <msg> element so that it would be possible for
a server operator to define parsable message structures.

-Scott- 

From: "Liu, Hong" <[email-masked]>
To: [email-masked]
Subject: RE: Proposed Document Changes - Pending Operations
Date: Mon, 22 Jul 2002 10:41:01 -0400
Sender: [email-masked]

Patrik,

Thanks for the clarification. At least we have consensus on the definition,
-:)

I initially thought that Scott and I were discussing means to achieving
this. But now you are suggesting that EPP shoud not support such operations.
I want to know why.

Now I think we have a big issue at hand if this capability is striped out of
the protocol at the last minute. This is not what I want to do, this is what
the reality of registry operations calls for. There are many cases where
instant execution of a requested operation on a server object is not
possible. This is particularly true for sponsored TLDs and/or ccTLDs where
registry policy requires that an operation be authorized before execution.
Take .au and .kids.us for example. There are also cases for advanced
services offered by unsponsored registries that need this capability.

Please tell me what I have available to accommodate these use cases? I don't
buy the idea that this has to be done outside of EPP since this is a generic
scenario. In addition, even for out-of-hand solutions, the response from the
server, step (2) in your definition, still does not mean the completion of
the command. So we are back to square zero.

--Hong

-----Original Message-----
From: Patrik Fältström [mailto:[email-masked]]
Sent: Monday, July 22, 2002 1:32 AM
To: Liu, Hong; [email-masked]
Subject: RE: Proposed Document Changes - Pending Operations

--On 2002-07-18 22.35 -0400 "Liu, Hong" <[email-masked]> wrote:

> I guess we had different definition for "delayed execution". Please refer
> to my response to Scott's email. In short, pending operation does not
> call for delayed response. In fact, it calls for additional information
> once the pending operation is completed.

This is exactly what I mean by "delayed execution".

I.e.:

(1) Client send a command to server
(2) Server respond that it has received command
(3) Server execute the command
(4) Client fetches the result code

This is what I urge this wg to _not_ do.

If you really need asynchronous execution like this (i.e. even delayed
execution like this), you have to (a) convince the IESG that is needed and
(b) redesign the protocol quite extensively, because what you want to do is
not possible with what you have on the table today.

    paf

Date: Mon, 22 Jul 2002 14:32:18 +0900
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
To: "Liu, Hong" <[email-masked]>, [email-masked]
Subject: RE: Proposed Document Changes - Pending Operations
Sender: [email-masked]

--On 2002-07-18 22.35 -0400 "Liu, Hong" <[email-masked]> wrote:

> I guess we had different definition for "delayed execution". Please refer
> to my response to Scott's email. In short, pending operation does not
> call for delayed response. In fact, it calls for additional information
> once the pending operation is completed.

This is exactly what I mean by "delayed execution".

I.e.:

(1) Client send a command to server
(2) Server respond that it has received command
(3) Server execute the command
(4) Client fetches the result code

This is what I urge this wg to _not_ do.

If you really need asynchronous execution like this (i.e. even delayed
execution like this), you have to (a) convince the IESG that is needed and
(b) redesign the protocol quite extensively, because what you want to do is
not possible with what you have on the table today.

    paf

From: "Liu, Hong" <[email-masked]>
To: [email-masked]
Subject: RE: Multiple Extension Elements  for Command/Response in EPP
Date: Fri, 19 Jul 2002 10:03:04 -0400
Sender: [email-masked]

Scott,

Thanks for the explanation. That will work for me, -:)

--Hong

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: Thursday, July 18, 2002 6:48 PM
To: Liu, Hong; [email-masked]
Subject: Re: Multiple Extension Elements for Command/Response in EPP

Hong,

I don't think what you're asking for is needed because the current syntax
permits multiple extensions within a single <extension> element.  Here's the
types involved:

<complexType name="commandType">
  <sequence>
...
    <element name="extension" type="epp:extAnyType"
     minOccurs="0"/>
...
  </sequence>
</complexType>

<complexType name="extAnyType">
  <sequence>
    <any namespace="##other"
     maxOccurs="unbounded"/>
  </sequence>
</complexType>

See the 'maxOccurs="unbounded"' attribute in the definition of extAnyType?

-Scott-

----- Original Message -----
From: "Liu, Hong" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, July 18, 2002 5:24 PM
Subject: Multiple Extension Elements for Command/Response in EPP

> Scott,
>
> I would like to request a small change in epp-1.0.xsd to allow multiple
> <extension> elements at the command and response level. Specifically, the
> changes are:
>
> (1) On page 56 of EPP-06 under the <commandType> definition, add attribute
> "maxOccurs=unbounded" to the <extension> element.
> (2) On page 59 of EPP-06 under the <responseType> definition, add
attribute
> "maxOccurs=unbounded" to the <extension> element.
>
> This change is based on the experiences gained through our recent EPP
> extension work (usTLD, EPP PUSH, etc...). At present, at most one
> <extension> is allowed. If I have two independent extensions for an object
> type, say domain, then I cannot list them independently in the command and
> response. Allowing multiple <extension> elements can solve the problem.
>
> Thanks!
>
> --Hong
>

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Liu, Hong'" <[email-masked]>, [email-masked]
Subject: RE: Proposed Document Changes - Pending Operations
Date: Fri, 19 Jul 2002 06:18:35 -0400
Sender: [email-masked]

> So the correct use of <status> command, under the proposed 
> change, is to
> find out whether the previous client command has been 
> successfully processed
> by the server. This does not mean that the operation requested in the
> command has been completed by the server. What I need is a 
> notification
> mechanism in EPP for the latter.

Hong,

As I said earlier, that mechanism is already present in the protocol: change
the status when completed, and notify the client by putting a message in the
queue for retrieval via the <poll> command.  The format of the notification
depends on what you want to say, just as the format of every other service
message is something to be defined by the server operator.  You might use
the client and server transaction IDs to identify the completed command in
you service message.

Hong, I don't know what's unclear about this.  To satisfy Patrik's question,
we're not (thankfully) talking about a delayed response and I'm now sure
that you haven't suggested that kind of operating mode -- we're talking
about an operation that might require third-party (maybe an offline person)
action before the requested action can be completed.  The protocol already
includes features to deal with this: object status can be determined using
the <info> command, and the server can let the client know when the offline
action has been completed using a polled message.

-Scott-

From: "Liu, Hong" <[email-masked]>
To: [email-masked]
Subject: RE: Proposed Document Changes - Pending Operations
Date: Thu, 18 Jul 2002 22:35:34 -0400
Sender: [email-masked]

Patrik,

I guess we had different definition for "delayed execution". Please refer to
my response to Scott's email. In short, pending operation does not call for
delayed response. In fact, it calls for additional information once the
pending operation is completed.

So the correct use of <status> command, under the proposed change, is to
find out whether the previous client command has been successfully processed
by the server. This does not mean that the operation requested in the
command has been completed by the server. What I need is a notification
mechanism in EPP for the latter.

--Hong

-----Original Message-----
From: Patrik Fältström [mailto:[email-masked]]
Sent: Thursday, July 18, 2002 7:48 PM
To: Hollenbeck, Scott; Liu, Hong; [email-masked]
Subject: Re: Proposed Document Changes - Pending Operations

--On 2002-07-18 19.25 -0400 "Hollenbeck, Scott" <[email-masked]>
wrote:

> I'm not sure I understand what you mean by "pending operation".  Given
> that all commands are supposed to receive a response immediately after
> being received and processed, there should never be a situation where a
> command is sent and it takes "a long time" before the server sends back a
> response, so I hope that's not what you're asking about.

I explicitly want to know whether this wg _really_ want to have what I
would call "delayed execution" or not. I heard from Scott and the wg chairs
when we had lunch that the wg has not wanted delayed execution.

I am even prepared saying that I don't see any need for either delayed
execution or pipelining in the protocol. It makes the protocol MUCH more
difficult. The current protocol do not handle either delayed execution or
pipelining, so if you want either of these things, you really have to go
back to the drawing board.

Scott and wg chairs told me the wg have not expressed interest in those
"features", and that the wording which is used today is possibly there
because of misunderstanding whether words are needed in the core protocol
or the protocol binding. This I think is much better if the changes Scott
propose are applied.

  paf

From: "Liu, Hong" <[email-masked]>
To: [email-masked]
Subject: RE: Proposed Document Changes - Pending Operations
Date: Thu, 18 Jul 2002 22:28:37 -0400
Sender: [email-masked]

Scott,

Thanks for the explanation. I should have mentioned in the beginning about
what I meant by "pending operation". So here is the definition: 

"A pending operation refers to a server operation requested by a client
command whose execution is pending at the time the server issues the
response to the command."

As such, the server dose NOT hold off the response to the command. In fact,
it replies with result code "Command completed successfully; action pending"
as you suggested in [i]. You put it quite correctly then that a response to
a command by the server only signals that the command has been processed
successfully. It does not necessarily mean that the operation requested in
the command has been executed prior to the server's response (although in
many cases it does). So support of pending operations does not in itself
breaks the tightly coupled command-response model of EPP. 

So yes, I was referring to the back-end processing that requires time to
complete. The most obvious one is transfer, and it has been taken care of in
EPP through special treatment. However, there are other use cases. Pending
update was the one I used as an example [ii] and you and Bruce also gave
example for "pending create" [i][iii]. I hope we can agree that these are
also valid use cases for EPP.

What I am looking for is a way to notify the client when the pending
operation is completed. Be it poll or push, we need something to put into
the message queue to indicate whether the pending operation is successful or
failed. <transfer> is treated specially in EPP so it is OK. Could you please
expand on how other pending operations may be supported by the message queue
and the <poll>? What message content shall we use and how do we identify the
pending operation in the message? I just need a solution to this problem.
Maybe an example, say for a pending create, would be very helpful.

I might have misunderstood a private email you and I exchanged regarding
using the <status> command. I will send it again to you in private. 

Thanks!

--Hong

[i]  http://www.cafax.se/ietf-provreg/maillist/2002-02/msg00038.html
[ii] http://www.cafax.se/ietf-provreg/maillist/2002-02/msg00035.html
[iii] http://www.cafax.se/ietf-provreg/maillist/2002-03/msg00000.html

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: Thursday, July 18, 2002 7:26 PM
To: Liu, Hong; [email-masked]
Subject: Re: Proposed Document Changes - Pending Operations

Hong,

You read my description of the change to <status> correctly.

I'm not sure I understand what you mean by "pending operation".  Given that
all commands are supposed to receive a response immediately after being
received and processed, there should never be a situation where a command is
sent and it takes "a long time" before the server sends back a response, so
I hope that's not what you're asking about.

<HL This is not what I meant. />

If you're talking about commands like <transfer> where some back-end
processing is required before the command can be completed, we already have
mechanisms in place to check on the status of the command.  Transfer, for
example, has a query command.

We already have a mechanism in place for the server to notify clients when
such operations are completed.  That's what message queuing and the <poll>
command are for.

Your original suggestion was target more towards updates, though.  I don't
recall there being unanimous support for the changes suggested in the
message you referenced, though I agreed to pass them to the IESG as part of
he last call (I did, and there's been no reaction).  Looking at the
archives, one person said "OK" and one objected.  I also didn't say anything
about use of <status> for this purpose in my response [1].  I can't see how
it can be used as all it does is confirm that a command has been received --
it doesn't tell you if policy-driven back-end processing has been completed.

Anyway, I'm OK with the changes you suggested in March as long as no one
objects.  The change to the <status> command doesn't impact this change at
all as the "pending" status can be determined using an <info> command.

-Scott-

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

----- Original Message -----
From: "Liu, Hong" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, July 18, 2002 6:45 PM
Subject: RE: Proposed Document Changes - Pending Operations

> Scott,
>
> I do have a concern about the proposed change for the use of <status>
> command that I hope you will address.
>
> Do you imply that <status> command can now only be used for checking the
> last unacknowledged command from the client? If so, what mechansim is
> available for the client to check the status of a pending operation [a]? I
> recall in that discussion, you suggested that the <status> command be used
> for that purpose. I assume that you will incorporate the changes suggested
> in [a] to the final EPP documents.
>
> I have no objection to the change as long as there is an alternative for
the
> server to notify the client about the completion of a pending operation.
May
> I suggest that we add two new result codes: "Pending operation successful"
> and "Pending operation failed" for that purpose?
>
> Another related issue is how the server identify the pending operation.
> Since with the proposed change, the server only caches the client
> transaction identifier for the last command processed, it will not have it
> available when it completes the pending operation (presumably after many
> other commands processed in between). Should the server transaction ID be
> used instead?
>
> I hope that I won't be penalized for speaking up, -:)
>
> Thanks!
>
> --Hong
>
> [a] http://www.cafax.se/ietf-provreg/maillist/2002-03/msg00006.html
>
> Sent: Wednesday, July 17, 2002 5:57 PM
> To: [email-masked]
> Subject: Proposed Document Changes
>
>
> [snip...]
>
> - The description of the <status> command should be changed to describe
the
> server's caching responsibilities.  We agreed that the server should only
be
> responsible for caching the identifier for the last command processed,
thus
> if a response isn't received the client should send a <status> command
> before sending any subsequent commands.  This should make <status>
> processing a lot easier for the server, and it's consistent with the
> protocol's command-response operating mode.  It might also make sense to
> make the client transaction identifier mandatory instead of optional if
the
> server doesn't have to cache identifiers for "a long time".
>
> [snip...]
>
> If anyone has any issues or concerns with the above, speak up!
>
> -Scott-
>
> [1]
> http://www.cafax.se/ietf-provreg/maillist/2002-06/msg00015.html
>

Date: Fri, 19 Jul 2002 08:47:53 +0900
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>, "Liu, Hong" <[email-masked]>, [email-masked]
Subject: Re: Proposed Document Changes - Pending Operations
Sender: [email-masked]

--On 2002-07-18 19.25 -0400 "Hollenbeck, Scott" <[email-masked]>
wrote:

> I'm not sure I understand what you mean by "pending operation".  Given
> that all commands are supposed to receive a response immediately after
> being received and processed, there should never be a situation where a
> command is sent and it takes "a long time" before the server sends back a
> response, so I hope that's not what you're asking about.

I explicitly want to know whether this wg _really_ want to have what I
would call "delayed execution" or not. I heard from Scott and the wg chairs
when we had lunch that the wg has not wanted delayed execution.

I am even prepared saying that I don't see any need for either delayed
execution or pipelining in the protocol. It makes the protocol MUCH more
difficult. The current protocol do not handle either delayed execution or
pipelining, so if you want either of these things, you really have to go
back to the drawing board.

Scott and wg chairs told me the wg have not expressed interest in those
"features", and that the wording which is used today is possibly there
because of misunderstanding whether words are needed in the core protocol
or the protocol binding. This I think is much better if the changes Scott
propose are applied.

  paf

From: "Hollenbeck, Scott" <[email-masked]>
To: "Liu, Hong" <[email-masked]>, <[email-masked]>
Subject: Re: Proposed Document Changes - Pending Operations
Date: Thu, 18 Jul 2002 19:25:35 -0400
Sender: [email-masked]

Hong,

You read my description of the change to <status> correctly.

I'm not sure I understand what you mean by "pending operation".  Given that
all commands are supposed to receive a response immediately after being
received and processed, there should never be a situation where a command is
sent and it takes "a long time" before the server sends back a response, so
I hope that's not what you're asking about.

If you're talking about commands like <transfer> where some back-end
processing is required before the command can be completed, we already have
mechanisms in place to check on the status of the command.  Transfer, for
example, has a query command.

We already have a mechanism in place for the server to notify clients when
such operations are completed.  That's what message queuing and the <poll>
command are for.

Your original suggestion was target more towards updates, though.  I don't
recall there being unanimous support for the changes suggested in the
message you referenced, though I agreed to pass them to the IESG as part of
he last call (I did, and there's been no reaction).  Looking at the
archives, one person said "OK" and one objected.  I also didn't say anything
about use of <status> for this purpose in my response [1].  I can't see how
it can be used as all it does is confirm that a command has been received --
it doesn't tell you if policy-driven back-end processing has been completed.

Anyway, I'm OK with the changes you suggested in March as long as no one
objects.  The change to the <status> command doesn't impact this change at
all as the "pending" status can be determined using an <info> command.

-Scott-

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

----- Original Message -----
From: "Liu, Hong" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, July 18, 2002 6:45 PM
Subject: RE: Proposed Document Changes - Pending Operations

> Scott,
>
> I do have a concern about the proposed change for the use of <status>
> command that I hope you will address.
>
> Do you imply that <status> command can now only be used for checking the
> last unacknowledged command from the client? If so, what mechansim is
> available for the client to check the status of a pending operation [a]? I
> recall in that discussion, you suggested that the <status> command be used
> for that purpose. I assume that you will incorporate the changes suggested
> in [a] to the final EPP documents.
>
> I have no objection to the change as long as there is an alternative for
the
> server to notify the client about the completion of a pending operation.
May
> I suggest that we add two new result codes: "Pending operation successful"
> and "Pending operation failed" for that purpose?
>
> Another related issue is how the server identify the pending operation.
> Since with the proposed change, the server only caches the client
> transaction identifier for the last command processed, it will not have it
> available when it completes the pending operation (presumably after many
> other commands processed in between). Should the server transaction ID be
> used instead?
>
> I hope that I won't be penalized for speaking up, -:)
>
> Thanks!
>
> --Hong
>
> [a] http://www.cafax.se/ietf-provreg/maillist/2002-03/msg00006.html
>
> Sent: Wednesday, July 17, 2002 5:57 PM
> To: [email-masked]
> Subject: Proposed Document Changes
>
>
> [snip...]
>
> - The description of the <status> command should be changed to describe
the
> server's caching responsibilities.  We agreed that the server should only
be
> responsible for caching the identifier for the last command processed,
thus
> if a response isn't received the client should send a <status> command
> before sending any subsequent commands.  This should make <status>
> processing a lot easier for the server, and it's consistent with the
> protocol's command-response operating mode.  It might also make sense to
> make the client transaction identifier mandatory instead of optional if
the
> server doesn't have to cache identifiers for "a long time".
>
> [snip...]
>
> If anyone has any issues or concerns with the above, speak up!
>
> -Scott-
>
> [1]
> http://www.cafax.se/ietf-provreg/maillist/2002-06/msg00015.html
>

From: "Hollenbeck, Scott" <[email-masked]>
To: "Liu, Hong" <[email-masked]>, <[email-masked]>
Subject: Re: Multiple Extension Elements  for Command/Response in EPP
Date: Thu, 18 Jul 2002 18:47:42 -0400
Sender: [email-masked]

Hong,

I don't think what you're asking for is needed because the current syntax
permits multiple extensions within a single <extension> element.  Here's the
types involved:

<complexType name="commandType">
  <sequence>
...
    <element name="extension" type="epp:extAnyType"
     minOccurs="0"/>
...
  </sequence>
</complexType>

<complexType name="extAnyType">
  <sequence>
    <any namespace="##other"
     maxOccurs="unbounded"/>
  </sequence>
</complexType>

See the 'maxOccurs="unbounded"' attribute in the definition of extAnyType?

-Scott-

----- Original Message -----
From: "Liu, Hong" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, July 18, 2002 5:24 PM
Subject: Multiple Extension Elements for Command/Response in EPP

> Scott,
>
> I would like to request a small change in epp-1.0.xsd to allow multiple
> <extension> elements at the command and response level. Specifically, the
> changes are:
>
> (1) On page 56 of EPP-06 under the <commandType> definition, add attribute
> "maxOccurs=unbounded" to the <extension> element.
> (2) On page 59 of EPP-06 under the <responseType> definition, add
attribute
> "maxOccurs=unbounded" to the <extension> element.
>
> This change is based on the experiences gained through our recent EPP
> extension work (usTLD, EPP PUSH, etc...). At present, at most one
> <extension> is allowed. If I have two independent extensions for an object
> type, say domain, then I cannot list them independently in the command and
> response. Allowing multiple <extension> elements can solve the problem.
>
> Thanks!
>
> --Hong
>

From: "Liu, Hong" <[email-masked]>
To: [email-masked]
Subject: RE: Proposed Document Changes - Pending Operations
Date: Thu, 18 Jul 2002 18:45:59 -0400
Sender: [email-masked]

Scott,

I do have a concern about the proposed change for the use of <status>
command that I hope you will address. 

Do you imply that <status> command can now only be used for checking the
last unacknowledged command from the client? If so, what mechansim is
available for the client to check the status of a pending operation [a]? I
recall in that discussion, you suggested that the <status> command be used
for that purpose. I assume that you will incorporate the changes suggested
in [a] to the final EPP documents.

I have no objection to the change as long as there is an alternative for the
server to notify the client about the completion of a pending operation. May
I suggest that we add two new result codes: "Pending operation successful"
and "Pending operation failed" for that purpose? 

Another related issue is how the server identify the pending operation.
Since with the proposed change, the server only caches the client
transaction identifier for the last command processed, it will not have it
available when it completes the pending operation (presumably after many
other commands processed in between). Should the server transaction ID be
used instead?

I hope that I won't be penalized for speaking up, -:)

Thanks!

--Hong

[a] http://www.cafax.se/ietf-provreg/maillist/2002-03/msg00006.html

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: Wednesday, July 17, 2002 5:57 PM
To: [email-masked]
Subject: Proposed Document Changes

[snip...]

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

[snip...]

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

-Scott-

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

From: "Liu, Hong" <[email-masked]>
To: [email-masked]
Subject: Multiple Extension Elements  for Command/Response in EPP
Date: Thu, 18 Jul 2002 16:24:15 -0500
Sender: [email-masked]

Scott,

I would like to request a small change in epp-1.0.xsd to allow multiple
<extension> elements at the command and response level. Specifically, the
changes are:

(1) On page 56 of EPP-06 under the <commandType> definition, add attribute
"maxOccurs=unbounded" to the <extension> element.
(2) On page 59 of EPP-06 under the <responseType> definition, add attribute
"maxOccurs=unbounded" to the <extension> element.

This change is based on the experiences gained through our recent EPP
extension work (usTLD, EPP PUSH, etc...). At present, at most one
<extension> is allowed. If I have two independent extensions for an object
type, say domain, then I cannot list them independently in the command and
response. Allowing multiple <extension> elements can solve the problem.

Thanks!

--Hong

From: "Hollenbeck, Scott" <[email-masked]>
To: <[email-masked]>
Subject: Proposed Document Changes
Date: Wed, 17 Jul 2002 17:56:33 -0400
Sender: [email-masked]

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

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

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

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

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

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

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

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

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

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

-Scott-

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

From: [email-masked]
To: [email-masked]
Date: Thu, 18 Jul 2002 06:50:16 +0700
Subject: (Fwd) .ID - plan to open zone transfer
Reply-To: [email-masked]
Content-description: Mail message body
Sender: [email-masked]

Sorry, a little out of topic.
I thought since this list has many respected people,
then I should cross post my email.
Sorry for any inconveniences.

-- budi

------- Forwarded message follows -------
From:           	[email-masked]
To:             	[email-masked]
Date sent:      	Thu, 18 Jul 2002 06:46:26 +0700
Subject:        	.ID - plan to open zone transfer
Priority:       	normal

Folks,
internally we (.ID ) is planning to open zone transfer
to various parties, including gTLD registrars.
No firm deadline/timeline is scheduled though.

We are looking for comments/suggestions/best practices
from other ccTLDs.
- is there any value in this?
- things that we should watch for?
- what can we get from gTLD registrars?
- should we jump into "new" protocols & techniques
  (eg. EPP and the like or should we stick with
  conventional methods?)
- agreement template?
- general comments?

[Note: To those who asked us about ICANN.
Yes, we allow zone transfer to ICANN. Why shouldn't we?]

Also, we are looking for secondaries (will be part of
glue record) for .ID and second level domains under .ID.
Suggestions to increase our reliability is welcome.

Regards
-- budi
------- End of forwarded message -------

From: "Hollenbeck, Scott" <[email-masked]>
To: <[email-masked]>
Subject: Proposed Document Changes
Date: Wed, 17 Jul 2002 17:56:33 -0400
Sender: [email-masked]

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

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

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

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

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

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

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

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

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

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

-Scott-

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

From: "Ram Mohan" <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>, "'Liu, Hong'" <[email-masked]>, <[email-masked]>
Subject: Re: EPP PUSH: Session Property Re-negotiation
Date: Mon, 8 Jul 2002 12:40:15 -0400
Organization: Afilias
Sender: [email-masked]

scott,
i agree- i don't see a compelling reason to change basic session negotiation
features and requirements.

-ram
----- Original Message -----
From: "Hollenbeck, Scott" <[email-masked]>
To: "'Liu, Hong'" <[email-masked]>; <[email-masked]>
Sent: Monday, July 08, 2002 9:07 AM
Subject: RE: EPP PUSH: Session Property Re-negotiation

> > I would like to know how people on the list feel about it: is
> > it desirable
> > to allow session property re-negotiation after the session is set up?
>
> I think it best to deal with renegotiation only by ending a session and
> starting a new one.  It keeps things simpler and consistent with other
> session negotiation features.
>
> -Scott-
>

From: "Liu, Hong" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: EPP PUSH: Session Property Re-negotiation
Date: Mon, 8 Jul 2002 09:15:52 -0500 
Sender: [email-masked]

I agree with you on this issue, too. In the case of TCP, since the server
cannot initiate a new session, if it does not have other push-enabled
sessions after terminating the current one, it has to wait for the client to
establish a new session (an negotiate it as push-enabled) before it can push
data again to the client.

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: Monday, July 08, 2002 9:07 AM
To: 'Liu, Hong'; [email-masked]'
Subject: RE: EPP PUSH: Session Property Re-negotiation

> I would like to know how people on the list feel about it: is 
> it desirable
> to allow session property re-negotiation after the session is set up?

I think it best to deal with renegotiation only by ending a session and
starting a new one.  It keeps things simpler and consistent with other
session negotiation features.

-Scott-

From: "Liu, Hong" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: EPP PUSH: Session Setup  Semantics
Date: Mon, 8 Jul 2002 09:12:24 -0500 
Sender: [email-masked]

Scott,

Thanks for the comment. I agree with you on this. The upcoming draft will
take this approach, and also discuss the interactions between push and poll.

Cheers,

--Hong

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: Monday, July 08, 2002 9:06 AM
To: 'Liu, Hong'; [email-masked]'
Subject: RE: EPP PUSH: Session Setup Semantics

> Suppose both the server and the client agree on supporting 
> EPP PUSH in this
> session, there are two possible semantics:
> a. Push-only semantics. The session can only be used for server-pushed
> messages. The client cannot use <poll> in this session to 
> retrieve messages
> from the server.
> b. Mixed semantics. Both server-push and client-poll are allowed.
> In both cases, I think it is reasonable to assume that other 
> EPP commands
> and responses are allowed.
> 
> Which semantics should we pick, (a) or (b)? 
> Is this a registry policy issue or a standardization issue?

I believe that (b) is the proper approach.  Polling is a "standard" protocol
feature that you can't just eliminate, so I see it as a standardization (and
thus interoperability) issue.

-Scott-

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Roger Castillo Cortazar'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: <poll> result codes
Date: Mon, 8 Jul 2002 09:14:33 -0400 
Sender: [email-masked]

Hmm, I think you're right -- the response code says that a message is
dequeued with a request, but the text says it should only be dequeued with
an ack.  I think I need to fix that response text.  I'll send this to the
list so others can note the issue.

When I next edit the EPP core doc, the text for the 1301 response code
should be changed to something like this:

"1301    "Command completed successfully; ack to dequeue message"
This response code MUST be returned when responding to a <poll>
request command and a message has been retrieved from the server
message queue."

Thanks for catching this!

-Scott-

-----Original Message-----
From: Roger Castillo Cortazar [mailto:[email-masked]]
Sent: Friday, July 05, 2002 5:36 PM
To: [email-masked]
Subject: <poll> result codes

Hi Scott.

I was writing use-cases for our EPP implementation and I have 
a few comments about the <poll> command and the result codes.

In the draft-ietf-provreg-epp-06.txt document we can read:

2.8.2.3 EPP <poll> Command
  ..........................................................After a
  message has been received by the client, the client MUST respond to
  the message with an explicit acknowledgement to confirm that the
  message has been received.  A server MUST dequeue the message and
  decrement the queue counter after receiving acknowledgement from the
  client, making the next message in the queue (if any) available for
  retrieval.
  
The message is dequeued just after receiving an acknowledgement 
from the client.
  
I think the result codes for the "req" and "ack" options of the <poll>
command server response examples are mixed, or inverted, although 
the message "count" attributes look good.

Even the result code description looks a little confusing for me..

  1301    "Command completed successfully; message dequeued"
  This response code MUST be returned when responding to a <poll>
  request command and a message has been dequeued from the server
  message queue.

The message is not dequeued when responding to a <poll> request, 
but when responding to a <poll> acknowledge command.

You can take a look at the <poll> examples and the result codes definitions.

Greetings, and I hope not being a bother.

Roger Castillo Cortazar
NIC-Mexico http://www.nic.mx
Top Level Domain .MX

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Liu, Hong'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: EPP PUSH: Session Property Re-negotiation
Date: Mon, 8 Jul 2002 09:07:18 -0400 
Sender: [email-masked]

> I would like to know how people on the list feel about it: is 
> it desirable
> to allow session property re-negotiation after the session is set up?

I think it best to deal with renegotiation only by ending a session and
starting a new one.  It keeps things simpler and consistent with other
session negotiation features.

-Scott-

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Liu, Hong'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: EPP PUSH: Session Setup  Semantics
Date: Mon, 8 Jul 2002 09:05:42 -0400 
Sender: [email-masked]

> Suppose both the server and the client agree on supporting 
> EPP PUSH in this
> session, there are two possible semantics:
> a. Push-only semantics. The session can only be used for server-pushed
> messages. The client cannot use <poll> in this session to 
> retrieve messages
> from the server.
> b. Mixed semantics. Both server-push and client-poll are allowed.
> In both cases, I think it is reasonable to assume that other 
> EPP commands
> and responses are allowed.
> 
> Which semantics should we pick, (a) or (b)? 
> Is this a registry policy issue or a standardization issue?

I believe that (b) is the proper approach.  Polling is a "standard" protocol
feature that you can't just eliminate, so I see it as a standardization (and
thus interoperability) issue.

-Scott-

To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>, Internet Architecture Board <[email-masked]>, [email-masked]
From: The IESG <[email-masked]>
Subject: Document Action: Generic Registry-Registrar Protocol Requirements  to Informational
Date: Fri, 05 Jul 2002 09:06:56 -0400
Sender: [email-masked]

The IESG has approved the Internet-Draft 'Generic Registry-Registrar 
Protocol Requirements' <draft-ietf-provreg-grrp-reqs-06.txt> as an
Informational RFC. This document is the product of the Provisioning Registry
Protocol Working Group.

The IESG contact persons are Ned Freed and Patrik Faltstrom.

Notes to RFC-Editor:

[1] Please remove this paragraph in the Introduction at the time of
        publication:

> This document is being discussed on the "ietf-provreg" mailing list.
> To join the list, send a message to <[email-masked]> with the
> words "subscribe ietf-provreg" in the body of the message. There is a
> web site for the list archives at http://www.cafax.se/ietf-provreg.

[2] Please remove Appendix A, Revisions From Previous Version, at the
        time of publication.

From: Robert Burbidge <[email-masked]>
To: "Ietf-Provreg (E-mail)" <[email-masked]>
Subject: EPP Extensions proposal for coop: comments invited
Date: Thu, 4 Jul 2002 13:04:31 +0100 
Sender: [email-masked]

Poptel has published the first draft of its proposal for EPP extensions to
support verification in the dot coop gTLD. They can be found on our web site
at http://www.coop/registrar_docs.asp#epp. As experts that you are (!) I
would be happy for you to review this document and pass on any feedback
either directly to me, or via this list if you prefer. Documents are in Word
and PDF formats.

A few comments that I would like to make before you read the proposal.

1. It's not a formal proposal in the IETF style. Partly this is for reasons
of time (I have not the time or inclination to master the format or style of
RFC-type documents). At the moment it contains an outline of our business
process, and examples EPP document interchange.
2. It does not include a formal XML schema for the extensions - this will
happen, but I though it would be nice to get some general discussion first.
3  It is not a "general" specification for verification in all
circumstances. For dot coop, potential registrants are verified to check
that they represent valid co-operative bodies. However, we don't validate
the domain names that they may register, apart obvious things like making
sure they are end in ".coop", have not already been provisioned, and are not
on a reserved names list. I'm aware that other registries have rather
different needs that we don't try to address.

Yours in anticipation
Rob Burbidge
Poptel Limited

Date: Wed, 03 Jul 2002 11:13:06 +0200
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
To: "Liu, Hong" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: TCP Mapping 
Sender: [email-masked]

--On 2002-06-29 20.27 -0500 "Liu, Hong" <[email-masked]> wrote:

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

If Push is something that EPP needs, then it MUST be done in the EPP spec,
and not in the transport binding.

   paf

Date: Wed, 03 Jul 2002 11:10:39 +0200
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
To: Eric Brunner-Williams in Portland Maine <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: Requirements Approved! 
Sender: [email-masked]

--On 2002-06-28 13.10 -0400 Eric Brunner-Williams in Portland Maine
<[email-masked]> wrote:

> data mining at its best (rummaging in the iesg's drawers)
> 
> its been a longish hump since what, pittsburg?

One of the reasons is that many people have (externally) claimed they had
ideas and comments, but at last I had to force a timeout on those groups of
people.

I.e. it is important that this document ends up being right, and that many
people have a chance looking at it. More important than many other
documents we produce.

   paf

From: "Michael Young" <[email-masked]>
To: "=?iso-8859-1?Q?'Juli=E1n_Mu=F1oz'?=" <[email-masked]>, <[email-masked]>
Subject: RE: EPP and # of nameservers
Date: Tue, 2 Jul 2002 08:44:32 -0400
Importance: Normal
Sender: [email-masked]

Saludos de Julián,

The requirement for two nameservers really relates to best practises in
respect of DNS related RFC's such as this excerpt from #1912.  So I
would say in a registry that it’s a policy decision based on separate
considerations of EPP.   

Hope that helps.

2.8 Authority and Delegation Errors (NS records)

   You are required to have at least two nameservers for every domain,
   though more is preferred.  Have secondaries outside your network.  If
   the secondary isn't under your control, periodically check up on them
   and make sure they're getting current zone data from you.  Queries to
   their nameserver about your hosts should always result in an
   "authoritative" response.  If not, this is called a "lame
   delegation".  A lame delegations exists when a nameserver is
   delegated responsibility for providing nameservice for a zone (via NS
   records) but is not performing nameservice for that zone (usually
   because it is not set up as a primary or secondary for the zone).

Michael Young

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Julián Muñoz
Sent: Tuesday, July 02, 2002 6:07 AM
To: [email-masked]
Subject: EPP and # of nameservers

Hello,

I would like to know if the EPP protocol forces 2 nameservers per domain
name, or it won't work.

Or it is really a decision of a registry to not allow only 1 nameserver.

Thank you,

-- 
Saludos de Julián
-.-

Date: Tue, 02 Jul 2002 18:07:15 +0200
From: Jens-Uwe Gaspar <[email-masked]>
Organization: Schlund + Partner AG
To: =?iso-8859-1?Q?Juli=E1n=20Mu=F1oz?= <[email-masked]>
CC: [email-masked]
Subject: Re: EPP and # of nameservers
Sender: [email-masked]

Hi,

Julián Muñoz wrote:
> 
> Hello,
> 
> I would like to know if the EPP protocol forces 2 nameservers per domain
> name, or it won't work.
> 
> Or it is really a decision of a registry to not allow only 1 nameserver.

It's registry-policy.

Remember, if registry uses nameserver-objects, then there must be
a possibility to attach glue-nameservers to a domain:

  NEW domain foo.info (without nameservers)
  NEW host  ns1.foo.info
  NEW host  ns2.foo.info
  UPD domain foo.info (attach ns1/ns2.foo.info)

First step is needed, because you cannot create nameserver-objects,
if the parent domain is not already existing.

--

Kind regards,

Jens-Uwe Gaspar

________________________________________________________________________
Jens-Uwe Gaspar                              Schlund + Partner AG
E-Mail: [email-masked]                       Erbprinzenstr. 4 - 12
Tel. +49-721-91374-50                        76133 Karlsruhe, Germany
Fax  +49-721-91374-20                        http://www.schlund.de

Date: Tue, 2 Jul 2002 11:08:15 -0400
To: "Ram Mohan" <[email-masked]>, "Edmon Chung" <[email-masked]>, =?iso-8859-1?Q?Juli=E1n?= =?iso-8859-1?Q?_?= =?iso-8859-1?Q?Mu=F1oz?=  <[email-masked]>, <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: EPP and # of nameservers
Sender: [email-masked]

EPP does not impose a 2 name server limit (i.e., does not enforce a 2 
name server minimum).

Such a limit is a registry-specific policy decision.  EPP is designed 
to be policy neutral.  I.e., a registrar can send an EPP schema with 
just one name server in a request and the registry has the option to 
deny the request.  This option is taken at a layer above the EPP 
protocol.  The only diffence to EPP is whether the registrar returns 
an 'ack' or 'nack' to the request.

At 9:29 AM -0400 7/2/02, Ram Mohan wrote:
>EPP itself, afaik, does not impose a 2 name server limit -- we've created
>test names with no host objects associated.
>
>we don't publish to the zone file if we have less than 2 name servers -
>that's a policy decision, not a protocol one.

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

From: "Ram Mohan" <[email-masked]>
To: "Edmon Chung" <[email-masked]>, =?iso-8859-1?Q?Juli=E1n_Mu=F1oz?= <[email-masked]>, <[email-masked]>
Subject: Re: EPP and # of nameservers
Date: Tue, 2 Jul 2002 09:29:55 -0400
Organization: Afilias
Sender: [email-masked]

EPP itself, afaik, does not impose a 2 name server limit -- we've created
test names with no host objects associated.

we don't publish to the zone file if we have less than 2 name servers -
that's a policy decision, not a protocol one.

-ram
--------------------------------------------------------
Ram Mohan
Vice President, Business Operations / CTO
Afilias.INFO
p: +1-215-706-5700; f: +1-215-706-5701
e: [email-masked]
--------------------------------------------------------

----- Original Message -----
From: "Edmon Chung" <[email-masked]>
To: "Julián Muñoz" <[email-masked]>; <[email-masked]>
Sent: Tuesday, July 02, 2002 8:38 AM
Subject: Re: EPP and # of nameservers

> I would be very surprised if EPP itself did force the rule of at least 2
> nameservers, cause I think a domain could be created with no name servers.
> EPP is a general provisioning framework, registry policies would be
> implemented in the registry system after obtaining information that was
sent
> via EPP.  This is based on my understanding and our implementation of EPP
to
> complement our Registry System.
> Edmon
>
>
> ----- Original Message -----
> From: "Julián Muñoz" <[email-masked]>
> To: <[email-masked]>
> Sent: Tuesday, July 02, 2002 6:06 AM
> Subject: EPP and # of nameservers
>
>
> Hello,
>
> I would like to know if the EPP protocol forces 2 nameservers per domain
> name, or it won't work.
>
> Or it is really a decision of a registry to not allow only 1 nameserver.
>
>
> Thank you,
>
>
>
> --
> Saludos de Julián
> -.-
>
>
>
>
>
>
>

From: "Edmon Chung" <[email-masked]>
To: "Julián Muñoz" <[email-masked]>, <[email-masked]>
Subject: Re: EPP and # of nameservers
Date: Tue, 2 Jul 2002 08:38:23 -0400
Sender: [email-masked]

I would be very surprised if EPP itself did force the rule of at least 2
nameservers, cause I think a domain could be created with no name servers.
EPP is a general provisioning framework, registry policies would be
implemented in the registry system after obtaining information that was sent
via EPP.  This is based on my understanding and our implementation of EPP to
complement our Registry System.
Edmon

----- Original Message -----
From: "Julián Muñoz" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, July 02, 2002 6:06 AM
Subject: EPP and # of nameservers

Hello,

I would like to know if the EPP protocol forces 2 nameservers per domain
name, or it won't work.

Or it is really a decision of a registry to not allow only 1 nameserver.

Thank you,

--
Saludos de Julián
-.-

Date: Tue, 2 Jul 2002 10:06:59 +0000 (GMT)
From: =?ISO-8859-1?Q?Juli=E1n_Mu=F1oz?= <[email-masked]>
To: <[email-masked]>
Subject: EPP and # of nameservers
Sender: [email-masked]

Hello,

I would like to know if the EPP protocol forces 2 nameservers per domain
name, or it won't work.

Or it is really a decision of a registry to not allow only 1 nameserver.

Thank you,

-- 
Saludos de Julián
-.-

From: "Liu, Hong" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: EPP PUSH: Session Property Re-negotiation
Date: Mon, 1 Jul 2002 13:33:59 -0500 
Sender: [email-masked]

Hi, all,

This quesiton has to do with whether the server can change the session
property regarding PUSH or not PUSH after the session is set up.

At present, if a session is set up for PUSH, the server is allowed to push
data to the client and the client shall be ready to process server-pushed
messages. On the other hand, if the session is not set up for PUSH, the
server shall not push data to the client and the client shall reject any
server-pushed message. The PUSH vs. not PUSH property is set during session
establishment and persists throughout the session until it is closed down.
This is the basic PUSH.

I would like to know how people on the list feel about it: is it desirable
to allow session property re-negotiation after the session is set up?

Thanks!

--Hong

From: "Liu, Hong" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: EPP PUSH: Session Setup  Semantics
Date: Mon, 1 Jul 2002 12:45:48 -0500 
Sender: [email-masked]

Hi, all,

Now that we are moving towards developing a transport neutral EPP PUSH
capability, I would like to ping the list on some design choices at hand.

The first issue comes to mind is what we mean by setting up a session that
the server can push data to the client. To set the context, I reiterate the
EPP session setup procedure in my previous email. I will use the terms
"server" and "client" as defined in the base EPP.

1. Upon  successful connection establishment, the server sends a <greeting>
message to the client, advertising its intent to support EPP PUSH in the
this EPP session. This is done by supplying the EPP PUSH URI as an <extURI>
value within the <svcExtension> field.
2. The client responds with a <login> command. The client includes the EPP
PUSH URI as an <extURI> value within the <svcExtension> field if and only if
it agrees to support EPP PUSH in this session.
3. The server responds to the <login> command.

If the client logins successfully, the EPP session is established AND both
the server and the client are in sync about whether this session can be used
for server-pushed data or not. Here is the potential ambiguity I would like
to resolve.

Suppose both the server and the client agree on supporting EPP PUSH in this
session, there are two possible semantics:
a. Push-only semantics. The session can only be used for server-pushed
messages. The client cannot use <poll> in this session to retrieve messages
from the server.
b. Mixed semantics. Both server-push and client-poll are allowed.
In both cases, I think it is reasonable to assume that other EPP commands
and responses are allowed.

Which semantics should we pick, (a) or (b)? 
Is this a registry policy issue or a standardization issue?

Cheers,

--Hong

To: "Liu, Hong" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: TCP Mapping 
Date: Mon, 01 Jul 2002 11:39:45 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Hong,

I'm sure Scott will be gratified.

Some observations:

	o NeuStar's rtk packages may need only minor or no modification to
	  skip the tcp header length error check, and not discard a message
	  which appears to be corrupted,

	o Liberty's rtk package's also may be easily modified to skip the
	  same apparent error condition,

	o It is unlikely that ordinary interoperability testing would ever
	  initiate a transfer of size 2^^24 bits, as you observed in your
	  initial note, and discover an unexpected return value,

	o I expect that the NeuStar's rtk packages can be modified to
	  reduce the probability of triggering a "large" return, exceeding
	  the 2^^24 bit size limit (or 2^^31 for that matter), quite possibly
	  it can't support large messages anyway,

	o I expect that ICANN could be pursuaded that "very large" queries
	  (made by non-NeuStar rtks, should any be used to connect to the
	  NeuStar registry, lacking the above "throttling limit"), are not
	  good policy, and so may be truncated (or discarded) at the whim
	  of the registry (or near 2^^24 bits).

In short, if you were willing to create an exception to the eventual status
docs this WG may produce, and simply require that length-based error check
not be used when clients connect your server, no one would ever have known
that NeuStar is using one or more low-probability-of-use bits in the tcp
header.

It used to be necessary to turn off udp checksums to run nfs (version 2) on
any kind of network. Turning off length-based error checking when connecting
to the NeuStar registry would be no stranger to experienced operators. It is
hard to distinguish from turning off parser validation.

I look forward to a draft.

Eric

From: "Liu, Hong" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: TCP Mapping 
Date: Mon, 1 Jul 2002 09:42:13 -0500 
Sender: [email-masked]

Eric,

Given the input we gathered from the list, we (my coauthors and I) decided
to adopt Scott's suggestion and forgo the "P"-bit option. I don't feel the
need to dwell on this subject any longer. 

Our draft is forth-coming. So please stay tuned...

--Hong

-----Original Message-----
From: Eric Brunner-Williams in Portland Maine
[mailto:[email-masked]]
Sent: Monday, July 01, 2002 7:04 AM
To: Liu, Hong
Cc: [email-masked]'; [email-masked]
Subject: Re: TCP Mapping 

Hong,

You've answered a flow-control (dualing endpoints flipping P-BITS) query.

You've answered a payload (same as <poll> elements, and unspec else) query.

For reasons I'm unclear on, your comments across several items of mail
suggest that these are mutually exclusive mechanisms for "tagging" some
"server-pushed message". (See also "careful reading" below).

Am I correct in guessing that if your preferred method of signaling (P-BIT)
is the mechanism, that the payload data could be marked up as <poll> data,
with some as yet unspecified additional content?

To correctly decode <poll>, a client would have to first determin the value
of P-BIT?

Or is XML even present in the P-BIT signaled payload data?

A question I don't seem to have seen answered is how you are proposing
to modify a transport draft that has no options, and which itself is not
optional in the protocol draft. 

Are the properties you've described unique to implementations that elect
to implement them (MAY), or are they common to all implementations (MUST)?

There are business reasons why a client implementation of 6/4 over tcp
wouldn't connect to a NeuStar server implementation of 6/4. Are there also
technical reasons why the same two implementations couldn't be capable of
error-free interoperation?

There has been prior discussion of a <push> command.

Looking back over your messages I see that I wasn't carefull enough reading.
I missed the fact that you proposed to use 8 bits to signal directionality,
not one (mail of 28 June). Either that mail, or your reply to my edit of
tcp-04 (mail of 29 June), which referenced a single bit, but not both, can
be correct.

Which is it? 8 bits, or 1 bit? If 8 bits, are the remaining 7 bits
"reserved"
for some future signaling or differentiation mechanism, or are they "don't
care" (ignore)?

Eric

From: "Liu, Hong" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: push
Date: Mon, 1 Jul 2002 09:37:35 -0500 
Sender: [email-masked]

Rick,

Given what we have gathered from the list so far, we (my coauthors and I)
decided to forgo the TCP mapping option and proceed with Scott's suggestion
to define a new XML schema. I hope that clarifies your inquiry. If not,
please expand. Thanks!

--Hong

-----Original Message-----
From: Rick Wesson [mailto:[email-masked]]
Sent: Sunday, June 30, 2002 11:38 PM
To: Liu, Hong
Cc: [email-masked]'
Subject: push

Hong,

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

thanks,

-rick

To: "Liu, Hong" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: TCP Mapping 
Date: Mon, 01 Jul 2002 07:03:42 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Hong,

You've answered a flow-control (dualing endpoints flipping P-BITS) query.

You've answered a payload (same as <poll> elements, and unspec else) query.

For reasons I'm unclear on, your comments across several items of mail
suggest that these are mutually exclusive mechanisms for "tagging" some
"server-pushed message". (See also "careful reading" below).

Am I correct in guessing that if your preferred method of signaling (P-BIT)
is the mechanism, that the payload data could be marked up as <poll> data,
with some as yet unspecified additional content?

To correctly decode <poll>, a client would have to first determin the value
of P-BIT?

Or is XML even present in the P-BIT signaled payload data?

A question I don't seem to have seen answered is how you are proposing
to modify a transport draft that has no options, and which itself is not
optional in the protocol draft. 

Are the properties you've described unique to implementations that elect
to implement them (MAY), or are they common to all implementations (MUST)?

There are business reasons why a client implementation of 6/4 over tcp
wouldn't connect to a NeuStar server implementation of 6/4. Are there also
technical reasons why the same two implementations couldn't be capable of
error-free interoperation?

There has been prior discussion of a <push> command.

Looking back over your messages I see that I wasn't carefull enough reading.
I missed the fact that you proposed to use 8 bits to signal directionality,
not one (mail of 28 June). Either that mail, or your reply to my edit of
tcp-04 (mail of 29 June), which referenced a single bit, but not both, can
be correct.

Which is it? 8 bits, or 1 bit? If 8 bits, are the remaining 7 bits "reserved"
for some future signaling or differentiation mechanism, or are they "don't
care" (ignore)?

Eric

Date: Sun, 30 Jun 2002 20:38:06 -0700 (PDT)
From: Rick Wesson <[email-masked]>
To: "Liu, Hong" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: push
Sender: [email-masked]

Hong,

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

thanks,

-rick

From: "Liu, Hong" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: TCP Mapping
Date: Sun, 30 Jun 2002 21:34:27 -0500
Sender: [email-masked]

Eric,

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

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

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

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

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

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

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

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

--Hong

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

Hong,

How is your extension supposed to work?

Exactly what do you mean by "EPP PUSH"?

Eric

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

Hong,

How is your extension supposed to work?

Exactly what do you mean by "EPP PUSH"?

Eric

------- Forwarded Message

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

------- End of Forwarded Message