Subject: RE: Comments on new drafts...
From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: [email-masked]
Date: Fri, 29 Jun 2001 08:32:31 -0400

Sorry I missed those -- thanks for catching them.

<Scott/>

>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]]
>Sent: Friday, June 29, 2001 8:06 AM
>To: [email-masked]
>Cc: [email-masked]
>Subject: Comments on new drafts...
>
>
>Hi,
>
>thanks for the new drafts. I found some minor issues though...
>
>
>1. In the host-02 draft (lines 921-924):
>.    <import namespace="urn:iana:xml:ns:epp-1.0com-1.0"
>.            schemaLocation="eppcom-1.0.xsd"/>
>.    <import namespace="urn:iana:xml:ns:epp-1.0-1.0"
>.            schemaLocation="epp-1.0.xsd"/>
>.
>.   I guess it should be "eppcom-1.0" (not "epp-1.0com-1.0") 
>and "epp-1.0" (not
>.   "epp-1.0-1.0").
>
>
>2. In the epp-04 draft (lines 1418-1420):
>.    S:    <msgQ count="5"/>
>.    S:      <qDate>2000-06-08T22:00:00.0Z</qDate>
>.    S:    </msgQ>
>.
>.  The first line should not have the trailing "/"
>
>
>3. In the epp-04 draft (lines 2997-2998):
>.          <pattern value="
>.    144168    </restriction>
>.
>.  This was (erroneously?) changed from 
>.        <pattern value="\w{1,80}-\w{1,8}"/>
>.      </restriction>

Date: 29 Jun 2001 12:06:12 -0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: Comments on new drafts...
Sender: [email-masked]

Hi,

thanks for the new drafts. I found some minor issues though...

1. In the host-02 draft (lines 921-924):
.    <import namespace="urn:iana:xml:ns:epp-1.0com-1.0"
.            schemaLocation="eppcom-1.0.xsd"/>
.    <import namespace="urn:iana:xml:ns:epp-1.0-1.0"
.            schemaLocation="epp-1.0.xsd"/>
.
.   I guess it should be "eppcom-1.0" (not "epp-1.0com-1.0") and "epp-1.0" (not
.   "epp-1.0-1.0").

2. In the epp-04 draft (lines 1418-1420):
.    S:    <msgQ count="5"/>
.    S:      <qDate>2000-06-08T22:00:00.0Z</qDate>
.    S:    </msgQ>
.
.  The first line should not have the trailing "/"

3. In the epp-04 draft (lines 2997-2998):
.          <pattern value="
.    144168    </restriction>
.
.  This was (erroneously?) changed from 
.        <pattern value="\w{1,80}-\w{1,8}"/>
.      </restriction>

Regards,

Asbjorn Steira
Global Name Registry

-- 
 The information transmitted in this email is intended only for the person(s)
 or entity to which it is addressed and may contain proprietary, confidential
 and/or privileged material. If you have received this email in error, please
 contact the sender by replying and delete this email so that it is not
 recoverable. If you are not the intended recipient(s), any retention, review,
 disclosure, distribution, copying, printing, dissemination, or other use of,
 or taking of any action in reliance upon, this information is strictly
 prohibited and without liability on our part.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-provreg-epp-tcp-02.txt
Date: Fri, 29 Jun 2001 06:57:36 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Provisioning Registry Protocol Working Group of the IETF.

	Title		: Extensible Provisioning Protocol Transport Over TCP
	Author(s)	: S. Hollenbeck
	Filename	: draft-ietf-provreg-epp-tcp-02.txt
	Pages		: 9
	Date		: 28-Jun-01
	
This document describes how an Extensible Provisioning Protocol (EPP)
session is mapped onto a single Transmission Control Protocol (TCP)
connection.  This mapping requires use of the Transport Layer Security
(TLS) Protocol to protect information exchanged between an EPP client
and an EPP server.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-tcp-02.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-provreg-epp-tcp-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-provreg-epp-tcp-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-provreg-epp-tcp-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-provreg-epp-tcp-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-provreg-epp-host-02.txt
Date: Fri, 29 Jun 2001 06:57:31 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Provisioning Registry Protocol Working Group of the IETF.

	Title		: Extensible Provisioning Protocol Host Mapping
	Author(s)	: S. Hollenbeck
	Filename	: draft-ietf-provreg-epp-host-02.txt
	Pages		: 27
	Date		: 28-Jun-01
	
This document describes an Extensible Provisioning Protocol (EPP)
mapping for the provisioning and management of Internet host names
stored in a shared central repository.  Specified in XML, the mapping
defines EPP command syntax and semantics as applied to host names.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-host-02.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-provreg-epp-host-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-provreg-epp-host-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-provreg-epp-host-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-provreg-epp-host-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-provreg-epp-domain-02.txt
Date: Fri, 29 Jun 2001 06:57:25 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Provisioning Registry Protocol Working Group of the IETF.

	Title		: Extensible Provisioning Protocol Domain Name Mapping
	Author(s)	: S. Hollenbeck
	Filename	: draft-ietf-provreg-epp-domain-02.txt
	Pages		: 37
	Date		: 28-Jun-01
	
This document describes an Extensible Provisioning Protocol (EPP)
mapping for the provisioning and management of Internet domain names
stored in a shared central repository.  Specified in XML, the mapping
defines EPP command syntax and semantics as applied to domain names.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-domain-02.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-provreg-epp-domain-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-provreg-epp-domain-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-provreg-epp-domain-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-provreg-epp-domain-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-provreg-epp-contact-02.txt
Date: Fri, 29 Jun 2001 06:57:18 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Provisioning Registry Protocol Working Group of the IETF.

	Title		: Extensible Provisioning Protocol Contact Mapping
	Author(s)	: S. Hollenbeck
	Filename	: draft-ietf-provreg-epp-contact-02.txt
	Pages		: 39
	Date		: 28-Jun-01
	
This document describes an Extensible Provisioning Protocol (EPP)
mapping for the provisioning and management of individual or
organizational social information identifiers (known as 'contacts')
stored in a shared central repository. Specified in XML, the mapping
defines EPP command syntax and semantics as applied to contacts.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-contact-02.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-provreg-epp-contact-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-provreg-epp-contact-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-provreg-epp-contact-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-provreg-epp-contact-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-provreg-epp-04.txt
Date: Fri, 29 Jun 2001 06:57:02 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Provisioning Registry Protocol Working Group of the IETF.

	Title		: Extensible Provisioning Protocol
	Author(s)	: S. Hollenbeck
	Filename	: draft-ietf-provreg-epp-04.txt
	Pages		: 65
	Date		: 28-Jun-01
	
This document describes an application layer client-server protocol
for the provisioning and management of objects stored in a shared
central repository.  Specified in XML, the protocol defines generic
object management operations and an extensible framework that maps
protocol operations to objects.  This document includes a protocol
specification, an object mapping template, and an XML media type
registration.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-04.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-provreg-epp-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-provreg-epp-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-provreg-epp-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-provreg-epp-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Wed, 27 Jun 2001 09:25:46 -0700 (PDT)
From: Rick H Wesson <[email-masked]>
To: Sheer El-Showk <[email-masked]>
cc: "Hollenbeck, Scott" <[email-masked]>, "Bason, Chris" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Poll response data
Sender: [email-masked]

Sheer,

On Wed, 27 Jun 2001, Sheer El-Showk wrote:

> To give a concrete example, I might use a cron job running every two hours
> to scan my registry database for queable records and then make entries in
> another database used by the queue server.  Even if my process finds no
> records in the registry database that need to be queued, it will still
> mark my queue database (in a header or special purpose record) every two
> hours to indicate that the queue represents the state of the registry up
> until this point in time (the time the last cron job was run).  Since this
> timestamp is then passed on to registrars with each poll request they
> know how recently the queue was synchronized with the canonical data
> source (the registry database) -- a useful piece of information in my
> opinion.  This presumes queue updates will be a batched process rather
> then some event-driven (pushed) system such as refreshing the queue in
> real-time as events occur at the registry.   Even in the later case
> however, it will be useful to know that the queue represents the state
> of the registry in real time.

>From a client perspective, I'm sending a poll request to keep my
connections alive and don't care when the last time the queue was updated.

>From an API perspective I register listeners that will be "called back" if
a queue has messages. If while I am keping a connection alive I learn of
messages I handle them, or tell something else it needs to handle them.

If you are keeping many sessions alive then you'll get tons of
notification that there are things inqueue that need somethings attention.
Having the last date the queue was updated, even if no updates were
applied, is uninteresting for me.

-rick

Date: Wed, 27 Jun 2001 18:07:14 +0200
From: Klaus Malorny <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
CC: [email-masked]
Subject: Re: Billing information and EPP/GRRP-REQ
Sender: [email-masked]

"Hollenbeck, Scott" wrote:
> 
> Klaus,
> 
> I don't think I understand your suggestion.  It sounds like you'd like to
> see a client-provided serial number and a client-provided credit/debit
> amount related to registrar billing actions with their customers, but I
> don't understand how that info is of any use or concern to a registry.
> 
> If I'm misreading what you wrote, are you instead talking about registry
> billing of the registrar, for example letting the registrar know how much
> credit they have left after adding or renewing a domain name?  If so,
> wouldn't this be best done in registry-defined extensions to the protocol?
> 
> If I'm still completely off-base, can you provide some XML examples that
> illustrate your suggestion?
> 
> <Scott/>
> 

Hi Scott,

sorry for the confusing text, I should practice english more often ;-) . Your
second interpretation is right - I meant the registry billing of the
registrar. I just wanted to explain where I see a value for the registrars.
The serial number and the amount was meant to be created by the registry.

In addition, I didn't want to make a concrete proposal, instead, I wanted to
discuss whether such an extension would make sense. I myself am not quite
convinced about it! Nevertheless, as we (hopefully) make standards, we should
think about whether we should standardize such aspects like accounting also.
Such a standard does not need to be a part of EPP or GRRP neccessarily. I can
also imagine other ways: e.g. a daily report in XML format, where I get
notified about it via EPP ("Hey, we've got your account report for 2001-06-27
ready, download it via the URL ..."). As a registrar, I could make some
assumptions about the costs my requests produced - which may be false - and,
at the end of the day, I can correct my accounts with the help of these
reports.

regards,

Klaus Malorny

___________________________________________________________________________
     |       |
     | knipp |                   Knipp  Medien und Kommunikation GmbH
      -------                           Technologiepark
                                        Martin-Schmeißer-Weg 9
     Dipl. Inf. Klaus Malorny           44227 Dortmund
     [email-masked]             Tel. +49 231 9703 0

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Poll response data
Date: Wed, 27 Jun 2001 11:55:12 -0400
Sender: [email-masked]

>I hope that I've managed to convey this clearly this time.  I would like
>to see what people think about this once its been conveyed properly.

Don't all speak at once... ;-)

Seriously, some other insights would be much appreciated.

<Scott/>

Date: Wed, 27 Jun 2001 09:58:58 -0400 (EDT)
From: Sheer El-Showk <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
cc: "Bason, Chris" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Poll response data
Sender: [email-masked]

My apologies for the continued confusion, let me try to make my suggestion
clearly and give a brief justification and then let everyone descide
whether its useful or not.

The idea is to include a timestamp in each poll response that would
indicate the time the queue update process was mostly recently run.  This
is NOT the time that the queue was last polled by a registrar (which would
be superflous as Scott and Chris have pointed out).  Nor is it
necassarily the time the most recent (as opposed to last, since as
Chris mentioned the most recent message could have been dequeued and an
earlier message would now be the last message on the queue) message was
placed on the queue, but rather the last time that the process that places
messages on the queue was actually run.

To give a concrete example, I might use a cron job running every two hours
to scan my registry database for queable records and then make entries in
another database used by the queue server.  Even if my process finds no
records in the registry database that need to be queued, it will still
mark my queue database (in a header or special purpose record) every two
hours to indicate that the queue represents the state of the registry up
until this point in time (the time the last cron job was run).  Since this
timestamp is then passed on to registrars with each poll request they
know how recently the queue was synchronized with the canonical data
source (the registry database) -- a useful piece of information in my
opinion.  This presumes queue updates will be a batched process rather
then some event-driven (pushed) system such as refreshing the queue in
real-time as events occur at the registry.   Even in the later case
however, it will be useful to know that the queue represents the state
of the registry in real time.

I hope that I've managed to convey this clearly this time.  I would like
to see what people think about this once its been conveyed properly.

Regards,
Sheer

On Wed, 27 Jun 2001, Hollenbeck, Scott wrote:

> Sheer,
>
> Now I'm getting confused.  If your suggestion is to note when the queue is
> updated, that happens every time is message is either enqueued or dequeued.
> So, pulling off a message would result in an update, and I'm not sure that
> the date and time of that event is of any value at all because the client
> already knows exactly when it happened because they caused the update.
>
> When you wrote "updated", did you mean "had a message added to the end of
> the queue"?  After thinking about that a bit, I'm not sure that this
> provides any really useful information, either.  The protocol currently
> provides a queue counter that tells the client how many message are queued
> for delivery.  If a client gets an indication in a response that there are
> "n" queued messages, I've thought (and I may be wrong) that clients will
> typically want to retrieve all of the queued messages at once through a
> series of "n" <poll> requests and acks without really worrying about when
> the last message was added.
>
> Could someone else with a client perspective provide any insights into ways
> that a "last updated" or "last queued" time would be valuable or not?  I'm
> OK with noting a date-time on each queued message, but I'm not so sure about
> the utility of this second date-time.
>
> <Scott/>
>
> >-----Original Message-----
> >From: Sheer El-Showk [mailto:[email-masked]]
> >Sent: Tuesday, June 26, 2001 2:05 PM
> >To: Bason, Chris
> >Cc: [email-masked]'
> >Subject: RE: Poll response data
> >
> >
> >Hi Chris,
> >
> >I think this concept makes a lot more sent if you think of it as a "queue
> >last updated" timestamp rather than a "last message queue time" (my
> >careless wording initiall, I apologize).  The idea is that the queue
> >structure (in memory or in a database or whatever) would maintain a
> >timestamp indicating the last time it was updated.  It would then
> >prepend/append this to any response to a <poll> request.  This wouldn't
> >be part of the actually queue message, but status information about the
> >overall queue.  In fact, if the queue is updated (by whatever batch or
> >synchronus process updates it) without any messages being added then this
> >time will be very different from a "last message queued" timestamp.
> >
> >The idea behind this is to give the polling registrar an idea of the
> >freshness of the queue overall.  If I'm polling for the state of a
> >transfer request and see only an "awaiting acknowledgement" message queued
> >two days ago it makes a big difference to me whether the queue was last
> >updated a few minutes ago or two days ago.  The idea is to allow automated
> >registrar systems to determine if they need to actively query for more
> >detailed information.  Of course, I think, if all these systems are kept
> >near real time then a lot of this will be redundant, but that expectation
> >can't be built into the protocol.
>

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Klaus Malorny'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Billing information and EPP/GRRP-REQ
Date: Wed, 27 Jun 2001 08:44:46 -0400
Sender: [email-masked]

Klaus,

I don't think I understand your suggestion.  It sounds like you'd like to
see a client-provided serial number and a client-provided credit/debit
amount related to registrar billing actions with their customers, but I
don't understand how that info is of any use or concern to a registry.

If I'm misreading what you wrote, are you instead talking about registry
billing of the registrar, for example letting the registrar know how much
credit they have left after adding or renewing a domain name?  If so,
wouldn't this be best done in registry-defined extensions to the protocol?

If I'm still completely off-base, can you provide some XML examples that
illustrate your suggestion?

<Scott/>

>-----Original Message-----
>From: Klaus Malorny [mailto:[email-masked]]
>Sent: Wednesday, June 27, 2001 8:32 AM
>To: Hollenbeck, Scott
>Cc: [email-masked]
>Subject: Re: Billing information and EPP/GRRP-REQ
>
>
>"Hollenbeck, Scott" wrote:
>
>
>> I'd certainly prefer to keep registry-specific billing details out of the
>> protocol.  If they have to be in there anywhere a registry could do
whatever
>> it wants in the <unspec> elements.  If you have a proposal in mind,
though,
>> please post it to the list to present a more complete picture and to
gather
>> other opinions.
>> 
>> <Scott/>.
>
>
>Hi Scott,
>
>sorry for not answering earlier, but I'm quite busy these days, so I had
not
>much time.
>
>My original idea was to add some general accounting information to each
>request, at least a serial number (I would have called it transaction
number
>if there wouldn't be a chance to be confused with other transaction IDs)
and
>the amount either deducted or credited. The serial number is used to keep
>track/synchronize with invoices received by other means, i.e., not to book
a
>certain item twice. Well, additional fields could contain the account
number
>and a description field, which holds the cause of the posting.
>
>There is of course a problem: Some costs may be generated outside of the
>requests, e.g. a registry may decide to have an auto-renewal mechanism
(like
>the .DE registry on a monthly base), or the gaining registrar does not have
to
>pay the fees before the loosing registrar accepts the transfer. So there
may
>be no chance to report it immediately together with the response. One way
>would be to report these costs via a poll, but I fear that either the
number
>or the sizes of the responses could be too much. Another way would be to
keep
>the records at the registry and report them on the next request to the
object.
>
>Please let me add the following to the background of my questions: Many
>registrars have or will have resellers, and these resellers also may have
>resellers and so on. Due to bad experiences, many registrars and resellers
>require prepayment for bulk domain registrations. To keep track how much of
>the payed money has been eaten up, it would be helpful to have immediate
>feedback from the registry about the costs of a request and therefore be
able
>to block requests from a certain customer if necessary. Since a registrar
may
>bill his customers different to the way he is billed, it may also be
suitable
>to have more abstract accounting information, e.g. on a delete request:
"you
>have been charged for X registration periods".

From: "Bason, Chris" <[email-masked]>
To: [email-masked]
Subject: RE: Poll response data
Date: Wed, 27 Jun 2001 08:30:42 -0400
Sender: [email-masked]

Sheer,

The idea of putting the queue update time in the
response seems to make even less sense. The problem
I see here is that when you dequeue a message you
are updating the queue. Therefore every time you
retrieve a queued message all you are doing is 
sending the time you retrieved that particular message
in the response.

There is a count that is returned in the response
to a poll that indicates how many messages are in 
the queue. I think "overall freshness" is not what
a registrar needs to be concerned with. They should
dequeue each message and process it in the sequence
received. The idea that a registrar can determine
what needs to be done with a message or whether to
process a message based on "overall freshness" seems
to me to be problematic. 

Chris Bason

-----Original Message-----
From: Sheer El-Showk [mailto:[email-masked]]
Sent: Tuesday, June 26, 2001 2:05 PM
To: Bason, Chris
Cc: [email-masked]'
Subject: RE: Poll response data

Hi Chris,

I think this concept makes a lot more sent if you think of it as a "queue
last updated" timestamp rather than a "last message queue time" (my
careless wording initiall, I apologize).  The idea is that the queue
structure (in memory or in a database or whatever) would maintain a
timestamp indicating the last time it was updated.  It would then
prepend/append this to any response to a <poll> request.  This wouldn't
be part of the actually queue message, but status information about the
overall queue.  In fact, if the queue is updated (by whatever batch or
synchronus process updates it) without any messages being added then this
time will be very different from a "last message queued" timestamp.

The idea behind this is to give the polling registrar an idea of the
freshness of the queue overall.  If I'm polling for the state of a
transfer request and see only an "awaiting acknowledgement" message queued
two days ago it makes a big difference to me whether the queue was last
updated a few minutes ago or two days ago.  The idea is to allow automated
registrar systems to determine if they need to actively query for more
detailed information.  Of course, I think, if all these systems are kept
near real time then a lot of this will be redundant, but that expectation
can't be built into the protocol.

Sheer

On Tue, 26 Jun 2001, Bason, Chris wrote:

> Sheer,
>
> The timestamp indicating when a message is queued
> is definitely relevant. Although, I don't see how a
> timestamp indicating when the "last" message is queued
> will help.
>
> You can't store the timestamp of the "last" message
> queued in the actual message being queued. The reason
> is that when you queue a message it IS the last message
> being queued and therefore the message queued timestamp
> and the "last" message queued timestamp would be the same.
> When the current message is dequeued from the queue, if
> you want to send in the message the "last" message queued
> timestamp, you would need to query the queue for the most
> recently queued message to determine when it was queued.
> You can't just send the message.
>
> Additionally, as soon as you send the message, the "last" message
> queued timestamp is obsolete. A message could be queued immediately
> after a message has been sent that obsoletes it and therefore
> makes the "last" message timestamp useless.
>
> Chris Bason
>
>
> -----Original Message-----
> From: Sheer El-Showk [mailto:[email-masked]]
> Sent: Thursday, June 21, 2001 12:33 PM
> To: Klaus Malorny
> Cc: Rick H Wesson; Hollenbeck, Scott; [email-masked]'
> Subject: Re: Poll response data
>
>
> Hi all,
>
> First off, I'm not all that concerned about the polling mecahism from an
> implementation perspective.  Depending on the registry architecture I
> think it would be possible to implement a notification system so that the
> queue is updated in near real time (the same way whois or zone file
> updates might eventually be implemented) upon transfer or other relevant
> events.
>
> That implementation detail aside, I think its still possible to address
> this concern within the protocol.  I may have missed it, but I didn't see
> any reference to a message timestamp in the EPP-03 discussion of <poll>.
> I think each poll resposne should include two new timestamps.  The first
> will be the time that the queue was most recently updated; the second will
> be the time that particular queued message was placed in the queue.  That
> way, the registrar has all the information it requires about the queued
> messages and can descide in a more informed manner whether or not it has
> to make further queries.
>
> Sheer
>
>
> On Thu, 21 Jun 2001, Klaus Malorny wrote:
>
> > Rick H Wesson wrote:
> > >
> > > Scott,
> > >
> > > On Wed, 20 Jun 2001, Hollenbeck, Scott wrote:
> > >
> > > > After thinking about this for a bit, I like Klaus' idea of returning
> more
> > > > transfer detail in the <poll> response.  Doing so will help reduce
the
> need
> > > > to do an immediate <transfer> query right after receiving a message
to
> > > > obtain the details of a pending transfer.
> > > >
> > >
> > > however the tradeoff is that the queue(s) wiill have to be larger and
> > > couldn't the information become out of sync with the rest of the
> registry?
> > >
> > >   Registrar-A submits a transfer request for foo.com from Registrar-B
> > >   <registry inserts stuff in queue>
> > >   Registrar-B does poll and ACK on foo.com
> > >   Registrar-A does a poll -> is the information correct?
> > >
> > > A better question is this situation ok?
> > >
> > > -rick
> >
> > Hi Rick,
> >
> > anywhere where you have multiple actions which are not executed
atomically
> in
> > a multitasking environment, there is a chance to get outdated
information.
> > E.g. you could query the registry about a transfer and it tells you that
> it is
> > pending, so you decide that you either accept or reject it. But before
you
> > submit your decision to the registry, the gaining registrar may have
> cancelled
> > the transfer, so you may get some kind of error message on your transfer
> > request despite the query reponse you got fractions of a second before.
> >
> > Therefore, the problem is not specific to the poll mechanism, although
the
> > effect may appear more often if you don't poll regularly.
> >
> > regards,
> >
> > Klaus Malorny
> >
> >
> >
>
___________________________________________________________________________
> >      |       |
> >      | knipp |                   Knipp  Medien und Kommunikation GmbH
> >       -------                           Technologiepark
> >                                         Martin-Schmeisser-Weg 9
> >      Dipl. Inf. Klaus Malorny           44227 Dortmund
> >      [email-masked]             Tel. +49 231 9703 0
> >
>

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Sheer El-Showk'" <[email-masked]>, "Bason, Chris" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Poll response data
Date: Wed, 27 Jun 2001 08:27:10 -0400
Sender: [email-masked]

Sheer,

Now I'm getting confused.  If your suggestion is to note when the queue is
updated, that happens every time is message is either enqueued or dequeued.
So, pulling off a message would result in an update, and I'm not sure that
the date and time of that event is of any value at all because the client
already knows exactly when it happened because they caused the update.

When you wrote "updated", did you mean "had a message added to the end of
the queue"?  After thinking about that a bit, I'm not sure that this
provides any really useful information, either.  The protocol currently
provides a queue counter that tells the client how many message are queued
for delivery.  If a client gets an indication in a response that there are
"n" queued messages, I've thought (and I may be wrong) that clients will
typically want to retrieve all of the queued messages at once through a
series of "n" <poll> requests and acks without really worrying about when
the last message was added.

Could someone else with a client perspective provide any insights into ways
that a "last updated" or "last queued" time would be valuable or not?  I'm
OK with noting a date-time on each queued message, but I'm not so sure about
the utility of this second date-time.

<Scott/>

>-----Original Message-----
>From: Sheer El-Showk [mailto:[email-masked]]
>Sent: Tuesday, June 26, 2001 2:05 PM
>To: Bason, Chris
>Cc: [email-masked]'
>Subject: RE: Poll response data
>
>
>Hi Chris,
>
>I think this concept makes a lot more sent if you think of it as a "queue
>last updated" timestamp rather than a "last message queue time" (my
>careless wording initiall, I apologize).  The idea is that the queue
>structure (in memory or in a database or whatever) would maintain a
>timestamp indicating the last time it was updated.  It would then
>prepend/append this to any response to a <poll> request.  This wouldn't
>be part of the actually queue message, but status information about the
>overall queue.  In fact, if the queue is updated (by whatever batch or
>synchronus process updates it) without any messages being added then this
>time will be very different from a "last message queued" timestamp.
>
>The idea behind this is to give the polling registrar an idea of the
>freshness of the queue overall.  If I'm polling for the state of a
>transfer request and see only an "awaiting acknowledgement" message queued
>two days ago it makes a big difference to me whether the queue was last
>updated a few minutes ago or two days ago.  The idea is to allow automated
>registrar systems to determine if they need to actively query for more
>detailed information.  Of course, I think, if all these systems are kept
>near real time then a lot of this will be redundant, but that expectation
>can't be built into the protocol.

Date: Wed, 27 Jun 2001 14:32:18 +0200
From: Klaus Malorny <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: Billing information and EPP/GRRP-REQ
Sender: [email-masked]

"Hollenbeck, Scott" wrote:

> I'd certainly prefer to keep registry-specific billing details out of the
> protocol.  If they have to be in there anywhere a registry could do whatever
> it wants in the <unspec> elements.  If you have a proposal in mind, though,
> please post it to the list to present a more complete picture and to gather
> other opinions.
> 
> <Scott/>.

Hi Scott,

sorry for not answering earlier, but I'm quite busy these days, so I had not
much time.

My original idea was to add some general accounting information to each
request, at least a serial number (I would have called it transaction number
if there wouldn't be a chance to be confused with other transaction IDs) and
the amount either deducted or credited. The serial number is used to keep
track/synchronize with invoices received by other means, i.e., not to book a
certain item twice. Well, additional fields could contain the account number
and a description field, which holds the cause of the posting.

There is of course a problem: Some costs may be generated outside of the
requests, e.g. a registry may decide to have an auto-renewal mechanism (like
the .DE registry on a monthly base), or the gaining registrar does not have to
pay the fees before the loosing registrar accepts the transfer. So there may
be no chance to report it immediately together with the response. One way
would be to report these costs via a poll, but I fear that either the number
or the sizes of the responses could be too much. Another way would be to keep
the records at the registry and report them on the next request to the object.

Please let me add the following to the background of my questions: Many
registrars have or will have resellers, and these resellers also may have
resellers and so on. Due to bad experiences, many registrars and resellers
require prepayment for bulk domain registrations. To keep track how much of
the payed money has been eaten up, it would be helpful to have immediate
feedback from the registry about the costs of a request and therefore be able
to block requests from a certain customer if necessary. Since a registrar may
bill his customers different to the way he is billed, it may also be suitable
to have more abstract accounting information, e.g. on a delete request: "you
have been charged for X registration periods".

regards,

Klaus Malorny

___________________________________________________________________________
     |       |
     | knipp |                   Knipp  Medien und Kommunikation GmbH
      -------                           Technologiepark
                                        Martin-Schmeisser-Weg 9
     Dipl. Inf. Klaus Malorny           44227 Dortmund
     [email-masked]             Tel. +49 231 9703 0

Date: Tue, 26 Jun 2001 14:04:36 -0400 (EDT)
From: Sheer El-Showk <[email-masked]>
To: "Bason, Chris" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: RE: Poll response data
Sender: [email-masked]

Hi Chris,

I think this concept makes a lot more sent if you think of it as a "queue
last updated" timestamp rather than a "last message queue time" (my
careless wording initiall, I apologize).  The idea is that the queue
structure (in memory or in a database or whatever) would maintain a
timestamp indicating the last time it was updated.  It would then
prepend/append this to any response to a <poll> request.  This wouldn't
be part of the actually queue message, but status information about the
overall queue.  In fact, if the queue is updated (by whatever batch or
synchronus process updates it) without any messages being added then this
time will be very different from a "last message queued" timestamp.

The idea behind this is to give the polling registrar an idea of the
freshness of the queue overall.  If I'm polling for the state of a
transfer request and see only an "awaiting acknowledgement" message queued
two days ago it makes a big difference to me whether the queue was last
updated a few minutes ago or two days ago.  The idea is to allow automated
registrar systems to determine if they need to actively query for more
detailed information.  Of course, I think, if all these systems are kept
near real time then a lot of this will be redundant, but that expectation
can't be built into the protocol.

Sheer

On Tue, 26 Jun 2001, Bason, Chris wrote:

> Sheer,
>
> The timestamp indicating when a message is queued
> is definitely relevant. Although, I don't see how a
> timestamp indicating when the "last" message is queued
> will help.
>
> You can't store the timestamp of the "last" message
> queued in the actual message being queued. The reason
> is that when you queue a message it IS the last message
> being queued and therefore the message queued timestamp
> and the "last" message queued timestamp would be the same.
> When the current message is dequeued from the queue, if
> you want to send in the message the "last" message queued
> timestamp, you would need to query the queue for the most
> recently queued message to determine when it was queued.
> You can't just send the message.
>
> Additionally, as soon as you send the message, the "last" message
> queued timestamp is obsolete. A message could be queued immediately
> after a message has been sent that obsoletes it and therefore
> makes the "last" message timestamp useless.
>
> Chris Bason
>
>
> -----Original Message-----
> From: Sheer El-Showk [mailto:[email-masked]]
> Sent: Thursday, June 21, 2001 12:33 PM
> To: Klaus Malorny
> Cc: Rick H Wesson; Hollenbeck, Scott; [email-masked]'
> Subject: Re: Poll response data
>
>
> Hi all,
>
> First off, I'm not all that concerned about the polling mecahism from an
> implementation perspective.  Depending on the registry architecture I
> think it would be possible to implement a notification system so that the
> queue is updated in near real time (the same way whois or zone file
> updates might eventually be implemented) upon transfer or other relevant
> events.
>
> That implementation detail aside, I think its still possible to address
> this concern within the protocol.  I may have missed it, but I didn't see
> any reference to a message timestamp in the EPP-03 discussion of <poll>.
> I think each poll resposne should include two new timestamps.  The first
> will be the time that the queue was most recently updated; the second will
> be the time that particular queued message was placed in the queue.  That
> way, the registrar has all the information it requires about the queued
> messages and can descide in a more informed manner whether or not it has
> to make further queries.
>
> Sheer
>
>
> On Thu, 21 Jun 2001, Klaus Malorny wrote:
>
> > Rick H Wesson wrote:
> > >
> > > Scott,
> > >
> > > On Wed, 20 Jun 2001, Hollenbeck, Scott wrote:
> > >
> > > > After thinking about this for a bit, I like Klaus' idea of returning
> more
> > > > transfer detail in the <poll> response.  Doing so will help reduce the
> need
> > > > to do an immediate <transfer> query right after receiving a message to
> > > > obtain the details of a pending transfer.
> > > >
> > >
> > > however the tradeoff is that the queue(s) wiill have to be larger and
> > > couldn't the information become out of sync with the rest of the
> registry?
> > >
> > >   Registrar-A submits a transfer request for foo.com from Registrar-B
> > >   <registry inserts stuff in queue>
> > >   Registrar-B does poll and ACK on foo.com
> > >   Registrar-A does a poll -> is the information correct?
> > >
> > > A better question is this situation ok?
> > >
> > > -rick
> >
> > Hi Rick,
> >
> > anywhere where you have multiple actions which are not executed atomically
> in
> > a multitasking environment, there is a chance to get outdated information.
> > E.g. you could query the registry about a transfer and it tells you that
> it is
> > pending, so you decide that you either accept or reject it. But before you
> > submit your decision to the registry, the gaining registrar may have
> cancelled
> > the transfer, so you may get some kind of error message on your transfer
> > request despite the query reponse you got fractions of a second before.
> >
> > Therefore, the problem is not specific to the poll mechanism, although the
> > effect may appear more often if you don't poll regularly.
> >
> > regards,
> >
> > Klaus Malorny
> >
> >
> >
> ___________________________________________________________________________
> >      |       |
> >      | knipp |                   Knipp  Medien und Kommunikation GmbH
> >       -------                           Technologiepark
> >                                         Martin-Schmeisser-Weg 9
> >      Dipl. Inf. Klaus Malorny           44227 Dortmund
> >      [email-masked]             Tel. +49 231 9703 0
> >
>

From: "Bason, Chris" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Poll response data
Date: Tue, 26 Jun 2001 09:02:44 -0400
Sender: [email-masked]

Sheer,

The timestamp indicating when a message is queued 
is definitely relevant. Although, I don't see how a 
timestamp indicating when the "last" message is queued 
will help.

You can't store the timestamp of the "last" message 
queued in the actual message being queued. The reason
is that when you queue a message it IS the last message
being queued and therefore the message queued timestamp
and the "last" message queued timestamp would be the same.
When the current message is dequeued from the queue, if 
you want to send in the message the "last" message queued 
timestamp, you would need to query the queue for the most 
recently queued message to determine when it was queued. 
You can't just send the message.

Additionally, as soon as you send the message, the "last" message 
queued timestamp is obsolete. A message could be queued immediately 
after a message has been sent that obsoletes it and therefore 
makes the "last" message timestamp useless.

Chris Bason

-----Original Message-----
From: Sheer El-Showk [mailto:[email-masked]]
Sent: Thursday, June 21, 2001 12:33 PM
To: Klaus Malorny
Cc: Rick H Wesson; Hollenbeck, Scott; [email-masked]'
Subject: Re: Poll response data

Hi all,

First off, I'm not all that concerned about the polling mecahism from an
implementation perspective.  Depending on the registry architecture I
think it would be possible to implement a notification system so that the
queue is updated in near real time (the same way whois or zone file
updates might eventually be implemented) upon transfer or other relevant
events.

That implementation detail aside, I think its still possible to address
this concern within the protocol.  I may have missed it, but I didn't see
any reference to a message timestamp in the EPP-03 discussion of <poll>.
I think each poll resposne should include two new timestamps.  The first
will be the time that the queue was most recently updated; the second will
be the time that particular queued message was placed in the queue.  That
way, the registrar has all the information it requires about the queued
messages and can descide in a more informed manner whether or not it has
to make further queries.

Sheer

On Thu, 21 Jun 2001, Klaus Malorny wrote:

> Rick H Wesson wrote:
> >
> > Scott,
> >
> > On Wed, 20 Jun 2001, Hollenbeck, Scott wrote:
> >
> > > After thinking about this for a bit, I like Klaus' idea of returning
more
> > > transfer detail in the <poll> response.  Doing so will help reduce the
need
> > > to do an immediate <transfer> query right after receiving a message to
> > > obtain the details of a pending transfer.
> > >
> >
> > however the tradeoff is that the queue(s) wiill have to be larger and
> > couldn't the information become out of sync with the rest of the
registry?
> >
> >   Registrar-A submits a transfer request for foo.com from Registrar-B
> >   <registry inserts stuff in queue>
> >   Registrar-B does poll and ACK on foo.com
> >   Registrar-A does a poll -> is the information correct?
> >
> > A better question is this situation ok?
> >
> > -rick
>
> Hi Rick,
>
> anywhere where you have multiple actions which are not executed atomically
in
> a multitasking environment, there is a chance to get outdated information.
> E.g. you could query the registry about a transfer and it tells you that
it is
> pending, so you decide that you either accept or reject it. But before you
> submit your decision to the registry, the gaining registrar may have
cancelled
> the transfer, so you may get some kind of error message on your transfer
> request despite the query reponse you got fractions of a second before.
>
> Therefore, the problem is not specific to the poll mechanism, although the
> effect may appear more often if you don't poll regularly.
>
> regards,
>
> Klaus Malorny
>
>
>
___________________________________________________________________________
>      |       |
>      | knipp |                   Knipp  Medien und Kommunikation GmbH
>       -------                           Technologiepark
>                                         Martin-Schmeisser-Weg 9
>      Dipl. Inf. Klaus Malorny           44227 Dortmund
>      [email-masked]             Tel. +49 231 9703 0
>

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Poll response data
Date: Thu, 21 Jun 2001 13:48:13 -0400
Sender: [email-masked]

>-----Original Message-----
>From: Sheer El-Showk [mailto:[email-masked]]
>Sent: Thursday, June 21, 2001 12:33 PM
>To: Klaus Malorny
>Cc: Rick H Wesson; Hollenbeck, Scott; [email-masked]'
>Subject: Re: Poll response data

[snip]

>That implementation detail aside, I think its still possible to address
>this concern within the protocol.  I may have missed it, but I didn't see
>any reference to a message timestamp in the EPP-03 discussion of <poll>.
>I think each poll resposne should include two new timestamps.  The first
>will be the time that the queue was most recently updated; the second will
>be the time that particular queued message was placed in the queue.  That
>way, the registrar has all the information it requires about the queued
>messages and can descide in a more informed manner whether or not it has
>to make further queries.

This could be done pretty easily by adding two child elements to the
existing <msgQ> element: <qHead> to note when the message being retrieved
was enqueued, and <qTail> to note when the last message was enqueued.

<Scott/>

Date: Thu, 21 Jun 2001 12:32:40 -0400 (EDT)
From: Sheer El-Showk <[email-masked]>
To: Klaus Malorny <[email-masked]>
cc: Rick H Wesson <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Poll response data
Sender: [email-masked]

Hi all,

First off, I'm not all that concerned about the polling mecahism from an
implementation perspective.  Depending on the registry architecture I
think it would be possible to implement a notification system so that the
queue is updated in near real time (the same way whois or zone file
updates might eventually be implemented) upon transfer or other relevant
events.

That implementation detail aside, I think its still possible to address
this concern within the protocol.  I may have missed it, but I didn't see
any reference to a message timestamp in the EPP-03 discussion of <poll>.
I think each poll resposne should include two new timestamps.  The first
will be the time that the queue was most recently updated; the second will
be the time that particular queued message was placed in the queue.  That
way, the registrar has all the information it requires about the queued
messages and can descide in a more informed manner whether or not it has
to make further queries.

Sheer

On Thu, 21 Jun 2001, Klaus Malorny wrote:

> Rick H Wesson wrote:
> >
> > Scott,
> >
> > On Wed, 20 Jun 2001, Hollenbeck, Scott wrote:
> >
> > > After thinking about this for a bit, I like Klaus' idea of returning more
> > > transfer detail in the <poll> response.  Doing so will help reduce the need
> > > to do an immediate <transfer> query right after receiving a message to
> > > obtain the details of a pending transfer.
> > >
> >
> > however the tradeoff is that the queue(s) wiill have to be larger and
> > couldn't the information become out of sync with the rest of the registry?
> >
> >   Registrar-A submits a transfer request for foo.com from Registrar-B
> >   <registry inserts stuff in queue>
> >   Registrar-B does poll and ACK on foo.com
> >   Registrar-A does a poll -> is the information correct?
> >
> > A better question is this situation ok?
> >
> > -rick
>
> Hi Rick,
>
> anywhere where you have multiple actions which are not executed atomically in
> a multitasking environment, there is a chance to get outdated information.
> E.g. you could query the registry about a transfer and it tells you that it is
> pending, so you decide that you either accept or reject it. But before you
> submit your decision to the registry, the gaining registrar may have cancelled
> the transfer, so you may get some kind of error message on your transfer
> request despite the query reponse you got fractions of a second before.
>
> Therefore, the problem is not specific to the poll mechanism, although the
> effect may appear more often if you don't poll regularly.
>
> regards,
>
> Klaus Malorny
>
>
> ___________________________________________________________________________
>      |       |
>      | knipp |                   Knipp  Medien und Kommunikation GmbH
>       -------                           Technologiepark
>                                         Martin-Schmeisser-Weg 9
>      Dipl. Inf. Klaus Malorny           44227 Dortmund
>      [email-masked]             Tel. +49 231 9703 0
>

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Klaus Malorny'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Billing information and EPP/GRRP-REQ
Date: Thu, 21 Jun 2001 07:05:35 -0400
Sender: [email-masked]

>-----Original Message-----
>From: Klaus Malorny [mailto:[email-masked]]
>Sent: Thursday, June 21, 2001 5:02 AM
>To: Hollenbeck, Scott; [email-masked]'
>Subject: Billing information and EPP/GRRP-REQ
>
>Hi together,
>hi Scott,
>
>while digging more and more into Afilias' and NeuLevel's documents (as far
as
>they exist ;-), I was wondering whether it would be a good idea to include
>billing information in EPP responses resp. include a requirement in the
>GRRP-REQ document to provide such a feature. Yes, I know that the pricing
of
>certain actions is a registry policy, of course. Nevertheless or especially
>for that reason it could be a good idea to have a common reporting
mechanism:
>Since a registry might introduce several grace periods (like NSI/Verisign
does
>with newly registered domains/renewed domains), in certain situations it
may
>not be quite clear to the registrar whether such a grace period applies or
>not. So for  near-registration-time accounting, it may be good if some
>information is included (I could detail this). This information should not
>make monthly reports obsolete, but could complement these.

I'd certainly prefer to keep registry-specific billing details out of the
protocol.  If they have to be in there anywhere a registry could do whatever
it wants in the <unspec> elements.  If you have a proposal in mind, though,
please post it to the list to present a more complete picture and to gather
other opinions.

<Scott/>.

Date: Thu, 21 Jun 2001 11:02:10 +0200
From: Klaus Malorny <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Billing information and EPP/GRRP-REQ
Sender: [email-masked]

Hi together,
hi Scott,

while digging more and more into Afilias' and NeuLevel's documents (as far as
they exist ;-), I was wondering whether it would be a good idea to include
billing information in EPP responses resp. include a requirement in the
GRRP-REQ document to provide such a feature. Yes, I know that the pricing of
certain actions is a registry policy, of course. Nevertheless or especially
for that reason it could be a good idea to have a common reporting mechanism:
Since a registry might introduce several grace periods (like NSI/Verisign does
with newly registered domains/renewed domains), in certain situations it may
not be quite clear to the registrar whether such a grace period applies or
not. So for  near-registration-time accounting, it may be good if some
information is included (I could detail this). This information should not
make monthly reports obsolete, but could complement these.

Klaus Malorny

___________________________________________________________________________
     |       |
     | knipp |                   Knipp  Medien und Kommunikation GmbH
      -------                           Technologiepark
                                        Martin-Schmeisser-Weg 9
     Dipl. Inf. Klaus Malorny           44227 Dortmund
     [email-masked]             Tel. +49 231 9703 0

Date: Thu, 21 Jun 2001 09:35:25 +0200
From: Klaus Malorny <[email-masked]>
To: Rick H Wesson <[email-masked]>
CC: "Hollenbeck, Scott" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Poll response data
Sender: [email-masked]

Rick H Wesson wrote:
> 
> Scott,
> 
> On Wed, 20 Jun 2001, Hollenbeck, Scott wrote:
> 
> > After thinking about this for a bit, I like Klaus' idea of returning more
> > transfer detail in the <poll> response.  Doing so will help reduce the need
> > to do an immediate <transfer> query right after receiving a message to
> > obtain the details of a pending transfer.
> >
> 
> however the tradeoff is that the queue(s) wiill have to be larger and
> couldn't the information become out of sync with the rest of the registry?
> 
>   Registrar-A submits a transfer request for foo.com from Registrar-B
>   <registry inserts stuff in queue>
>   Registrar-B does poll and ACK on foo.com
>   Registrar-A does a poll -> is the information correct?
> 
> A better question is this situation ok?
> 
> -rick

Hi Rick,

anywhere where you have multiple actions which are not executed atomically in
a multitasking environment, there is a chance to get outdated information.
E.g. you could query the registry about a transfer and it tells you that it is
pending, so you decide that you either accept or reject it. But before you
submit your decision to the registry, the gaining registrar may have cancelled
the transfer, so you may get some kind of error message on your transfer
request despite the query reponse you got fractions of a second before.

Therefore, the problem is not specific to the poll mechanism, although the
effect may appear more often if you don't poll regularly.

regards,

Klaus Malorny

___________________________________________________________________________
     |       |
     | knipp |                   Knipp  Medien und Kommunikation GmbH
      -------                           Technologiepark
                                        Martin-Schmeisser-Weg 9
     Dipl. Inf. Klaus Malorny           44227 Dortmund
     [email-masked]             Tel. +49 231 9703 0

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Poll response data
Date: Wed, 20 Jun 2001 12:56:10 -0400
Sender: [email-masked]

>-----Original Message-----
>From: Rick H Wesson [mailto:[email-masked]]
>Sent: Wednesday, June 20, 2001 12:50 PM
>To: Hollenbeck, Scott
>Cc: 'Klaus Malorny'; [email-masked]'
>Subject: RE: Poll response data
>
>
>
>Scott,
>
>On Wed, 20 Jun 2001, Hollenbeck, Scott wrote:
>
>
>> After thinking about this for a bit, I like Klaus' idea of returning more
>> transfer detail in the <poll> response.  Doing so will help reduce the
need
>> to do an immediate <transfer> query right after receiving a message to
>> obtain the details of a pending transfer.
>>
>
>however the tradeoff is that the queue(s) wiill have to be larger and
>couldn't the information become out of sync with the rest of 
>the registry?
>
>  Registrar-A submits a transfer request for foo.com from Registrar-B
>  <registry inserts stuff in queue>
>  Registrar-B does poll and ACK on foo.com
>  Registrar-A does a poll -> is the information correct?
>
>A better question is this situation ok?

All info will be correct as of the time a message was queued, though you're
right that things might change between the time a message gets queued and
the time it gets retrieved (in the case you mentioned, registrar-A's queued
messages will include a notice of B's ACK, so when viewed in aggregate all
of the info will be correct and current).  I suppose that the need or desire
to do a <transfer> query after receiving notice of a <transfer> action may
depend on the amount of time that has elapsed between message enqueuing and
message retrieval.  What I think is important, though, is that the client
will have all of the info it needs to determine if it _should_ do an
additional query -- it won't _have_ to.  Without more detail in the message,
the client _must_ do a query to obtain details.

<Scott/>

Date: Wed, 20 Jun 2001 09:49:40 -0700 (PDT)
From: Rick H Wesson <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
cc: "'Klaus Malorny'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Poll response data
Sender: [email-masked]

Scott,

On Wed, 20 Jun 2001, Hollenbeck, Scott wrote:

> After thinking about this for a bit, I like Klaus' idea of returning more
> transfer detail in the <poll> response.  Doing so will help reduce the need
> to do an immediate <transfer> query right after receiving a message to
> obtain the details of a pending transfer.
>

however the tradeoff is that the queue(s) wiill have to be larger and
couldn't the information become out of sync with the rest of the registry?

  Registrar-A submits a transfer request for foo.com from Registrar-B
  <registry inserts stuff in queue>
  Registrar-B does poll and ACK on foo.com
  Registrar-A does a poll -> is the information correct?

A better question is this situation ok?

-rick

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Klaus Malorny'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Poll response data
Date: Wed, 20 Jun 2001 12:27:14 -0400
Sender: [email-masked]

>-----Original Message-----
>From: Klaus Malorny [mailto:[email-masked]]
>Sent: Tuesday, June 19, 2001 8:14 AM
>To: Hollenbeck, Scott
>Cc: [email-masked]'
>Subject: Re: Poll response data

[snip]

>you are right, but this was just a suggestion (I want to make constructive
>comments ;-). I don't mind if you reduce the content to the absolute
minimum.
>It would of course be enough if it would be like the result of the poll
>request in the example on page 24 of draft-ietf-provreg-epp-03. But please
add
>this as a requirement. To me it's a kind of horror vision to see transfer
>notifications transmitted outside of the protocol (worst is per e-mail),
>albeit the EPP already contains the whole functionality for it. Making it
to a
>requirement will ensure that EPP is used for this purpose.

After thinking about this for a bit, I like Klaus' idea of returning more
transfer detail in the <poll> response.  Doing so will help reduce the need
to do an immediate <transfer> query right after receiving a message to
obtain the details of a pending transfer.

<Scott/>

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Versioning
Date: Wed, 20 Jun 2001 11:40:45 -0400
Sender: [email-masked]

>-----Original Message-----
>From: Rick H Wesson [mailto:[email-masked]]
>Sent: Wednesday, June 20, 2001 9:33 AM
>To: Hollenbeck, Scott
>Cc: [email-masked]'
>Subject: Re: Versioning
>
>
>
>Scott,
>
>On Wed, 20 Jun 2001, Hollenbeck, Scott wrote:
>
>> to identify version 1 of the mapping.  If a new version is needed at a
later
>> date, incrementing the version number in the URI provides an easy way to
>> ensure parser-enforced uniqueness.
>
>how about major-minor-patch. I forsee more object types than the ones we
>have now. Also how would you track the rfc ststus?
>
>   -draft-01
>   -rfc-01
>   -draft-standard-01

Major-minor-patch might be a bit much for specification identifiers because
I can't see patches requiring specification changes.  A major-minor revision
number (such as -1.0) could be used for both standards track progression
changes and future versioning needs, though.  Which version number gets
changed could well be a WG decision based on the scope of needed changes.

<Scott/>

Date: Wed, 20 Jun 2001 06:32:53 -0700 (PDT)
From: Rick H Wesson <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: Re: Versioning
Sender: [email-masked]

Scott,

On Wed, 20 Jun 2001, Hollenbeck, Scott wrote:

> to identify version 1 of the mapping.  If a new version is needed at a later
> date, incrementing the version number in the URI provides an easy way to
> ensure parser-enforced uniqueness.

how about major-minor-patch. I forsee more object types than the ones we
have now. Also how would you track the rfc ststus?

   -draft-01
   -rfc-01
   -draft-standard-01
   ...

If we will use this mechanism I'd like there to be some meaning behind it.

-rick

> Any thoughts or objections?  This type of URI versioning might also be
> useful in the base protocol specification, though we currently use a
> <version> element there for this purpose.
>
> <Scott/>
>

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Versioning
Date: Wed, 20 Jun 2001 08:56:43 -0400
Sender: [email-masked]

The current EPP object mappings don't include any sort of versioning
information.  Anticipating evolution, it's probably a good idea to have some
sort of versioning mechanism in place.  There are at least two ways it can
be done:

1. Add <version> elements in appropriate places, or

2. Use the namespace- and schema-identifying URIs to identify specific
versions.

Right now I like option 2 better than option 1 because it won't add any
additional elements, and it's more in line with the way XML Schema itself
manages version differences.  As an example, the URI used to identifying the
domain name mapping could be changed from this:

urn:iana:xml:ns:domain

to this:

urn:iana:xml:ns:domain-01

to identify version 1 of the mapping.  If a new version is needed at a later
date, incrementing the version number in the URI provides an easy way to
ensure parser-enforced uniqueness.

Any thoughts or objections?  This type of URI versioning might also be
useful in the base protocol specification, though we currently use a
<version> element there for this purpose.

<Scott/>

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: Flushing the Message Queue
Date: Tue, 19 Jun 2001 14:16:42 -0400
Sender: [email-masked]

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Tuesday, June 19, 2001 2:04 PM
>To: [email-masked]
>Subject: Re: Flushing the Message Queue

>Please forgive me but I am starting to get confused here. I was under
notion
>that we are working protocol design and not on system design or
>implementation. 
>
>The protocol should mainly focuses on the message syntax and its context. 
>Issues like dealing with duration of message remain on queue and how to
deal
>with the messages after a certain period of time or should we pass them via
>ftp / e-mail or idl implementation, all are system design and
implementation
>issue.

A protocol specification should provide enough information to build
complete, interoperable implementations.  The document describes a queuing
mechanism, but it currently says nothing about a very real operational issue
that every implementer is going to have to face.  I asked the question
because I would much prefer to make a statement in the document that
acknowledges the issue so that implementers know that we didn't fail to
recognize it, and that it's something they need to be aware of.

I do agree that the mechanics of how to deal with it do not belong in the
protocol document.

<Scott/>

Date: Tue, 19 Jun 2001 11:03:31 -0700 (PDT)
From: [email-masked]
To: [email-masked]
Subject: Re: Flushing the Message Queue
Sender: [email-masked]

On Tue, 19 Jun 2001 10:47:34 -0400, Hollenbeck, Scott wrote:

  While we're talking about messages exchanged between client and server, I
  might as well bring this up: there's currently nothing in the protocol
draft
  that says anything about how a server should deal with messages that
remain
  queued for "a long time" due to a client either not retrieving their
  messages or not acknowledging them.  I can't imagine a registry wanting to
  keep messages enqueued for an indefinite amount of time, but I doubt that
  it's a good idea to dequeue and throw messages away, either.
  
  One possibility could be that messages must be retained for some server-
or
  protocol-defined amount of time, and if not dequeued by the client before
  the end of the retention period perhaps the server can dequeue them and
send
  them to the client via an out-of-band method like email, or make them
  available via ftp, or who knows what else.
  
  Does anyone have any thoughts on the topic?
  
  <Scott/>

Please forgive me but I am starting to get confused here. I was under notion
that we are working protocol design and not on system design or
implementation. 

The protocol should mainly focuses on the message syntax and its context. 
Issues like dealing with duration of message remain on queue and how to deal
with the messages after a certain period of time or should we pass them via
ftp / e-mail or idl implementation, all are system design and implementation
issue.

With Regards

_______________________________________________________
Send a cool gift with your E-Card
http://www.bluemountain.com/giftcenter/

Date: Tue, 19 Jun 2001 11:28:37 -0400
From: Daniel Manley <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Re: Flushing the Message Queue
Sender: [email-masked]

But I think that the protocol should at least state that there is an 
OPTIONAL registry-specified timeout on poll nofications and that the 
out-of-band communication method, if there is one, is also 
registry-specific.

hmm... what about poll messages that have time-sensitive data (i.e. 
transfer notifications).  Should they be plucked from the message queue 
when the message is no longer applicable?  I'm hoping the answer is no - 
just cuz it sounds like a lot of work for the registrar to do.  Besides 
if the registrar didn't pick up the transfer notification in time, then 
they're clearly not polling enough.

Dan

Rick H Wesson wrote:

>Scott,
>
>Sounds like registry policy to me, the protocol does not need to specify
>how long they can be kept in queue. It should be up to the registry on how
>to handle it.
>
>-rick
>
>On Tue, 19 Jun 2001, Hollenbeck, Scott wrote:
>
>>While we're talking about messages exchanged between client and server, I
>>might as well bring this up: there's currently nothing in the protocol draft
>>that says anything about how a server should deal with messages that remain
>>queued for "a long time" due to a client either not retrieving their
>>messages or not acknowledging them.  I can't imagine a registry wanting to
>>keep messages enqueued for an indefinite amount of time, but I doubt that
>>it's a good idea to dequeue and throw messages away, either.
>>
>>One possibility could be that messages must be retained for some server- or
>>protocol-defined amount of time, and if not dequeued by the client before
>>the end of the retention period perhaps the server can dequeue them and send
>>them to the client via an out-of-band method like email, or make them
>>available via ftp, or who knows what else.
>>
>>Does anyone have any thoughts on the topic?
>>
>><Scott/>
>>
>

Date: Tue, 19 Jun 2001 08:06:23 -0700 (PDT)
From: Rick H Wesson <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: Re: Flushing the Message Queue
Sender: [email-masked]

Scott,

Sounds like registry policy to me, the protocol does not need to specify
how long they can be kept in queue. It should be up to the registry on how
to handle it.

-rick

On Tue, 19 Jun 2001, Hollenbeck, Scott wrote:

> While we're talking about messages exchanged between client and server, I
> might as well bring this up: there's currently nothing in the protocol draft
> that says anything about how a server should deal with messages that remain
> queued for "a long time" due to a client either not retrieving their
> messages or not acknowledging them.  I can't imagine a registry wanting to
> keep messages enqueued for an indefinite amount of time, but I doubt that
> it's a good idea to dequeue and throw messages away, either.
>
> One possibility could be that messages must be retained for some server- or
> protocol-defined amount of time, and if not dequeued by the client before
> the end of the retention period perhaps the server can dequeue them and send
> them to the client via an out-of-band method like email, or make them
> available via ftp, or who knows what else.
>
> Does anyone have any thoughts on the topic?
>
> <Scott/>
>

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Flushing the Message Queue
Date: Tue, 19 Jun 2001 10:47:34 -0400
Sender: [email-masked]

While we're talking about messages exchanged between client and server, I
might as well bring this up: there's currently nothing in the protocol draft
that says anything about how a server should deal with messages that remain
queued for "a long time" due to a client either not retrieving their
messages or not acknowledging them.  I can't imagine a registry wanting to
keep messages enqueued for an indefinite amount of time, but I doubt that
it's a good idea to dequeue and throw messages away, either.

One possibility could be that messages must be retained for some server- or
protocol-defined amount of time, and if not dequeued by the client before
the end of the retention period perhaps the server can dequeue them and send
them to the client via an out-of-band method like email, or make them
available via ftp, or who knows what else.

Does anyone have any thoughts on the topic?

<Scott/>

Date: Tue, 19 Jun 2001 14:14:12 +0200
From: Klaus Malorny <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: Poll response data
Sender: [email-masked]

"Hollenbeck, Scott" wrote:
> 
> Klaus,
> 
> There _is_ a well defined mechanism to determine all of the transfer details
> you've described.  Look at the definition of the <transfer> command's
> "query" operation.  You're suggesting that this exact same info be described
> and required for return via a polled message?
> 
> I don't have a problem with enhancing the description of the <poll> command
> to note that the format of transfer notices as described in the current text
> is a required feature (are there any others?), but I don't think it makes
> any sense at all to push the transfer details in a polled message.  As
> things are defined right now, a polled message goes away once received and
> acknowledged by the client.  With a transfer query operation the details can
> be retrieved at any time, including after the operation has been completed.
> 
> <Scott/>
> 

Scott,

you are right, but this was just a suggestion (I want to make constructive
comments ;-). I don't mind if you reduce the content to the absolute minimum.
It would of course be enough if it would be like the result of the poll
request in the example on page 24 of draft-ietf-provreg-epp-03. But please add
this as a requirement. To me it's a kind of horror vision to see transfer
notifications transmitted outside of the protocol (worst is per e-mail),
albeit the EPP already contains the whole functionality for it. Making it to a
requirement will ensure that EPP is used for this purpose.

regards,

Klaus Malorny

___________________________________________________________________________
     |       |
     | knipp |                   Knipp  Medien und Kommunikation GmbH
      -------                           Technologiepark
                                        Martin-Schmeisser-Weg 9
     Dipl. Inf. Klaus Malorny           44227 Dortmund
     [email-masked]             Tel. +49 231 9703 0

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Poll response data
Date: Tue, 19 Jun 2001 07:13:59 -0400
Sender: [email-masked]

Klaus,

There _is_ a well defined mechanism to determine all of the transfer details
you've described.  Look at the definition of the <transfer> command's
"query" operation.  You're suggesting that this exact same info be described
and required for return via a polled message?

I don't have a problem with enhancing the description of the <poll> command
to note that the format of transfer notices as described in the current text
is a required feature (are there any others?), but I don't think it makes
any sense at all to push the transfer details in a polled message.  As
things are defined right now, a polled message goes away once received and
acknowledged by the client.  With a transfer query operation the details can
be retrieved at any time, including after the operation has been completed.

<Scott/>

>-----Original Message-----
>From: Klaus Malorny [mailto:[email-masked]]
>Sent: Tuesday, June 19, 2001 5:16 AM
>To: Hollenbeck, Scott
>Cc: [email-masked]'
>Subject: Re: Poll response data
>
>
>"Hollenbeck, Scott" wrote:
>> 
>> Dan,
>> 
>> Echoing what Rick said, I believe that the types of 
>informational messages
>> that should be made available via a <poll> are a matter of 
>registry policy,
>> so that's why there isn't a detailed description of the 
>messages that may be
>> supported.  I also believe that some situations should be 
>relayed to a
>> client via messages that can be polled, and others should be 
>relayed to a
>> client via offline reporting.  Those situations that require 
>timely client
>> protocol action, such as any object transfer or upcoming 
>object expiration,
>> should be relayed to the client via the polling mechanism.  Purely
>> informational notices that don't have temporal factors may 
>be better left to
>> some kind of registry reporting service.
>> 
>> I'm sure I can make the text more clear to make this intent 
>more obvious.
>> 
>> <Scott/>
>
>
>Hi Scott,
>
>sorry, I have to disagree. Since the transfer of objects is an integral
part
>of your protocol, it is a kind of incompleteness if the mechanisms which
are
>used to notify the losing registrar are not described. You describe in
detail
>when the gaining or losing registrar may request/cancel/reject/approve a
>transfer, but not the exact way of the notification, although this is
similar
>essential to the transfer process as the other stuff. Since you already
>limited the freedom of a registry's policy* (e.g. the object model/fields,
the
>relation between hosts and domains, the way that objects are transferred),
I
>don't see any problems in defining a message returned on a poll that
contains
>at least the following information: the object which is requested to be
>transferred, the registrar who wants to gain the object, an expire date
that
>tells the losing registrar if/when a default action is taken and what this
>default action is (approval or rejection).

Date: Tue, 19 Jun 2001 11:16:07 +0200
From: Klaus Malorny <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: Poll response data
Sender: [email-masked]

"Hollenbeck, Scott" wrote:
> 
> Dan,
> 
> Echoing what Rick said, I believe that the types of informational messages
> that should be made available via a <poll> are a matter of registry policy,
> so that's why there isn't a detailed description of the messages that may be
> supported.  I also believe that some situations should be relayed to a
> client via messages that can be polled, and others should be relayed to a
> client via offline reporting.  Those situations that require timely client
> protocol action, such as any object transfer or upcoming object expiration,
> should be relayed to the client via the polling mechanism.  Purely
> informational notices that don't have temporal factors may be better left to
> some kind of registry reporting service.
> 
> I'm sure I can make the text more clear to make this intent more obvious.
> 
> <Scott/>

Hi Scott,

sorry, I have to disagree. Since the transfer of objects is an integral part
of your protocol, it is a kind of incompleteness if the mechanisms which are
used to notify the losing registrar are not described. You describe in detail
when the gaining or losing registrar may request/cancel/reject/approve a
transfer, but not the exact way of the notification, although this is similar
essential to the transfer process as the other stuff. Since you already
limited the freedom of a registry's policy* (e.g. the object model/fields, the
relation between hosts and domains, the way that objects are transferred), I
don't see any problems in defining a message returned on a poll that contains
at least the following information: the object which is requested to be
transferred, the registrar who wants to gain the object, an expire date that
tells the losing registrar if/when a default action is taken and what this
default action is (approval or rejection).

* this is, of course, not an accusation. Anyone who defines a protocol has to
fix things and thus limiting the degree of freedom.

regards,

Klaus Malorny

___________________________________________________________________________
     |       |
     | knipp |                   Knipp  Medien und Kommunikation GmbH
      -------                           Technologiepark
                                        Martin-Schmeisser-Weg 9
     Dipl. Inf. Klaus Malorny           44227 Dortmund
     [email-masked]             Tel. +49 231 9703 0

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Poll response data
Date: Mon, 18 Jun 2001 15:31:40 -0400
Sender: [email-masked]

Dan,

Echoing what Rick said, I believe that the types of informational messages
that should be made available via a <poll> are a matter of registry policy,
so that's why there isn't a detailed description of the messages that may be
supported.  I also believe that some situations should be relayed to a
client via messages that can be polled, and others should be relayed to a
client via offline reporting.  Those situations that require timely client
protocol action, such as any object transfer or upcoming object expiration,
should be relayed to the client via the polling mechanism.  Purely
informational notices that don't have temporal factors may be better left to
some kind of registry reporting service.

I'm sure I can make the text more clear to make this intent more obvious.

<Scott/>

>-----Original Message-----
>From: Daniel Manley [mailto:[email-masked]]
>Sent: Monday, June 18, 2001 3:08 PM
>To: [email-masked]'
>Subject: Poll response data
>
>
>Hi Scott,
>
>Perhaps this is answered in your latest documents.  If so, please
>forgive me -- I'll take a look soon.
>
>In the drafts I've seen so far, the specification for the poll response
>data is pretty lite.  Is it the spec's responsibility to define all the
>possible resData bits than can be returned in a Poll.  I've seen an XML
>sample that showed domain:transfer.  Would there also be
>contact:transfer?  How about domain:renew if the registry has
>automatically renewed a domain that was about to expired.  How about
>domain:delete, if the domain is not being auto-renewed and will be
>deleted.  Would a domain:delete response be accompanied by a sequence of
>host:delete's where the action is cascaded to children objects?
>
>Dan
>

Date: Mon, 18 Jun 2001 12:20:44 -0700 (PDT)
From: Rick H Wesson <[email-masked]>
To: Daniel Manley <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: Re: Poll response data
Sender: [email-masked]

Dan,

IMHO the resData should be opaque so that registries can define what
the returned objects look like. Much of that a poll request could return
MAY have alot to do with registry policy, and as such should be flexable
for whatever a registry wishes to push at their channel.

-rick

 On Mon, 18 Jun 2001, Daniel Manley wrote:

> Hi Scott,
>
> Perhaps this is answered in your latest documents.  If so, please
> forgive me -- I'll take a look soon.
>
> In the drafts I've seen so far, the specification for the poll response
> data is pretty lite.  Is it the spec's responsibility to define all the
> possible resData bits than can be returned in a Poll.  I've seen an XML
> sample that showed domain:transfer.  Would there also be
> contact:transfer?  How about domain:renew if the registry has
> automatically renewed a domain that was about to expired.  How about
> domain:delete, if the domain is not being auto-renewed and will be
> deleted.  Would a domain:delete response be accompanied by a sequence of
> host:delete's where the action is cascaded to children objects?
>
> Dan
>
>

Date: Mon, 18 Jun 2001 15:08:25 -0400
From: Daniel Manley <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Poll response data
Sender: [email-masked]

Hi Scott,

Perhaps this is answered in your latest documents.  If so, please 
forgive me -- I'll take a look soon.

In the drafts I've seen so far, the specification for the poll response 
data is pretty lite.  Is it the spec's responsibility to define all the 
possible resData bits than can be returned in a Poll.  I've seen an XML 
sample that showed domain:transfer.  Would there also be 
contact:transfer?  How about domain:renew if the registry has 
automatically renewed a domain that was about to expired.  How about 
domain:delete, if the domain is not being auto-renewed and will be 
deleted.  Would a domain:delete response be accompanied by a sequence of 
host:delete's where the action is cascaded to children objects?

Dan

Date: Fri, 15 Jun 2001 15:10:45 -0400
From: Daniel Manley <[email-masked]>
To: "[email-masked]'" <[email-masked]>
CC: [email-masked]
Subject: Re: [Epp-rtk-devel] RE: ROID Placement
Sender: [email-masked]

Actually Scott,

Here's the situation:

Afilias/Liberty and the latest release of the java RTK is using a 
pre-release of 02 which still uses ROID as the only way of identifying a 
contact.  Getting the RTK up to the newest EPP is no big impact (changes 
to the IDLs and a couple of lines here and there), but the jump will 
impact current registrars for .info.  I'm not sure if the ietf-provreg 
group has to care about that, although it would be nice to take into 
consideration in the future (especially as more registries come online). 
 The registry upgrade and consideration of the impacts to the registrars 
should be important to registry operators (eg. Afilias, Neulevel, GNR, 
RegistryPro, etc...).

so....
    going from pre-02 to current 02 -- little changes to RTK, but 
noticeable impact to users of the RTK (limited to .info registrars only 
at this point?)
    going from current 02 to changes in ROID (or it's removal) -- nearly 
none (which goes back to my comment early about the ROID having almost 
no use to the registrar at that point anyhow)

Dan

Hollenbeck, Scott wrote:

>>-----Original Message-----
>>From: Eric Brunner-Williams in Portland Maine
>>[mailto:[email-masked]]
>>Sent: Friday, June 15, 2001 11:02 AM
>>To: Hollenbeck, Scott
>>Cc: [email-masked]'; epp-rtk-devel; [email-masked]
>>Subject: Re: [Epp-rtk-devel] RE: ROID Placement 
>>
>
>[snip]
>
>>As Ayesha pointed out, the derivation is complicated by this change of roid
>>placement, and that alone should give pause. As you pointed out, this means
>>we delta the requirements draft, not a big deal, and get the roid
>>
>functionally
>
>>placed correctly. Clearly, from the registry use cases for requirements, a
>>global identifier is not optional.
>>
>
>A requirements change is needed only if we decide to remove ROIDs
>completely.  That's certainly an option, and maybe it's one we need to
>explore before re-examining the placement issue.
>
>Let's assume that we prefer to keep them.  Dan Manley, another implementer,
>didn't allude to any complications in his response sent yesterday.  I have a
>VeriSign implementer who also feels that it's not a problem.  However, if
>it's an issue for anyone it's a good topic for discussion.
>
>Would it be better if the only place a ROID was returned is in the object
>data returned in the response to an <info> command?  If so, I can live with
>that.
>
><Scott/>
>
>_______________________________________________
>Epp-rtk-devel mailing list
>[email-masked]
>http://lists.sourceforge.net/lists/listinfo/epp-rtk-devel
>

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, epp-rtk-devel <[email-masked]>
Subject: RE: [Epp-rtk-devel] RE: ROID Placement 
Date: Fri, 15 Jun 2001 11:57:53 -0400
Sender: [email-masked]

>-----Original Message-----
>From: Eric Brunner-Williams in Portland Maine
>[mailto:[email-masked]]
>Sent: Friday, June 15, 2001 11:02 AM
>To: Hollenbeck, Scott
>Cc: [email-masked]'; epp-rtk-devel; [email-masked]
>Subject: Re: [Epp-rtk-devel] RE: ROID Placement 
>

[snip]

>As Ayesha pointed out, the derivation is complicated by this change of roid
>placement, and that alone should give pause. As you pointed out, this means
>we delta the requirements draft, not a big deal, and get the roid
functionally
>placed correctly. Clearly, from the registry use cases for requirements, a
>global identifier is not optional.

A requirements change is needed only if we decide to remove ROIDs
completely.  That's certainly an option, and maybe it's one we need to
explore before re-examining the placement issue.

Let's assume that we prefer to keep them.  Dan Manley, another implementer,
didn't allude to any complications in his response sent yesterday.  I have a
VeriSign implementer who also feels that it's not a problem.  However, if
it's an issue for anyone it's a good topic for discussion.

Would it be better if the only place a ROID was returned is in the object
data returned in the response to an <info> command?  If so, I can live with
that.

<Scott/>

To: "Hollenbeck, Scott" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, epp-rtk-devel <[email-masked]>, [email-masked]
Subject: Re: [Epp-rtk-devel] RE: ROID Placement 
Date: Fri, 15 Jun 2001 11:01:52 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Scott, ietf-provreg contributors and participants

Our work is a protocol specification, not an IDL specification, and not some
indemnification policy for business decisions. The first is an implementor's
issue, and an optional one at that, the second is simply out-of-scope for any
IETF WG.

As Ayesha pointed out, the derivation is complicated by this change of roid
placement, and that alone should give pause. As you pointed out, this means
we delta the requirements draft, not a big deal, and get the roid functionally
placed correctly. Clearly, from the registry use cases for requirements, a
global identifier is not optional.

I appreciate Dan Kirkdorffer's point, but even if real technical cooperation
between registries were taking place, no registry or set of registries "owns"
the work product of this WG, or can unilaterally "gate" the versioning of the
core specification, or its last call(s). I'm not the best position to know
but I heard that the date he referred to has been slipped some 30 days, which
may be palitive, then again, there may be other issues than those arising from
this specification.

Periodically I put in my full .sig, and today is as good a day as any. Scott,
my admin has my actual phone number should you need to call.

Eric

Eric Brunner-Williams                  NeuStar, Inc.
Senior Technical Industry Liaison      http://www.neustar.com
Phone: (Portland, ME) +1.207.xxx.xxxx  (Washington, DC) +1.202.533.2600/2975
smail: 1415 Forest Ave. 04103          1120 Vermont Ave. N.W., Ste 400, 20005
email: [email-masked]             [email-masked]

P.S.
The contolling namesapce prefix for the r(h)oid element is "hemor".
Note: The "h" is elided as an XML compression technique.

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, epp-rtk-devel <[email-masked]>
Subject: RE: [Epp-rtk-devel] RE: ROID Placement
Date: Thu, 14 Jun 2001 21:19:03 -0400
Sender: [email-masked]

> -----Original Message-----
> From: Dan Kirkdorffer [mailto:[email-masked]]
> Sent: Thursday, June 14, 2001 9:12 PM
> To: 'Hollenbeck, Scott'; [email-masked]'; epp-rtk-devel
> Subject: RE: [Epp-rtk-devel] RE: ROID Placement

[snip]
 
> If the business decisions are not being made with a nod to the reality of
> the moving target this spec is, then we have a serious problem.
Production
> must be moved back.  Sunrise must be delayed.
> 
> That's this developers opinion.

It would be wise for whomever is calling the shots to understand completely
that there WILL be changes.  Thinking otherwise is bound to result in
unpleasant surprises.

<Scott/>

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, epp-rtk-devel <[email-masked]>
Subject: RE: [Epp-rtk-devel] RE: ROID Placement
Date: Thu, 14 Jun 2001 20:27:41 -0400
Sender: [email-masked]

> -----Original Message-----
> From: Dan Kirkdorffer [mailto:[email-masked]]
> Sent: Thursday, June 14, 2001 6:01 PM
> To: 'Rick H Wesson'
> Cc: 'Daniel Manley'; Hollenbeck, Scott; Damaraju, Ayesha;
> [email-masked]'; epp-rtk-devel
> Subject: RE: [Epp-rtk-devel] RE: ROID Placement
> 
> 
> > we could just go to release 10 but what would that mean...
> 
> A difference in expectations.  You and I know 0.3 code will change.
Bosses
> who tell me what to do barely understand that.  1.0 code is a level that
> says we may deprecate, but we won't break code.  Once registrars have
coded
> to a 1.0 spec then they should expect that code to work in 1.1.
> 
> The issue here is time.  Sunrise for .info is in 11 days, as far as I
know.
> I'm developing code for that.  Things must be stable, regardless of what
is
> being schemed.
> 
> Or sunrise must be pushed back.
> 
> It is the difference between R&D and Production.  R&D must not impact
> Production.

If "things must be stable", as Rick said you won't get that until an RFC or
RFCs are published.  Even then things can change as the protocol moves
through the RFC states of proposed standard, draft standard, and standard.

The WG has to have the freedom to revisit requirement and design decisions
as time and experience demonstrate a need for evolution.  I really don't
think we're at a point where we can declare victory and stop design work.
Until we are, change is a certainty and the scope of change isn't.

<Scott/>

Date: Thu, 14 Jun 2001 14:50:36 -0700 (PDT)
From: Rick H Wesson <[email-masked]>
To: Dan Kirkdorffer <[email-masked]>
cc: "'Daniel Manley'" <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>, "Damaraju, Ayesha" <[email-masked]>, "[email-masked]'" <[email-masked]>, epp-rtk-devel <[email-masked]>
Subject: RE: [Epp-rtk-devel] RE: ROID Placement
Sender: [email-masked]

On Thu, 14 Jun 2001, Dan Kirkdorffer wrote:

> Any change made now will impact any registrar coding to the API.
> Eliminating roids will break code.

yes, expect more as EPP revises itself within the IETF.

> When is the RTK planned to go 1.0 anyway?

I hope not before the RFC comes out, but release numbers are arbitrary, we
could just go to release 10 but what would that mean...

-rick

> Dan
> eNom
>
> > -----Original Message-----
> > From: Daniel Manley [mailto:[email-masked]]
> > Sent: Thursday, June 14, 2001 1:06 PM
> > To: Hollenbeck, Scott
> > Cc: 'Rick H Wesson'; Damaraju, Ayesha; [email-masked]';
> > epp-rtk-devel
> > Subject: Re: [Epp-rtk-devel] RE: ROID Placement
> >
> >
> > I'm fine with getting rid of ROIDs from the protocol.
> >
> > With the re-introduction of the contact id, ROIDs are mostly
> > useless for
> > registrars now because it's an extra piece of data that can't
> > be used in
> > any EPP requests.  At this point, they only seem to be of
> > benifit to the
> > registry (in reports?) and possibly to Whois service.
> >
> > As for the impact on the RTKs, we would just remove the ROIDs
> > from the
> > IDL and removing their parsing from the EPP responses.  Very
> > little impact.
> >
> > Dan
> >
> > Hollenbeck, Scott wrote:
> >
> > >>-----Original Message-----
> > >>From: Rick H Wesson [mailto:[email-masked]]
> > >>Sent: Thursday, June 14, 2001 2:31 PM
> > >>To: Damaraju, Ayesha
> > >>Cc: [email-masked]'; epp-rtk-devel
> > >>Subject: Re: your mail
> > >>
> > >>
> > >>
> > >>Ayesha,
> > >>
> > >>I agree with your analysis but, i woud also like to
> > understand what any
> > >>other object besides a contact needs a roid. Objects such
> > as hosts and
> > >>domains are unique within a registry, maybe we should only
> > have a ROID for
> > >>contacts?
> > >>
> > >
> > >This all goes back to a lengthy requirements discussion
> > about ROIDs and a
> > >decision that they were required for all objects.
> > Personally I wouldn't
> > >complain if we agreed to get rid of them completely ;-), but if a new
> > >decision is made to associate them only with contacts we'd
> > need to go back
> > >and change the requirements draft (no big deal), and then it
> > would make
> > >perfect sense to put the ROID-specific stuff in the contact
> > object mapping.
> > >
> > ><Scott/>
> > >
> > >_______________________________________________
> > >Epp-rtk-devel mailing list
> > >[email-masked]
> > >http://lists.sourceforge.net/lists/listinfo/epp-rtk-devel
> > >
> >
> >
> >
> >
> > _______________________________________________
> > Epp-rtk-devel mailing list
> > [email-masked]
> > http://lists.sourceforge.net/lists/listinfo/epp-rtk-devel
> >
>

Date: Thu, 14 Jun 2001 16:05:46 -0400
From: Daniel Manley <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
CC: "'Rick H Wesson'" <[email-masked]>, "Damaraju, Ayesha" <[email-masked]>, "[email-masked]'" <[email-masked]>, epp-rtk-devel <[email-masked]>
Subject: Re: [Epp-rtk-devel] RE: ROID Placement
Sender: [email-masked]

I'm fine with getting rid of ROIDs from the protocol.

With the re-introduction of the contact id, ROIDs are mostly useless for 
registrars now because it's an extra piece of data that can't be used in 
any EPP requests.  At this point, they only seem to be of benifit to the 
registry (in reports?) and possibly to Whois service.

As for the impact on the RTKs, we would just remove the ROIDs from the 
IDL and removing their parsing from the EPP responses.  Very little impact.

Dan

Hollenbeck, Scott wrote:

>>-----Original Message-----
>>From: Rick H Wesson [mailto:[email-masked]]
>>Sent: Thursday, June 14, 2001 2:31 PM
>>To: Damaraju, Ayesha
>>Cc: [email-masked]'; epp-rtk-devel
>>Subject: Re: your mail
>>
>>
>>
>>Ayesha,
>>
>>I agree with your analysis but, i woud also like to understand what any
>>other object besides a contact needs a roid. Objects such as hosts and
>>domains are unique within a registry, maybe we should only have a ROID for
>>contacts?
>>
>
>This all goes back to a lengthy requirements discussion about ROIDs and a
>decision that they were required for all objects.  Personally I wouldn't
>complain if we agreed to get rid of them completely ;-), but if a new
>decision is made to associate them only with contacts we'd need to go back
>and change the requirements draft (no big deal), and then it would make
>perfect sense to put the ROID-specific stuff in the contact object mapping.
>
><Scott/>
>
>_______________________________________________
>Epp-rtk-devel mailing list
>[email-masked]
>http://lists.sourceforge.net/lists/listinfo/epp-rtk-devel
>

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Rick H Wesson'" <[email-masked]>, "Damaraju, Ayesha" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, epp-rtk-devel <[email-masked]>
Subject: RE: ROID Placement
Date: Thu, 14 Jun 2001 15:24:08 -0400
Sender: [email-masked]

>-----Original Message-----
>From: Rick H Wesson [mailto:[email-masked]]
>Sent: Thursday, June 14, 2001 2:31 PM
>To: Damaraju, Ayesha
>Cc: [email-masked]'; epp-rtk-devel
>Subject: Re: your mail
>
>
>
>Ayesha,
>
>I agree with your analysis but, i woud also like to understand what any
>other object besides a contact needs a roid. Objects such as hosts and
>domains are unique within a registry, maybe we should only have a ROID for
>contacts?

This all goes back to a lengthy requirements discussion about ROIDs and a
decision that they were required for all objects.  Personally I wouldn't
complain if we agreed to get rid of them completely ;-), but if a new
decision is made to associate them only with contacts we'd need to go back
and change the requirements draft (no big deal), and then it would make
perfect sense to put the ROID-specific stuff in the contact object mapping.

<Scott/>

From: "Damaraju, Ayesha" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: your mail
Date: Thu, 14 Jun 2001 13:49:47 -0500
Sender: [email-masked]

-- i woud also like to understand what any
--other object besides a contact needs a roid. Objects such as hosts and
--domains are unique within a registry, maybe we should only have a ROID for
--contacts?

After introducing Client-id's in EPP-02 - which is used for <check> and
<info>
and other transform functions on contact object - the need for ROID is to
satisfy the requirement
of having global unique object id's - currently, they are not used for any
specific
function on objects. 

-A

Date: Thu, 14 Jun 2001 11:30:45 -0700 (PDT)
From: Rick H Wesson <[email-masked]>
To: "Damaraju, Ayesha" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, epp-rtk-devel <[email-masked]>
Subject: Re: your mail
Sender: [email-masked]

Ayesha,

I agree with your analysis but, i woud also like to understand what any
other object besides a contact needs a roid. Objects such as hosts and
domains are unique within a registry, maybe we should only have a ROID for
contacts?

It does look like this change will effect the Liberty RTK, does anyone
from liberty want to comment on the impact of this change?

-rick

On Thu, 14 Jun 2001, Damaraju, Ayesha wrote:

> > 1. Moved the <roid> element out of the response data for
> > <create> and <info>
> >    command, and now is in the <response> element as an
> > optional element.
> >
>
> --My litmus test for this move was the answer to the question "is the ROID
> --concept common to all objects, or is it required of specific objects".  As
> --discussed on this list, it's common to all objects, so I though it should
> be
> --in the base protocol instead of in the object mappings.  That's why it was
> --moved.
>
>
>
> It is common to all objects, but not to all responses. For example doesn't
> apply to a <check> response.
> And logically, <roid> is part of <resData>, as ---
>
> " An OPTIONAL <resData> (response data) element that contains child
>   elements specific to the command and associated object."
>
> Well I like to hear how the people working on implementing EPP feel about
> this, as this
> migration of <roid> in to base protocol changes the model, as XML generation
> is not straight
> forward anymore.
>
> Example domain_create_result.xml file from EPP-01
>
> <?xml version="1.0" standalone="no"?>
> <epp xmlns="urn:iana:xml:ns:epp"
>      xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
>      xsi:schemaLocation="urn:iana:xml:ns:epp epp.xsd">
>   <response>
>     <result code="1000">
>       <msg>Command completed successfully</msg>
>     </result>
>     <resData>
>       <domain:creData xmlns:domain="urn:iana:xml:ns:domain"
>        xsi:schemaLocation="urn:iana:xml:ns:domain domain.xsd">
>         <domain:name>example.com</domain:name>
>         <domain:roid>EXAMPLE1-VRSN</domain:roid>
>         <domain:exDate>2002-06-08T22:00:00.0Z</domain:exDate>
>       </domain:creData>
>     </resData>
>     <unspec/>
>     <trID>
>       <clTRID>ABC-12345</clTRID>
>       <svTRID>54321-XYZ</svTRID>
>     </trID>
>   </response>
> </epp>
>
>
> Example domain_create_result.xml file from EPP-02
> <?xml version="1.0" encoding="UTF-8" standalone="no"?>
> <epp xmlns="urn:iana:xml:ns:epp"
>      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>      xsi:schemaLocation="urn:iana:xml:ns:epp epp.xsd">
>   <response>
>     <result code="1000">
>       <msg>Command completed successfully</msg>
>     </result>
>     <resData>
>       <domain:creData xmlns:domain="urn:iana:xml:ns:domain"
>        xsi:schemaLocation="urn:iana:xml:ns:domain domain.xsd">
>         <domain:name>example.com</domain:name>
>         <domain:exDate>2002-06-08T22:00:00.0Z</domain:exDate>
>       </domain:creData>
>     </resData>
>     <unspec/>
>     <roid>EXAMPLE1-VRSN</roid>
>     <trID>
>       <clTRID>ABC-12345</clTRID>
>       <svTRID>54321-XYZ</svTRID>
>     </trID>
>   </response>
> </epp>
>
>
>
> -Ayesha
>

From: "Damaraju, Ayesha" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Date: Thu, 14 Jun 2001 13:04:57 -0500
Sender: [email-masked]

> 1. Moved the <roid> element out of the response data for 
> <create> and <info>
>    command, and now is in the <response> element as an 
> optional element.
> 

--My litmus test for this move was the answer to the question "is the ROID
--concept common to all objects, or is it required of specific objects".  As
--discussed on this list, it's common to all objects, so I though it should
be
--in the base protocol instead of in the object mappings.  That's why it was
--moved.

It is common to all objects, but not to all responses. For example doesn't
apply to a <check> response. 
And logically, <roid> is part of <resData>, as ---

" An OPTIONAL <resData> (response data) element that contains child
  elements specific to the command and associated object."

Well I like to hear how the people working on implementing EPP feel about
this, as this
migration of <roid> in to base protocol changes the model, as XML generation
is not straight  
forward anymore.

Example domain_create_result.xml file from EPP-01

<?xml version="1.0" standalone="no"?>
<epp xmlns="urn:iana:xml:ns:epp"
     xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
     xsi:schemaLocation="urn:iana:xml:ns:epp epp.xsd">
  <response>
    <result code="1000">
      <msg>Command completed successfully</msg>
    </result>
    <resData>
      <domain:creData xmlns:domain="urn:iana:xml:ns:domain"
       xsi:schemaLocation="urn:iana:xml:ns:domain domain.xsd">
        <domain:name>example.com</domain:name>
        <domain:roid>EXAMPLE1-VRSN</domain:roid>
        <domain:exDate>2002-06-08T22:00:00.0Z</domain:exDate>
      </domain:creData>
    </resData>
    <unspec/>
    <trID>
      <clTRID>ABC-12345</clTRID>
      <svTRID>54321-XYZ</svTRID>
    </trID>
  </response>
</epp>

Example domain_create_result.xml file from EPP-02
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:iana:xml:ns:epp"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="urn:iana:xml:ns:epp epp.xsd">
  <response>
    <result code="1000">
      <msg>Command completed successfully</msg>
    </result>
    <resData>
      <domain:creData xmlns:domain="urn:iana:xml:ns:domain"
       xsi:schemaLocation="urn:iana:xml:ns:domain domain.xsd">
        <domain:name>example.com</domain:name>
        <domain:exDate>2002-06-08T22:00:00.0Z</domain:exDate>
      </domain:creData>
    </resData>
    <unspec/>
    <roid>EXAMPLE1-VRSN</roid>
    <trID>
      <clTRID>ABC-12345</clTRID>
      <svTRID>54321-XYZ</svTRID>
    </trID>
  </response>
</epp>

-Ayesha

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-provreg-epp-tcp-01.txt
Date: Thu, 14 Jun 2001 07:08:51 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Provisioning Registry Protocol Working Group of the IETF.

	Title		: Extensible Provisioning Protocol Transport Over TCP
	Author(s)	: S. Hollenbeck
	Filename	: draft-ietf-provreg-epp-tcp-01.txt
	Pages		: 9
	Date		: 13-Jun-01
	
This document describes how an Extensible Provisioning Protocol (EPP)
session is mapped onto a single Transmission Control Protocol (TCP)
connection.  This mapping requires use of the Transport Layer Security
(TLS) Protocol to protect information exchanged between an EPP client
and an EPP server.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-tcp-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-provreg-epp-tcp-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-provreg-epp-tcp-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-provreg-epp-tcp-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-provreg-epp-tcp-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-provreg-epp-host-01.txt
Date: Thu, 14 Jun 2001 07:08:46 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Provisioning Registry Protocol Working Group of the IETF.

	Title		: Extensible Provisioning Protocol Host Mapping
	Author(s)	: S. Hollenbeck
	Filename	: draft-ietf-provreg-epp-host-01.txt
	Pages		: 26
	Date		: 13-Jun-01
	
This document describes an Extensible Provisioning Protocol (EPP)
mapping for the provisioning and management of Internet host names
stored in a shared central repository.  Specified in XML, the mapping
defines EPP command syntax and semantics as applied to host names.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-host-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-provreg-epp-host-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-provreg-epp-host-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-provreg-epp-host-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-provreg-epp-host-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-provreg-epp-domain-01.txt
Date: Thu, 14 Jun 2001 07:08:39 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Provisioning Registry Protocol Working Group of the IETF.

	Title		: Extensible Provisioning Protocol Domain Name Mapping
	Author(s)	: S. Hollenbeck
	Filename	: draft-ietf-provreg-epp-domain-01.txt
	Pages		: 35
	Date		: 13-Jun-01
	
This document describes an Extensible Provisioning Protocol (EPP)
mapping for the provisioning and management of Internet domain names
stored in a shared central repository.  Specified in XML, the mapping
defines EPP command syntax and semantics as applied to domain names.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-domain-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-provreg-epp-domain-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-provreg-epp-domain-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-provreg-epp-domain-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-provreg-epp-domain-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-provreg-epp-contact-01.txt
Date: Thu, 14 Jun 2001 07:08:35 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Provisioning Registry Protocol Working Group of the IETF.

	Title		: Extensible Provisioning Protocol Contact Mapping
	Author(s)	: S. Hollenbeck
	Filename	: draft-ietf-provreg-epp-contact-01.txt
	Pages		: 36
	Date		: 13-Jun-01
	
This document describes an Extensible Provisioning Protocol (EPP)
mapping for the provisioning and management of individual or
organizational social information identifiers (known as 'contacts')
stored in a shared central repository. Specified in XML, the mapping
defines EPP command syntax and semantics as applied to contacts.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-contact-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-provreg-epp-contact-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-provreg-epp-contact-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-provreg-epp-contact-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-provreg-epp-contact-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-provreg-epp-03.txt
Date: Thu, 14 Jun 2001 07:08:30 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Provisioning Registry Protocol Working Group of the IETF.

	Title		: Extensible Provisioning Protocol
	Author(s)	: S. Hollenbeck
	Filename	: draft-ietf-provreg-epp-03.txt
	Pages		: 63
	Date		: 13-Jun-01
	
This document describes an application layer client-server protocol
for the provisioning and management of objects stored in a shared
central repository.  Specified in XML, the protocol defines generic
object management operations and an extensible framework that maps
protocol operations to objects.  This document includes a protocol
specification, an object mapping template, and an XML media type
registration.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-03.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-provreg-epp-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-provreg-epp-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-provreg-epp-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-provreg-epp-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Wed, 13 Jun 2001 15:15:04 -0400
To: "Hollenbeck, Scott" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: EPP Document Updates
Cc: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

BTW - I sent the requirements document to the AD's and IESG the first week
of May and have yet to receive any acknowledgement from "them."  I have
contacted "them" a number of times...

At 2:16 PM -0400 6/13/01, Hollenbeck, Scott wrote:
>Earlier today I sent updated EPP specifications to the I-D administrator.
>The new documents contain mostly editorial fixes that I missed in the last
>revisions, but there were a few new things done:
>
>- An XML media type registration has been added to the base EPP
>specification.
>
>- Error code 1302 has been removed from the EPP schema.  This code was there
>to deal with what I first thought was a XML Schema "feature", but the -02
>version introduced an EPP Schema fix that made the error condition obsolete.
>I should have caught this in the last revision.  I'll get new example and
>schema files out for anonymous ftp ASAP.
>
><Scott/>

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

You fly too often when ... the airport taxi is on speed-dial.

Opinions expressed are property of my evil twin, not my employer.

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: EPP Document Updates
Date: Wed, 13 Jun 2001 14:16:34 -0400
Sender: [email-masked]

Earlier today I sent updated EPP specifications to the I-D administrator.
The new documents contain mostly editorial fixes that I missed in the last
revisions, but there were a few new things done:

- An XML media type registration has been added to the base EPP
specification.

- Error code 1302 has been removed from the EPP schema.  This code was there
to deal with what I first thought was a XML Schema "feature", but the -02
version introduced an EPP Schema fix that made the error condition obsolete.
I should have caught this in the last revision.  I'll get new example and
schema files out for anonymous ftp ASAP.

<Scott/>

To: "Hollenbeck, Scott" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: FW: I-D ACTION:draft-ietf-provreg-epp-02.txt 
Date: Mon, 11 Jun 2001 09:22:35 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Scott,

> You may want to consider defining application/epp+xml in an appendix,
> based on the template of RFC 3023.

Yup. The appendix to rfc3023 is sufficient motivation.

> You want to change the use of SHALL to MUST.

Uhh ... We need to check each one.

> Also, this phrase "raw Unicode character sets" should be changed to "and
> UTF-16".  Note that based on the new specification of UTF-32, raw
> Unicode character sets has a basically undefined meaning.  It probably
> is a good policy to limit exchanges to UTF-8.

Yup. UTF-8 it is.

> Finally, it would be nice to have an introductory section describing the
> problem space that EPP is attacking and a quick overview of its purpose.
> For example, see section 1.1 of RFC 2960.

Yup. I'll put one (extension) in my child-of-xrp (beep, push, privacy) drafts,
that I _really_ hope to post this week. Someone should do the core (tcp, poll)
draft.

Eric

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: FW: I-D ACTION:draft-ietf-provreg-epp-02.txt
Date: Mon, 11 Jun 2001 08:22:32 -0400
Sender: [email-masked]

I received the following private comments on the recent EPP drafts.  Does
anyone have any issues with these suggested changes?

<Scott/>

-----Original Message-----
[headers removed]

You may want to consider defining application/epp+xml in an appendix,
based on the template of RFC 3023.

You want to change the use of SHALL to MUST.

Also, this phrase "raw Unicode character sets" should be changed to "and
UTF-16".  Note that based on the new specification of UTF-32, raw
Unicode character sets has a basically undefined meaning.  It probably
is a good policy to limit exchanges to UTF-8.

Finally, it would be nice to have an introductory section describing the
problem space that EPP is attacking and a quick overview of its purpose.
For example, see section 1.1 of RFC 2960.

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: EPP Schema and Example Instance Files
Date: Thu, 31 May 2001 21:01:55 -0400
Sender: [email-masked]

> -----Original Message-----
> From: Damaraju, Ayesha [mailto:[email-masked]]
> Sent: Thursday, May 31, 2001 10:44 AM
> To: [email-masked]'
> Subject: RE: EPP Schema and Example Instance Files
> 
> 
> Scott,
> 
> One more..
> 
> For Contact/host objects.
> "ok" status MUST NOT be combined with any other status. 
> 
> -- I believe... it can be combined with "linked" status

True, I missed that.  Fixed in the next revision.

<Scott/>

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: EPP Schema and Example Instance Files
Date: Thu, 31 May 2001 21:00:27 -0400
Sender: [email-masked]

> -----Original Message-----
> From: Damaraju, Ayesha [mailto:[email-masked]]
> Sent: Thursday, May 31, 2001 10:39 AM
> To: [email-masked]'
> Subject: RE: EPP Schema and Example Instance Files
> 
> 
> 
> Scott,
> 
> Few questions/comments on new schemas...
> 
> 1. Moved the <roid> element out of the response data for 
> <create> and <info>
>    command, and now is in the <response> element as an 
> optional element.
> 
> - Please verify....This will complicate the XML validation 
> process as this
> element needs to be tested
>   explicitly for create and info. We prefer them being part 
> of create & info
> response data to simplify 
>   validations and object mappings.

My litmus test for this move was the answer to the question "is the ROID
concept common to all objects, or is it required of specific objects".  As
discussed on this list, it's common to all objects, so I though it should be
in the base protocol instead of in the object mappings.  That's why it was
moved.

Now, we could argue about where or when it should be returned.  I thought it
would be typically expected only after it was assigned (thus the <create>
response), and as part of a detailed attribute query (thus the <info>
response>).  It could just as well be returned within every response if that
makes things easier.

> 2. Added an <id> element into the <create> for creating contacts.
> 
> - Please confirm....<id> is provided by the Registrar with a <create>
> command.
>   It is a server-unique id (though generated by Registrar). 
> Server will
> reject <create> command
>   with existing <id> element.

Correct.  It must be locally unique, much as a host name or domain name must
be locally unique.

<Scott/>