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

["Hollenbeck, Scott" <[e-mail]>]

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

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.

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

Yup, that's pretty much it.

-Scott-



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6VKUMo2010532 for <[e-mail]>; Wed, 31 Jul 2002 22:30:22 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g6VKULrU010529 for ietf-provreg-outgoing; Wed, 31 Jul 2002 22:30:21 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6VKUKo2010523 for <[e-mail]>; Wed, 31 Jul 2002 22:30:20 +0200 (MEST)
Received: from stntimc1.va.neustar.com (stih650a-eth-s1p2c0.va.neustar.com [209.173.53.81]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id g6VKUID16082 for <[e-mail]>; Wed, 31 Jul 2002 20:30:19 GMT
Received: by STNTIMC1 with Internet Mail Service (5.5.2653.19) id <306V43LL>; Wed, 31 Jul 2002 16:31:08 -0400
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E08410D@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: I-D on Uniform Treatment of Pending Action Notification in EP P
Date: Wed, 31 Jul 2002 16:30:58 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
Sent: Wednesday, July 31, 2002 8:50 AM
To: '[e-mail]'
Subject: RE: I-D on Uniform Treatment of Pending Action Notification in
EP P


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-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6VCoKo2005920 for <[e-mail]>; Wed, 31 Jul 2002 14:50:20 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g6VCoKUm005919 for ietf-provreg-outgoing; Wed, 31 Jul 2002 14:50:20 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6VCoJo2005914 for <[e-mail]>; Wed, 31 Jul 2002 14:50:19 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id IAA18279 for <[e-mail]>; Wed, 31 Jul 2002 08:51:03 -0400 (EDT)
Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <PXVABAF8>; Wed, 31 Jul 2002 08:50:17 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: I-D on Uniform Treatment of Pending Action Notification in EP P
Date: Wed, 31 Jul 2002 08:50:16 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6V0Rso2001366 for <[e-mail]>; Wed, 31 Jul 2002 02:27:54 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g6V0RsBI001365 for ietf-provreg-outgoing; Wed, 31 Jul 2002 02:27:54 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6V0Rqo2001360 for <[e-mail]>; Wed, 31 Jul 2002 02:27:53 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id UAA29085 for <[e-mail]>; Tue, 30 Jul 2002 20:28:36 -0400 (EDT)
Received: by vsvapostalgw2.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <PX4P7HNB>; Tue, 30 Jul 2002 20:27:50 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: I-D on Uniform Treatment of Pending Action Notification in EP P
Date: Tue, 30 Jul 2002 20:27:40 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6UIRLo2028898 for <[e-mail]>; Tue, 30 Jul 2002 20:27:21 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g6UIRLlY028897 for ietf-provreg-outgoing; Tue, 30 Jul 2002 20:27:21 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6UIRJo2028892 for <[e-mail]>; Tue, 30 Jul 2002 20:27:19 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id OAA08932 for <[e-mail]>; Tue, 30 Jul 2002 14:28:01 -0400 (EDT)
Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <PXVAA2CW>; Tue, 30 Jul 2002 14:27:16 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: I-D on Uniform Treatment of Pending Action Notification in EP P
Date: Tue, 30 Jul 2002 14:27:09 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6UGfJo2028097 for <[e-mail]>; Tue, 30 Jul 2002 18:41:19 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g6UGfJ1L028096 for ietf-provreg-outgoing; Tue, 30 Jul 2002 18:41:19 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6UGfHo2028091 for <[e-mail]>; Tue, 30 Jul 2002 18:41:17 +0200 (MEST)
Received: from stntimc1.va.neustar.com (stih650a-eth-s1p2c0.va.neustar.com [209.173.53.81]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id g6UGfFD19447 for <[e-mail]>; Tue, 30 Jul 2002 16:41:16 GMT
Received: by STNTIMC1 with Internet Mail Service (5.5.2653.19) id <306V4MQJ>; Tue, 30 Jul 2002 12:42:04 -0400
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E0840F8@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: I-D on Uniform Treatment of Pending Action Notification in EPP
Date: Tue, 30 Jul 2002 12:41:59 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:

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

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




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6TF4po2020459 for <[e-mail]>; Mon, 29 Jul 2002 17:04:51 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g6TF4pYj020458 for ietf-provreg-outgoing; Mon, 29 Jul 2002 17:04:51 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6TF4oo2020453 for <[e-mail]>; Mon, 29 Jul 2002 17:04:50 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id LAA03498 for <[e-mail]>; Mon, 29 Jul 2002 11:05:34 -0400 (EDT)
Received: by vsvapostalgw2.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <PX4P6L09>; Mon, 29 Jul 2002 11:04:49 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Stateless vs. Stateful
Date: Mon, 29 Jul 2002 11:04:48 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6T1pwo2017548 for <[e-mail]>; Mon, 29 Jul 2002 03:51:58 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g6T1pwCm017547 for ietf-provreg-outgoing; Mon, 29 Jul 2002 03:51:58 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6T1pso2017542 for <[e-mail]>; Mon, 29 Jul 2002 03:51:57 +0200 (MEST)
Received: from stntimc1.va.neustar.com (stih650a-eth-s1p2c0.va.neustar.com [209.173.53.81]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id g6T1pqD21063 for <[e-mail]>; Mon, 29 Jul 2002 01:51:53 GMT
Received: by STNTIMC1 with Internet Mail Service (5.5.2653.19) id <306V4K61>; Sun, 28 Jul 2002 21:52:41 -0400
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E0840EA@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: [e-mail]
Subject: RE: July milestones
Date: Sun, 28 Jul 2002 21:52:33 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id g6T1pvo2017543
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
Sent: Friday, July 26, 2002 9:48 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]
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                                          [phone]
ARIN Research Engineer




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6QICYo2004257 for <[e-mail]>; Fri, 26 Jul 2002 20:12:34 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g6QICYGq004256 for ietf-provreg-outgoing; Fri, 26 Jul 2002 20:12:34 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6QICXo2004250 for <[e-mail]>; Fri, 26 Jul 2002 20:12:33 +0200 (MEST)
Received: from stntimc1.va.neustar.com (stih650a-eth-s1p2c0.va.neustar.com [209.173.53.81]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id g6QICTD28816 for <[e-mail]>; Fri, 26 Jul 2002 18:12:30 GMT
Received: by STNTIMC1 with Internet Mail Service (5.5.2653.19) id <306V4KCZ>; Fri, 26 Jul 2002 14:13:17 -0400
Message-ID: <[e-mail]>
From: "Zhang, Ning" <[e-mail]>
To: [e-mail]
Subject: RE: BEEP Document Comments (was RE: July milestones)
Date: Fri, 26 Jul 2002 14:12:22 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6QGYXo2003648 for <[e-mail]>; Fri, 26 Jul 2002 18:34:33 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g6QGYXtq003647 for ietf-provreg-outgoing; Fri, 26 Jul 2002 18:34:33 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6QGYWo2003642 for <[e-mail]>; Fri, 26 Jul 2002 18:34:32 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id MAA09336; Fri, 26 Jul 2002 12:35:14 -0400 (EDT)
Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <NJVGLVWX>; Fri, 26 Jul 2002 12:34:26 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Edward Lewis'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: BEEP Document Comments (was RE: July milestones)
Date: Fri, 26 Jul 2002 12:34:26 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6QFkBo2003332 for <[e-mail]>; Fri, 26 Jul 2002 17:46:11 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g6QFkA8s003331 for ietf-provreg-outgoing; Fri, 26 Jul 2002 17:46:10 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6QFk9o2003326 for <[e-mail]>; Fri, 26 Jul 2002 17:46:10 +0200 (MEST)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g6QBiK23077707; Fri, 26 Jul 2002 11:44:20 GMT
Received: from [192.149.252.226] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA29444; Fri, 26 Jul 2002 11:46:02 -0400 (EDT)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b05b9671ee34a0f@[192.149.252.226]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Fri, 26 Jul 2002 11:45:48 -0400
To: Rick Wesson <[e-mail]>, Edward Lewis <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: Re: July milestones
Cc: <[e-mail]>, <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6QFWKo2003255 for <[e-mail]>; Fri, 26 Jul 2002 17:32:20 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g6QFWKZR003254 for ietf-provreg-outgoing; Fri, 26 Jul 2002 17:32:20 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bean.ar.com (bean.ar.com [66.123.187.68]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6QFWIo2003249 for <[e-mail]>; Fri, 26 Jul 2002 17:32:19 +0200 (MEST)
Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.2/8.12.0) with ESMTP id g6QFVdlo002427; Fri, 26 Jul 2002 08:31:39 -0700 (PDT)
Date: Fri, 26 Jul 2002 08:31:45 -0700 (PDT)
From: Rick Wesson <[e-mail]>
To: Edward Lewis <[e-mail]>
cc: <[e-mail]>, <[e-mail]>
Subject: Re: July milestones
In-Reply-To: <a05111b01b967020f885a@[192.149.252.226]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

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




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6QDlQo2002477 for <[e-mail]>; Fri, 26 Jul 2002 15:47:26 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g6QDlQDg002476 for ietf-provreg-outgoing; Fri, 26 Jul 2002 15:47:26 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6QDlOo2002471 for <[e-mail]>; Fri, 26 Jul 2002 15:47:25 +0200 (MEST)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g6Q9je23075622; Fri, 26 Jul 2002 09:45:40 GMT
Received: from [192.149.252.226] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id JAA28386; Fri, 26 Jul 2002 09:47:22 -0400 (EDT)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b01b967020f885a@[192.149.252.226]>
Date: Fri, 26 Jul 2002 09:47:38 -0400
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: July milestones
Cc: [e-mail], [e-mail]
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id g6QDlPo2002472
Sender: [e-mail]
Precedence: bulk

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




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6QB68o2001893 for <[e-mail]>; Fri, 26 Jul 2002 13:06:08 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g6QB68EC001892 for ietf-provreg-outgoing; Fri, 26 Jul 2002 13:06:08 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6QB67o2001887 for <[e-mail]>; Fri, 26 Jul 2002 13:06:07 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id HAA04368 for <[e-mail]>; Fri, 26 Jul 2002 07:06:51 -0400 (EDT)
Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <NJVGLJDB>; Fri, 26 Jul 2002 07:06:03 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: <status> command  - one more opinion
Date: Fri, 26 Jul 2002 07:06:05 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6Q2Zjo2029967 for <[e-mail]>; Fri, 26 Jul 2002 04:35:45 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g6Q2Zj2C029966 for ietf-provreg-outgoing; Fri, 26 Jul 2002 04:35:45 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6Q2Zho2029961 for <[e-mail]>; Fri, 26 Jul 2002 04:35:44 +0200 (MEST)
Received: from chiimc01.il.neustar.com (stih650a-eth-s1p2c0.va.neustar.com [209.173.53.81]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id g6Q2ZfD12685 for <[e-mail]>; Fri, 26 Jul 2002 02:35:42 GMT
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <30KQV11K>; Thu, 25 Jul 2002 21:35:36 -0500
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E0840D8@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: <status> command  - one more opinion
Date: Thu, 25 Jul 2002 21:36:28 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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

-----Original Message-----
From: Robert Burbidge [mailto:[e-mail]]
Sent: Thursday, July 25, 2002 4:33 AM
To: '[e-mail]'
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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6PKtIo2027846 for <[e-mail]>; Thu, 25 Jul 2002 22:55:18 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g6PKtI59027845 for ietf-provreg-outgoing; Thu, 25 Jul 2002 22:55:18 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6PKtGo2027840 for <[e-mail]>; Thu, 25 Jul 2002 22:55:17 +0200 (MEST)
Received: from stntimc1.va.neustar.com (stih650a-eth-s1p2c0.va.neustar.com [209.173.53.81]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id g6PKtFD06622 for <[e-mail]>; Thu, 25 Jul 2002 20:55:15 GMT
Received: by STNTIMC1 with Internet Mail Service (5.5.2653.19) id <306V42TY>; Thu, 25 Jul 2002 16:56:02 -0400
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E0840D2@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: [e-mail]
Subject: RE: Proposed Document Changes - Pending Operations
Date: Thu, 25 Jul 2002 16:56:07 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
Sent: Thursday, July 25, 2002 4:32 PM
To: Hollenbeck, Scott
Cc: Daniel Manley; [e-mail]; 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-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6PK8Zo2027570 for <[e-mail]>; Thu, 25 Jul 2002 22:08:35 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g6PK8ZnH027569 for ietf-provreg-outgoing; Thu, 25 Jul 2002 22:08:35 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6PK8Yo2027564 for <[e-mail]>; Thu, 25 Jul 2002 22:08:34 +0200 (MEST)
Received: from chiimc01.il.neustar.com (stih650a-eth-s1p2c0.va.neustar.com [209.173.53.81]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id g6PK8XD05327 for <[e-mail]>; Thu, 25 Jul 2002 20:08:33 GMT
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <30KQVBV5>; Thu, 25 Jul 2002 15:08:28 -0500
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E0840D1@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: [e-mail]
Subject: RE: Proposed Document Changes - Pending Operations
Date: Thu, 25 Jul 2002 15:09:18 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Scott,

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6PJpso2027434 for <[e-mail]>; Thu, 25 Jul 2002 21:51:54 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g6PJpsuL027433 for ietf-provreg-outgoing; Thu, 25 Jul 2002 21:51:54 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6PJpro2027428 for <[e-mail]>; Thu, 25 Jul 2002 21:51:53 +0200 (MEST)
Received: from chiimc01.il.neustar.com (stih650a-eth-s1p2c0.va.neustar.com [209.173.53.81]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id g6PJppD04768 for <[e-mail]>; Thu, 25 Jul 2002 19:51:52 GMT
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <30KQVBPM>; Thu, 25 Jul 2002 14:51:46 -0500
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E0840D0@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: [e-mail]
Subject: RE: Proposed Document Changes - Pending Operations
Date: Thu, 25 Jul 2002 14:52:38 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Scott,

I 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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6PJJ9o2027233 for <[e-mail]>; Thu, 25 Jul 2002 21:19:09 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g6PJJ9s9027232 for ietf-provreg-outgoing; Thu, 25 Jul 2002 21:19:09 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6PJJ8o2027227 for <[e-mail]>; Thu, 25 Jul 2002 21:19:08 +0200 (MEST)
Received: from chiimc01.il.neustar.com (stih650a-eth-s1p2c0.va.neustar.com [209.173.53.81]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id g6PJJ6D03505 for <[e-mail]>; Thu, 25 Jul 2002 19:19:07 GMT
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <30KQVBD5>; Thu, 25 Jul 2002 14:19:01 -0500
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E0840CD@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: [e-mail]
Subject: RE: Proposed Document Changes - Pending Operations
Date: Thu, 25 Jul 2002 14:19:57 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
Sent: Thursday, July 25, 2002 2:46 PM
To: Hollenbeck, Scott
Cc: 'janusz sienkiewicz'; Daniel Manley; [e-mail]; 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-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6PJ58o2027123 for <[e-mail]>; Thu, 25 Jul 2002 21:05:08 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g6PJ581e027122 for ietf-provreg-outgoing; Thu, 25 Jul 2002 21:05:08 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6PJ56o2027117 for <[e-mail]>; Thu, 25 Jul 2002 21:05:07 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id PAA07850; Thu, 25 Jul 2002 15:05:46 -0400 (EDT)
Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <NJVGKZGS>; Thu, 25 Jul 2002 15:05:00 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'janusz sienkiewicz'" <[e-mail]>
Cc: Daniel Manley <[e-mail]>, [e-mail], "Liu, Hong" <[e-mail]>
Subject: RE: Proposed Document Changes - Pending Operations
Date: Thu, 25 Jul 2002 15:05:00 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6PIbHo2026978 for <[e-mail]>; Thu, 25 Jul 2002 20:37:17 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g6PIbHtJ026977 for ietf-provreg-outgoing; Thu, 25 Jul 2002 20:37:17 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6PIbFo2026972 for <[e-mail]>; Thu, 25 Jul 2002 20:37:16 +0200 (MEST)
Received: from chiimc01.il.neustar.com (stih650a-eth-s1p2c0.va.neustar.com [209.173.53.81]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id g6PIbED02258 for <[e-mail]>; Thu, 25 Jul 2002 18:37:14 GMT
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <30KQVAY1>; Thu, 25 Jul 2002 13:37:09 -0500
Message-ID: <[e-mail]>
From: "Zhang, Ning" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Re: Comments on draft-ietf-provreg-epp-beep-02.txt 
Date: Thu, 25 Jul 2002 13:37:08 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6PIO8o2026788 for <[e-mail]>; Thu, 25 Jul 2002 20:24:08 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g6PIO77A026787 for ietf-provreg-outgoing; Thu, 25 Jul 2002 20:24:07 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6PIO6o2026782 for <[e-mail]>; Thu, 25 Jul 2002 20:24:07 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id OAA04814; Thu, 25 Jul 2002 14:24:50 -0400 (EDT)
Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id <M6WSB1BR>; Thu, 25 Jul 2002 14:24:04 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'janusz sienkiewicz'" <[e-mail]>
Cc: Daniel Manley <[e-mail]>, [e-mail], "Liu, Hong" <[e-mail]>
Subject: RE: Proposed Document Changes - Pending Operations
Date: Thu, 25 Jul 2002 14:24:02 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6PHvVo2026622 for <[e-mail]>; Thu, 25 Jul 2002 19:57:31 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g6PHvUJm026621 for ietf-provreg-outgoing; Thu, 25 Jul 2002 19:57:30 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail.libertyrms.com ([216.94.172.167]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6PHvUo2026616 for <[e-mail]>; Thu, 25 Jul 2002 19:57:30 +0200 (MEST)
Received: from dev3.int.libertyrms.com ([10.1.1.204] helo=libertyrms.com) by mail.libertyrms.com with esmtp (Exim 3.22 #3 (Debian)) id 17XmrV-0003I7-00; Thu, 25 Jul 2002 13:57:17 -0400
Message-ID: <[e-mail]>
Date: Thu, 25 Jul 2002 13:57:20 -0400
From: janusz sienkiewicz <[e-mail]>
Organization: LibertyRMS Co.
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Hollenbeck, Scott" <[e-mail]>
CC: Daniel Manley <[e-mail]>, [e-mail], "Liu, Hong" <[e-mail]>
Subject: Re: Proposed Document Changes - Pending Operations
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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-



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6PHtMo2026581 for <[e-mail]>; Thu, 25 Jul 2002 19:55:22 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g6PHtMXg026580 for ietf-provreg-outgoing; Thu, 25 Jul 2002 19:55:22 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6PHtLo2026575 for <[e-mail]>; Thu, 25 Jul 2002 19:55:21 +0200 (MEST)
Received: from chiimc01.il.neustar.com (stih650a-eth-s1p2c0.va.neustar.com [209.173.53.81]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id g6PHtKD01279 for <[e-mail]>; Thu, 25 Jul 2002 17:55:20 GMT
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <30KQVA3M>; Thu, 25 Jul 2002 12:55:15 -0500
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E0840CB@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: [e-mail]
Subject: RE: Proposed Document Changes - Pending Operations
Date: Thu, 25 Jul 2002 12:56:07 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
Sent: Thursday, July 25, 2002 1:18 PM
To: Daniel Manley
Cc: [e-mail]; 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
> >
> >-----Original Message-----
> >From: Patrik Fältström [mailto:[e-mail]]
> >Sent: Monday, July 22, 2002 1:32 AM
> >To: Liu, Hong; [e-mail]
> >Subject: RE: Proposed Document Changes - Pending Operations
> >
> >
> >--On 2002-07-18 22.35 -0400 "Liu, Hong" <[e-mail]> 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
> [e-mail]


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6PHgwo2026476 for <[e-mail]>; Thu, 25 Jul 2002 19:42:58 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g6PHgwG0026475 for ietf-provreg-outgoing; Thu, 25 Jul 2002 19:42:58 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6PHgvo2026470 for <[e-mail]>; Thu, 25 Jul 2002 19:42:57 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id NAA02265; Thu, 25 Jul 2002 13:43:36 -0400 (EDT)
Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id <M6WSBD1V>; Thu, 25 Jul 2002 13:42:50 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'janusz sienkiewicz'" <[e-mail]>, Daniel Manley <[e-mail]>
Cc: [e-mail], "Liu, Hong" <[e-mail]>
Subject: RE: Proposed Document Changes - Pending Operations
Date: Thu, 25 Jul 2002 13:42:49 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6PHHfo2026176 for <[e-mail]>; Thu, 25 Jul 2002 19:17:41 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g6PHHfGp026175 for ietf-provreg-outgoing; Thu, 25 Jul 2002 19:17:41 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail.libertyrms.com ([216.94.172.167]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6PHHdo2026170 for <[e-mail]>; Thu, 25 Jul 2002 19:17:39 +0200 (MEST)
Received: from dev3.int.libertyrms.com ([10.1.1.204] helo=libertyrms.com) by mail.libertyrms.com with esmtp (Exim 3.22 #3 (Debian)) id 17XmF6-0002ba-00; Thu, 25 Jul 2002 13:17:36 -0400
Message-ID: <[e-mail]>
Date: Thu, 25 Jul 2002 13:17:40 -0400
From: janusz sienkiewicz <[e-mail]>
Organization: LibertyRMS Co.
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Daniel Manley <[e-mail]>
CC: [e-mail], "Liu, Hong" <[e-mail]>
Subject: Re: Proposed Document Changes - Pending Operations
References: <5E42C1C85C5D064A947CF92FADE6D82E084098@STNTEXCH1> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

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
> >
> >-----Original Message-----
> >From: Patrik Fältström [mailto:[e-mail]]
> >Sent: Monday, July 22, 2002 1:32 AM
> >To: Liu, Hong; [e-mail]
> >Subject: RE: Proposed Document Changes - Pending Operations
> >
> >
> >--On 2002-07-18 22.35 -0400 "Liu, Hong" <[e-mail]> 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
> [e-mail]



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6PG1Uo2025531 for <[e-mail]>; Thu, 25 Jul 2002 18:01:31 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g6PG1Ueq025530 for ietf-provreg-outgoing; Thu, 25 Jul 2002 18:01:30 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from toronto.mail.tucows.com (bfos.tucows.com [207.136.98.11]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6PG1Ro2025525 for <[e-mail]>; Thu, 25 Jul 2002 18:01:28 +0200 (MEST)
Received: from dmanley.pc.internal.tucows.com ([10.0.10.19] helo=tucows.com) by toronto.mail.tucows.com with esmtp (Exim 3.36 #3) id 17Xl3O-0005HJ-00; Thu, 25 Jul 2002 12:01:26 -0400
Message-ID: <[e-mail]>
Date: Thu, 25 Jul 2002 12:02:00 -0400
From: Daniel Manley <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020606
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
CC: "Liu, Hong" <[e-mail]>
Subject: Re: Proposed Document Changes - Pending Operations
References: <5E42C1C85C5D064A947CF92FADE6D82E084098@STNTEXCH1>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

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
>
>-----Original Message-----
>From: Patrik Fältström [mailto:[e-mail]]
>Sent: Monday, July 22, 2002 1:32 AM
>To: Liu, Hong; [e-mail]
>Subject: RE: Proposed Document Changes - Pending Operations
>
>
>--On 2002-07-18 22.35 -0400 "Liu, Hong" <[e-mail]> 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
[e-mail]





Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6P8Wto2022850 for <[e-mail]>; Thu, 25 Jul 2002 10:32:55 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g6P8WteT022849 for ietf-provreg-outgoing; Thu, 25 Jul 2002 10:32:55 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from popintmanex.poptel.org.uk (popintmanex.poptel.org.uk [213.55.9.22]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6P8Wso2022844 for <[e-mail]>; Thu, 25 Jul 2002 10:32:54 +0200 (MEST)
Received: by exchange.poptel.net with Internet Mail Service (5.5.2653.19) id <PNRDDYH1>; Thu, 25 Jul 2002 09:32:51 +0100
Message-ID: <[e-mail]>
From: Robert Burbidge <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: <status> command  - one more opinion
Date: Thu, 25 Jul 2002 09:32:48 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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

Rob Burbidge
Poptel Limited



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6OJwOo2018492 for <[e-mail]>; Wed, 24 Jul 2002 21:58:24 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g6OJwOwm018491 for ietf-provreg-outgoing; Wed, 24 Jul 2002 21:58:24 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6OJwMo2018486 for <[e-mail]>; Wed, 24 Jul 2002 21:58:23 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id PAA19433; Wed, 24 Jul 2002 15:59:02 -0400 (EDT)
Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <NJVGJ8GZ>; Wed, 24 Jul 2002 15:58:16 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Liu, Hong'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Result code for "Command completed successfully; action pendi ng"
Date: Wed, 24 Jul 2002 15:58:13 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6OJXto2018370 for <[e-mail]>; Wed, 24 Jul 2002 21:33:55 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g6OJXtEF018369 for ietf-provreg-outgoing; Wed, 24 Jul 2002 21:33:55 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6OJXso2018364 for <[e-mail]>; Wed, 24 Jul 2002 21:33:54 +0200 (MEST)
Received: from stntimc1.va.neustar.com (stih650a-eth-s1p2c0.va.neustar.com [209.173.53.81]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id g6OJXqD13706 for <[e-mail]>; Wed, 24 Jul 2002 19:33:53 GMT
Received: by STNTIMC1 with Internet Mail Service (5.5.2653.19) id <306V4HHN>; Wed, 24 Jul 2002 15:34:40 -0400
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E0840B9@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Result code for "Command completed successfully; action pending"
Date: Wed, 24 Jul 2002 15:34:45 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Scott,

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

--Hong


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6OHoqo2017530 for <[e-mail]>; Wed, 24 Jul 2002 19:50:52 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g6OHoqar017529 for ietf-provreg-outgoing; Wed, 24 Jul 2002 19:50:52 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6OHopo2017524 for <[e-mail]>; Wed, 24 Jul 2002 19:50:52 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id NAA11067; Wed, 24 Jul 2002 13:51:35 -0400 (EDT)
Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id <M6WSA3FL>; Wed, 24 Jul 2002 13:50:49 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'janusz sienkiewicz'" <[e-mail]>, [e-mail]
Subject: RE: Service Message Format
Date: Wed, 24 Jul 2002 13:50:49 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


  


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6OHJCo2017276 for <[e-mail]>; Wed, 24 Jul 2002 19:19:12 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g6OHJC1g017275 for ietf-provreg-outgoing; Wed, 24 Jul 2002 19:19:12 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail.libertyrms.com ([216.94.172.167]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6OHJBo2017270 for <[e-mail]>; Wed, 24 Jul 2002 19:19:11 +0200 (MEST)
Received: from dev3.int.libertyrms.com ([10.1.1.204] helo=libertyrms.com) by mail.libertyrms.com with esmtp (Exim 3.22 #3 (Debian)) id 17XPn4-0005k5-00 for <[e-mail]>; Wed, 24 Jul 2002 13:19:10 -0400
Message-ID: <[e-mail]>
Date: Wed, 24 Jul 2002 13:19:09 -0400
From: janusz sienkiewicz <[e-mail]>
Organization: LibertyRMS Co.
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: RE: Service Message Format
Content-Type: multipart/alternative; boundary="------------CFC1E6C4A6EDC85CC78F4512"
Sender: [e-mail]
Precedence: bulk

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6OGMTo2016841 for <[e-mail]>; Wed, 24 Jul 2002 18:22:29 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g6OGMTc5016840 for ietf-provreg-outgoing; Wed, 24 Jul 2002 18:22:29 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.san.rr.com (smtp1.san.rr.com [24.25.195.37]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6OGMRo2016835 for <[e-mail]>; Wed, 24 Jul 2002 18:22:28 +0200 (MEST)
Received: from san.rr.com (66-74-216-166.san.rr.com [66.74.216.166]) by smtp1.san.rr.com (8.11.4/8.11.4) with ESMTP id g6OGMPE11916 for <[e-mail]>; Wed, 24 Jul 2002 09:22:26 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 24 Jul 2002 09:22:54 -0700
From: Darren New <[e-mail]>
Organization: Boxes!
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Comments on draft-ietf-provreg-epp-beep-02.txt
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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.


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6ODhGo2015662 for <[e-mail]>; Wed, 24 Jul 2002 15:43:16 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g6ODhGV7015661 for ietf-provreg-outgoing; Wed, 24 Jul 2002 15:43:16 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6ODhDo2015656 for <[e-mail]>; Wed, 24 Jul 2002 15:43:13 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id JAA23512; Wed, 24 Jul 2002 09:43:52 -0400 (EDT)
Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id <M6WSAG4Q>; Wed, 24 Jul 2002 09:43:06 -0400
Message-ID: <[e-mail]>
From: "Gould, James" <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>, "'Liu, Hong'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Proposed Document Changes
Date: Wed, 24 Jul 2002 09:43:06 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
Sent: Wednesday, July 24, 2002 7:14 AM
To: 'Liu, Hong'
Cc: '[e-mail]'
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.


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6OCrlo2015307 for <[e-mail]>; Wed, 24 Jul 2002 14:53:47 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g6OCrlXL015306 for ietf-provreg-outgoing; Wed, 24 Jul 2002 14:53:47 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6OCrio2015301 for <[e-mail]>; Wed, 24 Jul 2002 14:53:45 +0200 (MEST)
Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id g6OCre5d016679 for <[e-mail]>; Wed, 24 Jul 2002 14:53:40 +0200 (CEST) (envelope-from [e-mail])
Received: (from jaap@localhost) by bartok.sidn.nl (8.12.5/8.12.5/Submit) id g6OCrdTh016678 for [e-mail]; Wed, 24 Jul 2002 14:53:39 +0200 (CEST)
Received: from mail.libertyrms.com ([216.94.172.167]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6OCFfo2015063 for <[e-mail]>; Wed, 24 Jul 2002 14:15:41 +0200 (MEST)
Received: from andrew by mail.libertyrms.com with local (Exim 3.22 #3 (Debian)) id 17XL3M-0000yA-00 for <[e-mail]>; Wed, 24 Jul 2002 08:15:40 -0400
Date: Wed, 24 Jul 2002 08:15:40 -0400
From: Andrew Sullivan <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Re: Proposed Document Changes
Message-ID: <[e-mail]>
Mail-Followup-To: Andrew Sullivan <[e-mail]>, "'[e-mail]'" <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Wed, Jul 24, 2002 at 07:13:46AM -0400
Sender: [e-mail]
Precedence: bulk

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
<[e-mail]>                              M6K 3E3
                                         [phone] x110



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6OBd9o2014906 for <[e-mail]>; Wed, 24 Jul 2002 13:39:09 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g6OBd9WR014905 for ietf-provreg-outgoing; Wed, 24 Jul 2002 13:39:09 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6OBd6o2014900 for <[e-mail]>; Wed, 24 Jul 2002 13:39:08 +0200 (MEST)
Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id g6OBcw5d006117; Wed, 24 Jul 2002 13:38:58 +0200 (CEST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
cc: "'Liu, Hong'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: Proposed Document Changes 
In-reply-to: Your message of Wed, 24 Jul 2002 07:13:46 -0400. <[e-mail]> 
Date: Wed, 24 Jul 2002 13:38:58 +0200
From: Jaap Akkerhuis <[e-mail]>
Sender: [e-mail]
Precedence: bulk

    > 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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6OBDto2014811 for <[e-mail]>; Wed, 24 Jul 2002 13:13:55 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g6OBDt6n014810 for ietf-provreg-outgoing; Wed, 24 Jul 2002 13:13:55 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6OBDso2014805 for <[e-mail]>; Wed, 24 Jul 2002 13:13:54 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id HAA17516; Wed, 24 Jul 2002 07:14:32 -0400 (EDT)
Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id <M6WSA14X>; Wed, 24 Jul 2002 07:13:47 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Liu, Hong'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Proposed Document Changes
Date: Wed, 24 Jul 2002 07:13:46 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6O3e8o2012769 for <[e-mail]>; Wed, 24 Jul 2002 05:40:08 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g6O3e8GX012768 for ietf-provreg-outgoing; Wed, 24 Jul 2002 05:40:08 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6O3e6o2012763 for <[e-mail]>; Wed, 24 Jul 2002 05:40:07 +0200 (MEST)
Received: from stntimc1.va.neustar.com (stih650a-eth-s1p2c0.va.neustar.com [209.173.53.81]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id g6O3e4D30788 for <[e-mail]>; Wed, 24 Jul 2002 03:40:05 GMT
Received: by STNTIMC1 with Internet Mail Service (5.5.2653.19) id <306V4GNN>; Tue, 23 Jul 2002 23:40:51 -0400
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E0840AF@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: [e-mail]
Subject: RE: Proposed Document Changes
Date: Tue, 23 Jul 2002 23:40:52 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
Sent: Wednesday, July 17, 2002 5:57 PM
To: [e-mail]
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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6NF6Lo2007955 for <[e-mail]>; Tue, 23 Jul 2002 17:06:21 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g6NF6LLU007954 for ietf-provreg-outgoing; Tue, 23 Jul 2002 17:06:21 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6NF6Ko2007949 for <[e-mail]>; Tue, 23 Jul 2002 17:06:20 +0200 (MEST)
Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id g6NF6J5d002980 for <[e-mail]>; Tue, 23 Jul 2002 17:06:19 +0200 (CEST) (envelope-from [e-mail])
Received: (from jaap@localhost) by bartok.sidn.nl (8.12.5/8.12.5/Submit) id g6NF6JpC002979 for [e-mail]; Tue, 23 Jul 2002 17:06:19 +0200 (CEST)
Received: from mail.ietf54.wide.ad.jp (www.ietf54.wide.ad.jp [133.93.192.80]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6HLuho2029632 for <[e-mail]>; Wed, 17 Jul 2002 23:56:44 +0200 (MEST)
Received: from HOLLENBECKLT2 (HOLLENBECK-LT2.dyn.ietf54.wide.ad.jp [133.93.72.250]) by mail.ietf54.wide.ad.jp (8.11.6/8.11.6) with SMTP id g6HLuXu15885 for <[e-mail]>; Thu, 18 Jul 2002 06:56:33 +0900 (JST)
Message-ID: <001001c22ddc$d112f210$fa485d85@HOLLENBECKLT2>
From: "Hollenbeck, Scott" <[e-mail]>
To: <[e-mail]>
Subject: Proposed Document Changes
Date: Wed, 17 Jul 2002 17:56:33 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6NB5Uo2006626 for <[e-mail]>; Tue, 23 Jul 2002 13:05:30 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g6NB5Up5006625 for ietf-provreg-outgoing; Tue, 23 Jul 2002 13:05:30 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6NB5So2006620 for <[e-mail]>; Tue, 23 Jul 2002 13:05:29 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id HAA20762; Tue, 23 Jul 2002 07:06:12 -0400 (EDT)
Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <NJVG2K1V>; Tue, 23 Jul 2002 07:05:26 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Roger Castillo Cortazar'" <[e-mail]>, [e-mail]
Subject: RE: Proposed Document Changes
Date: Tue, 23 Jul 2002 07:05:26 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Roger,

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

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

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

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

-Scott- 

> -----Original Message-----
> From: Roger Castillo Cortazar [mailto:[e-mail]]
> Sent: Monday, July 22, 2002 10:00 PM
> To: Hollenbeck, Scott; [e-mail]
> 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
> 


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6N1xwo2004296 for <[e-mail]>; Tue, 23 Jul 2002 03:59:58 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g6N1xw8f004295 for ietf-provreg-outgoing; Tue, 23 Jul 2002 03:59:58 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail.nic.mx (mail.nic.mx [200.23.1.17] (may be forged)) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6N1xuo2004290 for <[e-mail]>; Tue, 23 Jul 2002 03:59:56 +0200 (MEST)
Received: from RCASTILLO.nic.mx ([200.33.1.101]) (authenticated (0 bits)) by mail.nic.mx (8.11.6/8.11.6) with ESMTP id g6N1x0B03103 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO); Mon, 22 Jul 2002 20:59:01 -0500 (CDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 22 Jul 2002 20:59:51 -0500
To: "Hollenbeck, Scott" <[e-mail]>, <[e-mail]>
From: Roger Castillo Cortazar <[e-mail]>
Subject: Re: Proposed Document Changes
In-Reply-To: <001001c22ddc$d112f210$fa485d85@HOLLENBECKLT2>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6MM9to2002369 for <[e-mail]>; Tue, 23 Jul 2002 00:09:55 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g6MM9twe002368 for ietf-provreg-outgoing; Tue, 23 Jul 2002 00:09:55 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6MM9so2002363 for <[e-mail]>; Tue, 23 Jul 2002 00:09:54 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id SAA07137 for <[e-mail]>; Mon, 22 Jul 2002 18:10:38 -0400 (EDT)
Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <NJVGH9BY>; Mon, 22 Jul 2002 18:09:53 -0400
Message-ID: <[e-mail]>
From: "Gould, James" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "Hollenbeck, Scott" <[e-mail]>
Subject: RE: Service Message Format
Date: Mon, 22 Jul 2002 18:09:52 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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: 	'[e-mail]'; 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
> > To: 	'[e-mail]'
> > 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- 
> > 
> > 
> 
> 


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6MKfJo2001836 for <[e-mail]>; Mon, 22 Jul 2002 22:41:19 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g6MKfJ6R001835 for ietf-provreg-outgoing; Mon, 22 Jul 2002 22:41:19 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6MKfHo2001830 for <[e-mail]>; Mon, 22 Jul 2002 22:41:18 +0200 (MEST)
Received: from stntimc1.va.neustar.com (stih650a-eth-s1p2c0.va.neustar.com [209.173.53.81]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id g6MKfGD01492 for <[e-mail]>; Mon, 22 Jul 2002 20:41:16 GMT
Received: by STNTIMC1 with Internet Mail Service (5.5.2653.19) id <306V416V>; Mon, 22 Jul 2002 16:42:03 -0400
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E084098@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: [e-mail]
Subject: RE: Proposed Document Changes - Pending Operations
Date: Mon, 22 Jul 2002 16:42:07 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id g6MKfIo2001831
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
Sent: Monday, July 22, 2002 1:32 AM
To: Liu, Hong; [e-mail]
Subject: RE: Proposed Document Changes - Pending Operations


--On 2002-07-18 22.35 -0400 "Liu, Hong" <[e-mail]> 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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6MIKVo2000869 for <[e-mail]>; Mon, 22 Jul 2002 20:20:31 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g6MIKV8E000868 for ietf-provreg-outgoing; Mon, 22 Jul 2002 20:20:31 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from neteka.com (host-111.innovation.t1.primus.ca [216.254.145.111] (may be forged)) by nic.cafax.se (8.12.5/8.12.5) with SMTP id g6MIKUo2000863 for <[e-mail]>; Mon, 22 Jul 2002 20:20:30 +0200 (MEST)
Message-ID: <021a01c231ac$7157f180$[e-mail]>
From: "Edmon Chung" <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Service Message Format
Date: Mon, 22 Jul 2002 14:20:21 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk

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


----- Original Message -----
From: "Hollenbeck, Scott" <[e-mail]>
To: <[e-mail]>
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-
>



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6MHhUo2000573 for <[e-mail]>; Mon, 22 Jul 2002 19:43:30 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g6MHhUPj000572 for ietf-provreg-outgoing; Mon, 22 Jul 2002 19:43:30 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6MHhSo2000567 for <[e-mail]>; Mon, 22 Jul 2002 19:43:29 +0200 (MEST)
Received: from chiimc01.il.neustar.com (stih650a-eth-s1p2c0.va.neustar.com [209.173.53.81]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id g6MHhPD29002 for <[e-mail]>; Mon, 22 Jul 2002 17:43:25 GMT
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <30KQ4KT7>; Mon, 22 Jul 2002 12:43:24 -0500
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E084091@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: Service Message Format
Date: Mon, 22 Jul 2002 12:44:20 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Scott,

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:[e-mail]]
Sent: Monday, July 22, 2002 1:08 PM
To: '[e-mail]'
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- 


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6MHdQo2000524 for <[e-mail]>; Mon, 22 Jul 2002 19:39:26 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g6MHdQk3000523 for ietf-provreg-outgoing; Mon, 22 Jul 2002 19:39:26 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6MHdPo2000518 for <[e-mail]>; Mon, 22 Jul 2002 19:39:25 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id NAA19804 for <[e-mail]>; Mon, 22 Jul 2002 13:40:09 -0400 (EDT)
Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id <M6WR994P>; Mon, 22 Jul 2002 13:39:23 -0400
Message-ID: <[e-mail]>
From: "Gould, James" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "Hollenbeck, Scott" <[e-mail]>
Subject: RE: Service Message Format
Date: Mon, 22 Jul 2002 13:39:17 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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
> To: 	'[e-mail]'
> 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- 
> 
> 


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6MHZ8o2000464 for <[e-mail]>; Mon, 22 Jul 2002 19:35:08 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g6MHZ8Ii000463 for ietf-provreg-outgoing; Mon, 22 Jul 2002 19:35:08 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bean.ar.com (bean.ar.com [66.123.187.68]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6MHZ6o2000458 for <[e-mail]>; Mon, 22 Jul 2002 19:35:07 +0200 (MEST)
Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.2/8.12.0) with ESMTP id g6MHZ2lo009014; Mon, 22 Jul 2002 10:35:02 -0700 (PDT)
Date: Mon, 22 Jul 2002 10:35:04 -0700 (PDT)
From: Rick Wesson <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>
Subject: Re: Service Message Format
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6MHUdo2000399 for <[e-mail]>; Mon, 22 Jul 2002 19:30:39 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g6MHUdRD000398 for ietf-provreg-outgoing; Mon, 22 Jul 2002 19:30:39 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nohope.patoche.org (nohope.patoche.org [80.67.173.199]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6MHUbo2000393 for <[e-mail]>; Mon, 22 Jul 2002 19:30:38 +0200 (MEST)
Received: from nohope.patoche.org (localhost.gandi.net [127.0.0.1]) by nohope.patoche.org (8.12.1/8.12.1/Debian -5) with ESMTP id g6MHUVT8029880 for <[e-mail]>; Mon, 22 Jul 2002 19:30:31 +0200
Received: (from patrick@localhost) by nohope.patoche.org (8.12.1/8.12.1/Debian -5) id g6MHUV8d029878 for [e-mail]; Mon, 22 Jul 2002 19:30:31 +0200
Date: Mon, 22 Jul 2002 19:30:31 +0200
From: Patrick <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Re: Service Message Format
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.24i
X-PGP-KeyID: A241FB6B
X-Request-PGP: http://www.keyserver.net:11371/pks/lookup?op=vindex&search=0xA241FB6B
Organization: Gandi
Sender: [e-mail]
Precedence: bulk

On Mon, 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.


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6MH8ao2000264 for <[e-mail]>; Mon, 22 Jul 2002 19:08:36 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g6MH8ao4000262 for ietf-provreg-outgoing; Mon, 22 Jul 2002 19:08:36 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6MH8Zo2000257 for <[e-mail]>; Mon, 22 Jul 2002 19:08:35 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id NAA17864 for <[e-mail]>; Mon, 22 Jul 2002 13:09:19 -0400 (EDT)
Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id <M6WR99B1>; Mon, 22 Jul 2002 13:08:34 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Service Message Format
Date: Mon, 22 Jul 2002 13:08:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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- 


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6MEeKo2029214 for <[e-mail]>; Mon, 22 Jul 2002 16:40:20 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g6MEeKhg029213 for ietf-provreg-outgoing; Mon, 22 Jul 2002 16:40:20 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6MEeFo2029208 for <[e-mail]>; Mon, 22 Jul 2002 16:40:19 +0200 (MEST)
Received: from stntimc1.va.neustar.com (stih650a-eth-s1p2c0.va.neustar.com [209.173.53.81]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id g6MEeBD24073 for <[e-mail]>; Mon, 22 Jul 2002 14:40:12 GMT
Received: by STNTIMC1 with Internet Mail Service (5.5.2653.19) id <306V41G6>; Mon, 22 Jul 2002 10:40:57 -0400
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E084087@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: [e-mail]
Subject: RE: Proposed Document Changes - Pending Operations
Date: Mon, 22 Jul 2002 10:41:01 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id g6MEeKo2029209
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
Sent: Monday, July 22, 2002 1:32 AM
To: Liu, Hong; [e-mail]
Subject: RE: Proposed Document Changes - Pending Operations


--On 2002-07-18 22.35 -0400 "Liu, Hong" <[e-mail]> 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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6M5XCo2027203 for <[e-mail]>; Mon, 22 Jul 2002 07:33:12 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g6M5XCW8027202 for ietf-provreg-outgoing; Mon, 22 Jul 2002 07:33:12 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6M5XBo2027197 for <[e-mail]>; Mon, 22 Jul 2002 07:33:12 +0200 (MEST)
Received: from xbe-lon-303.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6M5WKiN007923; Mon, 22 Jul 2002 07:32:21 +0200 (MET DST)
Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-lon-303.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 22 Jul 2002 06:33:09 +0100
Received: from [172.16.0.100] ([171.68.225.134]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 22 Jul 2002 07:33:08 +0200
Date: Mon, 22 Jul 2002 14:32:18 +0900
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[e-mail]>
To: "Liu, Hong" <[e-mail]>, [e-mail]
Subject: RE: Proposed Document Changes - Pending Operations
Message-ID: <3118280.1027348338@localhost>
In-Reply-To: <5E42C1C85C5D064A947CF92FADE6D82E084075@STNTEXCH1>
References:  <5E42C1C85C5D064A947CF92FADE6D82E084075@STNTEXCH1>
X-Mailer: Mulberry/2.2.0 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-OriginalArrivalTime: 22 Jul 2002 05:33:09.0173 (UTC) FILETIME=[434FBE50:01C23141]
Sender: [e-mail]
Precedence: bulk

--On 2002-07-18 22.35 -0400 "Liu, Hong" <[e-mail]> 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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6JE2Ao2011523 for <[e-mail]>; Fri, 19 Jul 2002 16:02:10 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g6JE2AdW011522 for ietf-provreg-outgoing; Fri, 19 Jul 2002 16:02:10 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6JE26o2011517 for <[e-mail]>; Fri, 19 Jul 2002 16:02:09 +0200 (MEST)
Received: from stntimc1.va.neustar.com (stih650a-eth-s1p2c0.va.neustar.com [209.173.53.81]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id g6JE25D20500 for <[e-mail]>; Fri, 19 Jul 2002 14:02:05 GMT
Received: by STNTIMC1 with Internet Mail Service (5.5.2653.19) id <306V4C42>; Fri, 19 Jul 2002 10:02:50 -0400
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E08407E@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: [e-mail]
Subject: RE: Multiple Extension Elements  for Command/Response in EPP
Date: Fri, 19 Jul 2002 10:03:04 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Scott,

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

--Hong

-----Original Message-----
From: Hollenbeck, Scott [mailto:[e-mail]]
Sent: Thursday, July 18, 2002 6:48 PM
To: Liu, Hong; [e-mail]
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" <[e-mail]>
To: <[e-mail]>
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
>


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6JAIno2010683 for <[e-mail]>; Fri, 19 Jul 2002 12:18:49 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g6JAInW8010682 for ietf-provreg-outgoing; Fri, 19 Jul 2002 12:18:49 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6JAIio2010676 for <[e-mail]>; Fri, 19 Jul 2002 12:18:45 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id GAA00747; Fri, 19 Jul 2002 06:19:20 -0400 (EDT)
Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <NJVGFDCA>; Fri, 19 Jul 2002 06:18:37 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Liu, Hong'" <[e-mail]>, [e-mail]
Subject: RE: Proposed Document Changes - Pending Operations
Date: Fri, 19 Jul 2002 06:18:35 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6J2Yeo2009066 for <[e-mail]>; Fri, 19 Jul 2002 04:34:40 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g6J2YeKg009065 for ietf-provreg-outgoing; Fri, 19 Jul 2002 04:34:40 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6J2Ydo2009060 for <[e-mail]>; Fri, 19 Jul 2002 04:34:39 +0200 (MEST)
Received: from stntimc1.va.neustar.com (stih650a-eth-s1p2c0.va.neustar.com [209.173.53.81]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id g6J2YcD14778 for <[e-mail]>; Fri, 19 Jul 2002 02:34:38 GMT
Received: by STNTIMC1 with Internet Mail Service (5.5.2653.19) id <306V4CKV>; Thu, 18 Jul 2002 22:35:23 -0400
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E084075@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: [e-mail]
Subject: RE: Proposed Document Changes - Pending Operations
Date: Thu, 18 Jul 2002 22:35:34 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id g6J2Yeo2009061
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
Sent: Thursday, July 18, 2002 7:48 PM
To: Hollenbeck, Scott; Liu, Hong; [e-mail]
Subject: Re: Proposed Document Changes - Pending Operations


--On 2002-07-18 19.25 -0400 "Hollenbeck, Scott" <[e-mail]>
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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6J2Rpo2009031 for <[e-mail]>; Fri, 19 Jul 2002 04:27:51 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g6J2RoS0009030 for ietf-provreg-outgoing; Fri, 19 Jul 2002 04:27:50 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6J2Rio2009024 for <[e-mail]>; Fri, 19 Jul 2002 04:27:49 +0200 (MEST)
Received: from stntimc1.va.neustar.com (stih650a-eth-s1p2c0.va.neustar.com [209.173.53.81]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id g6J2RfD14655 for <[e-mail]>; Fri, 19 Jul 2002 02:27:41 GMT
Received: by STNTIMC1 with Internet Mail Service (5.5.2653.19) id <306V4CKT>; Thu, 18 Jul 2002 22:28:26 -0400
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E084074@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: [e-mail]
Subject: RE: Proposed Document Changes - Pending Operations
Date: Thu, 18 Jul 2002 22:28:37 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
Sent: Thursday, July 18, 2002 7:26 PM
To: Liu, Hong; [e-mail]
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" <[e-mail]>
To: <[e-mail]>
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
>
> -----Original Message-----
> From: Hollenbeck, Scott [mailto:[e-mail]]
> Sent: Wednesday, July 17, 2002 5:57 PM
> To: [e-mail]
> 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
>


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6INoso2007451 for <[e-mail]>; Fri, 19 Jul 2002 01:50:54 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g6INorC6007450 for ietf-provreg-outgoing; Fri, 19 Jul 2002 01:50:53 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6INoro2007445 for <[e-mail]>; Fri, 19 Jul 2002 01:50:53 +0200 (MEST)
Received: from xbe-ams-303.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6INnxI8006340; Fri, 19 Jul 2002 01:50:03 +0200 (MET DST)
Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by xbe-ams-303.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Fri, 19 Jul 2002 01:50:47 +0200
Received: from zx81.paf.se.dyn.ietf54.wide.ad.jp ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Fri, 19 Jul 2002 01:50:47 +0200
Date: Fri, 19 Jul 2002 08:47:53 +0900
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>, "Liu, Hong" <[e-mail]>, [e-mail]
Subject: Re: Proposed Document Changes - Pending Operations
Message-ID: <6438038.1027068473@localhost>
In-Reply-To: <002901c22eb2$6ae16d10$fa485d85@HOLLENBECKLT2>
References: <5E42C1C85C5D064A947CF92FADE6D82E084073@STNTEXCH1> <002901c22eb2$6ae16d10$fa485d85@HOLLENBECKLT2>
X-Mailer: Mulberry/2.2.0 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-OriginalArrivalTime: 18 Jul 2002 23:50:47.0507 (UTC) FILETIME=[F0490230:01C22EB5]
Sender: [e-mail]
Precedence: bulk

--On 2002-07-18 19.25 -0400 "Hollenbeck, Scott" <[e-mail]>
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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6INQ1o2007327 for <[e-mail]>; Fri, 19 Jul 2002 01:26:01 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g6INQ1S7007326 for ietf-provreg-outgoing; Fri, 19 Jul 2002 01:26:01 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail.ietf54.wide.ad.jp (www.ietf54.wide.ad.jp [133.93.192.80]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6INPwo2007321 for <[e-mail]>; Fri, 19 Jul 2002 01:25:59 +0200 (MEST)
Received: from HOLLENBECKLT2 (HOLLENBECK-LT2.dyn.ietf54.wide.ad.jp [133.93.72.250]) by mail.ietf54.wide.ad.jp (8.11.6/8.11.6) with SMTP id g6INPYJ01862; Fri, 19 Jul 2002 08:25:34 +0900 (JST)
Message-ID: <002901c22eb2$6ae16d10$fa485d85@HOLLENBECKLT2>
From: "Hollenbeck, Scott" <[e-mail]>
To: "Liu, Hong" <[e-mail]>, <[e-mail]>
References: <5E42C1C85C5D064A947CF92FADE6D82E084073@STNTEXCH1>
Subject: Re: Proposed Document Changes - Pending Operations
Date: Thu, 18 Jul 2002 19:25:35 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk

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" <[e-mail]>
To: <[e-mail]>
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
>
> -----Original Message-----
> From: Hollenbeck, Scott [mailto:[e-mail]]
> Sent: Wednesday, July 17, 2002 5:57 PM
> To: [e-mail]
> 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
>



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6IMm5o2007152 for <[e-mail]>; Fri, 19 Jul 2002 00:48:05 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g6IMm5ag007151 for ietf-provreg-outgoing; Fri, 19 Jul 2002 00:48:05 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail.ietf54.wide.ad.jp (www.ietf54.wide.ad.jp [133.93.192.80]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6IMm2o2007146 for <[e-mail]>; Fri, 19 Jul 2002 00:48:03 +0200 (MEST)
Received: from HOLLENBECKLT2 (HOLLENBECK-LT2.dyn.ietf54.wide.ad.jp [133.93.72.250]) by mail.ietf54.wide.ad.jp (8.11.6/8.11.6) with SMTP id g6IMlgJ01786; Fri, 19 Jul 2002 07:47:42 +0900 (JST)
Message-ID: <000f01c22ead$204e7db0$fa485d85@HOLLENBECKLT2>
From: "Hollenbeck, Scott" <[e-mail]>
To: "Liu, Hong" <[e-mail]>, <[e-mail]>
References: <5E42C1C85C5D064A947CF92FADE6D82E084070@STNTEXCH1>
Subject: Re: Multiple Extension Elements  for Command/Response in EPP
Date: Thu, 18 Jul 2002 18:47:42 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk

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" <[e-mail]>
To: <[e-mail]>
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
>



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6IMj7o2007136 for <[e-mail]>; Fri, 19 Jul 2002 00:45:07 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g6IMj7nL007135 for ietf-provreg-outgoing; Fri, 19 Jul 2002 00:45:07 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6IMj3o2007130 for <[e-mail]>; Fri, 19 Jul 2002 00:45:06 +0200 (MEST)
Received: from stntimc1.va.neustar.com (stih650a-eth-s1p2c0.va.neustar.com [209.173.53.81]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id g6IMj2D12782 for <[e-mail]>; Thu, 18 Jul 2002 22:45:02 GMT
Received: by STNTIMC1 with Internet Mail Service (5.5.2653.19) id <306V4CHR>; Thu, 18 Jul 2002 18:45:48 -0400
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E084073@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: [e-mail]
Subject: RE: Proposed Document Changes - Pending Operations
Date: Thu, 18 Jul 2002 18:45:59 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
Sent: Wednesday, July 17, 2002 5:57 PM
To: [e-mail]
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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6ILNQo2006718 for <[e-mail]>; Thu, 18 Jul 2002 23:23:26 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g6ILNQsP006717 for ietf-provreg-outgoing; Thu, 18 Jul 2002 23:23:26 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6ILNMo2006712 for <[e-mail]>; Thu, 18 Jul 2002 23:23:25 +0200 (MEST)
Received: from chiimc01.il.neustar.com (stih650a-eth-s1p2c0.va.neustar.com [209.173.53.81]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id g6ILNJD11550 for <[e-mail]>; Thu, 18 Jul 2002 21:23:19 GMT
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <30KQT6T3>; Thu, 18 Jul 2002 16:23:15 -0500
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E084070@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: [e-mail]
Subject: Multiple Extension Elements  for Command/Response in EPP
Date: Thu, 18 Jul 2002 16:24:15 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Scott,

I would like to 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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6I0jVo2000500 for <[e-mail]>; Thu, 18 Jul 2002 02:45:31 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g6I0jVhp000499 for ietf-provreg-outgoing; Thu, 18 Jul 2002 02:45:31 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6I0jUo2000494 for <[e-mail]>; Thu, 18 Jul 2002 02:45:30 +0200 (MEST)
Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id g6I0jN5d077418 for <[e-mail]>; Thu, 18 Jul 2002 02:45:23 +0200 (CEST) (envelope-from [e-mail])
Received: (from jaap@localhost) by bartok.sidn.nl (8.12.5/8.12.5/Submit) id g6I0jNrD077417 for [e-mail]; Thu, 18 Jul 2002 02:45:23 +0200 (CEST)
Received: from mail.ietf54.wide.ad.jp (www.ietf54.wide.ad.jp [133.93.192.80]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6HLuho2029632 for <[e-mail]>; Wed, 17 Jul 2002 23:56:44 +0200 (MEST)
Received: from HOLLENBECKLT2 (HOLLENBECK-LT2.dyn.ietf54.wide.ad.jp [133.93.72.250]) by mail.ietf54.wide.ad.jp (8.11.6/8.11.6) with SMTP id g6HLuXu15885 for <[e-mail]>; Thu, 18 Jul 2002 06:56:33 +0900 (JST)
Message-ID: <001001c22ddc$d112f210$fa485d85@HOLLENBECKLT2>
From: "Hollenbeck, Scott" <[e-mail]>
To: <[e-mail]>
Subject: Proposed Document Changes
Date: Wed, 17 Jul 2002 17:56:33 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6HNoKo2000228 for <[e-mail]>; Thu, 18 Jul 2002 01:50:20 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g6HNoKc7000227 for ietf-provreg-outgoing; Thu, 18 Jul 2002 01:50:20 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from insan.co.id (mx.insan.co.id [202.138.225.178]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6HNoFo2000222 for <[e-mail]>; Thu, 18 Jul 2002 01:50:17 +0200 (MEST)
Received: from localhost (localhost [127.0.0.1]) by insan.co.id (Postfix) with ESMTP id 194831499B for <[e-mail]>; Thu, 18 Jul 2002 06:50:27 +0700 (JAVT)
Received: from greymon (bojong.indocisc.com [202.138.228.8]) by insan.co.id (Postfix) with ESMTP id B74FF14987 for <[e-mail]>; Thu, 18 Jul 2002 06:50:25 +0700 (JAVT)
From: [e-mail]
To: [e-mail]
Date: Thu, 18 Jul 2002 06:50:16 +0700
MIME-Version: 1.0
Subject: (Fwd) .ID - plan to open zone transfer
Reply-To: [e-mail]
Message-ID: <3D366528.6221.53398E@localhost>
X-mailer: Pegasus Mail for Windows (v4.01)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

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:           	[e-mail]
To:             	[e-mail]
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 -------


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6HNALo2029915 for <[e-mail]>; Thu, 18 Jul 2002 01:10:21 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g6HNALdo029914 for ietf-provreg-outgoing; Thu, 18 Jul 2002 01:10:21 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from naptop.autonomica.net (naptop.autonomica.net [133.93.72.248]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6HNAIo2029909 for <[e-mail]>; Thu, 18 Jul 2002 01:10:19 +0200 (MEST)
Received: from naptop.autonomica.net (localhost [127.0.0.1]) by naptop.autonomica.net (8.12.5/8.12.5) with ESMTP id g6HNA4tP001626 for <[e-mail]>; Thu, 18 Jul 2002 08:10:04 +0900 (JST)
Received: (from liman@localhost) by naptop.autonomica.net (8.12.5/8.12.5/Submit) id g6HNA4oI001625 for [e-mail]; Thu, 18 Jul 2002 08:10:04 +0900 (JST)
Received: from mail.ietf54.wide.ad.jp (www.ietf54.wide.ad.jp [133.93.192.80]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6HLuho2029632 for <[e-mail]>; Wed, 17 Jul 2002 23:56:44 +0200 (MEST)
Received: from HOLLENBECKLT2 (HOLLENBECK-LT2.dyn.ietf54.wide.ad.jp [133.93.72.250]) by mail.ietf54.wide.ad.jp (8.11.6/8.11.6) with SMTP id g6HLuXu15885 for <[e-mail]>; Thu, 18 Jul 2002 06:56:33 +0900 (JST)
Message-ID: <001001c22ddc$d112f210$fa485d85@HOLLENBECKLT2>
From: "Hollenbeck, Scott" <[e-mail]>
To: <[e-mail]>
Subject: Proposed Document Changes
Date: Wed, 17 Jul 2002 17:56:33 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk

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




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g68H0Uo2014680 for <[e-mail]>; Mon, 8 Jul 2002 19:00:30 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g68H0Usf014679 for ietf-provreg-outgoing; Mon, 8 Jul 2002 19:00:30 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ns01.afilias.info (ns01.afilias.info [66.45.25.225]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g68H0To2014674 for <[e-mail]>; Mon, 8 Jul 2002 19:00:29 +0200 (MEST)
Received: from RAMLAPTOP (ATHM-216-217-xxx-252.newedgenetworks.com [216.217.55.252]) (authenticated) by ns01.afilias.info (8.11.2/8.11.2) with ESMTP id g68H0CY18140; Mon, 8 Jul 2002 13:00:12 -0400
Message-ID: <018c01c226a0$524c9a50$[e-mail]>
From: "Ram Mohan" <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>, "'Liu, Hong'" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: EPP PUSH: Session Property Re-negotiation
Date: Mon, 8 Jul 2002 12:40:15 -0400
Organization: Afilias
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk

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

-ram
----- Original Message -----
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Liu, Hong'" <[e-mail]>; <[e-mail]>
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-
>



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g68EHvo2013545 for <[e-mail]>; Mon, 8 Jul 2002 16:17:57 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g68EHv7A013544 for ietf-provreg-outgoing; Mon, 8 Jul 2002 16:17:57 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g68EHuo2013539 for <[e-mail]>; Mon, 8 Jul 2002 16:17:56 +0200 (MEST)
Received: from chiimc01.il.neustar.com (chih650b-eth-s4p2c0.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g68EHK501562 for <[e-mail]>; Mon, 8 Jul 2002 09:17:46 -0500
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <NJXKHM2Z>; Mon, 8 Jul 2002 09:17:06 -0500
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E084021@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: EPP PUSH: Session Property Re-negotiation
Date: Mon, 8 Jul 2002 09:15:52 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

I 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:[e-mail]]
Sent: Monday, July 08, 2002 9:07 AM
To: 'Liu, Hong'; '[e-mail]'
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-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g68EEKo2013499 for <[e-mail]>; Mon, 8 Jul 2002 16:14:20 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g68EEK9n013498 for ietf-provreg-outgoing; Mon, 8 Jul 2002 16:14:20 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g68EEIo2013493 for <[e-mail]>; Mon, 8 Jul 2002 16:14:19 +0200 (MEST)
Received: from chiimc01.il.neustar.com (chih650b-eth-s4p2c0.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g68EDr501495 for <[e-mail]>; Mon, 8 Jul 2002 09:14:08 -0500
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <NJXKHM2B>; Mon, 8 Jul 2002 09:13:38 -0500
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E084020@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: EPP PUSH: Session Setup  Semantics
Date: Mon, 8 Jul 2002 09:12:24 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Scott,

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:[e-mail]]
Sent: Monday, July 08, 2002 9:06 AM
To: 'Liu, Hong'; '[e-mail]'
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-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g68DEho2012931 for <[e-mail]>; Mon, 8 Jul 2002 15:14:43 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g68DEhhJ012930 for ietf-provreg-outgoing; Mon, 8 Jul 2002 15:14:43 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g68DEgo2012925 for <[e-mail]>; Mon, 8 Jul 2002 15:14:42 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id JAA10055; Mon, 8 Jul 2002 09:15:21 -0400 (EDT)
Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <NJVF6LNN>; Mon, 8 Jul 2002 09:14:39 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Roger Castillo Cortazar'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: <poll> result codes
Date: Mon, 8 Jul 2002 09:14:33 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
Sent: Friday, July 05, 2002 5:36 PM
To: [e-mail]
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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g68D7Zo2012878 for <[e-mail]>; Mon, 8 Jul 2002 15:07:35 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g68D7Zfj012877 for ietf-provreg-outgoing; Mon, 8 Jul 2002 15:07:35 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g68D7Yo2012872 for <[e-mail]>; Mon, 8 Jul 2002 15:07:34 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id JAA09616; Mon, 8 Jul 2002 09:08:10 -0400 (EDT)
Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <NJVF6L29>; Mon, 8 Jul 2002 09:07:28 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Liu, Hong'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: EPP PUSH: Session Property Re-negotiation
Date: Mon, 8 Jul 2002 09:07:18 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g68D6Fo2012858 for <[e-mail]>; Mon, 8 Jul 2002 15:06:15 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g68D6FZZ012857 for ietf-provreg-outgoing; Mon, 8 Jul 2002 15:06:15 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g68D6Eo2012852 for <[e-mail]>; Mon, 8 Jul 2002 15:06:14 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id JAA09543; Mon, 8 Jul 2002 09:06:25 -0400 (EDT)
Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id <M6WRW68X>; Mon, 8 Jul 2002 09:05:43 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Liu, Hong'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: EPP PUSH: Session Setup  Semantics
Date: Mon, 8 Jul 2002 09:05:42 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g65D7oo2025624 for <[e-mail]>; Fri, 5 Jul 2002 15:07:50 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g65D7o7j025623 for ietf-provreg-outgoing; Fri, 5 Jul 2002 15:07:50 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g65D7no2025618 for <[e-mail]>; Fri, 5 Jul 2002 15:07:49 +0200 (MEST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23132; Fri, 5 Jul 2002 09:06:57 -0400 (EDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: RFC Editor <[e-mail]>, Internet Architecture Board <[e-mail]>, [e-mail]
From: The IESG <[e-mail]>
Subject: Document Action: Generic Registry-Registrar Protocol Requirements  to Informational
Date: Fri, 05 Jul 2002 09:06:56 -0400
Sender: [e-mail]
Precedence: bulk

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 <[e-mail]> 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.


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g64C4bo2017931 for <[e-mail]>; Thu, 4 Jul 2002 14:04:37 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g64C4bmM017930 for ietf-provreg-outgoing; Thu, 4 Jul 2002 14:04:37 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from popintmanex.poptel.org.uk (popintmanex.poptel.org.uk [213.55.9.22]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g64C4Zo2017925 for <[e-mail]>; Thu, 4 Jul 2002 14:04:36 +0200 (MEST)
Received: by exchange.poptel.net with Internet Mail Service (5.5.2653.19) id <31RG63SW>; Thu, 4 Jul 2002 13:04:32 +0100
Message-ID: <[e-mail]>
From: Robert Burbidge <[e-mail]>
To: "Ietf-Provreg (E-mail)" <[e-mail]>
Subject: EPP Extensions proposal for coop: comments invited
Date: Thu, 4 Jul 2002 13:04:31 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g639FQo2009224 for <[e-mail]>; Wed, 3 Jul 2002 11:15:26 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g639FQ44009223 for ietf-provreg-outgoing; Wed, 3 Jul 2002 11:15:26 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g639FQo2009218 for <[e-mail]>; Wed, 3 Jul 2002 11:15:26 +0200 (MEST)
Received: from xbe-ams-303.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g639EWXk014522; Wed, 3 Jul 2002 11:14:40 +0200 (MET DST)
Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-ams-303.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Wed, 3 Jul 2002 11:15:24 +0200
Received: from [10.0.1.2] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Wed, 3 Jul 2002 11:15:21 +0200
Date: Wed, 03 Jul 2002 11:13:06 +0200
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[e-mail]>
To: "Liu, Hong" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: TCP Mapping 
Message-ID: <29657431.1025694786@localhost>
In-Reply-To: <5E42C1C85C5D064A947CF92FADE6D82E084004@STNTEXCH1>
References:  <5E42C1C85C5D064A947CF92FADE6D82E084004@STNTEXCH1>
X-Mailer: Mulberry/2.2.0 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-OriginalArrivalTime: 03 Jul 2002 09:15:23.0778 (UTC) FILETIME=[2981BE20:01C22272]
Sender: [e-mail]
Precedence: bulk

--On 2002-06-29 20.27 -0500 "Liu, Hong" <[e-mail]> 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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g639FNo2009216 for <[e-mail]>; Wed, 3 Jul 2002 11:15:23 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g639FMfr009215 for ietf-provreg-outgoing; Wed, 3 Jul 2002 11:15:22 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g639FMo2009210 for <[e-mail]>; Wed, 3 Jul 2002 11:15:22 +0200 (MEST)
Received: from xbe-ams-303.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g639ES0l014480; Wed, 3 Jul 2002 11:14:36 +0200 (MET DST)
Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-ams-303.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Wed, 3 Jul 2002 11:15:21 +0200
Received: from [10.0.1.2] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Wed, 3 Jul 2002 11:15:20 +0200
Date: Wed, 03 Jul 2002 11:10:39 +0200
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[e-mail]>
To: Eric Brunner-Williams in Portland Maine <[e-mail]>, "Hollenbeck, Scott" <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: Requirements Approved! 
Message-ID: <29648605.1025694639@localhost>
In-Reply-To: <[e-mail]>
References:  <[e-mail]>
X-Mailer: Mulberry/2.2.0 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-OriginalArrivalTime: 03 Jul 2002 09:15:20.0638 (UTC) FILETIME=[27A29DE0:01C22272]
Sender: [e-mail]
Precedence: bulk

--On 2002-06-28 13.10 -0400 Eric Brunner-Williams in Portland Maine
<[e-mail]> 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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g638k4o2009091 for <[e-mail]>; Wed, 3 Jul 2002 10:46:04 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g638k403009090 for ietf-provreg-outgoing; Wed, 3 Jul 2002 10:46:04 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g638k3o2009085 for <[e-mail]>; Wed, 3 Jul 2002 10:46:03 +0200 (MEST)
Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id g638juZk011304 for <[e-mail]>; Wed, 3 Jul 2002 10:45:56 +0200 (CEST) (envelope-from [e-mail])
Received: (from jaap@localhost) by bartok.sidn.nl (8.12.5/8.12.5/Submit) id g638jtg2011303 for [e-mail]; Wed, 3 Jul 2002 10:45:55 +0200 (CEST)
Received: from mail.libertyrms.com ([216.94.172.167]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g62Ciao2001976 for <[e-mail]>; Tue, 2 Jul 2002 14:44:36 +0200 (MEST)
Received: from [10.1.1.139] (helo=dun220) by mail.libertyrms.com with esmtp (Exim 3.22 #3 (Debian)) id 17PN1H-0002FJ-00; Tue, 02 Jul 2002 08:44:35 -0400
From: "Michael Young" <[e-mail]>
To: "=?iso-8859-1?Q?'Juli=E1n_Mu=F1oz'?=" <[e-mail]>, <[e-mail]>
Subject: RE: EPP and # of nameservers
Date: Tue, 2 Jul 2002 08:44:32 -0400
Message-ID: <000001c221c6$368df770$8b01010a@dun220>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id g62Ciao2001977
Sender: [e-mail]
Precedence: bulk

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: [e-mail] [mailto:[e-mail]]
On Behalf Of Julián Muñoz
Sent: Tuesday, July 02, 2002 6:07 AM
To: [e-mail]
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
-.-









Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g62G7Ko2003315 for <[e-mail]>; Tue, 2 Jul 2002 18:07:20 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g62G7KmE003314 for ietf-provreg-outgoing; Tue, 2 Jul 2002 18:07:20 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from moutng1.kundenserver.de (moutng1.kundenserver.de [212.227.126.171]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g62G7Jo2003309 for <[e-mail]>; Tue, 2 Jul 2002 18:07:20 +0200 (MEST)
Received: from [195.20.224.148] (helo=mxintern.kundenserver.de) by moutng1.kundenserver.de with esmtp (Exim 3.22 #2) id 17PQBN-0008WS-00; Tue, 02 Jul 2002 18:07:14 +0200
Received: from rocco.schlund.de ([172.17.0.162] helo=schlund.de) by mxintern.kundenserver.de with esmtp (Exim 2.12 #3) id 17PQBN-00076q-00; Tue, 2 Jul 2002 18:07:13 +0200
Message-ID: <[e-mail]>
Date: Tue, 02 Jul 2002 18:07:15 +0200
From: Jens-Uwe Gaspar <[e-mail]>
Organization: Schlund + Partner AG
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-5 i686)
X-Accept-Language: en, de
MIME-Version: 1.0
To: =?iso-8859-1?Q?Juli=E1n=20Mu=F1oz?= <[e-mail]>
CC: [e-mail]
Subject: Re: EPP and # of nameservers
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

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: [e-mail]                       Erbprinzenstr. 4 - 12
Tel. [phone]                        76133 Karlsruhe, Germany
Fax  [phone]                        http://www.schlund.de


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g62F8Ko2002937 for <[e-mail]>; Tue, 2 Jul 2002 17:08:20 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g62F8KQH002936 for ietf-provreg-outgoing; Tue, 2 Jul 2002 17:08:20 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g62F8Io2002931 for <[e-mail]>; Tue, 2 Jul 2002 17:08:19 +0200 (MEST)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id LAA23191; Tue, 2 Jul 2002 11:08:15 -0400 (EDT)
Received: from [192.149.252.229] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA07728; Tue, 2 Jul 2002 11:08:13 -0400 (EDT)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b01b947717d0cf2@[192.149.252.229]>
In-Reply-To: <00b701c221d0$f6c3daa0$[e-mail]>
References:  <[e-mail]> <002f01c221c5$5be23320$[e-mail]> <00b701c221d0$f6c3daa0$[e-mail]>
Date: Tue, 2 Jul 2002 11:08:15 -0400
To: "Ram Mohan" <[e-mail]>, "Edmon Chung" <[e-mail]>, =?iso-8859-1?Q?Juli=E1n?= =?iso-8859-1?Q?_?= =?iso-8859-1?Q?Mu=F1oz?=  <[e-mail]>, <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: Re: EPP and # of nameservers
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g62E5Lo2002488 for <[e-mail]>; Tue, 2 Jul 2002 16:05:21 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g62E5LIH002487 for ietf-provreg-outgoing; Tue, 2 Jul 2002 16:05:21 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ns01.afilias.info (ns01.afilias.info [66.45.25.225]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g62E5Jo2002482 for <[e-mail]>; Tue, 2 Jul 2002 16:05:20 +0200 (MEST)
Received: from RAMLAPTOP (ATHM-216-217-xxx-252.newedgenetworks.com [216.217.55.252]) by ns01.afilias.info (8.11.2/8.11.2) with ESMTP id g62E4d229064; Tue, 2 Jul 2002 10:04:39 -0400
Message-ID: <00b701c221d0$f6c3daa0$[e-mail]>
From: "Ram Mohan" <[e-mail]>
To: "Edmon Chung" <[e-mail]>, =?iso-8859-1?Q?Juli=E1n_Mu=F1oz?= <[e-mail]>, <[e-mail]>
References: <[e-mail]> <002f01c221c5$5be23320$[e-mail]>
Subject: Re: EPP and # of nameservers
Date: Tue, 2 Jul 2002 09:29:55 -0400
Organization: Afilias
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk

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: [phone]; f: [phone]
e: [e-mail]
--------------------------------------------------------

----- Original Message -----
From: "Edmon Chung" <[e-mail]>
To: "Julián Muñoz" <[e-mail]>; <[e-mail]>
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" <[e-mail]>
> To: <[e-mail]>
> 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
> -.-
>
>
>
>
>
>
>



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g62CcZo2001930 for <[e-mail]>; Tue, 2 Jul 2002 14:38:35 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g62CcZf2001928 for ietf-provreg-outgoing; Tue, 2 Jul 2002 14:38:35 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from neteka.com (host-111.innovation.t1.primus.ca [216.254.145.111] (may be forged)) by nic.cafax.se (8.12.5/8.12.5) with SMTP id g62CcXo2001923 for <[e-mail]>; Tue, 2 Jul 2002 14:38:34 +0200 (MEST)
Message-ID: <002f01c221c5$5be23320$[e-mail]>
From: "Edmon Chung" <[e-mail]>
To: "Julián Muñoz" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: EPP and # of nameservers
Date: Tue, 2 Jul 2002 08:38:23 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk

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" <[e-mail]>
To: <[e-mail]>
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
-.-









Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g62A7so2001003 for <[e-mail]>; Tue, 2 Jul 2002 12:07:54 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g62A7sU5001002 for ietf-provreg-outgoing; Tue, 2 Jul 2002 12:07:54 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from julian.ea4acl.ampr.org (10.Red-80-33-22.pooles.rima-tde.net [80.33.22.10]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g62A7qo2000997 for <[e-mail]>; Tue, 2 Jul 2002 12:07:53 +0200 (MEST)
Received: by julian.ea4acl.ampr.org (Postfix, from userid 501) id 64F408F915; Tue,  2 Jul 2002 10:06:59 +0000 (GMT)
Received: from localhost (localhost [127.0.0.1]) by julian.ea4acl.ampr.org (Postfix) with ESMTP id 632088F913 for <[e-mail]>; Tue,  2 Jul 2002 10:06:59 +0000 (GMT)
Date: Tue, 2 Jul 2002 10:06:59 +0000 (GMT)
From: =?ISO-8859-1?Q?Juli=E1n_Mu=F1oz?= <[e-mail]>
X-Sender:  <[e-mail]>
To: <[e-mail]>
Subject: EPP and # of nameservers
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by nic.cafax.se id g62A7so2000998
Sender: [e-mail]
Precedence: bulk

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







Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g61Ia1o2025500 for <[e-mail]>; Mon, 1 Jul 2002 20:36:01 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g61Ia1tD025499 for ietf-provreg-outgoing; Mon, 1 Jul 2002 20:36:01 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g61Ia0o2025494 for <[e-mail]>; Mon, 1 Jul 2002 20:36:00 +0200 (MEST)
Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g61IZON29119 for <[e-mail]>; Mon, 1 Jul 2002 14:35:49 -0400
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <NJXKGMH5>; Mon, 1 Jul 2002 13:35:09 -0500
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E084016@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: EPP PUSH: Session Property Re-negotiation
Date: Mon, 1 Jul 2002 13:33:59 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g61Hlro2025174 for <[e-mail]>; Mon, 1 Jul 2002 19:47:53 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g61HlrCm025173 for ietf-provreg-outgoing; Mon, 1 Jul 2002 19:47:53 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g61Hlpo2025168 for <[e-mail]>; Mon, 1 Jul 2002 19:47:52 +0200 (MEST)
Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g61HlFN27491 for <[e-mail]>; Mon, 1 Jul 2002 13:47:41 -0400
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <NJXKGL5B>; Mon, 1 Jul 2002 12:47:00 -0500
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E084013@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: EPP PUSH: Session Setup  Semantics
Date: Mon, 1 Jul 2002 12:45:48 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g61FfQo2024323 for <[e-mail]>; Mon, 1 Jul 2002 17:41:27 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g61FfQaY024322 for ietf-provreg-outgoing; Mon, 1 Jul 2002 17:41:26 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g61FfPo2024317 for <[e-mail]>; Mon, 1 Jul 2002 17:41:25 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.4/8.11.6) with ESMTP id g61FdjBZ028260; Mon, 1 Jul 2002 11:39:45 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Liu, Hong" <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: TCP Mapping 
In-Reply-To: Your message of "Mon, 01 Jul 2002 09:42:13 CDT." <5E42C1C85C5D064A947CF92FADE6D82E08400E@STNTEXCH1> 
Date: Mon, 01 Jul 2002 11:39:45 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g61Ei1o2024000 for <[e-mail]>; Mon, 1 Jul 2002 16:44:01 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g61Ei1BZ023999 for ietf-provreg-outgoing; Mon, 1 Jul 2002 16:44:01 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g61Ehxo2023994 for <[e-mail]>; Mon, 1 Jul 2002 16:44:00 +0200 (MEST)
Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g61EhYN22008 for <[e-mail]>; Mon, 1 Jul 2002 10:43:49 -0400
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <NJXKGKG5>; Mon, 1 Jul 2002 09:43:19 -0500
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E08400E@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: TCP Mapping 
Date: Mon, 1 Jul 2002 09:42:13 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Eric,

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:[e-mail]]
Sent: Monday, July 01, 2002 7:04 AM
To: Liu, Hong
Cc: '[e-mail]'; [e-mail]
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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g61Edfo2023956 for <[e-mail]>; Mon, 1 Jul 2002 16:39:41 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g61EdfPG023955 for ietf-provreg-outgoing; Mon, 1 Jul 2002 16:39:41 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g61Eddo2023950 for <[e-mail]>; Mon, 1 Jul 2002 16:39:40 +0200 (MEST)
Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g61Ed3N21856 for <[e-mail]>; Mon, 1 Jul 2002 10:39:29 -0400
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <NJXKGK1T>; Mon, 1 Jul 2002 09:38:48 -0500
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E08400D@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: push
Date: Mon, 1 Jul 2002 09:37:35 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Rick,

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g61B5Qo2022668 for <[e-mail]>; Mon, 1 Jul 2002 13:05:26 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g61B5QMT022667 for ietf-provreg-outgoing; Mon, 1 Jul 2002 13:05:26 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g61B5No2022662 for <[e-mail]>; Mon, 1 Jul 2002 13:05:23 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.4/8.11.6) with ESMTP id g61B3gBZ027553; Mon, 1 Jul 2002 07:03:43 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Liu, Hong" <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: TCP Mapping 
In-Reply-To: Your message of "Sun, 30 Jun 2002 21:34:27 CDT." <5E42C1C85C5D064A947CF92FADE6D82E08400A@STNTEXCH1> 
Date: Mon, 01 Jul 2002 07:03:42 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g613cCo2020673 for <[e-mail]>; Mon, 1 Jul 2002 05:38:12 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g613cBGa020672 for ietf-provreg-outgoing; Mon, 1 Jul 2002 05:38:11 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bean.ar.com ([66.123.187.68]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g613cAo2020667 for <[e-mail]>; Mon, 1 Jul 2002 05:38:10 +0200 (MEST)
Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.2/8.12.0) with ESMTP id g613c0Th027734; Sun, 30 Jun 2002 20:38:00 -0700 (PDT)
Date: Sun, 30 Jun 2002 20:38:06 -0700 (PDT)
From: Rick Wesson <[e-mail]>
To: "Liu, Hong" <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>
Subject: push
In-Reply-To: <5E42C1C85C5D064A947CF92FADE6D82E08400A@STNTEXCH1>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

Hong,

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

thanks,

-rick




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g612Zfo2020460 for <[e-mail]>; Mon, 1 Jul 2002 04:35:41 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g612ZfYp020459 for ietf-provreg-outgoing; Mon, 1 Jul 2002 04:35:41 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g612Zeo2020454 for <[e-mail]>; Mon, 1 Jul 2002 04:35:40 +0200 (MEST)
Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g612Zat12181 for <[e-mail]>; Sun, 30 Jun 2002 21:35:39 -0500
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <NJXKGHPF>; Sun, 30 Jun 2002 21:35:32 -0500
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E08400A@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: TCP Mapping
Date: Sun, 30 Jun 2002 21:34:27 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Eric,

I 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:[e-mail]]
Sent: Sunday, June 30, 2002 6:24 PM
To: Liu, Hong
Cc: '[e-mail]'; [e-mail]
Subject: Re: TCP Mapping


Hong,

How is your extension supposed to work?

Exactly what do you mean by "EPP PUSH"?

Eric



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5UMPBo2018897 for <[e-mail]>; Mon, 1 Jul 2002 00:25:11 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g5UMPBhg018896 for ietf-provreg-outgoing; Mon, 1 Jul 2002 00:25:11 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g5UMP9o2018888 for <[e-mail]>; Mon, 1 Jul 2002 00:25:10 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.4/8.11.6) with ESMTP id g5UMNdBZ025782; Sun, 30 Jun 2002 18:23:40 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Liu, Hong" <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: TCP Mapping
In-Reply-To: Your message of "Sun, 30 Jun 2002 10:16:42 CDT." <5E42C1C85C5D064A947CF92FADE6D82E084006@STNTEXCH1>
Date: Sun, 30 Jun 2002 18:23:39 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

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