Subject: RE: a new domain name status

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 30 Aug 2002 07:45:38 -0400

> I am a programer from CNNIC(China Internet Information Center),
> We are developing an epp-compatible registration system.
> And now, we are facing a problem. Because CNNIC's policy is different
> from ICANN's. We have no AutoRenew operation. When a domain 
> name expire,
> it will be stopped resolving but still in the database. And 
> after serveral days, it will be
> deleted permanently from the DB if it never be renewed again, 
> then other registrant
> can register this domain name.
> 
> As far as I know, there are serveral status about domain 
> names in the epp protocol.
> But, none of them can support our model. So,  I prefer to add 
> a new status for the
> domain name, pendingExpired.  Do you think our idea is 
> reasonable? If not, would
> you please explain for me which extent status can be used in 
> our model?

pendingDelete is appropriate, though in your case no explicit delete command
was used to put it in that status.  Some time before the spec is finished I
should probably add back a sentence saying that objects can get into a
status either because of a transform command or a server-driven action.

-Scott-

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Fri, 30 Aug 2002 10:23:28 -0400

> [add a sentence to the effect that]
> objects [state change] because of a [client event (explicit in protocol)]
> or a [server event (not)].

Yup.

Eric

To: "Hollenbeck, Scott" <[email-masked]>
cc: "'wenzhe lu'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: a new domain name status 
Date: Fri, 30 Aug 2002 10:23:28 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> [add a sentence to the effect that]
> objects [state change] because of a [client event (explicit in protocol)]
> or a [server event (not)].

Yup.

Eric

From: "Hollenbeck, Scott" <[email-masked]>
To: "'wenzhe lu'" <[email-masked]>, [email-masked]
Subject: RE: a new domain name status
Date: Fri, 30 Aug 2002 07:45:38 -0400
Sender: [email-masked]

-Scott-

From: "wenzhe lu" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: a new domain name status
Date: Fri, 30 Aug 2002 16:01:39 +0800
Importance: Normal
Sender: [email-masked]

Hi Scott and All,

I am a programer from CNNIC(China Internet Information Center),
We are developing an epp-compatible registration system.
And now, we are facing a problem. Because CNNIC's policy is different
from ICANN's. We have no AutoRenew operation. When a domain name expire,
it will be stopped resolving but still in the database. And after serveral days, it will be
deleted permanently from the DB if it never be renewed again, then other registrant
can register this domain name.

As far as I know, there are serveral status about domain names in the epp protocol.
But, none of them can support our model. So,  I prefer to add a new status for the
domain name, pendingExpired.  Do you think our idea is reasonable? If not, would
you please explain for me which extent status can be used in our model?

Thanks.

Lu Wenzhe

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: FW: I-D ACTION:draft-hollenbeck-epp-ext-00.txt
Date: Wed, 28 Aug 2002 12:54:58 -0400
Sender: [email-masked]

FYI...

-Scott- 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, August 28, 2002 7:56 AM
To: IETF-Announce; @loki.ietf.org
Subject: I-D ACTION:draft-hollenbeck-epp-ext-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Guidelines for Extending the Extensible
Provisioning 
                          Protocol
	Author(s)	: S. Hollenbeck
	Filename	: draft-hollenbeck-epp-ext-00.txt
	Pages		: 26
	Date		: 2002-8-27
	
The Extensible Provisioning Protocol (EPP) is 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 presents guidelines for use of EPP's extension mechanisms to
define new features and object management capabilities.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-hollenbeck-epp-ext-00.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-hollenbeck-epp-ext-00.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.

From: Phil Roberts <[email-masked]>
To: IETF WG Participants: ;
Subject: Nomcom call for volunteers
Date: Tue, 27 Aug 2002 14:44:44 -0400
Sender: [email-masked]

The members of the IESG and IAB and the IETF chair are selected
by a nominations committee made up of volunteers from the
IETF community.  The nominations committee is now in the process
of being formed and volunteers are being accepted until Sep 6.
Please see (http://www.ietf.org/nomcom/msg19765.html)
for information if you are interested in volunteering 
to be on the nominations committee.

To: "Hollenbeck, Scott" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: New Schema Files and Examples 
Date: Tue, 27 Aug 2002 08:31:40 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

as usual, for those who prefer ftp and have problems with the verisign ftp
server (i do), i've put the gzip tarball up on nic-naa.net.

user == anonymous
password == something drole (i read my logs)

cheers,
eric

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: New Schema Files and Examples
Date: Tue, 27 Aug 2002 08:07:35 -0400
Sender: [email-masked]

The updated EPP documents have just been published.  Those of you interested
in getting your hands on the schemas and examples in compressed file-based
form can pull them down from either here:

http://www.verisign-grs.com/files/

(you want the files dated "August 19, 2002")

or here:

ftp://ftp.verisign.com/pub/epp/20020819/

-Scott-

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-provreg-epp-tcp-05.txt
Date: Tue, 27 Aug 2002 07:50:42 -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-05.txt
	Pages		: 13
	Date		: 2002-8-26
	
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-05.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-provreg-epp-tcp-05.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-05.txt
Date: Tue, 27 Aug 2002 07:50: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 Host Mapping
	Author(s)	: S. Hollenbeck
	Filename	: draft-ietf-provreg-epp-host-05.txt
	Pages		: 33
	Date		: 2002-8-26
	
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-05.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-provreg-epp-host-05.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-05.txt
Date: Tue, 27 Aug 2002 07:50: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 Domain Name Mapping
	Author(s)	: S. Hollenbeck
	Filename	: draft-ietf-provreg-epp-domain-05.txt
	Pages		: 47
	Date		: 2002-8-26
	
This document describes an Extensible Provisioning Protocol (EPP) map-
ping 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-05.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-provreg-epp-domain-05.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-05.txt
Date: Tue, 27 Aug 2002 07:50: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 Contact Mapping
	Author(s)	: S. Hollenbeck
	Filename	: draft-ietf-provreg-epp-contact-05.txt
	Pages		: 43
	Date		: 2002-8-26
	
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-05.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-provreg-epp-contact-05.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-07.txt
Date: Tue, 27 Aug 2002 07:50:19 -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-07.txt
	Pages		: 75
	Date		: 2002-8-26
	
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-07.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

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

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

--OtherAccess--

--NextPart--

To: "Jordyn A. Buchanan" <[email-masked]>
cc: [email-masked], "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: epp status 
Date: Wed, 21 Aug 2002 22:04:00 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> ... allows us to
> avoid making the server go insane when ...

Still, isn't this a registry-private issue?

and

> Is there an assumption of auto-renewal within any of the EPP specs?

If it exists, we should remove it.

> ... There
> may be some registries where the desired behavior at the end of the
> registration period is auto-deletion ...

Or whatever.

There is a protocol state machine (or an approximation of one).
There is a registry policy state machine (or ditto).

There is no guarantee that one can't hang one with the other, just
that we don't hang the first, and the second is registry-private.

Eric

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Jordyn A. Buchanan'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: epp status
Date: Wed, 21 Aug 2002 20:28:03 -0400
Sender: [email-masked]

> (Is there an assumption of auto-renewal within any of the EPP 
> specs?  There
> may be some registries where the desired behavior at the end of the
> registration period is auto-deletion.)

Nope, there are no presumptions of auto-renewal or auto-deletion.  That's
something for a server operator to decide, as you did.

-Scott-

Date: Wed, 21 Aug 2002 20:04:10 -0400
Subject: Re: epp status
From: "Jordyn A. Buchanan" <[email-masked]>
To: <[email-masked]>, "[email-masked]'" <[email-masked]>
Sender: [email-masked]

On 8/20/02 3:01 PM, "[email-masked]" <[email-masked]> wrote:

> 
> what happens when a domain has passed its expiration date and has a status
> of renewalProhibited?

We had a long internal discussion about this to figure out how to deal with
the situation in our implementation, and decided that *RenewProhibited
should prevent the renew command, but not necessarily the renew action.  So,
in our implementation, the domain will auto-renew regardless of the status.
(Is there an assumption of auto-renewal within any of the EPP specs?  There
may be some registries where the desired behavior at the end of the
registration period is auto-deletion.)  This interpretation allows us to
avoid making the server go insane when *RenewProhibited and
*DeleteProhibited are both set.

Jordyn

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Susan Goodsir'" <[email-masked]>, [email-masked]
Subject: RE: Subordinate hosts and domain transfers
Date: Wed, 21 Aug 2002 14:06:57 -0400
Sender: [email-masked]

> Am I right to understand that there is no requirement for the 
> superordinate
> domain to be sponsored by the client who wishes to provision 
> the host?  So,
> for example, may ClientX create "ns1.blah.tld" despite 
> ClientY being the
> sponsoring registrar of "blah.tld"?

Section 1.1 of the host mapping document describes the relationship between
host objects and domain objects.  In my mind, "subordinate" and
"superordinate" have sponsorship implications such that only the client who
sponsors the superordinate domain object can create a subordinate host
object.  The short answer to your question is "no", but that depends on the
relationship between host TLD, domain TLD, and if the host is an external
host or not.  The external host concept, and how such hosts are treated
(note that they don't get transferred), is also described in section 1.1.

> If so, there are implications for domain transfer.  For example if
> "blah.tld" is transferred to ClientZ, then 
> draft-ietf-provreg-epp-domain-04
> states that "ns1.blah.tld" must implicitly be transferred 
> from ClientX to
> ClientZ.  This will be done without ClientX's knowledge or 
> approval.  Is
> this behaviour intended?

Considering that the ClientY is responsible for the management of all hosts
subordinate to blah.tld, ClientX can't provision a host in blah.tld and is
not involved in the transfer at all.

-Scott-

From: Susan Goodsir <[email-masked]>
To: [email-masked]
Subject: Subordinate hosts and domain transfers
Date: Wed, 21 Aug 2002 18:32:04 +0100
Sender: [email-masked]

The draft-ietf-provreg-epp-host-04 states that hosts within the name space
for which a server is authoritative may only be created if the relevant
superordinate domain is known to the server. 

Am I right to understand that there is no requirement for the superordinate
domain to be sponsored by the client who wishes to provision the host?  So,
for example, may ClientX create "ns1.blah.tld" despite ClientY being the
sponsoring registrar of "blah.tld"?

If so, there are implications for domain transfer.  For example if
"blah.tld" is transferred to ClientZ, then draft-ietf-provreg-epp-domain-04
states that "ns1.blah.tld" must implicitly be transferred from ClientX to
ClientZ.  This will be done without ClientX's knowledge or approval.  Is
this behaviour intended?

Regards,

Suzy Goodsir
www.poptel.coop

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Rick Wesson'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: epp status
Date: Wed, 21 Aug 2002 08:19:12 -0400
Sender: [email-masked]

> what happens when a domain has passed its expiration date and 
> has a status
> of renewalProhibited?

Sounds like a server operator policy issue to me, but one could argue that
the domain should be purged if it can't be renewed and the expiration date
is reached.

-Scott-

Date: Tue, 20 Aug 2002 12:01:18 -0700 (PDT)
From: Rick Wesson <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: epp status
Sender: [email-masked]

what happens when a domain has passed its expiration date and has a status
of renewalProhibited?

-rick

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Roger Castillo Cortazar'" <[email-masked]>, [email-masked]
Subject: RE: Result codes to handle protocol extension-related errors.
Date: Mon, 19 Aug 2002 19:49:36 -0400
Sender: [email-masked]

> I mean the 1600 and 2600 generic result codes for protocol 
> extensions, as 
> suggested by Scott.
> Any comments ?
> I'd appreciate some some directions if I'm getting off the 
> right track ?

I sent the updated documents off to the I-D administrator earlier today, and
didn't do anything to add new error codes as described above.  There doesn't
seem to be agreement that they're needed; I certainly don't think they are
after giving this some more thought and hearing other people's comments.

When a client does a <login> it selects the extensions it wishes to use
during the session.  If the server then sends back one of those extensions
in a response, the client is obligated to understand it.  The very fact that
the extension is present is enough to tell the client "look in here", so
adding response codes to say "look in the extension" just doesn't seem to
add anything.

-Scott-

Date: Mon, 19 Aug 2002 17:05:59 -0500
To: [email-masked]
From: Roger Castillo Cortazar <[email-masked]>
Subject: RE: Result codes to handle protocol extension-related errors.
Sender: [email-masked]

Some clarifications.

>>The trouble with a code that means "look in the extension" is that a client
>>must know how to interpret the extension to find the supplementary error
>>information. Since formats will vary from one extension to another, the
>>client will have to have built-in knowledge about what elements in extension
>>to look at. So why not just return the generic EPP command failure status
>>code(s) and let the client look at the extension if it wants to? This allows
>>for a fairly smooth degradation in functionality in cases where the
>>extension element isn't understood.
>
>Exactly !!! A little bit more ....
>The use of extensions have to be with an agreemente between the parts.
>IMHO there has to be a previous arrangemente between registry and 
>registrar to use
>a particular protocol extension. A client must have buitl-in knowledge in 
>order
>to use an extension, and a registry may requiere that a registrar 
>implements that
>knowledge to do bussiness with him.
>
>I'd go with the generic EPP command failure status code(s), to indicate the
>client to look in the extension element for details.

I mean the 1600 and 2600 generic result codes for protocol extensions, as 
suggested by Scott.
Any comments ?
I'd appreciate some some directions if I'm getting off the right track ?

>Greetings.
More Greetings.

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

To: Roger Castillo Cortazar <[email-masked]>
cc: [email-masked]
Subject: Failed contribution to ietf-provreg
Date: Mon, 19 Aug 2002 21:33:02 +0200
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

	I dont see it in the list, so here it goes again.

It didn't got to the list because you apparently chanced your mail
adress. According to majordomo, you are [email-masked] but your
message came from [email-masked]. To prevent spam (you don't
want to know how much I see daily as list maintainer), the list
software is quite picky about the proper mail adress. So plaese
adjust your subscribtion.

Folks, please keep track of the way you are subscribed. If your
mail adresses changes, please change your subscribtion as well.

	jaap

Date: Mon, 19 Aug 2002 13:09:19 -0500
To: [email-masked]
From: Roger Castillo Cortazar <[email-masked]>
Subject: RE: Result codes to handle protocol extension-related errors.
Sender: [email-masked]

I dont see it in the list, so here it goes again.

At 14/08/2002 09:20 a.m., you wrote:
> >I'd much rather see extensions (including error extensions) left within the
> >boundaries of an <extension> element instead of trying to anticipate
> >extension errors in the core document, we might be able to define two new
> >response codes (like maybe 1600 and 2600) that means either "command
> >succeeded" or "command failed", and "look at the <extension> for details.
> >I'm not sure if there's much value in this, though, since extensions can
> >supplement existing response codes anyway.
>
>I would tend to agree with this.

Me too.It looks good.
In this way, you can deal with features added by protocol extensions, without
going into too much trouble with the core docs.

>The trouble with a code that means "look in the extension" is that a client
>must know how to interpret the extension to find the supplementary error
>information. Since formats will vary from one extension to another, the
>client will have to have built-in knowledge about what elements in extension
>to look at. So why not just return the generic EPP command failure status
>code(s) and let the client look at the extension if it wants to? This allows
>for a fairly smooth degradation in functionality in cases where the
>extension element isn't understood.

Exactly !!! A little bit more ....
The use of extensions have to be with an agreemente between the parts.
IMHO there has to be a previous arrangemente between registry and registrar 
to use
a particular protocol extension. A client must have buitl-in knowledge in order
to use an extension, and a registry may requiere that a registrar 
implements that
knowledge to do bussiness with him.

I'd go with the generic EPP command failure status code(s), to indicate the
client to look in the extension element for details.

Greetings.

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

Date: Mon, 19 Aug 2002 11:37:44 -0500
To: [email-masked]
From: Roger Castillo Cortazar <[email-masked]>
Subject: RE: Result codes to handle protocol extension-related errors.
Sender: [email-masked]

At 14/08/2002 09:20 a.m., you wrote:
> >I'd much rather see extensions (including error extensions) left within the
> >boundaries of an <extension> element instead of trying to anticipate
> >extension errors in the core document, we might be able to define two new
> >response codes (like maybe 1600 and 2600) that means either "command
> >succeeded" or "command failed", and "look at the <extension> for details.
> >I'm not sure if there's much value in this, though, since extensions can
> >supplement existing response codes anyway.
>
>I would tend to agree with this.

Me too.It looks good.
In this way, you can deal with features added by protocol extensions, without
going into too much trouble with the core docs.

>The trouble with a code that means "look in the extension" is that a client
>must know how to interpret the extension to find the supplementary error
>information. Since formats will vary from one extension to another, the
>client will have to have built-in knowledge about what elements in extension
>to look at. So why not just return the generic EPP command failure status
>code(s) and let the client look at the extension if it wants to? This allows
>for a fairly smooth degradation in functionality in cases where the
>extension element isn't understood.

Exactly !!! A little bit more ....
The use of extensions have to be with an agreemente between the parts.
IMHO there has to be a previous arrangemente between registry and registrar 
to use
a particular protocol extension. A client must have buitl-in knowledge in order
to use an extension, and a registry may requiere that a registrar 
implements that
knowledge to do bussiness with him.

I'd go with the generic EPP command failure status code(s), to indicate the
client to look in the extension element for details.

Greetings.

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

From: "Liu, Hong" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Response Code 2501
Date: Sat, 17 Aug 2002 15:17:59 -0500
Sender: [email-masked]

Andy,

I see your points. Believe me, I'd love to make it mandatory. However, I am
not sure if that is the only problem you had for keeping it in EPP.

--Hong

-----Original Message-----
From: Andrew Sullivan [mailto:[email-masked]]
Sent: Thursday, August 15, 2002 10:13 AM
To: [email-masked]'
Subject: Re: Response Code 2501

On Thu, Aug 15, 2002 at 12:03:24AM -0400, Liu, Hong wrote:

> BTW, what I am asking is to leave it as an implementation option. If a
> server implementation does not want to do this, it is OK. If a client
> implementation does not want to pick up the last server message in the
> buffer after detecting the session is gone, that is OK, too. Why? Because
it
> does not affect in any way the "normal" EPP operations in any way. But a
> server implementation should be allowed to do so if it chooses to. And a
> client implementation should be allowed to take advantage of this
diagnosis
> mechanism after detecting the lose of a session. 

That seems to me like the worst of all possible worlds.  I cannot see
any advantage is having session-control messages be optional.  Either
the specification requires these control messages, or not.  If it is
optional, client implementors at least have to build in the ability
to handle the message in case it arrives.

What's worse, if it's optional, the client won't know if the failure
to receive the message is because the server doesn't support it, or
because the network went away, or anything else.  Since that very
ambiguity is what the message is supposed to be solving, making the
"response" code optional just pushes the ambiguity deeper.  Of
course, one could add a bunch of stuff in the session initialisation
to say whether the message is supported; but that means building in a
bunch more overhead in order to support a message that is outside the
passive-server model anyway.  Seems like a bad idea, at least to me.

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

Date: Fri, 16 Aug 2002 10:36:02 +0200
From: Stephane Bortzmeyer <[email-masked]>
To: Patrick <[email-masked]>
Cc: [email-masked]
Subject: Re: Using P3P technologies to express privacy preferences
Organization: NIC France
Sender: [email-masked]

On Fri, Aug 16, 2002 at 10:23:00AM +0200,
 Patrick <[email-masked]> wrote 
 a message of 31 lines which said:

> I am not sure that P3P exactly as is will nicely fit in EPP, since
> P3P was designed for websites.

Yes, this is an issue to study. But I believe (although we'll be sure
only when an actual P3P policy file for a registry will be published)
that it does not bend P3P too much to use it for a registry. Besides,
there is no alternative. I'm not in the mood to write an EPP extension
for that.
 
> to fit that in EPP. Since the EPP client is not the final user (the
> one you specify in contact:create) nor run by the final user, 
> what options are there ?

The registrar should relay the preferences of the contact. For
instance, if the registrant uses a Web form, it will be queried for
his choices and they will be translated in APPEL and sent to the
registry in the EPP XML stream. An alternative is to use the APPEL
directly from the browser export system (I'm not aware of any Web
browser which supports it yet). 

> I guess that Registrars will adopt only one behavior with maybe some
> exceptions. 

I'm not sure (IANAL) that it will be legal. The european law seems to
mandate that at least some stuff must be available to an opt-out
choice.

Date: Fri, 16 Aug 2002 10:23:00 +0200
From: Patrick <[email-masked]>
To: [email-masked]
Subject: Re: Using P3P technologies to express privacy preferences
Organization: Gandi
Sender: [email-masked]

On Fri, Aug 16, 2002 at 09:58:57AM +0200, Stephane Bortzmeyer took time to write:
> Was there any work done after that? I assume that a P3P policy file
> could be included in the XML stream (although the registry policy does
> not change so often, registrars do not need to read it each time) and,

<dcp> ?
�2.3 of draft-ietf-provreg-epp-06.txt

> more important, that an APPEL file
> <URL:http://www.w3.org/TR/P3P-preferences/> could be included in the
> <contact:create> element to carry to the registry the privacy
> preferences of a contact. Anyone interested to follow this idea?

I am not sure that P3P exactly as is will nicely fit in EPP, since
P3P was designed for websites.

In fact by reading �1.1 of your reference, I fail to understand how
to fit that in EPP. Since the EPP client is not the final user (the
one you specify in contact:create) nor run by the final user, 
what options are there ?
(as quoted: 4.The agent fetches the policy ... and determines what
action to take)

Also, it would probably be a huge overhead to specify things
everytime in contact:create
I guess that Registrars will adopt only one behavior with maybe some
exceptions. 

Other than that I am interested.

Patrick.

Date: Fri, 16 Aug 2002 09:58:57 +0200
From: Stephane Bortzmeyer <[email-masked]>
To: [email-masked]
Subject: Using P3P technologies to express privacy preferences
Organization: NIC France
Sender: [email-masked]

Sometimes ago, there was a discussion ("Data Collection Requirements")
about using P3P:

http://www.cafax.se/ietf-provreg/maillist/2001-07/msg00002.html

But there was no real conclusion expect that the protocol should
provide a way for an individual contact to indicate its privacy
preferences.

Was there any work done after that? I assume that a P3P policy file
could be included in the XML stream (although the registry policy does
not change so often, registrars do not need to read it each time) and,
more important, that an APPEL file
<URL:http://www.w3.org/TR/P3P-preferences/> could be included in the
<contact:create> element to carry to the registry the privacy
preferences of a contact. Anyone interested to follow this idea?

Date: Thu, 15 Aug 2002 10:12:37 -0400
From: Andrew Sullivan <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Re: Response Code 2501
Mail-Followup-To: Andrew Sullivan <[email-masked]>, "[email-masked]'" <[email-masked]>
Sender: [email-masked]

On Thu, Aug 15, 2002 at 12:03:24AM -0400, Liu, Hong wrote:

> BTW, what I am asking is to leave it as an implementation option. If a
> server implementation does not want to do this, it is OK. If a client
> implementation does not want to pick up the last server message in the
> buffer after detecting the session is gone, that is OK, too. Why? Because it
> does not affect in any way the "normal" EPP operations in any way. But a
> server implementation should be allowed to do so if it chooses to. And a
> client implementation should be allowed to take advantage of this diagnosis
> mechanism after detecting the lose of a session. 

That seems to me like the worst of all possible worlds.  I cannot see
any advantage is having session-control messages be optional.  Either
the specification requires these control messages, or not.  If it is
optional, client implementors at least have to build in the ability
to handle the message in case it arrives.

What's worse, if it's optional, the client won't know if the failure
to receive the message is because the server doesn't support it, or
because the network went away, or anything else.  Since that very
ambiguity is what the message is supposed to be solving, making the
"response" code optional just pushes the ambiguity deeper.  Of
course, one could add a bunch of stuff in the session initialisation
to say whether the message is supported; but that means building in a
bunch more overhead in order to support a message that is outside the
passive-server model anyway.  Seems like a bad idea, at least to me.

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

Date: Thu, 15 Aug 2002 08:25:33 -0400
To: "Hollenbeck, Scott" <[email-masked]>, "'Robert Burbidge'" <[email-masked]>, "Ietf-Provreg (E-mail)" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: RE: Header in TCP Mapping
Sender: [email-masked]

At 12:00 PM -0400 8/12/02, Hollenbeck, Scott wrote:
>While I appreciate what you're saying, we can't let implementations to I-Ds
>dictate what we can or can't do to get the specifications finished.  Having
>said that, though, I'm inclined to leave things as-is unless someone comes
>up with a real compelling reason for the change.

Looking at IP and TCP, the length fields include the length field 
(noting that the length fields are embedded in the header structure). 
My inclination as a chair is to not change this (other that to clean 
up the byte ordering), i.e., leave the length field to cover itself. 
The reason is that past protocols have done it that way.

'Course, there's a potential counter example in DNS - the TCP version 
of the datagram is preceded by a length field that does not include 
itself.  But in this case, the length field is an addition for the 
connection-oriented version of the protocol only.  The datagram that 
follows is all that appears in the connection-less version, which 
means that the datagram is most likely prepared prior to knowing if 
the length field will be needed.

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

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Rick Wesson'" <[email-masked]>, [email-masked]
Subject: RE: BEEP transport
Date: Thu, 15 Aug 2002 06:57:33 -0400
Sender: [email-masked]

> again I'd like ask for a show of hands of those interested in a BEEP
> transport for EPP.

While I'm interested in the concept, I have no immediate or planned need to
implement BEEP transport.

-Scott-

From: "Michael Young" <[email-masked]>
To: "'Rick Wesson'" <[email-masked]>, <[email-masked]>
Subject: RE: BEEP transport
Date: Wed, 14 Aug 2002 12:07:40 -0400
Importance: Normal
Sender: [email-masked]

For the show of hands, we don't have any interest in a BEEP transport
Rick. 

Michael Young

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Rick Wesson
Sent: Wednesday, August 14, 2002 11:24 AM
To: [email-masked]'
Subject: BEEP transport

again I'd like ask for a show of hands of those interested in a BEEP
transport for EPP.

I didn't see anyone stand-up last time I asked.

If we don't have support for a BEEP transport for EPP at this time I'm
going to ask that the document be removed from or list of working
documents.

-rick

From: "Liu, Hong" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Response Code 2501
Date: Wed, 14 Aug 2002 23:23:47 -0500
Sender: [email-masked]

Claus,

Instead of repeating my arguments, I refer you to my response to Scott...

This issue has nothing to do with EPP PUSH or unsolicited response in
general. It is exception handling at the end of a server terminating
session.

Implementing a good EPP client that works well is by no means easy. We have
been there, done that. However, handling this is the least that you need to
worry about: you can choose to ignore it if you want. So the complexity
argument does not hold.

I hope you can take back the non-standard accusation. We are still in
discussion about EPP. We did not invent any twist to the protocol. Quite to
the contrary, we are following sound common practices that have proven to
work well in the past.

To the WG Chairs: I hate to use the strong language above, but I reserve the
rights to defend myself against any careless and false accusations.

--Hong

-----Original Message-----
From: Claus Dahl [mailto:[email-masked]]
Sent: Wednesday, August 14, 2002 10:09 AM
To: [email-masked]'
Subject: RE: Response Code 2501

I monitor the list and maintain the EPP client implementation at our
company. I would like to say that I agree completely that the server SHOULD
NOT send unsolicited data, and I am quite surprised the disussion has gone
on this long.

It is highly inconvenient from a client perspective to have any kind of
server initiated messages. This applies to the earlier suggested "EPP PUSH"
also. 
The pure client server approach makes client implementation much simpler.
For instance we use a simple EPP client which does session management for
efficency but otherwise adapts all communication to local interfaces, and
maintains no state. The EPP implementation is completely detached from the
rest of the system. In particular it is completely separated from all object
state concerns.
With server push or other server initiated communication, the EPP service
now has to maintain  more state than connection/session state. Highly
inconvenient and a poor separation of concerns.

Wrt "Sound technical arguments" I think the burden of proof is squarely on
the non-standard (i.e. Hong Liu's) approach. Why invent a twist on a
standard approach that is not broken? 

Claus Dahl
Ascio Technologies

From: "Liu, Hong" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Response Code 2501
Date: Thu, 15 Aug 2002 00:03:24 -0400
Sender: [email-masked]

Scott,

I insisted on keeping this option open for implementation because I feel
strongly that this is the right thing to do. 

Is this an exception to the rule? Yes, it is because it handles an
exceptional case: server-initiated session termination. This unsolicited
response is _only_ sent at the end of a session. This unsolicited response
is _not_ used anywhere else during the session.

Has this be done before? Yes, the same approach was taken in most existing
FTP implementations. Why we use FTP as a reference point? Because FTP has to
handle the same problem as in EPP. And the best common practice in FTP
server implementations today is to send an unsolicited response to the
client before the server closes the connection. More information is provided
below.

Why this is useful? It helps a client to find out why the session is gone.
Otherwise, how can one tell that it is because of the server timeout or
because of network problems? So this is a hint from the server to the client
why the session is gone, not a mechanism for the client to detect the lose
of a session.

BTW, what I am asking is to leave it as an implementation option. If a
server implementation does not want to do this, it is OK. If a client
implementation does not want to pick up the last server message in the
buffer after detecting the session is gone, that is OK, too. Why? Because it
does not affect in any way the "normal" EPP operations in any way. But a
server implementation should be allowed to do so if it chooses to. And a
client implementation should be allowed to take advantage of this diagnosis
mechanism after detecting the lose of a session. 

I hope we can think of this issue more carefully before jumping into
conclusion that this should be excluded.

I have to leave this discussion for now since I will be out of town in the
next two weeks. I probably won't be able to access the list in the next
couple of days, but I will try to be back next Monday. In the meantime, as
you said before, silence != concurrence, -:)

More comments in line enclosed with <HL/>.

--Hong 

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: Wednesday, August 14, 2002 9:39 AM
To: 'Liu, Hong'; [email-masked]'
Subject: RE: Response Code 2501

> I know what it says in RFC959, and I also looked carefully at 
> the tcpdump in
> one of the most popular FTP implementations. Sometimes, we 
> get too bolted
> down to interpret the standard literally. Are you going to 
> say that the
> Linux implementation is not confirming to RFC959?

If it's sending an unsolicited response, yes, my interpretation would be
that it's not conforming as the text in 959 is pretty clear to me about 421
being a _response_.  Interpreting standards literally is what ensures
interoperability.

<HL> 
What I meant is that RFC959 does not explicitly exclude _unsolicited_
response. Yes, it is odd. But it is the approach taken by most of the FTP
server implementations today. Are you going to say they are all
non-conforming? Then where is the conforming one? I am not aware of any
major FTP interoperability issues because of this one.
</HL>

> As I explained before, server initiated session termination is not a
> "normal" operation that fits into the client-request 
> server-response mode.
> Having the server send the last message notifying the client 
> that it is
> closing down the session makes a lot of sense for the client 
> to figure out
> later on why the session is gone.

Dead or hung clients aren't going to figure anything out.  

<HL> 
This is just bad client implementation. Sorry, that is the only way I can
say. A client should not be dead or hung just because the session is gone.
For example, an FTP client is not dead or hung when the connection is lost.
</HL>

If anything,
section 4.1.2.11 of RFC 1123 clearly says that the client should detect
connection closure without interpreting response code 421 in any special
way:

"A User-FTP SHOULD NOT interpret a 421 reply code ("Service
not available, closing control connection") specially, but
SHOULD detect closing of the control connection by the
server."

<HL>
Actually, I don't see a problem here. As I explained above, an FTP client
does not use it to detect the closing of a connection. It simply fetches
that message and displays it to the user why the connection is gone, _after_
it detects that the connection is closed.
</HL>

> You got to have a sound technical argument why you are 
> against it instead of
> just saying that it does not fit into the client/server model, because
> existing client/server implementation, i.e., FTP, does use 
> the unsolicited
> response before terminating a session.

The sound technical argument has already been provided: a passive server
should not be sending a response to a client in the absence of a command.
An implementation of another protocol that does something different is not a
good example of a counter argument.

<HL>
You brought up the FTP example, and I agreed that it is a good example to
learn how other protocols handle similar situation. Why do we invent
something against a common practice that has proven to work very well over
so many years? 
</HL>

> If necessary, I will post the trace to the list for your reference.

Feel free, but it's not needed for my reference.  I've already seen it for
myself.

Since we continue to disagree (though as far as I can tell you're the only
one who has objected to removing this response code), I'll defer to the
chairs to determine WG consensus.  Even if popular ftp implementations are
sending unsolicited responses, I don't think that we should.

<HL>
I hope that this WG can keep the IETF principle of "rough consensue and
running code". Here are the FTP running codes I would like to share with the
WG:

FTP servers:

Solaris 5.8				 ?		421 Timeout (900
seconds): closing control connection.
HP-UX B.11				1.1.214.6	421 Service not
available, remote server has closed connection
RedHat Linux 7.1			wu-2.6.1-16	421 Timeout (900
seconds): closing control connection.
Windows NT: ftp.microsoft.com	 ?		421 Timeout (180 seconds):
closing control connection.
ProFTPD Server: ftp.sf.net	 ?		421 No Transfer Timeout (600
seconds): closing control connection.
NcFTPd: ftp.cdrom.com (FreeBSD)?		421 Disconnecting you since
you were inactive for 300 seconds.	
	
Other popular FTP servers, such as ftp.uu.net, nic.funet.fi, would behave
the same way as above. WS_FTP server sends the following spontaneous reply
"500 connection timed out" before closing the connection. The result code is
different, but the principle remains the same.

I think it is a _very_ good idea to draw upon previous protocol
implementation experiences when designing new protocols. To me, it just
makes a lot of sense. Of course, I would love to see others from IETF to
share their thoughts on why most FTP implementations are done this way.
</HL>

Janusz made another suggestion that might be a reasonable compromise:

http://www.cafax.se/ietf-provreg/maillist/2002-08/msg00062.html

<HL>
I don't think it is a bad idea, but why invent a new EPP command for the
same purpose? You still need an XML structure similar to <result> inside
<goodbye> to explain why the session is closed. But I will keep an open mind
and think through it a bit more on the airplane...
</HL>

-Scott-

From: Robert Burbidge <[email-masked]>
To: "Ietf-Provreg (E-mail)" <[email-masked]>
Subject: RE: BEEP transport
Date: Wed, 14 Aug 2002 16:45:42 +0100
Sender: [email-masked]

>again I'd like ask for a show of hands of those interested in a BEEP
>transport for EPP.

At the moment I'd say that I'm NOT interested. This is purely a matter of
supply and demand rather than any technical preference for or against the
BEEP transport. From a short-term business perspective, we have no clients
asking to connect to our provisioning services using BEEP - TCP is adequate
for us. Your mileage may vary. Obviously I can't speak for others, but I
wouldn't like Rick to think that he was being ignored.

I don't want to betray my ignorance too much, but who should be interested
in BEEP transport for EPP: i.e. in what provisioning situations might it
give one the edge?

Rob Burbidge
Poptel

Date: Wed, 14 Aug 2002 08:23:39 -0700 (PDT)
From: Rick Wesson <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: BEEP transport
Sender: [email-masked]

again I'd like ask for a show of hands of those interested in a BEEP
transport for EPP.

I didn't see anyone stand-up last time I asked.

If we don't have support for a BEEP transport for EPP at this time I'm
going to ask that the document be removed from or list of working
documents.

-rick

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Robert Burbidge'" <[email-masked]>, "Ietf-Provreg (E-mail)" <[email-masked]>
Subject: RE: Byte order marks and character sets
Date: Wed, 14 Aug 2002 10:55:27 -0400
Sender: [email-masked]

> One longer-term issue remains, and it's not urgent in my 
> mind, but I will
> mention it for completeness. Can you forsee any situations 
> (right now or in
> the future) where UTF16 or other encodings would be desirable and/or
> necessary? If so, can we ensure that the spec doesn't make too many
> assumptions about UTF8 encoding. If UTF8 is RECOMMENDED 
> that's probably
> enough in most cases, but would it be either valid and/or 
> desirable to have
> an EPP server that works entirely in UTF16 for example? Let 
> me stress I have
> no strong views on the subject, although vague topics like 
> "chinese domain
> names" or "use of EPP as a generic provisioning protocol" do 
> occasionally
> cross my mind in this context.

Yes, I think it's entirely possible that the protocol will be used with
encodings other than UTF-8.  As long as you use either UTF-8 or UTF-16 a
conformant XML parser has no problems with either form.  Other encodings
might not be supported by all parsers, but the protocol certainly allows
their use.

-Scott-

Date: Wed, 14 Aug 2002 10:14:56 -0400
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: Result codes to handle protocol extension-related errors.
Mail-Followup-To: Andrew Sullivan <[email-masked]>, [email-masked]
Sender: [email-masked]

On Wed, Aug 14, 2002 at 09:48:22AM -0400, Hollenbeck, Scott wrote:
> 
> I'd much rather see extensions (including error extensions) left within the
> boundaries of an <extension> element instead of trying to anticipate
> extension errors in the core document, we might be able to define two new
> response codes (like maybe 1600 and 2600) that means either "command
> succeeded" or "command failed", and "look at the <extension> for details.
> I'm not sure if there's much value in this, though, since extensions can
> supplement existing response codes anyway.

True, but it might be helpful to registrars (and registries) to
have a code dedicated just to indicating that the whole of the error
is in the <extension> part.  This would cut down on "well, my code
works in registry xyz; the server must be broken" reports.  (I'm not
wedded to theidea, but I can see its utility.)

A

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

From: Claus Dahl <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Response Code 2501
Date: Wed, 14 Aug 2002 16:09:11 +0200
Sender: [email-masked]

I monitor the list and maintain the EPP client implementation at our
company. I would like to say that I agree completely that the server SHOULD
NOT send unsolicited data, and I am quite surprised the disussion has gone
on this long.

It is highly inconvenient from a client perspective to have any kind of
server initiated messages. This applies to the earlier suggested "EPP PUSH"
also. 
The pure client server approach makes client implementation much simpler.
For instance we use a simple EPP client which does session management for
efficency but otherwise adapts all communication to local interfaces, and
maintains no state. The EPP implementation is completely detached from the
rest of the system. In particular it is completely separated from all object
state concerns.
With server push or other server initiated communication, the EPP service
now has to maintain  more state than connection/session state. Highly
inconvenient and a poor separation of concerns.

Wrt "Sound technical arguments" I think the burden of proof is squarely on
the non-standard (i.e. Hong Liu's) approach. Why invent a twist on a
standard approach that is not broken? 

Claus Dahl
Ascio Technologies

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: 14. august 2002 15:39
To: 'Liu, Hong'; [email-masked]'
Subject: RE: Response Code 2501

> I know what it says in RFC959, and I also looked carefully at 
> the tcpdump in
> one of the most popular FTP implementations. Sometimes, we 
> get too bolted
> down to interpret the standard literally. Are you going to 
> say that the
> Linux implementation is not confirming to RFC959?

If it's sending an unsolicited response, yes, my interpretation would be
that it's not conforming as the text in 959 is pretty clear to me about 421
being a _response_.  Interpreting standards literally is what ensures
interoperability.

> As I explained before, server initiated session termination is not a
> "normal" operation that fits into the client-request 
> server-response mode.
> Having the server send the last message notifying the client 
> that it is
> closing down the session makes a lot of sense for the client 
> to figure out
> later on why the session is gone.

Dead or hung clients aren't going to figure anything out.  If anything,
section 4.1.2.11 of RFC 1123 clearly says that the client should detect
connection closure without interpreting response code 421 in any special
way:

"A User-FTP SHOULD NOT interpret a 421 reply code ("Service
not available, closing control connection") specially, but
SHOULD detect closing of the control connection by the
server."

> You got to have a sound technical argument why you are 
> against it instead of
> just saying that it does not fit into the client/server model, because
> existing client/server implementation, i.e., FTP, does use 
> the unsolicited
> response before terminating a session.

The sound technical argument has already been provided: a passive server
should not be sending a response to a client in the absence of a command.
An implementation of another protocol that does something different is not a
good example of a counter argument.

> If necessary, I will post the trace to the list for your reference.

Feel free, but it's not needed for my reference.  I've already seen it for
myself.

Since we continue to disagree (though as far as I can tell you're the only
one who has objected to removing this response code), I'll defer to the
chairs to determine WG consensus.  Even if popular ftp implementations are
sending unsolicited responses, I don't think that we should.

Janusz made another suggestion that might be a reasonable compromise:

http://www.cafax.se/ietf-provreg/maillist/2002-08/msg00062.html

-Scott-

From: Robert Burbidge <[email-masked]>
To: "Ietf-Provreg (E-mail)" <[email-masked]>
Subject: RE: Result codes to handle protocol extension-related errors.
Date: Wed, 14 Aug 2002 15:20:26 +0100
Sender: [email-masked]

>I'd much rather see extensions (including error extensions) left within the
>boundaries of an <extension> element instead of trying to anticipate
>extension errors in the core document, we might be able to define two new
>response codes (like maybe 1600 and 2600) that means either "command
>succeeded" or "command failed", and "look at the <extension> for details.
>I'm not sure if there's much value in this, though, since extensions can
>supplement existing response codes anyway.

I would tend to agree with this.

The trouble with a code that means "look in the extension" is that a client
must know how to interpret the extension to find the supplementary error
information. Since formats will vary from one extension to another, the
client will have to have built-in knowledge about what elements in extension
to look at. So why not just return the generic EPP command failure status
code(s) and let the client look at the extension if it wants to? This allows
for a fairly smooth degradation in functionality in cases where the
extension element isn't understood.

For what it's worth, we've managed to implement the verification extensions
for dot coop without defining any extra EPP error codes. The existing error
codes are adequate for processing the initial requests, and any subsequent
"error" conditions can be handled using <extension> elements inside <poll>
messages queued by the server. (Your mileage may vary).

Rob Burbidge
Poptel

From: Robert Burbidge <[email-masked]>
To: "Ietf-Provreg (E-mail)" <[email-masked]>
Subject: Byte order marks and character sets
Date: Wed, 14 Aug 2002 15:05:37 +0100
Sender: [email-masked]

>While it MAY be used it's certainly not necessary and most people I talked
>to strongly suggested that it's use should be discouraged.  Thus, this is
>what I intend to add to Section 2 of the EPP document to address the issue:

>"Normative section 4.3.3 and non-normative appendix F of [XML] describe
>use of a byte order mark (BOM) to identify the character encoding in
>the absence of an XML declaration or encapsulating headers.  Appendix F
>includes a BOM to represent UTF-8 encoding, though section 4.3.3
>notes that a BOM is not needed to identify UTF-8 encoding.  Section
>4.3.3 was later amended (see [XMLE]) to clarify that a BOM MAY be used
>to identify UTF-8 encoding.  EPP clients and servers MUST accept a
>UTF-8 BOM if present, though emitting a UTF-8 BOM is NOT RECOMMENDED."

This seems to me to be a significant improvement in the specification which
I support. As I mentioned before, we've decided to supress outgoing UTF-8
BOMs from our server, although we can handle incoming UTF8 BOMS if they are
provided by a client.

One longer-term issue remains, and it's not urgent in my mind, but I will
mention it for completeness. Can you forsee any situations (right now or in
the future) where UTF16 or other encodings would be desirable and/or
necessary? If so, can we ensure that the spec doesn't make too many
assumptions about UTF8 encoding. If UTF8 is RECOMMENDED that's probably
enough in most cases, but would it be either valid and/or desirable to have
an EPP server that works entirely in UTF16 for example? Let me stress I have
no strong views on the subject, although vague topics like "chinese domain
names" or "use of EPP as a generic provisioning protocol" do occasionally
cross my mind in this context.

Thanks for your quick action on clarifying this.

Rob Burbidge

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Roger Castillo Cortazar'" <[email-masked]>, [email-masked]
Subject: RE: Result codes to handle protocol extension-related errors.
Date: Wed, 14 Aug 2002 09:48:22 -0400
Sender: [email-masked]

> Hi everybody.
> 
> Now that some folks in the list are talking about extensions.
> 
> We are working on a protocol extension for nic.mx, and we'll 
> be needing to 
> inform our clients about errors related to the features added 
> by the extension.
> 
> What if I need to handle an error that is not covered in the 
> core documents ?
> 
> Could we define a new category to handle this result codes ? 
> For example ...
> 
> x3zz   Data Management
> x4zz   Server System
> x5zz   Connection Management
> x6xx   Extension Related
> 
> ... and leave it open ? or maybe we need to identify specific 
> errors to be 
> added to the core docs using the existing categories?
> (I think this is the way the "Action Pending"  result code is 
> going to be 
> handled).

I'd much rather see extensions (including error extensions) left within the
boundaries of an <extension> element instead of trying to anticipate
extension errors in the core document, we might be able to define two new
response codes (like maybe 1600 and 2600) that means either "command
succeeded" or "command failed", and "look at the <extension> for details.
I'm not sure if there's much value in this, though, since extensions can
supplement existing response codes anyway.

-Scott-

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Liu, Hong'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Response Code 2501
Date: Wed, 14 Aug 2002 09:39:18 -0400
Sender: [email-masked]

> I know what it says in RFC959, and I also looked carefully at 
> the tcpdump in
> one of the most popular FTP implementations. Sometimes, we 
> get too bolted
> down to interpret the standard literally. Are you going to 
> say that the
> Linux implementation is not confirming to RFC959?

If it's sending an unsolicited response, yes, my interpretation would be
that it's not conforming as the text in 959 is pretty clear to me about 421
being a _response_.  Interpreting standards literally is what ensures
interoperability.

> As I explained before, server initiated session termination is not a
> "normal" operation that fits into the client-request 
> server-response mode.
> Having the server send the last message notifying the client 
> that it is
> closing down the session makes a lot of sense for the client 
> to figure out
> later on why the session is gone.

Dead or hung clients aren't going to figure anything out.  If anything,
section 4.1.2.11 of RFC 1123 clearly says that the client should detect
connection closure without interpreting response code 421 in any special
way:

"A User-FTP SHOULD NOT interpret a 421 reply code ("Service
not available, closing control connection") specially, but
SHOULD detect closing of the control connection by the
server."

> You got to have a sound technical argument why you are 
> against it instead of
> just saying that it does not fit into the client/server model, because
> existing client/server implementation, i.e., FTP, does use 
> the unsolicited
> response before terminating a session.

The sound technical argument has already been provided: a passive server
should not be sending a response to a client in the absence of a command.
An implementation of another protocol that does something different is not a
good example of a counter argument.

> If necessary, I will post the trace to the list for your reference.

Feel free, but it's not needed for my reference.  I've already seen it for
myself.

Since we continue to disagree (though as far as I can tell you're the only
one who has objected to removing this response code), I'll defer to the
chairs to determine WG consensus.  Even if popular ftp implementations are
sending unsolicited responses, I don't think that we should.

Janusz made another suggestion that might be a reasonable compromise:

http://www.cafax.se/ietf-provreg/maillist/2002-08/msg00062.html

-Scott-

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Robert Burbidge'" <[email-masked]>, "Ietf-Provreg (E-mail)" <[email-masked]>
Subject: RE: Byte order marks and character sets
Date: Wed, 14 Aug 2002 09:32:05 -0400
Sender: [email-masked]

> My problem seems to be that no clients read the UTF-8 BOM. I 
> think they
> should understand it even if it's optional; that's what a 
> conforming XML
> parser should do. If I'm right, then the problem is not 
> strictly a problem
> with the EPP spec but with client implementations which is outside the
> strict scope of this discussion group but hey....

OK, investigation complete.  Use of the BOM to identify UTF-8 is covered in
the errata for the XML 1.0 second edition recommendation:

http://www.w3.org/XML/xml-V10-2e-errata#E22

While it MAY be used it's certainly not necessary and most people I talked
to strongly suggested that it's use should be discouraged.  Thus, this is
what I intend to add to Section 2 of the EPP document to address the issue:

"Normative section 4.3.3 and non-normative appendix F of [XML] describe
use of a byte order mark (BOM) to identify the character encoding in
the absence of an XML declaration or encapsulating headers.  Appendix F
includes a BOM to represent UTF-8 encoding, though section 4.3.3
notes that a BOM is not needed to identify UTF-8 encoding.  Section
4.3.3 was later amended (see [XMLE]) to clarify that a BOM MAY be used
to identify UTF-8 encoding.  EPP clients and servers MUST accept a
UTF-8 BOM if present, though emitting a UTF-8 BOM is NOT RECOMMENDED."

Date: Tue, 13 Aug 2002 13:12:46 -0500
To: [email-masked]
From: Roger Castillo Cortazar <[email-masked]>
Subject: Result codes to handle protocol extension-related errors.
Sender: [email-masked]

Hi everybody.

Now that some folks in the list are talking about extensions.

We are working on a protocol extension for nic.mx, and we'll be needing to 
inform our clients about errors related to the features added by the extension.

What if I need to handle an error that is not covered in the core documents ?

Could we define a new category to handle this result codes ? For example ...

x3zz   Data Management
x4zz   Server System
x5zz   Connection Management
x6xx   Extension Related

... and leave it open ? or maybe we need to identify specific errors to be 
added to the core docs using the existing categories?
(I think this is the way the "Action Pending"  result code is going to be 
handled).

Any comments ?

Greetings.

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

From: "Liu, Hong" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Response Code 2501
Date: Tue, 13 Aug 2002 20:34:20 -0400
Sender: [email-masked]

Scott,

I know what it says in RFC959, and I also looked carefully at the tcpdump in
one of the most popular FTP implementations. Sometimes, we get too bolted
down to interpret the standard literally. Are you going to say that the
Linux implementation is not confirming to RFC959?

As I explained before, server initiated session termination is not a
"normal" operation that fits into the client-request server-response mode.
Having the server send the last message notifying the client that it is
closing down the session makes a lot of sense for the client to figure out
later on why the session is gone.

You got to have a sound technical argument why you are against it instead of
just saying that it does not fit into the client/server model, because
existing client/server implementation, i.e., FTP, does use the unsolicited
response before terminating a session.

If necessary, I will post the trace to the list for your reference.

--Hong

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: Tuesday, August 13, 2002 7:51 PM
To: 'Liu, Hong'; [email-masked]'
Subject: RE: Response Code 2501

[snip...]

> It is good that you brought up FTP as an example to shed 
> lights on how 421
> is being used. My colleague Ning Zhang collected an FTP trace 
> yesterday from
> an WFTP implementation on Linux. The trace clearly shows that 
> the FTP server
> sends 421 to the client before closing down the control 
> connection after
> timeout. 

Looking at RFC 959, I don't agree at all that the situation is similar.
Response code 421 is clearly identified as a _response_ sent for the various
ftp commands, not an unsolicited response to note connection closing as a
result of a timeout:

"421 Service not available, closing control connection.
This may be a reply to any command if the service knows it
must shut down."

> So, should result code 2501 be handled similarly in EPP in the case of
> server closing down the session?

Nope.  No unsolicited responses.

-Scott-

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Liu, Hong'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Response Code 2501
Date: Tue, 13 Aug 2002 19:51:22 -0400
Sender: [email-masked]

> I could not find the section in RFC1132, maybe you referred 
> to a different
> RFC number. In any case, I did check the FTP RFC959, where 
> result code 421
> is defined in FTP for a similar purpose as 2501 for EPP.

Oops, sorry, it's RFC 1123.

> It is good that you brought up FTP as an example to shed 
> lights on how 421
> is being used. My colleague Ning Zhang collected an FTP trace 
> yesterday from
> an WFTP implementation on Linux. The trace clearly shows that 
> the FTP server
> sends 421 to the client before closing down the control 
> connection after
> timeout. 

Looking at RFC 959, I don't agree at all that the situation is similar.
Response code 421 is clearly identified as a _response_ sent for the various
ftp commands, not an unsolicited response to note connection closing as a
result of a timeout:

"421 Service not available, closing control connection.
This may be a reply to any command if the service knows it
must shut down."

> So, should result code 2501 be handled similarly in EPP in the case of
> server closing down the session?

Nope.  No unsolicited responses.

-Scott-

From: "Liu, Hong" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Response Code 2501
Date: Tue, 13 Aug 2002 12:21:04 -0500
Sender: [email-masked]

Scott,

I could not find the section in RFC1132, maybe you referred to a different
RFC number. In any case, I did check the FTP RFC959, where result code 421
is defined in FTP for a similar purpose as 2501 for EPP.

It is good that you brought up FTP as an example to shed lights on how 421
is being used. My colleague Ning Zhang collected an FTP trace yesterday from
an WFTP implementation on Linux. The trace clearly shows that the FTP server
sends 421 to the client before closing down the control connection after
timeout. 

So, should result code 2501 be handled similarly in EPP in the case of
server closing down the session?

--Hong

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: Monday, August 12, 2002 3:58 PM
To: 'Liu, Hong'; [email-masked]'
Subject: RE: Response Code 2501

> I am looking for a solution to problem of server terminating session
> management. I will be happy if you or someone else can give me an
> alternative solution.

I think the way that ftp servers deal with this is an excellent example; see
section 4.1.3.2 of RFC 1132.  The ftp control connection can be closed by
the server after a period of client inactivity.  There's no
message/response/error code sent to the client because the server only
responds to commands, just as in EPP today.  If/when the client next tries
to do something (if ever), it finds that the connection has been closed and
the situation is reported to the user.

BTW, the mapping of a session to the concept of a connection to a server is
being addressed in the next edition of the documents.  I'm not saying that
we get tied to connection-oriented transports like TCP in the core document,
but as part of the whole stateful vs. stateless issue Patrik wanted to see a
clearer mapping between the session and connection concepts.  Transport
documents are going to have to be specific about how sessions are mapped to
client-server connections.

-Scott-

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Robert Burbidge'" <[email-masked]>, "Ietf-Provreg (E-mail)" <[email-masked]>
Subject: RE: Command-Response Extension - Minor ambiguity in specification ?
Date: Tue, 13 Aug 2002 08:15:39 -0400
Sender: [email-masked]

> In fairness to Scott, I should add that the XML schema resolves the
> ambiguity in favour of the first form, and I accept that the schema is
> normative. I would, however, suggest that the example using the
> <EPPCommandName> tag be re-written to make the example more clear.

Good catch -- the text needs to be fixed to match the schema.  It'll be done
in the next version of the document.

-Scott-

From: Robert Burbidge <[email-masked]>
To: "Ietf-Provreg (E-mail)" <[email-masked]>
Subject: Command-Response Extension - Minor ambiguity in specification?
Date: Tue, 13 Aug 2002 11:24:57 +0100
Sender: [email-masked]

Epp Spec Draft 4, section 2.6.3

The example for commands is a bit ambigous. It uses an element called
<EPPCommandName>. Obviously from context this is a placeholder for some
other element defined in EPP, but it wasn't very clear to me whether this
was the <command> element itself or one of the elements such as <create> or
<delete> that appear in inside <command>.

As I understand it, if I was to write an extension for contact creation, it
would have the form

<command>
  <create>
    <contact:create>
    </contact:create>
  </create>
  <extension>
    .. extension elements here ..
  </extension>
</command>

However the example fragment implies (to my mind anyway) the form

<command>
  <create>
    <contact:create>
    </contact:create>
    <extension>
      .. extension elements here ..
    </extension>
  </create>
</command>

In fairness to Scott, I should add that the XML schema resolves the
ambiguity in favour of the first form, and I accept that the schema is
normative. I would, however, suggest that the example using the
<EPPCommandName> tag be re-written to make the example more clear.

If I have misunderstood any of the above please feel free to correct me of
course.

Rob Burbidge

Subject: RE: [[email-masked]: [open-eu] Open Registry Robot  / EPP transport layer]
From: Sven-Holger Wabnitz <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
Cc: [email-masked], open-eu discuss <[email-masked]>
Date: 13 Aug 2002 11:58:54 +0200
Sender: [email-masked]

--=-Elo68tczeiB3baqQ9abd
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Am Mon, 2002-08-12 um 17.00 schrieb Hollenbeck, Scott:
> > Sent on a public mailing list of CORE so I assume I can redistribute
> > it.
>=20
> Well, this is certainly the right mailing list to discuss EPP I-Ds.  It
> would be nice if we could have the discussion here.
>=20
> I also hope the authors are well-versed on current IETF thinking around u=
se
> of HTTP as a substrate as it has been hotly debated in the IETF in the pa=
st:
>=20
> ftp://ftp.isi.edu/in-notes/rfc3205.txt
>=20
> -Scott-

The rfc is known and the idea why rfc3205 was written is one of the
ideas to choose http as a transport layer for EPP. The issues
mentioned in rfc3205 have to be well discussed (more than one road=20
lead to Rome).

Regards,
Sven-Holger

--=20
___________________________________________________________________

Sven-Holger Wabnitz   DSS Gesellschaft fuer Digitale Sicherheit mbH
phone +49 2222 990-0            **             fax +49 2222 990-444
http://www.digital-security.com **            http://www.dominic.de

>From the Portland Pattern Repository (de facto home of the
extreme programming discipline), hosted by Cunningham & Cunningham.

        "Life's too short to write code that nobody wants."

--=-Elo68tczeiB3baqQ9abd
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: Dies ist ein digital signierter Nachrichtenteil

--=-Elo68tczeiB3baqQ9abd--

From: Robert Burbidge <[email-masked]>
To: "Ietf-Provreg (E-mail)" <[email-masked]>
Subject: RE: Byte order marks and character sets
Date: Tue, 13 Aug 2002 09:52:52 +0100
Sender: [email-masked]

Getting advice from the XML folks seems like the right thing to do.
Rob

>This is an XML issue, not directly an EPP issue, but it could be described
>in the EPP document since the normative references aren't quite clear.
>Given that it's not a normative part of the XML recommendation and it's not
>mentioned in RFC 2279 I'm not sure of the best way to address this at the
>moment.  I'm going to ping some of the folks I worked with when writing my
>IETF XML guidelines I-D to see what they have to say.

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Liu, Hong'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Response Code 2501
Date: Mon, 12 Aug 2002 15:57:34 -0400
Sender: [email-masked]

> I am looking for a solution to problem of server terminating session
> management. I will be happy if you or someone else can give me an
> alternative solution.

I think the way that ftp servers deal with this is an excellent example; see
section 4.1.3.2 of RFC 1132.  The ftp control connection can be closed by
the server after a period of client inactivity.  There's no
message/response/error code sent to the client because the server only
responds to commands, just as in EPP today.  If/when the client next tries
to do something (if ever), it finds that the connection has been closed and
the situation is reported to the user.

BTW, the mapping of a session to the concept of a connection to a server is
being addressed in the next edition of the documents.  I'm not saying that
we get tied to connection-oriented transports like TCP in the core document,
but as part of the whole stateful vs. stateless issue Patrik wanted to see a
clearer mapping between the session and connection concepts.  Transport
documents are going to have to be specific about how sessions are mapped to
client-server connections.

-Scott-

Date: Mon, 12 Aug 2002 15:53:51 -0400
From: janusz sienkiewicz <[email-masked]>
Organization: LibertyRMS Co.
To: "Hollenbeck, Scott" <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: Response Code 2501
Sender: [email-masked]

An alternative solution to an  unsolicited 2501 response  could be sending an
optional unsolicited  epp element that is symetric to <greeting> element . It s
name could be <goodbye>.

Regards,

Janusz

"Hollenbeck, Scott" wrote:

> > While I understand that the normal operating mode for EPP is
> > client-initiated command/response, this is a special case
> > where the server
> > initiates the action due to non-activity by a client.
> > Otherwise, the client
> > will be left without any clue why the connection is gone.
>
> Hong,
>
> It's not just the "normal" operating mode, it's the _only_ operating mode
> currently defined.  If the client is dead or otherwise hung, a clue isn't
> going to help.
>
> I'm OK with leaving this response code in if it might have some future
> benefit (like if someone ever writes a draft describing server message
> pushing ;-)), but as things are written currently I'd consider a server that
> sends an unsolicited 2501 response to be non-conforming.
>
> -Scott-

From: "Liu, Hong" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Response Code 2501
Date: Mon, 12 Aug 2002 15:29:53 -0400
Sender: [email-masked]

Scott,

I should have clarified better what I meant by "normal" in the previous
email. I would also like to distinguish between session and connection in my
posting, too.

By "normal" operation, I mean the client/server exchange after the session
is established. The issue at hand has to do with session management, rather
than a response to a command. Terminating a session does not necessarily
triggers the termination of the underlying transport connection. I hope that
we can address this issue in EPP without being completely tied to the TCP
mapping.

At present, a client can notify the server to terminate a session via a
<logout> command. However, it is not clear in EPP how a server should
terminate a session on its own end. The use of 2501 at least provides a way
for the server to notify the client that it is closing down the session due
to timeout. The client is not necessarily dead and hung at this point. So it
will be able to retrieve the message from its buffer.

I am looking for a solution to problem of server terminating session
management. I will be happy if you or someone else can give me an
alternative solution.

--Hong

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: Monday, August 12, 2002 11:58 AM
To: 'Liu, Hong'; [email-masked]'
Subject: RE: Response Code 2501

> While I understand that the normal operating mode for EPP is
> client-initiated command/response, this is a special case 
> where the server
> initiates the action due to non-activity by a client. 
> Otherwise, the client
> will be left without any clue why the connection is gone.

Hong,

It's not just the "normal" operating mode, it's the _only_ operating mode
currently defined.  If the client is dead or otherwise hung, a clue isn't
going to help.

I'm OK with leaving this response code in if it might have some future
benefit (like if someone ever writes a draft describing server message
pushing ;-)), but as things are written currently I'd consider a server that
sends an unsolicited 2501 response to be non-conforming.

-Scott-

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Robert Burbidge'" <[email-masked]>, "Ietf-Provreg (E-mail)" <[email-masked]>
Subject: RE: Byte order marks and character sets
Date: Mon, 12 Aug 2002 13:47:42 -0400
Sender: [email-masked]

> See http://www.w3.org/TR/REC-xml#sec-guessing which mentions 
> BOM for UTF-8.
> My understanding of this is that a BOM does exist for UTF-8, 
> although the
> document is discussing non-normative interferencing of 
> character encodings.
> The .NET framework for example will generate the EF BB BF 
> UTF-8 BOM. A few
> minutes with Google also found
> http://www.unicode.org/unicode/faq/utf_bom.html#25.
> 
> My problem seems to be that no clients read the UTF-8 BOM. I 
> think they
> should understand it even if it's optional; that's what a 
> conforming XML
> parser should do. If I'm right, then the problem is not 
> strictly a problem
> with the EPP spec but with client implementations which is outside the
> strict scope of this discussion group but hey....

Hmm, OK, now I see what you're saying.  Sigh, if folks used XML declarations
this wouldn't be an issue...

This is an XML issue, not directly an EPP issue, but it could be described
in the EPP document since the normative references aren't quite clear.
Given that it's not a normative part of the XML recommendation and it's not
mentioned in RFC 2279 I'm not sure of the best way to address this at the
moment.  I'm going to ping some of the folks I worked with when writing my
IETF XML guidelines I-D to see what they have to say.

FWIW, I know of at least one XML parser that seems to digest a UTF-8 BOM
just fine: Xerces-J v2.0.2.  I just ran a quick test and it worked properly.

-Scott-

From: Robert Burbidge <[email-masked]>
To: "Ietf-Provreg (E-mail)" <[email-masked]>
Subject: RE: Byte order marks and character sets
Date: Mon, 12 Aug 2002 17:51:33 +0100
Sender: [email-masked]

>This is addressed in more detail in section 5, though perhaps a "UTF-8 is
>RECOMMENDED" would make things more clear.  I don't think it wise to say
>that only UTF-8 can be used as the protocol may clearly be useful in
>localized environments where something other than UTF-8 or UTF-16 might be
>more useful.

In that case perhaps you can add "UTF-8 is RECOMMENDED" in next draft.

> So what's your suggested improvement?  Section 4.3.3 of the XML rec (a
> normative reference) already says that "XML processors must be able to use
> this character to differentiate between UTF-8 and UTF-16 encoded
documents",
> and there's no mention of BOMs in RFC 2279 (UTF-8) so I don't know what
you
> mean by "the UTF-8 BOM".

See http://www.w3.org/TR/REC-xml#sec-guessing which mentions BOM for UTF-8.
My understanding of this is that a BOM does exist for UTF-8, although the
document is discussing non-normative interferencing of character encodings.
The .NET framework for example will generate the EF BB BF UTF-8 BOM. A few
minutes with Google also found
http://www.unicode.org/unicode/faq/utf_bom.html#25.

My problem seems to be that no clients read the UTF-8 BOM. I think they
should understand it even if it's optional; that's what a conforming XML
parser should do. If I'm right, then the problem is not strictly a problem
with the EPP spec but with client implementations which is outside the
strict scope of this discussion group but hey....

> Sorry, I don't see BOMs as a transport issue.  It's an encoding issue that
> should be addressed in the core document, and as far as I can tell it
> already is through the normative reference to the W3C XML recommendation.

I think you are correct on this point. I just felt that it was
insufficiently clear taking the document set as a whole.

Rob Burbidge

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Robert Burbidge'" <[email-masked]>, "Ietf-Provreg (E-mail)" <[email-masked]>
Subject: RE: Byte order marks and character sets
Date: Mon, 12 Aug 2002 12:30:14 -0400
Sender: [email-masked]

> 1. Page 5 of current draft says "EPP use with current 
> character sets other
> than UTF-8 is not described in the document". Is this meant 
> to imply that
> the current draft assumes UTF-8 for all XML document 
> interchange? If so it
> would be preferable to say so in explicit terms rather than the double
> negative at present.

This is addressed in more detail in section 5, though perhaps a "UTF-8 is
RECOMMENDED" would make things more clear.  I don't think it wise to say
that only UTF-8 can be used as the protocol may clearly be useful in
localized environments where something other than UTF-8 or UTF-16 might be
more useful.

> 2. Byte order marks are only considered in passing on page 76 
> in reference
> to RFC3023. This RFC is relevant and useful if an underlying 
> transport uses
> MIME headers for passing EPP documents around. However, I 
> don't think it
> offers any useful advice fo transports that don't have a MIME type or
> similar - such as the current TCP binding specification. Our 
> EPP server
> interprets incoming BOMs if the client provides them, and if no BOM is
> provided UTF-8 encoding is assumed. But when we generate 
> responses, should
> we provide the UTF-8 BOM or not? In an ideal world all 
> clients would have a
> conforming XML parser and it would not matter for UTF8 data. 
> However, having
> seen some of the published EPP clients it looks like no one 
> handles BOM
> correctly for server responses. [Note: if you have written a 
> client that
> does handle BOM correctly please accept my apologies!]

So what's your suggested improvement?  Section 4.3.3 of the XML rec (a
normative reference) already says that "XML processors must be able to use
this character to differentiate between UTF-8 and UTF-16 encoded documents",
and there's no mention of BOMs in RFC 2279 (UTF-8) so I don't know what you
mean by "the UTF-8 BOM".

> 3. TCP bindings section 5 "does not introduce or present any
> internationalization or localization issues". If we don't make the BOM
> situation explicit then we absolutely will be introducing 
> long term i18n
> issues for unicode (etc.) contact or domain names.

Sorry, I don't see BOMs as a transport issue.  It's an encoding issue that
should be addressed in the core document, and as far as I can tell it
already is through the normative reference to the W3C XML recommendation.

-Scott-

From: "Gould, James" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>
Subject: RE: Response Code 2501
Date: Mon, 12 Aug 2002 12:22:00 -0400
Sender: [email-masked]

Scott,

I don't see value in the 2501 response, since as you indicated the server is
not supposed to send an unsolicited response.  Even if the server sends the
response before closing the connection, the client will most likely not be
in a state to read it.  From a protocol perspective, simply closing the
connection would be more straight forward and would not introduce
unsolicited packets.  

Jim 

> ----------
> From: 	Hollenbeck, Scott
> Sent: 	Monday, August 12, 2002 10:52 AM
> To: 	[email-masked]'
> Subject: 	Response Code 2501
> 
> While working through the new state diagram to be added to the EPP core
> document, I had to ponder idle timeouts and they're addressed.  Right now
> there's an error code defined that allows a server to notify a client of a
> timeout situation:
> 
> 2501 "Timeout; server ending session"
> 
> Is this error code really needed, though?  Servers aren't supposed to send
> a
> response to a client without having first received a command, so if a
> client
> dies or creates a session that's been alive for "a long time" the server
> shouldn't be sending this as an unsolicited response.  It seems to make
> more
> sense in this case for the server to just close the connection, and if the
> client tries to write something it'll find the connection closed.
> 
> Thoughts?
> 
> FWIW this and the TCP header thing are the last two things I need to
> address
> before being able to release the updated documents.
> 
> -Scott-
> 
> 

From: "Ram Mohan" <[email-masked]>
To: "Liu, Hong" <[email-masked]>, <[email-masked]>
Subject: Re: Response Code 2501
Date: Mon, 12 Aug 2002 12:11:18 -0400
Organization: Afilias
Sender: [email-masked]

Liu, Scott:
>From a purist's (and standards-based) perspective, in a client-server model,
a server-initiated message is not appropriate.

Unsolicited server "responses" (it's not really a response if it's server
initiated, is it) should not be in the draft.

-ram

----- Original Message -----
From: "Liu, Hong" <[email-masked]>
To: <[email-masked]>
Sent: Monday, August 12, 2002 11:37 AM
Subject: RE: Response Code 2501

> Scott,
>
> I would prefer to keep this response code as an option for implementation.
> The command is useful for the server to notify the client that it is
closing
> down the idle connection and this is the last message from the server.
>
> While I understand that the normal operating mode for EPP is
> client-initiated command/response, this is a special case where the server
> initiates the action due to non-activity by a client. Otherwise, the
client
> will be left without any clue why the connection is gone.
>
> --Hong
>
> -----Original Message-----
> From: Hollenbeck, Scott [mailto:[email-masked]]
> Sent: Monday, August 12, 2002 10:52 AM
> To: [email-masked]'
> Subject: Response Code 2501
>
>
> While working through the new state diagram to be added to the EPP core
> document, I had to ponder idle timeouts and they're addressed.  Right now
> there's an error code defined that allows a server to notify a client of a
> timeout situation:
>
> 2501 "Timeout; server ending session"
>
> Is this error code really needed, though?  Servers aren't supposed to send
a
> response to a client without having first received a command, so if a
client
> dies or creates a session that's been alive for "a long time" the server
> shouldn't be sending this as an unsolicited response.  It seems to make
more
> sense in this case for the server to just close the connection, and if the
> client tries to write something it'll find the connection closed.
>
> Thoughts?
>
> FWIW this and the TCP header thing are the last two things I need to
address
> before being able to release the updated documents.
>
> -Scott-
>

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Robert Burbidge'" <[email-masked]>, "Ietf-Provreg (E-mail)" <[email-masked]>
Subject: RE: Header in TCP Mapping
Date: Mon, 12 Aug 2002 12:00:18 -0400
Sender: [email-masked]

> 2. Speaking as a pragmatist, I would suggest leaving things 
> as they are.
> There's no real benefit in the change except from the purist 
> point of view,
> and I'm in the final stages of getting a server up right now. 
> If it changes
> in the next draft, then I and my clients will have to make 
> one more change
> to live software with no net benefit. I'm all for improving the
> specification, but please bear in mind that there are several
> implementations based on drafts out there already. I realise 
> that when EPP
> gets finally approved, we will all be obliged to upgrade to the final
> release, but let's keep things as simple as possible in the meantime.

While I appreciate what you're saying, we can't let implementations to I-Ds
dictate what we can or can't do to get the specifications finished.  Having
said that, though, I'm inclined to leave things as-is unless someone comes
up with a real compelling reason for the change.

-Scott-

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Liu, Hong'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Response Code 2501
Date: Mon, 12 Aug 2002 11:57:30 -0400
Sender: [email-masked]

> While I understand that the normal operating mode for EPP is
> client-initiated command/response, this is a special case 
> where the server
> initiates the action due to non-activity by a client. 
> Otherwise, the client
> will be left without any clue why the connection is gone.

Hong,

It's not just the "normal" operating mode, it's the _only_ operating mode
currently defined.  If the client is dead or otherwise hung, a clue isn't
going to help.

I'm OK with leaving this response code in if it might have some future
benefit (like if someone ever writes a draft describing server message
pushing ;-)), but as things are written currently I'd consider a server that
sends an unsolicited 2501 response to be non-conforming.

-Scott-

From: Robert Burbidge <[email-masked]>
To: "Ietf-Provreg (E-mail)" <[email-masked]>
Subject: Byte order marks and character sets
Date: Mon, 12 Aug 2002 16:40:32 +0100
Sender: [email-masked]

I find the current state of documentation regarding character sets and byte
order marks somewhat unsatisfactory. 

1. Page 5 of current draft says "EPP use with current character sets other
than UTF-8 is not described in the document". Is this meant to imply that
the current draft assumes UTF-8 for all XML document interchange? If so it
would be preferable to say so in explicit terms rather than the double
negative at present.

2. Byte order marks are only considered in passing on page 76 in reference
to RFC3023. This RFC is relevant and useful if an underlying transport uses
MIME headers for passing EPP documents around. However, I don't think it
offers any useful advice fo transports that don't have a MIME type or
similar - such as the current TCP binding specification. Our EPP server
interprets incoming BOMs if the client provides them, and if no BOM is
provided UTF-8 encoding is assumed. But when we generate responses, should
we provide the UTF-8 BOM or not? In an ideal world all clients would have a
conforming XML parser and it would not matter for UTF8 data. However, having
seen some of the published EPP clients it looks like no one handles BOM
correctly for server responses. [Note: if you have written a client that
does handle BOM correctly please accept my apologies!]

3. TCP bindings section 5 "does not introduce or present any
internationalization or localization issues". If we don't make the BOM
situation explicit then we absolutely will be introducing long term i18n
issues for unicode (etc.) contact or domain names.

This may also have some bearing on the current discussions surrounding
international postal addresses, although this is not my field of expertise
... I'll leave it for others to consider.

Rob Burbidge

From: "Liu, Hong" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Response Code 2501
Date: Mon, 12 Aug 2002 11:37:08 -0400
Sender: [email-masked]

Scott,

I would prefer to keep this response code as an option for implementation.
The command is useful for the server to notify the client that it is closing
down the idle connection and this is the last message from the server.

While I understand that the normal operating mode for EPP is
client-initiated command/response, this is a special case where the server
initiates the action due to non-activity by a client. Otherwise, the client
will be left without any clue why the connection is gone.

--Hong

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: Monday, August 12, 2002 10:52 AM
To: [email-masked]'
Subject: Response Code 2501

While working through the new state diagram to be added to the EPP core
document, I had to ponder idle timeouts and they're addressed.  Right now
there's an error code defined that allows a server to notify a client of a
timeout situation:

2501 "Timeout; server ending session"

Is this error code really needed, though?  Servers aren't supposed to send a
response to a client without having first received a command, so if a client
dies or creates a session that's been alive for "a long time" the server
shouldn't be sending this as an unsolicited response.  It seems to make more
sense in this case for the server to just close the connection, and if the
client tries to write something it'll find the connection closed.

Thoughts?

FWIW this and the TCP header thing are the last two things I need to address
before being able to release the updated documents.

-Scott-

From: Robert Burbidge <[email-masked]>
To: "Ietf-Provreg (E-mail)" <[email-masked]>
Subject: RE: Header in TCP Mapping
Date: Mon, 12 Aug 2002 16:24:08 +0100
Sender: [email-masked]

I have two conflicting responses to this, based on what hat I'm wearing at
the time.

1. Speaking as a purist, it seems sensible to change the length byte as you
suggest. When implementing the first prototype of our EPP server, my
datagram lengths were out by 4 because it simply did not occur to me that it
would be implemented as described in current drafts.

2. Speaking as a pragmatist, I would suggest leaving things as they are.
There's no real benefit in the change except from the purist point of view,
and I'm in the final stages of getting a server up right now. If it changes
in the next draft, then I and my clients will have to make one more change
to live software with no net benefit. I'm all for improving the
specification, but please bear in mind that there are several
implementations based on drafts out there already. I realise that when EPP
gets finally approved, we will all be obliged to upgrade to the final
release, but let's keep things as simple as possible in the meantime. 

Rob Burbidge
Poptel

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: 12 August 2002 13:13
To: [email-masked]'
Subject: Header in TCP Mapping

I've received a private comment about the EPP header as currently described
in the TCP mapping draft.  Here's what it currently says:

"Total Length (32 bits): The total length of the EPP datagram measured
in octets.  The octets contained in this field MUST be included in the
total length calculation."

and here's what I was planning on changing it to:

"Total Length (32 bits): The total length of the EPP data unit measured
in octets in network (big endian) byte order.  The octets contained in
this field MUST be included in the total length calculation."

The comment (really a question) was along the lines of "why do we need to
include the 4 octets for the length field in the total length calculation?"
I'm not sure that there is any real value, but before I change the wording
I'd like to ask if anyone does see any value in always adding those 4 octets
to the total length.  In short, if we have an XML instance that contains 200
octets, is it better to have the length field say "200" or "204"?

-Scott-

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Stephane Bortzmeyer'" <[email-masked]>, [email-masked]
Subject: RE: [[email-masked]: [open-eu] Open Registry Robot  / EPP transport layer]
Date: Mon, 12 Aug 2002 11:00:32 -0400
Sender: [email-masked]

> Sent on a public mailing list of CORE so I assume I can redistribute
> it.

Well, this is certainly the right mailing list to discuss EPP I-Ds.  It
would be nice if we could have the discussion here.

I also hope the authors are well-versed on current IETF thinking around use
of HTTP as a substrate as it has been hotly debated in the IETF in the past:

ftp://ftp.isi.edu/in-notes/rfc3205.txt

-Scott-

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Response Code 2501
Date: Mon, 12 Aug 2002 10:52:12 -0400
Sender: [email-masked]

While working through the new state diagram to be added to the EPP core
document, I had to ponder idle timeouts and they're addressed.  Right now
there's an error code defined that allows a server to notify a client of a
timeout situation:

2501 "Timeout; server ending session"

Is this error code really needed, though?  Servers aren't supposed to send a
response to a client without having first received a command, so if a client
dies or creates a session that's been alive for "a long time" the server
shouldn't be sending this as an unsolicited response.  It seems to make more
sense in this case for the server to just close the connection, and if the
client tries to write something it'll find the connection closed.

Thoughts?

FWIW this and the TCP header thing are the last two things I need to address
before being able to release the updated documents.

-Scott-

From: "Gould, James" <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Header in TCP Mapping
Date: Mon, 12 Aug 2002 10:51:02 -0400
Sender: [email-masked]

Scott,

I would prefer that the total length not include the 4 octets, since the
client and server would have to subtract 4 from the total length to
determine how much to read.  Including the 4 octets in the total length
provides no value.   

Jim

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: Monday, August 12, 2002 8:13 AM
To: [email-masked]'
Subject: Header in TCP Mapping

I've received a private comment about the EPP header as currently described
in the TCP mapping draft.  Here's what it currently says:

"Total Length (32 bits): The total length of the EPP datagram measured
in octets.  The octets contained in this field MUST be included in the
total length calculation."

and here's what I was planning on changing it to:

"Total Length (32 bits): The total length of the EPP data unit measured
in octets in network (big endian) byte order.  The octets contained in
this field MUST be included in the total length calculation."

The comment (really a question) was along the lines of "why do we need to
include the 4 octets for the length field in the total length calculation?"
I'm not sure that there is any real value, but before I change the wording
I'd like to ask if anyone does see any value in always adding those 4 octets
to the total length.  In short, if we have an XML instance that contains 200
octets, is it better to have the length field say "200" or "204"?

-Scott-

Date: Mon, 12 Aug 2002 16:26:37 +0200
From: Stephane Bortzmeyer <[email-masked]>
To: [email-masked]
Subject: [[email-masked]: [open-eu] Open Registry Robot / EPP transport layer]
Organization: NIC France
Sender: [email-masked]

--PEIAKu/WMn1b1Hv9
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Sent on a public mailing list of CORE so I assume I can redistribute
it.

--PEIAKu/WMn1b1Hv9
Content-Type: message/rfc822
Content-Disposition: inline

Subject: [open-eu] Open Registry Robot / EPP transport layer
From: Sven-Holger Wabnitz <[email-masked]>
To: open-eu discuss <[email-masked]>
Date: 09 Aug 2002 14:05:11 +0200
Sender: [email-masked]
Reply-To: [email-masked]

--=-0YG9PI5W1amZCUT6xi5q
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Dear all,

to run the registry for .eu technically, we decided to build
an open source registry robot based on EPP.

In various discussions there was formed the idea of another
transport layer for EPP parallel to BEEP and Email. The
new transport layer follows the idea to use an existing document
encapsulation framework. Another advantage is the possibility
for registrars to communicate directly with the registry robot
with a http-client.

The idea is to use http and https, respectively, as an connectionles
protocol contrarious to BEEP. Attached you find a first draft
for EPP over http.

It can be discussed how the authentication, the user identification
for registrars and their resellers (a nice feature), will be handled:
via user specific URI or via http-post method.

It is very important, that the application (EPP) specific tasks
are NOT shifted to the transport layer (<creds> Element see epp 2.4).

Now one of the important things is how the response is handled:
-> the (registry)server establishes a connection to the
   (registrar)server.
   -> the hostname is known by the registry.
   -> the hostname is given by the registrar to the registry
      via EPP, see Cap. 2.6 "Extension Framework"
-> the client (registrar) polls the data. The problem here is,
   that the answer is not expicit assigned to an command. The
   answer to a poll command has the <trId> of the poll command.

Another problem of the poll command is the higher traffic. The
registrar doesn' know when to poll, there are polling in vain,
the other point is that one poll command has three times more
traffic: the poll request, the answer and the acknowledge to
the answer!
I think we have to handle a handshake (not EPP handshake) at
the underlying layer.

Please note that this is work in progress. Some comments?

Regards
Sven-Holger Wabnitz

cut --- cut --- cut --- cut --- cut --- cut --- cut --- cut ---=20

         Extensible Provisioning Protocol Transport over HTTP
                       <draft-epp-http-00.txt>

Status of this Memo

  This document is an Internet-Draft and is NOT offered in
  accordance with Section 10 of RFC2026, and the author does not
  provide the IETF with any rights other than to publish as an
  Internet-Draft
 =20
  Internet-Drafts are working documents of the Internet Engineering
  Task Force (IETF), its areas, and its working groups.  Note that
  other groups may also distribute working documents as
  Internet-Drafts.

  Internet-Drafts are draft documents valid for a maximum of six
  months and may be updated, replaced, or obsoleted by other
  documents at any time.  It is inappropriate to use Internet-
  Drafts as reference material or to cite them other than as
  "work in progress."

  The list of current Internet-Drafts can be accessed at
  http://www.ietf.org/1id-abstracts.html

  The list of Internet-Draft Shadow Directories can be accessed at
  http://www.ietf.org/shadow.html

Abstract
 =20
  This document describs how an Extensible Provisioning Protocol (EPP)
  is used over the connection-less Hypertext Transfer Protocol
  (HTTP/1.1). This mapping requires use of the Transport Layer
  Security (TLS) protocol to protect information exchanged between an
  EPP client and an EPP server.

1. Introduction
 =20
  This document describes how the Extensible Provisioning Protocol
  (EPP) is mapped onto client-server connections using the Hypertext
  Transfer Protocol (HTTP). Security services beyond those described=20
  in EPP are provided by the Transport Layer Security (TLS) Protocol
  [RFC2246]. EPP is described in [EPP]. HTTP is described in [RFC2616].

  Both parties the EPP server and the EPP Client will act as a HTTP
  server and a HTTP client. The client will transmit an EPP command=20
  by a HTTP request. The HTTP response MUST inform the client about=20
  the status of the command transmission. The result code of the=20
  command will be delivered over an HTTP request originated by the=20
  EPP Server.

  In summary we describe a connection less communication between an
  EPP server and an EPP client without the need of polling the result
  code of the requests.

x. References

  Norminative References

  [EPP] S. Hollenbeck: "Extensible Provisioning Protocol", work in
  progress.

  [RFC2246] T. Dierks and C. Allen: "The TLS Protocol Version 1.0", RFC
  2246, January 1999.

  [RFC2616] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter,
  P. Leach, T. Berners-Lee: "Hypertext Transfer Protocol -- HTTP/1.1",
  RFC2616, June 1999.=20

cut --- cut --- cut --- cut --- cut --- cut --- cut --- cut ---=20

--=20
___________________________________________________________________

Sven-Holger Wabnitz   DSS Gesellschaft fuer Digitale Sicherheit mbH
phone +49 2222 990-0            **             fax +49 2222 990-444
http://www.digital-security.com **            http://www.dominic.de

>From the Portland Pattern Repository (de facto home of the
extreme programming discipline), hosted by Cunningham & Cunningham.

        "Life's too short to write code that nobody wants."

--=-0YG9PI5W1amZCUT6xi5q
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: Dies ist ein digital signierter Nachrichtenteil

--=-0YG9PI5W1amZCUT6xi5q--

--
Wish to unsubscribe to [email-masked] or need other help?
echo "help" | mailx [email-masked]

--PEIAKu/WMn1b1Hv9--

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Header in TCP Mapping
Date: Mon, 12 Aug 2002 08:13:05 -0400
Sender: [email-masked]

I've received a private comment about the EPP header as currently described
in the TCP mapping draft.  Here's what it currently says:

"Total Length (32 bits): The total length of the EPP datagram measured
in octets.  The octets contained in this field MUST be included in the
total length calculation."

and here's what I was planning on changing it to:

"Total Length (32 bits): The total length of the EPP data unit measured
in octets in network (big endian) byte order.  The octets contained in
this field MUST be included in the total length calculation."

The comment (really a question) was along the lines of "why do we need to
include the 4 octets for the length field in the total length calculation?"
I'm not sure that there is any real value, but before I change the wording
I'd like to ask if anyone does see any value in always adding those 4 octets
to the total length.  In short, if we have an XML instance that contains 200
octets, is it better to have the length field say "200" or "204"?

-Scott-

Date: Thu, 8 Aug 2002 17:59:44 +0700
From: Budi Rahardjo <[email-masked]>
Cc: [email-masked]
Subject: Re: Sending the original (Unicode) domain name as well as the ACE ?
Sender: [email-masked]

On Thu, Aug 08, 2002 at 10:11:32AM +0200, Elisabeth Porteneuve wrote:
...
> The nature of a postal address is that is might be used to send 
> a _paper_ letter. Then a person in, say Italy, will have to write 
> it on a paper and post to, say Korea. 

Hi Elisabeth,
I understand what you're saying. You are correct if a person
in Korea wants to communicate with a person in Italy (or vice versa).
But, it doesn't have to be that way for a person in Korea who
wants to communicate with another person in Korea.
S/he may not really care about other people in other parts of the world.
Perhaps a similar situation may also happen in China, Taiwan,
Arabic countries, and so on.

It doesn't make sense to *force* them to use our alphabet
if they just want to communicate internally, does it?

> We do not speak here about content of letters, or content of websites.

No, I am not talking the content of a letter.
I am thinking of the address.

In China, Taiwan, Japan, etc... they can write the *address*
with their own characters on the envelope, can't they?
Or do they *have* to write in "our" alphanumeric characters? ;-)
Of course, the letters may not make sense to us, but it is not
intended to us anyway.

> The intent of my message was to recall that LDH used in postal address 
> is not to prevent people to communicate, neither to dominate them, 
> but exactly the opposite, to permit international communication happen.

As long as it does not *force* people to do one way.
They know that using their own characters may restrict international
communication, but that's their choice.
We shouldn't ram it down to their throats ;-)
(figure of speach of course)

I hope my explanation is clear.
Or ... create more confusion, as usual...

Regards
-- budi

Date: Thu, 8 Aug 2002 10:11:32 +0200 (MET DST)
From: Elisabeth Porteneuve <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Sending the original (Unicode) domain name as well as the ACE ?
Sender: [email-masked]

Budi Rahardjo <[email-masked]> wrote:
> > > The UPU, established in 1874, (http://www.upu.int/) provides postal 
> > > addresses in English for every country.
> > > 
> > > The very basic reason is that the common lowest dominator is needed
> > > to ensure the postmen worldwide read postal addresses, and put 
> > > enveloppes in appropriate bag to be delivered in appropriate country.
> > > 
> > > We better have the postal address information in EPP that
> > > respects the UPU conventions.
> 
> It's fine as long as EPP supports "other forms" of addresses.
> That is, it is possible for a country/region to use EPP with
> their own characters (whatever that be).
> There are many cases of people who cannot read & write English
> and still want to use Internet (and don't care about English
> emails/pages/and so on). They want to communicate internally
> (within their region), have their own domain names, 
> email addresses, etc.
> 
> 
> -- budi
> 

The nature of a postal address is that is might be used to send 
a _paper_ letter. Then a person in, say Italy, will have to write 
it on a paper and post to, say Korea. Whatever country/region
approach, we shall have provision for it.
You have then to ensure few things: (1) that a correspondent staying
in Italy can correctly write on a paper, (2) that Italian postmen 
can put that paper letter to an appropriate bag and route it to Korea,
and (3) that Korean postmen can read and understand the address.

We do not speak here about content of letters, or content of websites.
If any comparison, postal addresses are much closer to airport 
names and flights numbers. It is papa-tango-charlie Esperanto 
which allows for international communication.

The intent of my message was to recall that LDH used in postal address 
is not to prevent people to communicate, neither to dominate them, 
but exactly the opposite, to permit international communication happen.

Elisabeth

Date: Thu, 8 Aug 2002 06:11:25 +0700
From: Budi Rahardjo <[email-masked]>
To: [email-masked]
Subject: Re: Sending the original (Unicode) domain name as well as the ACE ?
Sender: [email-masked]

> > The UPU, established in 1874, (http://www.upu.int/) provides postal 
> > addresses in English for every country.
> > 
> > The very basic reason is that the common lowest dominator is needed
> > to ensure the postmen worldwide read postal addresses, and put 
> > enveloppes in appropriate bag to be delivered in appropriate country.
> > 
> > We better have the postal address information in EPP that
> > respects the UPU conventions.

It's fine as long as EPP supports "other forms" of addresses.
That is, it is possible for a country/region to use EPP with
their own characters (whatever that be).
There are many cases of people who cannot read & write English
and still want to use Internet (and don't care about English
emails/pages/and so on). They want to communicate internally
(within their region), have their own domain names, 
email addresses, etc.

-- budi

Date: Wed, 7 Aug 2002 19:23:30 +0200
From: Olivier Guillard / AFNIC <[email-masked]>
To: [email-masked]
Cc: Jim Reid <[email-masked]>
Subject: Re: Sending the original (Unicode) domain name as well as the ACE ?
Sender: [email-masked]

le mercredi 07 ao�t � 08 H 56 , Jim Reid a �crit :
> This is a very good suggestion. It also gets us (or maybe IANA) off
> the hook of deciding what is and isn't a country.

supporting unicode give the solution to another question:
what is and isn't a letter.

(by the way upu give also an answer to that question)

-- 
Olivier

To: Elisabeth Porteneuve <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Sending the original (Unicode) domain name as well as the ACE ? 
Date: Wed, 07 Aug 2002 08:56:10 -0700
From: Jim Reid <[email-masked]>
Sender: [email-masked]

>>>>> "Elisabeth" == Elisabeth Porteneuve <[email-masked]> writes:

    Elisabeth> We better have the postal address information in EPP
    Elisabeth> that respects the UPU conventions.

This is a very good suggestion. It also gets us (or maybe IANA) off
the hook of deciding what is and isn't a country.

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Elisabeth Porteneuve'" <[email-masked]>, [email-masked]
Subject: RE: Sending the original (Unicode) domain name as well as the ACE ?
Date: Wed, 7 Aug 2002 11:27:19 -0400 
Sender: [email-masked]

> Sorry for jumping in with non-technical comment.
> 
> The UPU, established in 1874, (http://www.upu.int/) provides postal 
> addresses in English for every country.
> 
> The very basic reason is that the common lowest dominator is needed
> to ensure the postmen worldwide read postal addresses, and put 
> enveloppes in appropriate bag to be delivered in appropriate country.
> 
> We better have the postal address information in EPP that
> respects the UPU conventions.

To quote from an old American tomato sauce television advertisement, "It's
in there!".

-Scott-

Date: Wed, 7 Aug 2002 17:20:16 +0200 (MET DST)
From: Elisabeth Porteneuve <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: RE: Sending the original (Unicode) domain name as well as the ACE ?
Sender: [email-masked]

Sorry for jumping in with non-technical comment.

The UPU, established in 1874, (http://www.upu.int/) provides postal 
addresses in English for every country.

The very basic reason is that the common lowest dominator is needed
to ensure the postmen worldwide read postal addresses, and put 
enveloppes in appropriate bag to be delivered in appropriate country.

We better have the postal address information in EPP that
respects the UPU conventions.

Elisabeth Porteneuve

=================================================================
  - One or two <contact:postalInfo> elements that contain postal address
  information.  Two elements are provided so that address information
  can be provided in both internationalized and localized forms.  If an
  internationalized form is provided, it MUST be listed first and
  element content MUST be represented in a subset of UTF-8 that can be
  represented in the 7-bit US-ASCII character set.  If a localized form
  is provided, element content MAY be represented in unrestricted UTF-8.
  The <contact:postalInfo> element contains the following child
  elements:

> From: "Hollenbeck, Scott" <[email-masked]>
> To: "'Stephane Bortzmeyer'" <[email-masked]>, [email-masked]
> Subject: RE: Sending the original (Unicode) domain name as well as the ACE
> 	?
> Date: Wed, 7 Aug 2002 10:17:01 -0400 
> 
> > I'm curious about the rationale. Why not just accepting Unicode and
> > translating it to ASCII when necessary? Is it because automatic
> > transliteration of Unicode to ASCII is quite difficult so we prefer
> > that the registrar does it?
> 
> In the contact context such translations are likely impossible to do
> automatically.  The two forms are allowed because the contact might prefer
> to have both internationalized and localized forms of the information
> available for display purposes, and a translation between the two forms
> might not be possible.
> 
> In the domain context the conversions are quite possible and relatively
> easy, so they can be done wherever it makes the most sense for a given
> provisioning environment.
> 
> -Scott-
> 

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Stephane Bortzmeyer'" <[email-masked]>, [email-masked]
Subject: RE: Sending the original (Unicode) domain name as well as the ACE ?
Date: Wed, 7 Aug 2002 10:17:01 -0400 
Sender: [email-masked]

> I'm curious about the rationale. Why not just accepting Unicode and
> translating it to ASCII when necessary? Is it because automatic
> transliteration of Unicode to ASCII is quite difficult so we prefer
> that the registrar does it?

In the contact context such translations are likely impossible to do
automatically.  The two forms are allowed because the contact might prefer
to have both internationalized and localized forms of the information
available for display purposes, and a translation between the two forms
might not be possible.

In the domain context the conversions are quite possible and relatively
easy, so they can be done wherever it makes the most sense for a given
provisioning environment.

-Scott-

Date: Wed, 7 Aug 2002 16:09:48 +0200
From: Patrick <[email-masked]>
To: [email-masked]
Subject: Re: Sending the original (Unicode) domain name as well as the ACE?
Organization: Gandi
Sender: [email-masked]

On Wed, Aug 07, 2002 at 03:42:36PM +0200, Stephane Bortzmeyer took time to write:
> I'm curious about the rationale. Why not just accepting Unicode and
> translating it to ASCII when necessary? Is it because automatic

How do you translate Chinese and Japanese and many other characters
available in Unicode to ASCII ?

> transliteration of Unicode to ASCII is quite difficult so we prefer
> that the registrar does it?

There were threads about this in the past.
I remember vaguely that there was something about putting only ASCII
in whois, since Unicode in that would probably break many clients.

Patrick.

Date: Wed, 7 Aug 2002 15:42:36 +0200
From: Stephane Bortzmeyer <[email-masked]>
To: [email-masked]
Subject: Re: Sending the original (Unicode) domain name as well as the ACE?
Organization: NIC France
Sender: [email-masked]

On Tue, Aug 06, 2002 at 09:03:50AM +0200,
 Stephane Bortzmeyer <[email-masked]> wrote 
 a message of 16 lines which said:

> it could be a good idea, for the registry, to store the original
> (Unicode) form of an IDN, as well as its ACE (ASCII-encoded) form. 
...
> Am I correct when reading draft-ietf-provreg-epp-domain-04.txt that it
> contains nothing about transmitting the original form from the
> registrar, which knows it, to the registry?

Funny, but I did not notice yet that
draft-ietf-provreg-epp-contact-04.txt (which does not deal with IDN at
all) suggests exactly that for contact information.

  - One or two <contact:postalInfo> elements that contain postal address
  information.  Two elements are provided so that address information
  can be provided in both internationalized and localized forms.  If an
  internationalized form is provided, it MUST be listed first and
  element content MUST be represented in a subset of UTF-8 that can be
  represented in the 7-bit US-ASCII character set.  If a localized form
  is provided, element content MAY be represented in unrestricted UTF-8.
  The <contact:postalInfo> element contains the following child
  elements:

I'm curious about the rationale. Why not just accepting Unicode and
translating it to ASCII when necessary? Is it because automatic
transliteration of Unicode to ASCII is quite difficult so we prefer
that the registrar does it?

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: FW: Lack of reference client Implementation for  EPP 6 / TCP 4
Date: Wed, 7 Aug 2002 09:17:44 -0400
Importance: Normal
Sender: [email-masked]

FYI all,

Liberty RMS will be offering the following contributions to the
SourceForge project.

Within the next few weeks:

A 6/4 Open SSL EPP client (also supports legacy versions of the
protocol).  This client is useful for both compliance and load-testing.
We will also provide a low-level 6/4 C client.  This client is useful
for low-level unit testing. 

We are also currently working on a upgrade to the public EPP sandbox
server for 6/4.  We expect to promote this server in the near future.
We hope the community will find these efforts helpful, and we look
forward to any feedback you have to offer.

Michael Young

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: RE: Lack of reference client Implementation for  EPP 6 / TCP 4
Date: Wed, 7 Aug 2002 09:00:31 -0400
Importance: Normal
Sender: [email-masked]

FYI all,

Liberty RMS will be offering the following contributions to the
SourceForge project.

Within the next few weeks:

A 6/4 Open SSL EPP client (also supports legacy versions of the
protocol).  This client is useful for both compliance and load-testing.
We will also provide a low-level 6/4 C client.  This client is useful
for low-level unit testing. 

We are also currently working on a upgrade to the public EPP sandbox
server for 6/4.  We expect to promote this server in the near future.
We hope the community will find these efforts helpful, and we look
forward to any feedback you have to offer.

Michael Young

Date: Tue, 6 Aug 2002 20:38:31 +0200
From: Patrick <[email-masked]>
To: [email-masked]
Subject: Re: Lack of reference client Implementation for  EPP 6 / TCP 4
Organization: Gandi
Sender: [email-masked]

On Tue, Aug 06, 2002 at 02:05:08PM -0400, Daniel Manley took time to write:
> Tucows has been pretty quiet lately on the SourceForge epp-rtk front. 
> Being the main Tucows developer on this project, I can explain this by 
> me being occupied with some other non-domain/registry work.  The other 
> main developers, Asbjorn and Vidar, who are from GNR (.name), have 
> understandably been busy lately with the recent release of their live 
> registry.  
> 
> In the past, we've released RTK versions as registries launch with new 
> versions of EPP -- those have been .info, .biz and .name.  I see from 
> Stuart's email that .coop is up to bat now, and I have also heard 
> rumours of some ccTLDs launching with EPP 06/04.  So, we will start the 
> development of the next release of the RTKs (Java and C++) for 06/04.

Alternatively, please note, that we will soon make available a Perl
OO toolkit implementing EPP (as well as RRP) among other things, and
handling transparently all known EPP versions (excluding 06/04 since
no live Registry use it for now) : you just give it an EPP version
number (sort of), and it handles internally changes needed.

This exact code is used in production as interface to 4 Registries (1
RRP, and 3 EPP all three using a distinct EPP version) for ``high''
volume.

Sorry if you think this is not appropriate, but I felt this may be of
interest to some of you.
It will be available under the GPL.
Support for EPP 06/04 should be easy to add in the current framework,
and anyone will be welcome to help as soon as it is released.

BTW it is a toolkit to build an EPP/RRP/X client (as used now), but
we also plan to build a server on top of it as free software (this
way a thread lately I recall), or a least a toolkit for a server.

After it being available, I will be happy to participate in any
interoperabilty tests (since that is in the milestones).
Please note however that I am still an IETF rookie, so do not
hesitate to educate me in this aspect ;-)

Patrick.

Date: Tue, 06 Aug 2002 14:05:08 -0400
From: Daniel Manley <[email-masked]>
To: [email-masked]
Subject: Re: Lack of reference client Implementation for  EPP 6 / TCP 4
Sender: [email-masked]

Tucows has been pretty quiet lately on the SourceForge epp-rtk front. 
 Being the main Tucows developer on this project, I can explain this by 
me being occupied with some other non-domain/registry work.  The other 
main developers, Asbjorn and Vidar, who are from GNR (.name), have 
understandably been busy lately with the recent release of their live 
registry.  

In the past, we've released RTK versions as registries launch with new 
versions of EPP -- those have been .info, .biz and .name.  I see from 
Stuart's email that .coop is up to bat now, and I have also heard 
rumours of some ccTLDs launching with EPP 06/04.  So, we will start the 
development of the next release of the RTKs (Java and C++) for 06/04.

Dan

Hollenbeck, Scott wrote:

>>The new datagram format described in TCP-04 describes the new header,
>>however it is silent out how the record is terminated, however
>>epp-rtk-java expects a <CR><NL> terminator.
>>    
>>
>
>Seems like a bogus requirement to me because as far as I can tell the specs
>are quite clear.  Section 3 of the TCP draft notes that the record is
>terminated with a </epp> element, and Section 4 of the TCP draft says that
>the record contains "the EPP XML instance".  Section 2.1 of the core draft
>also describes the start and end elements.  There's no mention of a <CR><NL>
>terminator anywhere.
>
>Anyway, the idea of a reference implementation is a good one.  Someone just
>has to write, release, and maintain it.
>
>-Scott-
>  
>

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

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Stuart Marsden'" <[email-masked]>, [email-masked]
Subject: RE: Lack of reference client Implementation for  EPP 6 / TCP 4 
Date: Tue, 6 Aug 2002 12:59:46 -0400 
Sender: [email-masked]

> The new datagram format described in TCP-04 describes the new header,
> however it is silent out how the record is terminated, however
> epp-rtk-java expects a <CR><NL> terminator.

Seems like a bogus requirement to me because as far as I can tell the specs
are quite clear.  Section 3 of the TCP draft notes that the record is
terminated with a </epp> element, and Section 4 of the TCP draft says that
the record contains "the EPP XML instance".  Section 2.1 of the core draft
also describes the start and end elements.  There's no mention of a <CR><NL>
terminator anywhere.

Anyway, the idea of a reference implementation is a good one.  Someone just
has to write, release, and maintain it.

-Scott-

From: "Stuart Marsden" <[email-masked]>
To: <[email-masked]>
Subject: Lack of reference client Implementation for  EPP 6 / TCP 4 
Date: Tue, 6 Aug 2002 17:29:59 +0100
Importance: Normal
Sender: [email-masked]

Hi,

Following my posting at the weekend and the lack of a concrete response,
I am concerned that not keeping a client reference implementation for
the current EPP spec available is going to cause problems in the short /
medium term.

My concern is two fold, 

1st it is going to make problem resolution harder in the long run as
registries / registrars up spec and compatibility problems arise.

2nd it helps identify any omissions in the specification. 

I can give a concrete example of the 2nd pt.

The new datagram format described in TCP-04 describes the new header,
however it is silent out how the record is terminated, however
epp-rtk-java expects a <CR><NL> terminator.

I can imagine how EPP implementation politics would act against having a
single reference implementation, however I do believe now all the macho
froth is going / has gone out of the registry business it would be worth
looking at ways to address this.

I guess I feel strongly enough about it, that if necessary dot coop will
do it, otherwise I have nothing to bolt my verification extensions to.

Stuart

Date: Tue, 6 Aug 2002 17:31:18 +0200
From: Patrick <[email-masked]>
To: [email-masked]
Subject: Re: Sending the original (Unicode) domain name as well as the ACE?
Organization: Gandi
Sender: [email-masked]

On Tue, Aug 06, 2002 at 02:06:32PM +0200, Stephane Bortzmeyer took time to write:
> > > > since epp's char set is utf8 i see no reason why a native utf name
> > > > cound't be enclosed in <domain:name> insted of the ace name.
> > 
> > I totally agree with Rick's comments.
> 
> In theory, yes. In practice, it is probably fair to assume that few
> EPP servers will be happy with Unicode. I just tried on LibertyRMS
> testbed and I got:

The fact that it is already now possible with the EPP protocol, does
not mean necessarily that
1) there are EPP implementations out there that support it
2) there are policies that accept it.

It is just possible.

I suspect that when the idn IETG wg will finish its work, new
Registries will start accepting IDN registrations, and thus make sure
that their EPP software and that their policies are ok with that.

Patrick.

Date: Tue, 6 Aug 2002 09:09:31 -0400
To: "Hollenbeck, Scott" <[email-masked]>, "'Liu, Hong'" <[email-masked]>, [email-masked]
From: Edward Lewis <[email-masked]>
Subject: RE: Login Failure and Sessions
Sender: [email-masked]

For what it matters, speaking as a state machinist and not as the chair:

        |
        |  /-------------------\
        |  |                   |
        v  v                   |
    +-------+                  |
    | login |--fail < N tries--/
    +-------+
     |     |
  success  fail
     |     >= N tries
     |     \
     |      ------------------>
     v

This is roughly how I would draw option 2 - not that I am suggesting 
that option 2 is the preferred solution.  This is a shorthand, 
strictly speaking you shouldn't have state (the value of N) on the 
arcs.  But I think this would fly in a protocol specification.

At 3:41 PM -0400 8/5/02, Hollenbeck, Scott wrote:
>>  I understand your concerns, but the retrial number N is really a
>>  configuration parameter. It is not unusual to leave this type
>>  of parameters
>>  for run-time configuration, take the windowing protocol as an
>>  example. The
>>  size of the window is not fixed in the spec.
>
>You didn't address the problem I presented: the need to craft a
>deterministic state diagram.  If what you're saying, though, is that you
>prefer option 2 (blast the connection after N failures) with the value of N
>(0 <= N <= inf) to be determined by the server operator, I can work with
>that.  That's at least easier to describe formally than "it's a policy
>issue". ;-)
>
>-Scott-

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

Date: Tue, 6 Aug 2002 14:06:32 +0200
From: Stephane Bortzmeyer <[email-masked]>
To: Patrick <[email-masked]>
Cc: [email-masked]
Subject: Re: Sending the original (Unicode) domain name as well as the ACE?
Organization: NIC France
Sender: [email-masked]

On Tue, Aug 06, 2002 at 12:47:56PM +0200,
 Patrick <[email-masked]> wrote 
 a message of 29 lines which said:

> On Tue, Aug 06, 2002 at 09:27:19AM +0200, Stephane Bortzmeyer took time to write:
> > > since epp's char set is utf8 i see no reason why a native utf name
> > > cound't be enclosed in <domain:name> insted of the ace name.
> 
> I totally agree with Rick's comments.

In theory, yes. In practice, it is probably fair to assume that few
EPP servers will be happy with Unicode. I just tried on LibertyRMS
testbed and I got:

Executing domain create [aèçà.epp]
    Code: 2005
    Message: Parameter value syntax error
     2005:Parameter value syntax error (Value contains invalid character: -1(�))

It is not a message for a policy violation :-)

> My opinion is that Registry should accept the UTF-8 version and do
> the ACE things by themselves. Of course this is a matter of policy.

Date: Tue, 6 Aug 2002 12:47:56 +0200
From: Patrick <[email-masked]>
To: [email-masked]
Subject: Re: Sending the original (Unicode) domain name as well as the ACE?
Organization: Gandi
Sender: [email-masked]

On Tue, Aug 06, 2002 at 09:27:19AM +0200, Stephane Bortzmeyer took time to write:
> > since epp's char set is utf8 i see no reason why a native utf name
> > cound't be enclosed in <domain:name> insted of the ace name.

I totally agree with Rick's comments.

> It is a matter of registrar-registry policy. I assume that a IDN
> registry will require its registrars to create domain with
> <domain:name> set to the original form OR the ACE form. And that this
> choice will be uniform among all the registrars.

My opinion is that Registry should accept the UTF-8 version and do
the ACE things by themselves. Of course this is a matter of policy.

> For instance, if the registry decides it will accept the original
> form, it will have to perform nameprep before deciding if the domain
> is already registered.

This is not a problem, I think.

> But, if the registry decides to let the registrars encode the IDN in
> ACE, it could be useful to accept the original name as well (remember

See http://www.verisign-grs.com/idn/techpaper.pdf for an example.
The Registry takes the ACE version, translates it to ISO10646,
do again the nameprep+ACE stuff on it, and compare its result with
what was given by the Registrar.

Patrick.

Date: Tue, 6 Aug 2002 09:29:50 +0200
From: Stephane Bortzmeyer <[email-masked]>
To: Dave Crocker <[email-masked]>
Cc: Stephane Bortzmeyer <[email-masked]>, [email-masked]
Subject: Re: Sending the original (Unicode) domain name as well as the ACE?
Organization: NIC France
Sender: [email-masked]

On Tue, Aug 06, 2002 at 12:19:50AM -0700,
 Dave Crocker <[email-masked]> wrote 
 a message of 24 lines which said:

> ace is an encoding form.  so is utf-8.  so is utf-16.  all of them are 
> unicode.

Big difference: you can go from UTF-8 to UTF-16 (and back) without
losing information. You CANNOT go from UTF-8 (or 16) to ACE without
losing information (because of nameprep).
 
> so ace is just as much "original (Unicode)" as utf-8 or utf-16.

I slightly disagree.

> There is no informational benefit in having the string stored in two 
> different encodings. 

I do not regard ACE as an encoding of Unicode.

Date: Tue, 6 Aug 2002 09:27:19 +0200
From: Stephane Bortzmeyer <[email-masked]>
To: Rick Wesson <[email-masked]>
Cc: Stephane Bortzmeyer <[email-masked]>, [email-masked]
Subject: Re: Sending the original (Unicode) domain name as well as the ACE?
Organization: NIC France
Sender: [email-masked]

On Tue, Aug 06, 2002 at 12:16:01AM -0700,
 Rick Wesson <[email-masked]> wrote 
 a message of 8 lines which said:

> since epp's char set is utf8 i see no reason why a native utf name
> cound't be enclosed in <domain:name> insted of the ace name.

It is a matter of registrar-registry policy. I assume that a IDN
registry will require its registrars to create domain with
<domain:name> set to the original form OR the ACE form. And that this
choice will be uniform among all the registrars.

For instance, if the registry decides it will accept the original
form, it will have to perform nameprep before deciding if the domain
is already registered.

But, if the registry decides to let the registrars encode the IDN in
ACE, it could be useful to accept the original name as well (remember
also that the mapping between the IDN and its ACE form is N->1 and
1->1 in reverse so the registry cannot compute the original form
itself).

Date: Tue, 06 Aug 2002 00:19:50 -0700
To: Stephane Bortzmeyer <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Sending the original (Unicode) domain name as well as the ACE?
Cc: [email-masked]
Sender: [email-masked]

At 09:03 AM 8/6/2002 +0200, Stephane Bortzmeyer wrote:
>This issue was raised on the Crisp mailing list
><URL:http://www.ietf.org/html.charters/crisp-charter.html>. It seems
>it could be a good idea, for the registry, to store the original
>(Unicode) form of an IDN, as well as its ACE (ASCII-encoded) form.
>
>It would allow more searches (Crisp protocols do not perform only
>exact-match searches but also partial-name searches, which are not
>possible on the ACE form).

ace is an encoding form.  so is utf-8.  so is utf-16.  all of them are unicode.

so ace is just as much "original (Unicode)" as utf-8 or utf-16.

There is no informational benefit in having the string stored in two 
different encodings.  There also is not computational benefit, given that 
the strings are so short.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.850.1850

Date: Tue, 6 Aug 2002 00:16:01 -0700 (PDT)
From: Rick Wesson <[email-masked]>
To: Stephane Bortzmeyer <[email-masked]>
cc: <[email-masked]>
Subject: Re: Sending the original (Unicode) domain name as well as the ACE?
Sender: [email-masked]

>
> And that <domain:name> is only the ACE form? Shouldn't we add an
> optional element <domain:original_name>?

since epp's char set is utf8 i see no reason why a native utf name
cound't be enclosed in <domain:name> insted of the ace name.

-rick (who is guessing)

Date: Tue, 6 Aug 2002 09:03:50 +0200
From: Stephane Bortzmeyer <[email-masked]>
To: [email-masked]
Subject: Sending the original (Unicode) domain name as well as the ACE?
Organization: NIC France
Sender: [email-masked]

This issue was raised on the Crisp mailing list
<URL:http://www.ietf.org/html.charters/crisp-charter.html>. It seems
it could be a good idea, for the registry, to store the original
(Unicode) form of an IDN, as well as its ACE (ASCII-encoded) form. 

It would allow more searches (Crisp protocols do not perform only
exact-match searches but also partial-name searches, which are not
possible on the ACE form).

Am I correct when reading draft-ietf-provreg-epp-domain-04.txt that it
contains nothing about transmitting the original form from the
registrar, which knows it, to the registry?

And that <domain:name> is only the ACE form? Shouldn't we add an
optional element <domain:original_name>?

Date: Mon, 5 Aug 2002 22:37:13 +0200
From: Patrick <[email-masked]>
To: [email-masked]
Subject: Re: Login Failure and Sessions
Organization: Gandi
Sender: [email-masked]

Scott,

> deterministic state diagram.  If what you're saying, though, is that you
> prefer option 2 (blast the connection after N failures) with the value of N
> (0 <= N <= inf) to be determined by the server operator, I can work with
> that.  That's at least easier to describe formally than "it's a policy
> issue". ;-)

Sorry for my formulation then.
What you describe (N being whatever from 0 to inf included) is what I
had in mind.

Sorry again.

Patrick.

From: "Liu, Hong" <[email-masked]>
To: [email-masked]
Subject: RE: Login Failure and Sessions
Date: Mon, 5 Aug 2002 15:46:40 -0400 
Sender: [email-masked]

Scott,

Now I understand what your problem was, -:) Yes, I was referring to option 2
with N to be determined by the server operator.

--Hong

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: Monday, August 05, 2002 3:41 PM
To: 'Liu, Hong'; [email-masked]
Subject: RE: Login Failure and Sessions

> I understand your concerns, but the retrial number N is really a
> configuration parameter. It is not unusual to leave this type 
> of parameters
> for run-time configuration, take the windowing protocol as an 
> example. The
> size of the window is not fixed in the spec.

You didn't address the problem I presented: the need to craft a
deterministic state diagram.  If what you're saying, though, is that you
prefer option 2 (blast the connection after N failures) with the value of N
(0 <= N <= inf) to be determined by the server operator, I can work with
that.  That's at least easier to describe formally than "it's a policy
issue". ;-)

-Scott-

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Liu, Hong'" <[email-masked]>, [email-masked]
Subject: RE: Login Failure and Sessions
Date: Mon, 5 Aug 2002 15:41:10 -0400 
Sender: [email-masked]

> I understand your concerns, but the retrial number N is really a
> configuration parameter. It is not unusual to leave this type 
> of parameters
> for run-time configuration, take the windowing protocol as an 
> example. The
> size of the window is not fixed in the spec.

You didn't address the problem I presented: the need to craft a
deterministic state diagram.  If what you're saying, though, is that you
prefer option 2 (blast the connection after N failures) with the value of N
(0 <= N <= inf) to be determined by the server operator, I can work with
that.  That's at least easier to describe formally than "it's a policy
issue". ;-)

-Scott-

From: "Liu, Hong" <[email-masked]>
To: [email-masked]
Subject: RE: Login Failure and Sessions
Date: Mon, 5 Aug 2002 14:14:44 -0500 
Sender: [email-masked]

Scott,

I understand your concerns, but the retrial number N is really a
configuration parameter. It is not unusual to leave this type of parameters
for run-time configuration, take the windowing protocol as an example. The
size of the window is not fixed in the spec.

It may help, though, to give guidelines to selecting an appropriate value of
N in the spec.

--Hong

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: Monday, August 05, 2002 12:40 PM
To: 'Liu, Hong'; [email-masked]
Subject: RE: Login Failure and Sessions

> I agree with Patrick that this is a server policy issue. The 
> protocol should
> not specify the exact value of N.

If so, then we have a protocol with a non-deterministic state diagram.  The
state of the server WRT to login failures ends up being
implementation-dependent, and I think this is going to get us in trouble
with the IESG *.

-Scott-

* I say this because I've been told by our AD that we need a state diagram
in the specs, and I can't draw such a diagram if I can't document how the
server behaves when it has to deal with a client authentication failure.
I'm open to suggestions as to how this kind of implementation choice might
be described in a state diagram...

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Liu, Hong'" <[email-masked]>, [email-masked]
Subject: RE: Login Failure and Sessions
Date: Mon, 5 Aug 2002 12:40:22 -0400 
Sender: [email-masked]

> I agree with Patrick that this is a server policy issue. The 
> protocol should
> not specify the exact value of N.

If so, then we have a protocol with a non-deterministic state diagram.  The
state of the server WRT to login failures ends up being
implementation-dependent, and I think this is going to get us in trouble
with the IESG *.

-Scott-

* I say this because I've been told by our AD that we need a state diagram
in the specs, and I can't draw such a diagram if I can't document how the
server behaves when it has to deal with a client authentication failure.
I'm open to suggestions as to how this kind of implementation choice might
be described in a state diagram...

From: "Liu, Hong" <[email-masked]>
To: [email-masked]
Subject: RE: Login Failure and Sessions
Date: Mon, 5 Aug 2002 11:19:20 -0500 
Sender: [email-masked]

Scott,

I agree with Patrick that this is a server policy issue. The protocol should
not specify the exact value of N.

--Hong

-----Original Message-----
From: Patrick [mailto:[email-masked]]
Sent: Monday, August 05, 2002 10:55 AM
To: [email-masked]
Subject: Re: Login Failure and Sessions

On Mon, Aug 05, 2002 at 09:52:59AM -0400, Hollenbeck, Scott took time to
write:
> I'm working on putting a state diagram in the EPP draft per a last-call
> comment from our AD.  While working through this I came across something
> that we haven't captured in the documents: what should a server do in case
> of a login failure due to bogus credentials?
> 
> My preference would be for consistent behavior across all transports.  I
see
> a few options for dealing with login failures:

I think that this is a policy issue.
The protocol should only state that the server MAY close the
connection after login failure, so that the client knows he must deal
with this case.
Of course following commands (in such case as the one you describe
with an email containing login-commands-lougout) are not processed,
and discarded by the server.

Other than that, it should be up to each Registry to see if they
prefer to close the connection, limit the number of attempts or do
not limit anything.

Patrick.

Date: Mon, 5 Aug 2002 16:54:45 +0200
From: Patrick <[email-masked]>
To: [email-masked]
Subject: Re: Login Failure and Sessions
Organization: Gandi
Sender: [email-masked]

On Mon, Aug 05, 2002 at 09:52:59AM -0400, Hollenbeck, Scott took time to write:
> I'm working on putting a state diagram in the EPP draft per a last-call
> comment from our AD.  While working through this I came across something
> that we haven't captured in the documents: what should a server do in case
> of a login failure due to bogus credentials?
> 
> My preference would be for consistent behavior across all transports.  I see
> a few options for dealing with login failures:

I think that this is a policy issue.
The protocol should only state that the server MAY close the
connection after login failure, so that the client knows he must deal
with this case.
Of course following commands (in such case as the one you describe
with an email containing login-commands-lougout) are not processed,
and discarded by the server.

Other than that, it should be up to each Registry to see if they
prefer to close the connection, limit the number of attempts or do
not limit anything.

Patrick.

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Login Failure and Sessions
Date: Mon, 5 Aug 2002 09:52:59 -0400 
Sender: [email-masked]

I'm working on putting a state diagram in the EPP draft per a last-call
comment from our AD.  While working through this I came across something
that we haven't captured in the documents: what should a server do in case
of a login failure due to bogus credentials?

My preference would be for consistent behavior across all transports.  I see
a few options for dealing with login failures:

1. Send an error response and end the session/close the connection.

2. Send an error response, but allow N failures before ending the
session/close the connection.

3. Send an error response and allow an unlimited number of failures.

Option 1 is the safest for the server as it helps slow down an attacker, and
it some situations it can eliminate processing of batched commands that
won't be able to succeed because of the login failure.

Option 3 is easiest for clients, but it provides a means for a DoS attack on
the server if misused.

Option 2 is a compromise between options 1 and 3, but what's the right value
of N -- maybe three?

I'm leaning towards option 1 myself as it seems best suited for all
transports.  For example, if an email transport allows a complete
"login-commands-logout" session to be sent in one mail message, aborting
after the login failure means that all of the other commands (which won't be
able to succeed anyway because of the login failure) won't get processed,
which makes the server more efficient.  It would also work for a TCP or BEEP
transport, though it would slow down the client a little.

Any other thoughts/comments?

-Scott-

From: "Stuart Marsden" <[email-masked]>
To: <[email-masked]>
Subject:  EPP 6 / TCP 4 Implementation of epp-rtk-java
Date: Sun, 4 Aug 2002 08:45:28 +0100
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_000A_01C23B93.4AB08970
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi,

I am doing some cross registry compatibility testing 

Source forge only has EPP 5/3 in Java and it would defeat my testing if
I update it

Can anybody lend me a copy of a 6/4 version for the weekend, I promise
to return it

Thanks in advance

Stuart

_________________________________ 
Stuart Marsden

POPTEL Ltd
21-25 Bruges Place
Randolph Street
London NW1 0TF 
Tel: 020 7284 6976
Mob: 07788 107013

Fax: 020 7284 6901 
mail to: [email-masked]
<http://www.poptel.coop/>
_________________________________ 

------=_NextPart_000_000A_01C23B93.4AB08970
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">

<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p
	{margin-right:0cm;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.emailstyle17
	{font-family:Arial;
	color:windowtext;}
span.EmailStyle19
	{font-family:Arial;
	color:navy;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DArial><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>Hi,</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DArial><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DArial><span
lang=3DEN-GB style=3D'font-size:10.0pt;font-family:Arial'>I am doing =
some cross
registry compatibility testing </span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DArial><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DArial><span
lang=3DEN-GB style=3D'font-size:10.0pt;font-family:Arial'>Source forge =
only has EPP
5/3 in Java and it would defeat my testing if I update =
it</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DArial><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DArial><span
lang=3DEN-GB style=3D'font-size:10.0pt;font-family:Arial'>Can anybody =
lend me a
copy of a 6/4 version for the weekend, I promise to return =
it</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DArial><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span lang=3DEN-GB =
style=3D'font-size:12.0pt'>Thanks in
advance</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span lang=3DEN-GB =
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span lang=3DEN-GB =
style=3D'font-size:12.0pt'>Stuart</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span lang=3DEN-GB =
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span lang=3DEN-GB =
style=3D'font-size:12.0pt'>______________________<font
color=3Dred><span style=3D'color:red'>___________</span></font> <br>
<font color=3Dgray><span style=3D'color:gray'>Stuart =
Marsden</span></font></span></font></p>

<p style=3D'margin-left:36.0pt'><b><font size=3D2 color=3Dgray =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:gray;font-weight:bold'>=
POPTEL
Ltd</span></font></b><br>
  <b><font size=3D2 color=3Dsilver face=3DArial><span =
style=3D'font-size:10.0pt;
  font-family:Arial;color:silver;font-weight:bold'>21-25 Bruges =
Place</span></font></b><br>
  <b><font size=3D2 color=3Dsilver face=3DArial><span =
style=3D'font-size:10.0pt;
  font-family:Arial;color:silver;font-weight:bold'>Randolph =
Street</span></font></b><br>
  <b><font size=3D2 color=3Dsilver face=3DArial><span =
style=3D'font-size:10.0pt;
  =
font-family:Arial;color:silver;font-weight:bold'>London</span></font></b>=
<b><font
size=3D2 color=3Dsilver face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:silver;font-weight:bold'> NW1 0TF</span></font></b> <br>
<b><font size=3D2 color=3Dsilver face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:silver;font-weight:bold'>Tel: 020 7284 =
6976</span></font></b><br>
<b><font size=3D2 color=3Dsilver face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:silver;font-weight:bold'>Mob: 07788 =
107013</span></font></b></p>

<p style=3D'margin-left:36.0pt'><b><font size=3D2 color=3Dsilver =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:silver;font-weight:bold=
'>Fax:
020 7284 6901</span></font></b> <br>
<b><font size=3D2 color=3Dsilver face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:silver;font-weight:bold'>mail to: <a
href=3D"mailto:[email-masked]">[email-masked]</a>=
</span></font></b><br>
<b><u><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue;font-weight:bold'>&lt;<a
href=3D"http://www.poptel.coop/" =
target=3D"_blank">http://www.poptel.coop/</a>&gt;</span></font></u></b><b=
r>
<b><font size=3D2 color=3Dfuchsia face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:fuchsia;font-weight:bold'>______________________<=
/span></font></b><b><font
size=3D2 color=3Dred face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:red;font-weight:bold'>___________</span></font></b> </p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span lang=3DEN-GB =
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

</div>

</body>

</html>

------=_NextPart_000_000A_01C23B93.4AB08970--

Date: Fri, 02 Aug 2002 14:12:41 -0400
From: janusz sienkiewicz <[email-masked]>
Organization: LibertyRMS Co.
To: "Hollenbeck, Scott" <[email-masked]>, [email-masked]
Subject: Re: Proposed Document Changes
Sender: [email-masked]

Defending <status> command I assumed wrong interpretation of the command
description. My intepretation was (assuming uniquness of clTRID):

Response with empty <status> - command not processed
Response with positive ack attribute - command processed, success
Response with negative ack attribute - command processed, failure

That was the only interpretation, I could figure out, that was making the
command usefull. After your clarification I agree that there is not much value
in keeping the command.

Regards,

Janusz

"Hollenbeck, Scott" wrote:

> > A few more words regarding resubmitting transform commands in
> > case of unknown
> > result of the first command. If the result of the original
> > comand is unknown and
> > the same command is resubmitted and returns error we may
> > still not know the
> > result of the original request. If we take <renew> as an
> > example the fact that
> > the second command returned an error is not sufficient for an
> > automated process
> > to make a decision whether submit it again or not. A more
> > sophisticated process
> > (object and method specific) is required to make such a decision.
>
> If you consider parsing of the response to an <info> command and doing some
> comparisons sophisticated, you may be right -- but that's not the point.
>
> All the <status> command does/did was confirm that a command was received
> and processed.  It does _not_ tell you if the command succeeded or failed --
> that's what responses are for, and that's why the necessity of the command
> has been questioned.
>
> Now, this might lead us back to the "well, what if a response is lost"
> argument?  That's why we have reliable transports, transaction identifiers,
> query commands, and idempotent transform commands.
>
> -Scott-

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: FW: BCP 59, RFC 3349 on A Transient Prefix for Identifying Profil es under Development by the Working Groups of the Internet Engineering Ta sk Force
Date: Thu, 1 Aug 2002 19:54:42 -0400 
Sender: [email-masked]

Being BEEP-related, this might be of interest to folks looking at the BEEP
transport I-D.

-Scott-

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, August 01, 2002 5:44 PM
To: [email-masked]
Cc: [email-masked]
Subject: [rfc-dist] BCP 59, RFC 3349 on A Transient Prefix for
Identifying Profiles under Development by the Working Groups of the
Internet Engineering Task Force

A new Request for Comments is now available in online RFC libraries.

        BCP 59
        RFC 3349

        Title:	    A Transient Prefix for Identifying Profiles under
                    Development by the Working Groups of the Internet
                    Engineering Task Force 
        Author(s):  M. Rose
        Status:	    Best Current Practice
	Date:       July 2002
        Mailbox:    [email-masked]
        Pages:      6
        Characters: 7916
        SeeAlso:    BCP 59

        I-D Tag:    draft-mrose-beep-transientid-02.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3349.txt

As a part of their deliverables, working groups of the IETF may
develop BEEP profiles.  During the development process, it is
desirable to assign a transient identifier to each profile.  If the
profile is subsequently published as an RFC, then a permanent
identifier is subsequently assigned by the IANA.

This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements.  Distribution of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

From: "Hollenbeck, Scott" <[email-masked]>
To: "'janusz sienkiewicz'" <[email-masked]>, [email-masked]
Subject: RE: Proposed Document Changes
Date: Thu, 1 Aug 2002 19:51:46 -0400 
Sender: [email-masked]

> A few more words regarding resubmitting transform commands in 
> case of unknown
> result of the first command. If the result of the original 
> comand is unknown and
> the same command is resubmitted and returns error we may 
> still not know the
> result of the original request. If we take <renew> as an 
> example the fact that
> the second command returned an error is not sufficient for an 
> automated process
> to make a decision whether submit it again or not. A more 
> sophisticated process
> (object and method specific) is required to make such a decision.

If you consider parsing of the response to an <info> command and doing some
comparisons sophisticated, you may be right -- but that's not the point.

All the <status> command does/did was confirm that a command was received
and processed.  It does _not_ tell you if the command succeeded or failed --
that's what responses are for, and that's why the necessity of the command
has been questioned.

Now, this might lead us back to the "well, what if a response is lost"
argument?  That's why we have reliable transports, transaction identifiers,
query commands, and idempotent transform commands.

-Scott-

Date: Thu, 01 Aug 2002 15:30:01 -0400
From: janusz sienkiewicz <[email-masked]>
Organization: LibertyRMS Co.
To: "Hollenbeck, Scott" <[email-masked]>, [email-masked]
Subject: Re: Proposed Document Changes
Sender: [email-masked]

A few more words regarding resubmitting transform commands in case of unknown
result of the first command. If the result of the original comand is unknown and
the same command is resubmitted and returns error we may still not know the
result of the original request. If we take <renew> as an example the fact that
the second command returned an error is not sufficient for an automated process
to make a decision whether submit it again or not. A more sophisticated process
(object and method specific) is required to make such a decision.

Regards,

Janusz

janusz sienkiewicz wrote:

> In a way you are right about <renew> command. Right now <renew> is defined for
> domains only and <curExpDate> ensures that the next <renew> command should
> fail. But it is object extension (domain) specific.
>
> Why using <info> may not be easy?
> Any automatic processing based on <info> command will be object and  command
> specific or it will based on the last modification date. Since last
> modification date in <info> response is defined in object mapping document
> using last modifification date makes such processing still object and command
> dependant. Besides it requires perfect time synchronization between client and
> server for any transform command for any object. That's why I added the
> subjective part to my original opinion.
>
> Regards,
>
> Janusz
>
> "Hollenbeck, Scott" wrote:
>
> > > I would like to say a few words in defence of <status> command. Unlike
> > > some other participants of the thread I see value in retaining the
> > > command. It was said in the discussion that transform commands can be
> > > resubmitted or their results can be determined by <info> command.
> > > Retransmitting some commands could be risky (let's take <renew> for
> > > example).
> >
> > There's no risk at all because all of the transform commands are idempotent.
> > If you send the exact same <renew> command and the first command "took" but
> > the response was "lost", the second command _should_ fail because the value
> > of the <curExpDate> element will contain the value from before the first
> > command succeeded.  If it doesn't fail the server is doing something wrong.
> >
> > > Using <info> command to determine the state of the
> > > object may not be easy.
> >
> > Please explain why.  The <info> command exists explicitly to determine the
> > state of an object.  Even if it _is_ hard for a client to compare the
> > current state with what they think the state should be, there is no harm or
> > risk in retrying a command to be sure it "took".
> >
> > > If a registrar enforces uniquenes of clTRID <status>
> > > command provides a convenient way of handling failure situations.
> >
> > That's the subjective part. ;-)
> >
> > -Scott-

Date: Thu, 01 Aug 2002 12:16:12 -0400
From: janusz sienkiewicz <[email-masked]>
Organization: LibertyRMS Co.
To: "Hollenbeck, Scott" <[email-masked]>
CC: [email-masked]
Subject: Re: Proposed Document Changes
Sender: [email-masked]

In a way you are right about <renew> command. Right now <renew> is defined for
domains only and <curExpDate> ensures that the next <renew> command should
fail. But it is object extension (domain) specific.

Why using <info> may not be easy?
Any automatic processing based on <info> command will be object and  command
specific or it will based on the last modification date. Since last
modification date in <info> response is defined in object mapping document
using last modifification date makes such processing still object and command
dependant. Besides it requires perfect time synchronization between client and
server for any transform command for any object. That's why I added the
subjective part to my original opinion.

Regards,

Janusz

"Hollenbeck, Scott" wrote:

> > I would like to say a few words in defence of <status> command. Unlike
> > some other participants of the thread I see value in retaining the
> > command. It was said in the discussion that transform commands can be
> > resubmitted or their results can be determined by <info> command.
> > Retransmitting some commands could be risky (let's take <renew> for
> > example).
>
> There's no risk at all because all of the transform commands are idempotent.
> If you send the exact same <renew> command and the first command "took" but
> the response was "lost", the second command _should_ fail because the value
> of the <curExpDate> element will contain the value from before the first
> command succeeded.  If it doesn't fail the server is doing something wrong.
>
> > Using <info> command to determine the state of the
> > object may not be easy.
>
> Please explain why.  The <info> command exists explicitly to determine the
> state of an object.  Even if it _is_ hard for a client to compare the
> current state with what they think the state should be, there is no harm or
> risk in retrying a command to be sure it "took".
>
> > If a registrar enforces uniquenes of clTRID <status>
> > command provides a convenient way of handling failure situations.
>
> That's the subjective part. ;-)
>
> -Scott-

From: "Hollenbeck, Scott" <[email-masked]>
To: "'janusz sienkiewicz'" <[email-masked]>, [email-masked]
Subject: RE: Proposed Document Changes
Date: Thu, 1 Aug 2002 11:42:52 -0400 
Sender: [email-masked]

> I would like to say a few words in defence of <status> command. Unlike
> some other participants of the thread I see value in retaining the
> command. It was said in the discussion that transform commands can be
> resubmitted or their results can be determined by <info> command.
> Retransmitting some commands could be risky (let's take <renew> for
> example).

There's no risk at all because all of the transform commands are idempotent.
If you send the exact same <renew> command and the first command "took" but
the response was "lost", the second command _should_ fail because the value
of the <curExpDate> element will contain the value from before the first
command succeeded.  If it doesn't fail the server is doing something wrong.

> Using <info> command to determine the state of the 
> object may not be easy.

Please explain why.  The <info> command exists explicitly to determine the
state of an object.  Even if it _is_ hard for a client to compare the
current state with what they think the state should be, there is no harm or
risk in retrying a command to be sure it "took".

> If a registrar enforces uniquenes of clTRID <status>
> command provides a convenient way of handling failure situations.

That's the subjective part. ;-)

-Scott-

Date: Thu, 01 Aug 2002 11:10:30 -0400
From: janusz sienkiewicz <[email-masked]>
Organization: LibertyRMS Co.
To: [email-masked]
Subject: Proposed Document Changes
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------F636EB6F24D779C7E6BF8892
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The message was orinally sent from another account so I have to send it
again.

--------------F636EB6F24D779C7E6BF8892
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

X-Mozilla-Status2: 00000000
Message-ID: <[email-masked]>
Date: Fri, 26 Jul 2002 14:30:23 -0400
From: janusz sienkiewicz <[email-masked]>
Organization: LibertyRMS Co.
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: [email-masked]
Subject: RE: Proposed Document Changes
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I would like to say a few words in defence of <status> command. Unlike
some other participants of the thread I see value in retaining the
command. It was said in the discussion that transform commands can be
resubmitted or their results can be determined by <info> command.
Retransmitting some commands could be risky (let's take <renew> for
example). Using <info> command to determine the state of the object may
not be easy.  If a registrar enforces uniquenes of clTRID <status>
command provides a convenient way of handling failure situations.

Regards,

Janusz

--------------F636EB6F24D779C7E6BF8892--

Date: Thu, 01 Aug 2002 10:50:10 -0400
From: janusz sienkiewicz <[email-masked]>
Organization: LibertyRMS Co.
To: "[email-masked]'" <[email-masked]>
Subject: Re: I-D on Uniform Treatment of Pending Action Notification in EPP
Sender: [email-masked]

I can not fully evalue Scott's proposal untill it is presented in a formal way

with all its implications on epp document and all associated object mapping
documents. I can only express opinion about the direction he is taking for
handling 'Pending Action Notification'.

I think a good and comprehensive example for handling 'Pending Action' can be
found in <transfer> command.  It make sense to solve any 'Pending Action'
situation in a manner similiar to <transfer> (to a reasonable extent). What I
can see from Scott's proposal he is making steps in that direction.

Regards,

Janusz

"Hollenbeck, Scott" wrote:

> > When I wrote the draft at the beginning, I was actually
> > thinking exactly
> > your way since the pending action is performed on a specific
> > object mapping.
> > But after I finished the writing, I realized that I have to
> > add <paData> to
> > every object mapping (i.e., domain, contact, and host) that
> > may need this
> > feature. The advantage for doing so, as you explained, is
> > that more object
> > specific information can be added in. The downside is that
> > <paData> will
> > have to be defined in every object mapping (existing and
> > to-be-defined).
> > Since my main goal is to minimize the changes to existing
> > schemas, after
> > some struggle myself, I took the approach to extract the
> > basic elements for
> > notification that are object independent. But this may be
> > just my personal
> > preference in schema design. Both your suggestion and mine
> > should work. I
> > will leave it to the WG to decide which way to go.
>
> Given that I firmly believe that we should be consistent in our approach
> (and I don't want to try to explain to Patrik why we weren't consistent), I
> would strongly urge anyone who objects to my suggested compromise to speak
> up sooner rather than later.  I'm trying to get the document edits finished
> in short order.
>
> > Just to be complete, taking your input, <paNotify> can be defined as
> > follows:
> >
> > <complexType name="paNotify">
> >   <sequence>
> >     <element name="paTRID" type="epp:trIDType"/>
> >     <element name="paDate" type="dateTime"/>
> >   </sequence>
> >   <attribute name="paResult" type="boolean" use="required"/>
> > </complexType>
>
> Yup, that's pretty much it.
>
> -Scott-

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Stateless vs. Stateful
Date: Thu, 1 Aug 2002 10:47:58 -0400 
Sender: [email-masked]

> At 11:04 AM -0400 7/29/02, Hollenbeck, Scott wrote:
> >With email, for example, a transport mapping could be 
> written to say that
> >all of the needed commands must be sent in one message/session.
> 
> One issue is the means of authentication.  Since I'm a chair, I'll 
> sit back and listen to comments on this in lieu of speaking my mind. 
> (Unless I am urged to do so.)

That issue could be addressed by requiring a <login> command as the first
command in the batch.  The "session" could then be ended with either an
explicit <logout> command or reaching the end of the batch.  Additional
authentication services could be provided with either PGP or S/MIME signing
of the batch, but that's getting ahead into the specifics of an email
transport.

-Scott-

Date: Thu, 1 Aug 2002 10:37:44 -0400
To: "Hollenbeck, Scott" <[email-masked]>, "[email-masked]'" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: Stateless vs. Stateful
Sender: [email-masked]

At 11:04 AM -0400 7/29/02, Hollenbeck, Scott wrote:
>With email, for example, a transport mapping could be written to say that
>all of the needed commands must be sent in one message/session.

One issue is the means of authentication.  Since I'm a chair, I'll 
sit back and listen to comments on this in lieu of speaking my mind. 
(Unless I am urged to do so.)

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

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

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

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

> Just to be complete, taking your input, <paNotify> can be defined as
> follows:
> 
> <complexType name="paNotify">
>   <sequence>
>     <element name="paTRID" type="epp:trIDType"/>
>     <element name="paDate" type="dateTime"/>
>   </sequence>
>   <attribute name="paResult" type="boolean" use="required"/>
> </complexType>

Yup, that's pretty much it.

-Scott-