Re: a new domain name status

[Eric Brunner-Williams in Portland Maine <[e-mail]>]

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7UENDo2009755 for <[e-mail]>; Fri, 30 Aug 2002 16:23:13 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g7UEND6I009754 for ietf-provreg-outgoing; Fri, 30 Aug 2002 16:23:13 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7UENBo2009749 for <[e-mail]>; Fri, 30 Aug 2002 16:23:12 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.5/8.11.6) with ESMTP id g7UENSbi003800; Fri, 30 Aug 2002 10:23:28 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
cc: "'wenzhe lu'" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: a new domain name status 
In-Reply-To: Your message of "Fri, 30 Aug 2002 07:45:38 EDT." <[e-mail]> 
Date: Fri, 30 Aug 2002 10:23:28 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7UBjpo2008068 for <[e-mail]>; Fri, 30 Aug 2002 13:45:51 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g7UBjoXi008067 for ietf-provreg-outgoing; Fri, 30 Aug 2002 13:45:50 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7UBjno2008062 for <[e-mail]>; Fri, 30 Aug 2002 13:45:50 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id HAA09856; Fri, 30 Aug 2002 07:46:32 -0400 (EDT)
Received: by vsvapostalgw2.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <RV4HAHJG>; Fri, 30 Aug 2002 07:45:39 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'wenzhe lu'" <[e-mail]>, [e-mail]
Subject: RE: a new domain name status
Date: Fri, 30 Aug 2002 07:45:38 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="gb2312"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7U86oo2006653 for <[e-mail]>; Fri, 30 Aug 2002 10:06:50 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g7U86orf006652 for ietf-provreg-outgoing; Fri, 30 Aug 2002 10:06:50 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from whale.cnnic.net.cn ([159.226.6.187]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7U86lo2006647 for <[e-mail]>; Fri, 30 Aug 2002 10:06:49 +0200 (MEST)
Received: from lwz ([159.226.7.67]) by whale.cnnic.net.cn (Netscape Messaging Server 4.15) with SMTP id H1ND8400.HFZ; Fri, 30 Aug 2002 16:07:16 +0800 
From: "wenzhe lu" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: a new domain name status
Date: Fri, 30 Aug 2002 16:01:39 +0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="gb2312"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by nic.cafax.se id g7U86oo2006648
Sender: [e-mail]
Precedence: bulk

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7SGt6o2021839 for <[e-mail]>; Wed, 28 Aug 2002 18:55:06 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g7SGt65K021838 for ietf-provreg-outgoing; Wed, 28 Aug 2002 18:55:06 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7SGt5o2021833 for <[e-mail]>; Wed, 28 Aug 2002 18:55:05 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id MAA26158 for <[e-mail]>; Wed, 28 Aug 2002 12:55:55 -0400 (EDT)
Received: by vsvapostalgw2.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <RV4G9516>; Wed, 28 Aug 2002 12:55:01 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: FW: I-D ACTION:draft-hollenbeck-epp-ext-00.txt
Date: Wed, 28 Aug 2002 12:54:58 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

FYI...

-Scott- 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
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:
	[e-mail].
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.


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7RJ5ko2013007 for <[e-mail]>; Tue, 27 Aug 2002 21:05:46 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g7RJ5kbd013006 for ietf-provreg-outgoing; Tue, 27 Aug 2002 21:05:46 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7RJ5jo2013001 for <[e-mail]>; Tue, 27 Aug 2002 21:05:45 +0200 (MEST)
Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id g7RJ5cUW016201 for <[e-mail]>; Tue, 27 Aug 2002 21:05:38 +0200 (CEST) (envelope-from [e-mail])
Received: (from jaap@localhost) by bartok.sidn.nl (8.12.5/8.12.5/Submit) id g7RJ5cLD016200 for [e-mail]; Tue, 27 Aug 2002 21:05:38 +0200 (CEST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7RIoeo2012815; Tue, 27 Aug 2002 20:50:40 +0200 (MEST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06546 for <1timer>; Tue, 27 Aug 2002 14:44:44 -0400 (EDT)
Message-Id: <[e-mail]>
From: Phil Roberts <[e-mail]>
To: IETF WG Participants: ;
Subject: Nomcom call for volunteers
Date: Tue, 27 Aug 2002 14:44:44 -0400
Sender: [e-mail]
Precedence: bulk

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.



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7RCVmo2009159 for <[e-mail]>; Tue, 27 Aug 2002 14:31:48 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g7RCVmCR009158 for ietf-provreg-outgoing; Tue, 27 Aug 2002 14:31:48 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7RCVko2009153 for <[e-mail]>; Tue, 27 Aug 2002 14:31:47 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.5/8.11.6) with ESMTP id g7RCVenW025412; Tue, 27 Aug 2002 08:31:40 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: New Schema Files and Examples 
In-Reply-To: Your message of "Tue, 27 Aug 2002 08:07:35 EDT." <[e-mail]> 
Date: Tue, 27 Aug 2002 08:31:40 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7RCDno2009048 for <[e-mail]>; Tue, 27 Aug 2002 14:13:49 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g7RCDn9u009047 for ietf-provreg-outgoing; Tue, 27 Aug 2002 14:13:49 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7RCDlo2009042 for <[e-mail]>; Tue, 27 Aug 2002 14:13:48 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id IAA07968 for <[e-mail]>; Tue, 27 Aug 2002 08:14:38 -0400 (EDT)
Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <RV4GAMTD>; Tue, 27 Aug 2002 08:13:45 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: New Schema Files and Examples
Date: Tue, 27 Aug 2002 08:07:35 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7RBqEo2008842 for <[e-mail]>; Tue, 27 Aug 2002 13:52:14 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g7RBqEwm008841 for ietf-provreg-outgoing; Tue, 27 Aug 2002 13:52:14 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7RBqDo2008836 for <[e-mail]>; Tue, 27 Aug 2002 13:52:13 +0200 (MEST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18667; Tue, 27 Aug 2002 07:50:42 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-provreg-epp-tcp-05.txt
Date: Tue, 27 Aug 2002 07:50:42 -0400
Sender: [e-mail]
Precedence: bulk

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

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

--OtherAccess--

--NextPart--




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7RBq8o2008834 for <[e-mail]>; Tue, 27 Aug 2002 13:52:08 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g7RBq8fg008833 for ietf-provreg-outgoing; Tue, 27 Aug 2002 13:52:08 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7RBq7o2008828 for <[e-mail]>; Tue, 27 Aug 2002 13:52:07 +0200 (MEST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18649; Tue, 27 Aug 2002 07:50:36 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-provreg-epp-host-05.txt
Date: Tue, 27 Aug 2002 07:50:36 -0400
Sender: [e-mail]
Precedence: bulk

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

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

--OtherAccess--

--NextPart--




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7RBq3o2008826 for <[e-mail]>; Tue, 27 Aug 2002 13:52:03 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g7RBq2DV008825 for ietf-provreg-outgoing; Tue, 27 Aug 2002 13:52:02 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7RBq1o2008820 for <[e-mail]>; Tue, 27 Aug 2002 13:52:01 +0200 (MEST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18633; Tue, 27 Aug 2002 07:50:30 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-provreg-epp-domain-05.txt
Date: Tue, 27 Aug 2002 07:50:30 -0400
Sender: [e-mail]
Precedence: bulk

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

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

--OtherAccess--

--NextPart--




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7RBpvo2008818 for <[e-mail]>; Tue, 27 Aug 2002 13:51:58 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g7RBpvrw008817 for ietf-provreg-outgoing; Tue, 27 Aug 2002 13:51:57 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7RBpuo2008812 for <[e-mail]>; Tue, 27 Aug 2002 13:51:56 +0200 (MEST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18617; Tue, 27 Aug 2002 07:50:25 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-provreg-epp-contact-05.txt
Date: Tue, 27 Aug 2002 07:50:25 -0400
Sender: [e-mail]
Precedence: bulk

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

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

--OtherAccess--

--NextPart--




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7RBpro2008810 for <[e-mail]>; Tue, 27 Aug 2002 13:51:53 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g7RBprn9008809 for ietf-provreg-outgoing; Tue, 27 Aug 2002 13:51:53 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7RBppo2008804 for <[e-mail]>; Tue, 27 Aug 2002 13:51:52 +0200 (MEST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18600; Tue, 27 Aug 2002 07:50:20 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-provreg-epp-07.txt
Date: Tue, 27 Aug 2002 07:50:19 -0400
Sender: [e-mail]
Precedence: bulk

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

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

--OtherAccess--

--NextPart--




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7M244o2007075 for <[e-mail]>; Thu, 22 Aug 2002 04:04:04 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g7M244mU007074 for ietf-provreg-outgoing; Thu, 22 Aug 2002 04:04:04 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7M243o2007069 for <[e-mail]>; Thu, 22 Aug 2002 04:04:03 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.5/8.11.6) with ESMTP id g7M240Ic055875; Wed, 21 Aug 2002 22:04:00 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Jordyn A. Buchanan" <[e-mail]>
cc: [e-mail], "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: epp status 
In-Reply-To: Your message of "Wed, 21 Aug 2002 20:04:10 EDT." <[e-mail]> 
Date: Wed, 21 Aug 2002 22:04:00 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7M0SSo2005754 for <[e-mail]>; Thu, 22 Aug 2002 02:28:28 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g7M0SSs7005753 for ietf-provreg-outgoing; Thu, 22 Aug 2002 02:28:28 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7M0SRo2005748 for <[e-mail]>; Thu, 22 Aug 2002 02:28:27 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id UAA10606; Wed, 21 Aug 2002 20:29:17 -0400 (EDT)
Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <PXVATSMV>; Wed, 21 Aug 2002 20:28:25 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Jordyn A. Buchanan'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: epp status
Date: Wed, 21 Aug 2002 20:28:03 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7M043o2005627 for <[e-mail]>; Thu, 22 Aug 2002 02:04:03 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g7M043Sj005626 for ietf-provreg-outgoing; Thu, 22 Aug 2002 02:04:03 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from total.confusion.net (buchanan.nac.net [209.123.121.74]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7M042o2005621 for <[e-mail]>; Thu, 22 Aug 2002 02:04:02 +0200 (MEST)
Received: from ed1.total.confusion.net ([172.16.1.1] helo=[172.16.1.100]) by total.confusion.net with asmtp (Exim 3.34 #1) id 17hfS2-0003Yy-00; Wed, 21 Aug 2002 20:03:51 -0400
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Wed, 21 Aug 2002 20:04:10 -0400
Subject: Re: epp status
From: "Jordyn A. Buchanan" <[e-mail]>
To: <[e-mail]>, "'[e-mail]'" <[e-mail]>
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk

On 8/20/02 3:01 PM, "[e-mail]" <[e-mail]> 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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7LI7Qo2022566 for <[e-mail]>; Wed, 21 Aug 2002 20:07:27 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g7LI7Q1q022565 for ietf-provreg-outgoing; Wed, 21 Aug 2002 20:07:26 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7LI7Po2022559 for <[e-mail]>; Wed, 21 Aug 2002 20:07:25 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id OAA22980; Wed, 21 Aug 2002 14:08:11 -0400 (EDT)
Received: by vsvapostalgw2.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <RGHVZ65N>; Wed, 21 Aug 2002 14:07:18 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Susan Goodsir'" <[e-mail]>, [e-mail]
Subject: RE: Subordinate hosts and domain transfers
Date: Wed, 21 Aug 2002 14:06:57 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7LHWBo2022212 for <[e-mail]>; Wed, 21 Aug 2002 19:32:11 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g7LHWBug022211 for ietf-provreg-outgoing; Wed, 21 Aug 2002 19:32:11 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from popintmanex.poptel.org.uk (popintmanex.poptel.org.uk [213.55.9.22]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7LHW9o2022206 for <[e-mail]>; Wed, 21 Aug 2002 19:32:10 +0200 (MEST)
Received: by exchange.poptel.net with Internet Mail Service (5.5.2653.19) id <QA2BWN29>; Wed, 21 Aug 2002 18:32:06 +0100
Message-ID: <[e-mail]>
From: Susan Goodsir <[e-mail]>
To: [e-mail]
Subject: Subordinate hosts and domain transfers
Date: Wed, 21 Aug 2002 18:32:04 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7LCJgo2019444 for <[e-mail]>; Wed, 21 Aug 2002 14:19:43 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g7LCJg59019443 for ietf-provreg-outgoing; Wed, 21 Aug 2002 14:19:42 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7LCJfo2019438 for <[e-mail]>; Wed, 21 Aug 2002 14:19:41 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id IAA22802; Wed, 21 Aug 2002 08:20:25 -0400 (EDT)
Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <PXVASVRQ>; Wed, 21 Aug 2002 08:19:33 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Rick Wesson'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: epp status
Date: Wed, 21 Aug 2002 08:19:12 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7KJ1Lo2013530 for <[e-mail]>; Tue, 20 Aug 2002 21:01:21 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g7KJ1LBn013529 for ietf-provreg-outgoing; Tue, 20 Aug 2002 21:01:21 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bean.ar.com (bean.ar.com [66.123.187.68]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7KJ1Ko2013524 for <[e-mail]>; Tue, 20 Aug 2002 21:01:20 +0200 (MEST)
Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.2/8.12.0) with ESMTP id g7KJ1Gt6017596 for <[e-mail]>; Tue, 20 Aug 2002 12:01:16 -0700 (PDT)
Date: Tue, 20 Aug 2002 12:01:18 -0700 (PDT)
From: Rick Wesson <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: epp status
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

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


-rick




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7JNo0o2004822 for <[e-mail]>; Tue, 20 Aug 2002 01:50:00 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g7JNo0GW004821 for ietf-provreg-outgoing; Tue, 20 Aug 2002 01:50:00 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7JNnxo2004814 for <[e-mail]>; Tue, 20 Aug 2002 01:49:59 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id TAA06939; Mon, 19 Aug 2002 19:50:46 -0400 (EDT)
Received: by vsvapostalgw2.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <RGHVYXR0>; Mon, 19 Aug 2002 19:49:54 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Roger Castillo Cortazar'" <[e-mail]>, [e-mail]
Subject: RE: Result codes to handle protocol extension-related errors.
Date: Mon, 19 Aug 2002 19:49:36 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7JM63o2004280 for <[e-mail]>; Tue, 20 Aug 2002 00:06:03 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g7JM63Pe004279 for ietf-provreg-outgoing; Tue, 20 Aug 2002 00:06:03 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail.nic.mx (mail.nic.mx [200.23.1.77]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7JM61o2004271 for <[e-mail]>; Tue, 20 Aug 2002 00:06:02 +0200 (MEST)
Received: from RCASTILLO.nic.mx ([200.33.1.101]) (authenticated (0 bits)) by mail.nic.mx (8.11.6/8.11.6) with ESMTP id g7JM5xO27183 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO) for <[e-mail]>; Mon, 19 Aug 2002 17:05:59 -0500 (CDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Date: Mon, 19 Aug 2002 17:05:59 -0500
To: [e-mail]
From: Roger Castillo Cortazar <[e-mail]>
Subject: RE: Result codes to handle protocol extension-related errors.
In-Reply-To: <[e-mail]>
References: <[e-mail]. org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7JJX7o2003169 for <[e-mail]>; Mon, 19 Aug 2002 21:33:07 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g7JJX701003168 for ietf-provreg-outgoing; Mon, 19 Aug 2002 21:33:07 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7JJX5o2003161 for <[e-mail]>; Mon, 19 Aug 2002 21:33:06 +0200 (MEST)
Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id g7JJX2UW029797; Mon, 19 Aug 2002 21:33:02 +0200 (CEST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Roger Castillo Cortazar <[e-mail]>
cc: [e-mail]
Subject: Failed contribution to ietf-provreg
Date: Mon, 19 Aug 2002 21:33:02 +0200
From: Jaap Akkerhuis <[e-mail]>
Sender: [e-mail]
Precedence: bulk

	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 [e-mail] but your
message came from [e-mail]. 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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7JJIgo2003036 for <[e-mail]>; Mon, 19 Aug 2002 21:18:42 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g7JJIgbo003035 for ietf-provreg-outgoing; Mon, 19 Aug 2002 21:18:42 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7JJIfo2003030 for <[e-mail]>; Mon, 19 Aug 2002 21:18:42 +0200 (MEST)
Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id g7JJIeUW029748 for <[e-mail]>; Mon, 19 Aug 2002 21:18:40 +0200 (CEST) (envelope-from [e-mail])
Received: (from jaap@localhost) by bartok.sidn.nl (8.12.5/8.12.5/Submit) id g7JJIeWw029747 for [e-mail]; Mon, 19 Aug 2002 21:18:40 +0200 (CEST)
Received: from mail.nic.mx (mail.nic.mx [200.23.1.77]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7JI9Mo2002384 for <[e-mail]>; Mon, 19 Aug 2002 20:09:23 +0200 (MEST)
Received: from RCASTILLO.nic.mx ([200.33.1.101]) (authenticated (0 bits)) by mail.nic.mx (8.11.6/8.11.6) with ESMTP id g7JI9JO21548 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO) for <[e-mail]>; Mon, 19 Aug 2002 13:09:20 -0500 (CDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Date: Mon, 19 Aug 2002 13:09:19 -0500
To: [e-mail]
From: Roger Castillo Cortazar <[e-mail]>
Subject: RE: Result codes to handle protocol extension-related errors.
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7JJIUo2003028 for <[e-mail]>; Mon, 19 Aug 2002 21:18:30 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g7JJIUMK003027 for ietf-provreg-outgoing; Mon, 19 Aug 2002 21:18:30 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7JJISo2003019 for <[e-mail]>; Mon, 19 Aug 2002 21:18:29 +0200 (MEST)
Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id g7JJIMUW029738 for <[e-mail]>; Mon, 19 Aug 2002 21:18:22 +0200 (CEST) (envelope-from [e-mail])
Received: (from jaap@localhost) by bartok.sidn.nl (8.12.5/8.12.5/Submit) id g7JJIMKa029737 for [e-mail]; Mon, 19 Aug 2002 21:18:22 +0200 (CEST)
Received: from mail.nic.mx (mail.nic.mx [200.23.1.77]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7JGbmo2001636 for <[e-mail]>; Mon, 19 Aug 2002 18:37:48 +0200 (MEST)
Received: from RCASTILLO.nic.mx ([200.33.1.101]) (authenticated (0 bits)) by mail.nic.mx (8.11.6/8.11.6) with ESMTP id g7JGbiO18731 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO) for <[e-mail]>; Mon, 19 Aug 2002 11:37:45 -0500 (CDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Date: Mon, 19 Aug 2002 11:37:44 -0500
To: [e-mail]
From: Roger Castillo Cortazar <[e-mail]>
Subject: RE: Result codes to handle protocol extension-related errors.
In-Reply-To: <[e-mail]. org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7HKHeo2001300 for <[e-mail]>; Sat, 17 Aug 2002 22:17:40 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g7HKHeUm001299 for ietf-provreg-outgoing; Sat, 17 Aug 2002 22:17:40 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7HKHdo2001294 for <[e-mail]>; Sat, 17 Aug 2002 22:17:39 +0200 (MEST)
Received: from chiimc01.il.neustar.com (stih650a-eth-s1p2c0.va.neustar.com [209.173.53.81]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id g7HKHaC21307 for <[e-mail]>; Sat, 17 Aug 2002 20:17:37 GMT
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <QCQWVQ7D>; Sat, 17 Aug 2002 15:17:31 -0500
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E3EC2C4@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: Response Code 2501
Date: Sat, 17 Aug 2002 15:17:59 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
Sent: Thursday, August 15, 2002 10:13 AM
To: '[e-mail]'
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
<[e-mail]>                              M6K 3E3
                                         [phone] x110


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7G8a6o2013080 for <[e-mail]>; Fri, 16 Aug 2002 10:36:06 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g7G8a52R013079 for ietf-provreg-outgoing; Fri, 16 Aug 2002 10:36:05 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from astrid2.nic.fr (astrid2.nic.fr [192.134.4.2]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7G8a4o2013074 for <[e-mail]>; Fri, 16 Aug 2002 10:36:04 +0200 (MEST)
Received: from vespucci.nic.fr ([e-mail] [192.134.4.68]) by astrid2.nic.fr (8.9.1/jtpda-5.3.1) with ESMTP id KAA15873 ; Fri, 16 Aug 2002 10:36:02 +0200 (MET DST)
Received: by vespucci.nic.fr (Postfix, from userid 1000) id B6EFA10D30; Fri, 16 Aug 2002 10:36:02 +0200 (CEST)
Date: Fri, 16 Aug 2002 10:36:02 +0200
From: Stephane Bortzmeyer <[e-mail]>
To: Patrick <[e-mail]>
Cc: [e-mail]
Subject: Re: Using P3P technologies to express privacy preferences
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.28i
Organization: NIC France
X-URL: http://www.nic.fr/
X-Operating-System: Debian GNU/Linux 3.0
X-Kernel: Linux 2.4.18-686 i686
Sender: [e-mail]
Precedence: bulk

On Fri, Aug 16, 2002 at 10:23:00AM +0200,
 Patrick <[e-mail]> 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.


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7G8N6o2013008 for <[e-mail]>; Fri, 16 Aug 2002 10:23:06 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g7G8N6wJ013007 for ietf-provreg-outgoing; Fri, 16 Aug 2002 10:23:06 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nohope.patoche.org (nohope.patoche.org [80.67.173.199]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7G8N4o2013002 for <[e-mail]>; Fri, 16 Aug 2002 10:23:05 +0200 (MEST)
Received: from nohope.patoche.org (localhost.gandi.net [127.0.0.1]) by nohope.patoche.org (8.12.1/8.12.1/Debian -5) with ESMTP id g7G8N0T8013653 for <[e-mail]>; Fri, 16 Aug 2002 10:23:00 +0200
Received: (from patrick@localhost) by nohope.patoche.org (8.12.1/8.12.1/Debian -5) id g7G8N03I013651 for [e-mail]; Fri, 16 Aug 2002 10:23:00 +0200
Date: Fri, 16 Aug 2002 10:23:00 +0200
From: Patrick <[e-mail]>
To: [e-mail]
Subject: Re: Using P3P technologies to express privacy preferences
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.24i
X-PGP-KeyID: A241FB6B
X-Request-PGP: http://www.keyserver.net:11371/pks/lookup?op=vindex&search=0xA241FB6B
Organization: Gandi
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7G7x1o2012862 for <[e-mail]>; Fri, 16 Aug 2002 09:59:01 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g7G7x1gk012861 for ietf-provreg-outgoing; Fri, 16 Aug 2002 09:59:01 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from astrid2.nic.fr (astrid2.nic.fr [192.134.4.2]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7G7x0o2012856 for <[e-mail]>; Fri, 16 Aug 2002 09:59:00 +0200 (MEST)
Received: from vespucci.nic.fr ([e-mail] [192.134.4.68]) by astrid2.nic.fr (8.9.1/jtpda-5.3.1) with ESMTP id JAA32175 for <[e-mail]>; Fri, 16 Aug 2002 09:58:58 +0200 (MET DST)
Received: by vespucci.nic.fr (Postfix, from userid 1000) id CBBAA10D30; Fri, 16 Aug 2002 09:58:57 +0200 (CEST)
Date: Fri, 16 Aug 2002 09:58:57 +0200
From: Stephane Bortzmeyer <[e-mail]>
To: [e-mail]
Subject: Using P3P technologies to express privacy preferences
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.28i
Organization: NIC France
X-URL: http://www.nic.fr/
X-Operating-System: Debian GNU/Linux 3.0
X-Kernel: Linux 2.4.18-686 i686
Sender: [e-mail]
Precedence: bulk

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?



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7FEsBo2005776 for <[e-mail]>; Thu, 15 Aug 2002 16:54:11 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g7FEsBKl005775 for ietf-provreg-outgoing; Thu, 15 Aug 2002 16:54:11 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7FEsAo2005770 for <[e-mail]>; Thu, 15 Aug 2002 16:54:10 +0200 (MEST)
Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id g7FEs4UW096639 for <[e-mail]>; Thu, 15 Aug 2002 16:54:04 +0200 (CEST) (envelope-from [e-mail])
Received: (from jaap@localhost) by bartok.sidn.nl (8.12.5/8.12.5/Submit) id g7FEs3sa096638 for [e-mail]; Thu, 15 Aug 2002 16:54:03 +0200 (CEST)
Received: from mail.libertyrms.com ([216.94.172.167]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7FECho2005450 for <[e-mail]>; Thu, 15 Aug 2002 16:12:44 +0200 (MEST)
Received: from andrew by mail.libertyrms.com with local (Exim 3.22 #3 (Debian)) id 17fLMb-0001k2-00 for <[e-mail]>; Thu, 15 Aug 2002 10:12:37 -0400
Date: Thu, 15 Aug 2002 10:12:37 -0400
From: Andrew Sullivan <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Re: Response Code 2501
Message-ID: <[e-mail]>
Mail-Followup-To: Andrew Sullivan <[e-mail]>, "'[e-mail]'" <[e-mail]>
References: <5E42C1C85C5D064A947CF92FADE6D82E08418E@STNTEXCH1>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <5E42C1C85C5D064A947CF92FADE6D82E08418E@STNTEXCH1>; from [e-mail] on Thu, Aug 15, 2002 at 12:03:24AM -0400
Sender: [e-mail]
Precedence: bulk

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7FCXro2004614 for <[e-mail]>; Thu, 15 Aug 2002 14:33:53 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g7FCXr2J004613 for ietf-provreg-outgoing; Thu, 15 Aug 2002 14:33:53 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7FCXqo2004608 for <[e-mail]>; Thu, 15 Aug 2002 14:33:52 +0200 (MEST)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g7F8Xm23041026; Thu, 15 Aug 2002 08:33:49 GMT
Received: from [192.149.252.169] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id IAA22320; Thu, 15 Aug 2002 08:33:48 -0400 (EDT)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b02b9814d1122e2@[192.149.252.169]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Thu, 15 Aug 2002 08:25:33 -0400
To: "Hollenbeck, Scott" <[e-mail]>, "'Robert Burbidge'" <[e-mail]>, "Ietf-Provreg (E-mail)" <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: RE: Header in TCP Mapping
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7FAvso2004114 for <[e-mail]>; Thu, 15 Aug 2002 12:57:54 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g7FAvsav004113 for ietf-provreg-outgoing; Thu, 15 Aug 2002 12:57:54 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7FAvro2004108 for <[e-mail]>; Thu, 15 Aug 2002 12:57:53 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id GAA08104; Thu, 15 Aug 2002 06:58:39 -0400 (EDT)
Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <PXVAM76D>; Thu, 15 Aug 2002 06:57:50 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Rick Wesson'" <[e-mail]>, [e-mail]
Subject: RE: BEEP transport
Date: Thu, 15 Aug 2002 06:57:33 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7F7LWo2002763 for <[e-mail]>; Thu, 15 Aug 2002 09:21:32 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g7F7LWE6002762 for ietf-provreg-outgoing; Thu, 15 Aug 2002 09:21:32 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7F7LVo2002757 for <[e-mail]>; Thu, 15 Aug 2002 09:21:31 +0200 (MEST)
Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id g7F7LTUW026738 for <[e-mail]>; Thu, 15 Aug 2002 09:21:29 +0200 (CEST) (envelope-from [e-mail])
Received: (from jaap@localhost) by bartok.sidn.nl (8.12.5/8.12.5/Submit) id g7F7LTOR026727 for [e-mail]; Thu, 15 Aug 2002 09:21:29 +0200 (CEST)
Received: from mail.libertyrms.com ([216.94.172.167]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7EG7oo2025753 for <[e-mail]>; Wed, 14 Aug 2002 18:07:51 +0200 (MEST)
Received: from [10.1.1.139] (helo=dun220) by mail.libertyrms.com with esmtp (Exim 3.22 #3 (Debian)) id 17f0gV-0006IL-00; Wed, 14 Aug 2002 12:07:47 -0400
From: "Michael Young" <[e-mail]>
To: "'Rick Wesson'" <[e-mail]>, <[e-mail]>
Subject: RE: BEEP transport
Date: Wed, 14 Aug 2002 12:07:40 -0400
Message-ID: <003501c243ac$b6fa2d40$8b01010a@dun220>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

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

Michael Young


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Rick Wesson
Sent: Wednesday, August 14, 2002 11:24 AM
To: '[e-mail]'
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





Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7F4NOo2001870 for <[e-mail]>; Thu, 15 Aug 2002 06:23:24 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g7F4NOm7001869 for ietf-provreg-outgoing; Thu, 15 Aug 2002 06:23:24 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7F4NNo2001864 for <[e-mail]>; Thu, 15 Aug 2002 06:23:23 +0200 (MEST)
Received: from chiimc01.il.neustar.com (stih650a-eth-s1p2c0.va.neustar.com [209.173.53.81]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id g7F4NLC10081 for <[e-mail]>; Thu, 15 Aug 2002 04:23:21 GMT
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <QCQWVB06>; Wed, 14 Aug 2002 23:23:16 -0500
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E08418F@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: Response Code 2501
Date: Wed, 14 Aug 2002 23:23:47 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
Sent: Wednesday, August 14, 2002 10:09 AM
To: '[e-mail]'
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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7F43Bo2001749 for <[e-mail]>; Thu, 15 Aug 2002 06:03:11 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g7F43BTA001748 for ietf-provreg-outgoing; Thu, 15 Aug 2002 06:03:11 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7F43Ao2001743 for <[e-mail]>; Thu, 15 Aug 2002 06:03:10 +0200 (MEST)
Received: from stntimc1.va.neustar.com (stih650a-eth-s1p2c0.va.neustar.com [209.173.53.81]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id g7F438C09916 for <[e-mail]>; Thu, 15 Aug 2002 04:03:08 GMT
Received: by STNTIMC1 with Internet Mail Service (5.5.2653.19) id <306V48QB>; Thu, 15 Aug 2002 00:04:01 -0400
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E08418E@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: Response Code 2501
Date: Thu, 15 Aug 2002 00:03:24 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Scott,

I 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:[e-mail]]
Sent: Wednesday, August 14, 2002 9:39 AM
To: 'Liu, Hong'; '[e-mail]'
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-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7EFjno2025496 for <[e-mail]>; Wed, 14 Aug 2002 17:45:49 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g7EFjnGU025495 for ietf-provreg-outgoing; Wed, 14 Aug 2002 17:45:49 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from popintmanex.poptel.org.uk (popintmanex.poptel.org.uk [213.55.9.22]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7EFjlo2025490 for <[e-mail]>; Wed, 14 Aug 2002 17:45:48 +0200 (MEST)
Received: by exchange.poptel.net with Internet Mail Service (5.5.2653.19) id <QA2BVPB1>; Wed, 14 Aug 2002 16:45:46 +0100
Message-ID: <[e-mail]>
From: Robert Burbidge <[e-mail]>
To: "Ietf-Provreg (E-mail)" <[e-mail]>
Subject: RE: BEEP transport
Date: Wed, 14 Aug 2002 16:45:42 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

>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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7EFNho2025317 for <[e-mail]>; Wed, 14 Aug 2002 17:23:43 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g7EFNhdV025316 for ietf-provreg-outgoing; Wed, 14 Aug 2002 17:23:43 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bean.ar.com (bean.ar.com [66.123.187.68]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7EFNfo2025311 for <[e-mail]>; Wed, 14 Aug 2002 17:23:41 +0200 (MEST)
Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.2/8.12.0) with ESMTP id g7EFNbA2001929 for <[e-mail]>; Wed, 14 Aug 2002 08:23:37 -0700 (PDT)
Date: Wed, 14 Aug 2002 08:23:39 -0700 (PDT)
From: Rick Wesson <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: BEEP transport
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

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




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7EEtmo2025078 for <[e-mail]>; Wed, 14 Aug 2002 16:55:48 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g7EEtmY4025077 for ietf-provreg-outgoing; Wed, 14 Aug 2002 16:55:48 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7EEtlo2025072 for <[e-mail]>; Wed, 14 Aug 2002 16:55:47 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id KAA21870; Wed, 14 Aug 2002 10:56:33 -0400 (EDT)
Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <PXVAMDCC>; Wed, 14 Aug 2002 10:55:43 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Robert Burbidge'" <[e-mail]>, "Ietf-Provreg (E-mail)" <[e-mail]>
Subject: RE: Byte order marks and character sets
Date: Wed, 14 Aug 2002 10:55:27 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7EEhko2024939 for <[e-mail]>; Wed, 14 Aug 2002 16:43:46 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g7EEhkRs024938 for ietf-provreg-outgoing; Wed, 14 Aug 2002 16:43:46 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7EEhjo2024932 for <[e-mail]>; Wed, 14 Aug 2002 16:43:45 +0200 (MEST)
Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id g7EEhhUW004649 for <[e-mail]>; Wed, 14 Aug 2002 16:43:43 +0200 (CEST) (envelope-from [e-mail])
Received: (from jaap@localhost) by bartok.sidn.nl (8.12.5/8.12.5/Submit) id g7EEhhw5004648 for [e-mail]; Wed, 14 Aug 2002 16:43:43 +0200 (CEST)
Received: from mail.libertyrms.com ([216.94.172.167]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7EEEwo2024604 for <[e-mail]>; Wed, 14 Aug 2002 16:14:58 +0200 (MEST)
Received: from andrew by mail.libertyrms.com with local (Exim 3.22 #3 (Debian)) id 17eyvI-0004Ho-00 for <[e-mail]>; Wed, 14 Aug 2002 10:14:56 -0400
Date: Wed, 14 Aug 2002 10:14:56 -0400
From: Andrew Sullivan <[e-mail]>
To: [e-mail]
Subject: Re: Result codes to handle protocol extension-related errors.
Message-ID: <[e-mail]>
Mail-Followup-To: Andrew Sullivan <[e-mail]>, [e-mail]
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Wed, Aug 14, 2002 at 09:48:22AM -0400
Sender: [e-mail]
Precedence: bulk

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7EEgno2024922 for <[e-mail]>; Wed, 14 Aug 2002 16:42:49 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g7EEgnUf024921 for ietf-provreg-outgoing; Wed, 14 Aug 2002 16:42:49 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7EEgmo2024916 for <[e-mail]>; Wed, 14 Aug 2002 16:42:48 +0200 (MEST)
Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id g7EEgkUW004636 for <[e-mail]>; Wed, 14 Aug 2002 16:42:46 +0200 (CEST) (envelope-from [e-mail])
Received: (from jaap@localhost) by bartok.sidn.nl (8.12.5/8.12.5/Submit) id g7EEgkIL004635 for [e-mail]; Wed, 14 Aug 2002 16:42:46 +0200 (CEST)
Received: from leo.dk.speednames.com (leo.dk.speednames.com [213.237.145.52]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7EE9Fo2024552 for <[e-mail]>; Wed, 14 Aug 2002 16:09:16 +0200 (MEST)
Received: from aries.dk.speednames.com (unverified) by leo.dk.speednames.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <[e-mail]> for <[e-mail]>; Wed, 14 Aug 2002 16:09:12 +0200
Received: by aries.dk.speednames.com with Internet Mail Service (5.5.2655.55) id <QT3C5FV3>; Wed, 14 Aug 2002 16:09:12 +0200
Message-ID: <[e-mail]>
From: Claus Dahl <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: Response Code 2501
Date: Wed, 14 Aug 2002 16:09:11 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
Sent: 14. august 2002 15:39
To: 'Liu, Hong'; '[e-mail]'
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-



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7EEKdo2024664 for <[e-mail]>; Wed, 14 Aug 2002 16:20:39 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g7EEKdUI024663 for ietf-provreg-outgoing; Wed, 14 Aug 2002 16:20:39 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from popintmanex.poptel.org.uk (popintmanex.poptel.org.uk [213.55.9.22]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7EEKco2024658 for <[e-mail]>; Wed, 14 Aug 2002 16:20:38 +0200 (MEST)
Received: by exchange.poptel.net with Internet Mail Service (5.5.2653.19) id <QA2BV3VR>; Wed, 14 Aug 2002 15:20:36 +0100
Message-ID: <[e-mail]>
From: Robert Burbidge <[e-mail]>
To: "Ietf-Provreg (E-mail)" <[e-mail]>
Subject: RE: Result codes to handle protocol extension-related errors.
Date: Wed, 14 Aug 2002 15:20:26 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

>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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7EE5oo2024532 for <[e-mail]>; Wed, 14 Aug 2002 16:05:50 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g7EE5oTm024531 for ietf-provreg-outgoing; Wed, 14 Aug 2002 16:05:50 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from popintmanex.poptel.org.uk (popintmanex.poptel.org.uk [213.55.9.22]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7EE5mo2024526 for <[e-mail]>; Wed, 14 Aug 2002 16:05:49 +0200 (MEST)
Received: by exchange.poptel.net with Internet Mail Service (5.5.2653.19) id <QA2BV3TT>; Wed, 14 Aug 2002 15:05:45 +0100
Message-ID: <[e-mail]>
From: Robert Burbidge <[e-mail]>
To: "Ietf-Provreg (E-mail)" <[e-mail]>
Subject: Byte order marks and character sets
Date: Wed, 14 Aug 2002 15:05:37 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

>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




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7EDmYo2024347 for <[e-mail]>; Wed, 14 Aug 2002 15:48:34 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g7EDmYoI024346 for ietf-provreg-outgoing; Wed, 14 Aug 2002 15:48:34 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7EDmXo2024341 for <[e-mail]>; Wed, 14 Aug 2002 15:48:33 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id JAA16953; Wed, 14 Aug 2002 09:49:19 -0400 (EDT)
Received: by vsvapostalgw2.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <PX4QDJ3R>; Wed, 14 Aug 2002 09:48:30 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Roger Castillo Cortazar'" <[e-mail]>, [e-mail]
Subject: RE: Result codes to handle protocol extension-related errors.
Date: Wed, 14 Aug 2002 09:48:22 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7EDdao2024267 for <[e-mail]>; Wed, 14 Aug 2002 15:39:36 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g7EDdaeT024266 for ietf-provreg-outgoing; Wed, 14 Aug 2002 15:39:36 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7EDdYo2024261 for <[e-mail]>; Wed, 14 Aug 2002 15:39:35 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id JAA16381; Wed, 14 Aug 2002 09:40:17 -0400 (EDT)
Received: by vsvapostalgw2.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <PX4QDJ24>; Wed, 14 Aug 2002 09:39:27 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Liu, Hong'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Response Code 2501
Date: Wed, 14 Aug 2002 09:39:18 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7EDWQo2024194 for <[e-mail]>; Wed, 14 Aug 2002 15:32:26 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g7EDWQCt024193 for ietf-provreg-outgoing; Wed, 14 Aug 2002 15:32:26 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7EDWPo2024188 for <[e-mail]>; Wed, 14 Aug 2002 15:32:25 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id JAA15866; Wed, 14 Aug 2002 09:33:06 -0400 (EDT)
Received: by vsvapostalgw2.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <PX4QDJD8>; Wed, 14 Aug 2002 09:32:16 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Robert Burbidge'" <[e-mail]>, "Ietf-Provreg (E-mail)" <[e-mail]>
Subject: RE: Byte order marks and character sets
Date: Wed, 14 Aug 2002 09:32:05 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7EAAjo2022696 for <[e-mail]>; Wed, 14 Aug 2002 12:10:45 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g7EAAjsD022695 for ietf-provreg-outgoing; Wed, 14 Aug 2002 12:10:45 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7EAAio2022690 for <[e-mail]>; Wed, 14 Aug 2002 12:10:44 +0200 (MEST)
Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id g7EAAcUW003155 for <[e-mail]>; Wed, 14 Aug 2002 12:10:38 +0200 (CEST) (envelope-from [e-mail])
Received: (from jaap@localhost) by bartok.sidn.nl (8.12.5/8.12.5/Submit) id g7EAAbbA003154 for [e-mail]; Wed, 14 Aug 2002 12:10:37 +0200 (CEST)
Received: from mail.nic.mx (mail.nic.mx [200.23.1.77]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7DICoo2016257 for <[e-mail]>; Tue, 13 Aug 2002 20:12:51 +0200 (MEST)
Received: from RCASTILLO.nic.mx ([200.33.1.101]) (authenticated (0 bits)) by mail.nic.mx (8.11.6/8.11.6) with ESMTP id g7DICkM27084 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO); Tue, 13 Aug 2002 13:12:47 -0500 (CDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Date: Tue, 13 Aug 2002 13:12:46 -0500
To: [e-mail]
From: Roger Castillo Cortazar <[e-mail]>
Subject: Result codes to handle protocol extension-related errors.
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7E0Xuo2018863 for <[e-mail]>; Wed, 14 Aug 2002 02:33:56 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g7E0XuUS018862 for ietf-provreg-outgoing; Wed, 14 Aug 2002 02:33:56 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7E0Xto2018857 for <[e-mail]>; Wed, 14 Aug 2002 02:33:55 +0200 (MEST)
Received: from stntimc1.va.neustar.com (stih650a-eth-s1p2c0.va.neustar.com [209.173.53.81]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id g7E0Xr117490 for <[e-mail]>; Wed, 14 Aug 2002 00:33:53 GMT
Received: by STNTIMC1 with Internet Mail Service (5.5.2653.19) id <306V47KX>; Tue, 13 Aug 2002 20:34:46 -0400
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E084178@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: Response Code 2501
Date: Tue, 13 Aug 2002 20:34:20 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Scott,

I 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:[e-mail]]
Sent: Tuesday, August 13, 2002 7:51 PM
To: 'Liu, Hong'; '[e-mail]'
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-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7DNpio2018605 for <[e-mail]>; Wed, 14 Aug 2002 01:51:44 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g7DNpinK018604 for ietf-provreg-outgoing; Wed, 14 Aug 2002 01:51:44 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7DNpfo2018599 for <[e-mail]>; Wed, 14 Aug 2002 01:51:42 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id TAA26285; Tue, 13 Aug 2002 19:52:19 -0400 (EDT)
Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <PXVAL48R>; Tue, 13 Aug 2002 19:51:30 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Liu, Hong'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Response Code 2501
Date: Tue, 13 Aug 2002 19:51:22 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7DHKho2015749 for <[e-mail]>; Tue, 13 Aug 2002 19:20:43 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g7DHKhRj015748 for ietf-provreg-outgoing; Tue, 13 Aug 2002 19:20:43 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7DHKdo2015743 for <[e-mail]>; Tue, 13 Aug 2002 19:20:42 +0200 (MEST)
Received: from chiimc01.il.neustar.com (stih650a-eth-s1p2c0.va.neustar.com [209.173.53.81]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id g7DHKb108800 for <[e-mail]>; Tue, 13 Aug 2002 17:20:38 GMT
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <QCQW4XC6>; Tue, 13 Aug 2002 12:20:32 -0500
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E084177@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: Response Code 2501
Date: Tue, 13 Aug 2002 12:21:04 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
Sent: Monday, August 12, 2002 3:58 PM
To: 'Liu, Hong'; '[e-mail]'
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-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7DCFso2013126 for <[e-mail]>; Tue, 13 Aug 2002 14:15:54 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g7DCFsuo013125 for ietf-provreg-outgoing; Tue, 13 Aug 2002 14:15:54 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7DCFro2013120 for <[e-mail]>; Tue, 13 Aug 2002 14:15:53 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id IAA14004; Tue, 13 Aug 2002 08:16:36 -0400 (EDT)
Received: by vsvapostalgw2.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <PX4QCV27>; Tue, 13 Aug 2002 08:15:47 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Robert Burbidge'" <[e-mail]>, "Ietf-Provreg (E-mail)" <[e-mail]>
Subject: RE: Command-Response Extension - Minor ambiguity in specification ?
Date: Tue, 13 Aug 2002 08:15:39 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7DAP0o2012602 for <[e-mail]>; Tue, 13 Aug 2002 12:25:00 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g7DAP0FI012601 for ietf-provreg-outgoing; Tue, 13 Aug 2002 12:25:00 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from popintmanex.poptel.org.uk (popintmanex.poptel.org.uk [213.55.9.22]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7DAOxo2012596 for <[e-mail]>; Tue, 13 Aug 2002 12:24:59 +0200 (MEST)
Received: by exchange.poptel.net with Internet Mail Service (5.5.2653.19) id <QA2BVK5Y>; Tue, 13 Aug 2002 11:24:57 +0100
Message-ID: <[e-mail]>
From: Robert Burbidge <[e-mail]>
To: "Ietf-Provreg (E-mail)" <[e-mail]>
Subject: Command-Response Extension - Minor ambiguity in specification?
Date: Tue, 13 Aug 2002 11:24:57 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7D9xeo2012453 for <[e-mail]>; Tue, 13 Aug 2002 11:59:40 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g7D9xefp012452 for ietf-provreg-outgoing; Tue, 13 Aug 2002 11:59:40 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail.net-design.net (mail.net-design.net [195.127.214.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7D9xdo2012447 for <[e-mail]>; Tue, 13 Aug 2002 11:59:40 +0200 (MEST)
Received: from (tullius.shw.com) [195.127.214.3]  by mail.net-design.net with esmtp (Exim 3.12 #1 (Debian)) id 17eYSd-0000Qa-00; Tue, 13 Aug 2002 11:59:35 +0200
Received: from lutetia.dss (localhost.localdomain) [172.29.101.129] (sven) by tullius.shw.com with esmtp (Exim 3.12 #1 (Debian)) id 17eYS9-00067I-00; Tue, 13 Aug 2002 11:59:05 +0200
Subject: RE: [[e-mail]: [open-eu] Open Registry Robot  / EPP transport layer]
From: Sven-Holger Wabnitz <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
Cc: [e-mail], open-eu discuss <[e-mail]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Elo68tczeiB3baqQ9abd"
X-Mailer: Ximian Evolution 1.0.5 
Date: 13 Aug 2002 11:58:54 +0200
Message-Id: <1029232745.21668.87.camel@lutetia>
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk

--=-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 [phone]            **             fax [phone]
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

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8

iQA/AwUAPVjYXaPdS86CNWfsEQLvwgCgobhKQFr9pgkda8UVVJTZD3iSneEAoOiv
LEDzRZOhm87k6jH/9KdLeau/
=1sBn
-----END PGP SIGNATURE-----

--=-Elo68tczeiB3baqQ9abd--



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7D8qxo2011962 for <[e-mail]>; Tue, 13 Aug 2002 10:52:59 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g7D8qxST011961 for ietf-provreg-outgoing; Tue, 13 Aug 2002 10:52:59 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from popintmanex.poptel.org.uk (popintmanex.poptel.org.uk [213.55.9.22]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7D8qvo2011956 for <[e-mail]>; Tue, 13 Aug 2002 10:52:58 +0200 (MEST)
Received: by exchange.poptel.net with Internet Mail Service (5.5.2653.19) id <QA2BVKPP>; Tue, 13 Aug 2002 09:52:55 +0100
Message-ID: <[e-mail]>
From: Robert Burbidge <[e-mail]>
To: "Ietf-Provreg (E-mail)" <[e-mail]>
Subject: RE: Byte order marks and character sets
Date: Tue, 13 Aug 2002 09:52:52 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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.



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7CJvno2007158 for <[e-mail]>; Mon, 12 Aug 2002 21:57:49 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g7CJvmVj007157 for ietf-provreg-outgoing; Mon, 12 Aug 2002 21:57:48 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7CJvlo2007152 for <[e-mail]>; Mon, 12 Aug 2002 21:57:48 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id PAA19852; Mon, 12 Aug 2002 15:58:29 -0400 (EDT)
Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <PXVAKSAL>; Mon, 12 Aug 2002 15:57:40 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Liu, Hong'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Response Code 2501
Date: Mon, 12 Aug 2002 15:57:34 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7CJqmo2007062 for <[e-mail]>; Mon, 12 Aug 2002 21:52:48 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g7CJqlsv007061 for ietf-provreg-outgoing; Mon, 12 Aug 2002 21:52:47 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail.libertyrms.com ([216.94.172.167]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7CJqko2007056 for <[e-mail]>; Mon, 12 Aug 2002 21:52:46 +0200 (MEST)
Received: from dev3.int.libertyrms.com ([10.1.1.204] helo=libertyrms.info) by mail.libertyrms.com with esmtp (Exim 3.22 #3 (Debian)) id 17eLF2-0001o1-00; Mon, 12 Aug 2002 15:52:40 -0400
Message-ID: <[e-mail]>
Date: Mon, 12 Aug 2002 15:53:51 -0400
From: janusz sienkiewicz <[e-mail]>
Organization: LibertyRMS Co.
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Hollenbeck, Scott" <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: Response Code 2501
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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-



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7CJTRo2006757 for <[e-mail]>; Mon, 12 Aug 2002 21:29:27 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g7CJTRql006756 for ietf-provreg-outgoing; Mon, 12 Aug 2002 21:29:27 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7CJTPo2006751 for <[e-mail]>; Mon, 12 Aug 2002 21:29:26 +0200 (MEST)
Received: from stntimc1.va.neustar.com (stih650a-eth-s1p2c0.va.neustar.com [209.173.53.81]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id g7CJTNS21055 for <[e-mail]>; Mon, 12 Aug 2002 19:29:24 GMT
Received: by STNTIMC1 with Internet Mail Service (5.5.2653.19) id <306V45V9>; Mon, 12 Aug 2002 15:30:16 -0400
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E084165@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: Response Code 2501
Date: Mon, 12 Aug 2002 15:29:53 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Scott,

I 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:[e-mail]]
Sent: Monday, August 12, 2002 11:58 AM
To: 'Liu, Hong'; '[e-mail]'
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-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7CHlso2006029 for <[e-mail]>; Mon, 12 Aug 2002 19:47:54 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g7CHlsK1006028 for ietf-provreg-outgoing; Mon, 12 Aug 2002 19:47:54 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7CHlqo2006023 for <[e-mail]>; Mon, 12 Aug 2002 19:47:53 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id NAA10931; Mon, 12 Aug 2002 13:48:37 -0400 (EDT)
Received: by vsvapostalgw2.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <PX4QCKRN>; Mon, 12 Aug 2002 13:47:47 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Robert Burbidge'" <[e-mail]>, "Ietf-Provreg (E-mail)" <[e-mail]>
Subject: RE: Byte order marks and character sets
Date: Mon, 12 Aug 2002 13:47:42 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7CGpco2005691 for <[e-mail]>; Mon, 12 Aug 2002 18:51:38 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g7CGpcFt005690 for ietf-provreg-outgoing; Mon, 12 Aug 2002 18:51:38 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from popintmanex.poptel.org.uk (popintmanex.poptel.org.uk [213.55.9.22]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7CGpbo2005685 for <[e-mail]>; Mon, 12 Aug 2002 18:51:37 +0200 (MEST)
Received: by exchange.poptel.net with Internet Mail Service (5.5.2653.19) id <QA2BV26G>; Mon, 12 Aug 2002 17:51:34 +0100
Message-ID: <[e-mail]>
From: Robert Burbidge <[e-mail]>
To: "Ietf-Provreg (E-mail)" <[e-mail]>
Subject: RE: Byte order marks and character sets
Date: Mon, 12 Aug 2002 17:51:33 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

>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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7CGUQo2005458 for <[e-mail]>; Mon, 12 Aug 2002 18:30:26 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g7CGUP9O005457 for ietf-provreg-outgoing; Mon, 12 Aug 2002 18:30:25 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7CGUOo2005452 for <[e-mail]>; Mon, 12 Aug 2002 18:30:25 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id MAA06115; Mon, 12 Aug 2002 12:31:10 -0400 (EDT)
Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <PXVAKMLC>; Mon, 12 Aug 2002 12:30:21 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Robert Burbidge'" <[e-mail]>, "Ietf-Provreg (E-mail)" <[e-mail]>
Subject: RE: Byte order marks and character sets
Date: Mon, 12 Aug 2002 12:30:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7CGM8o2005391 for <[e-mail]>; Mon, 12 Aug 2002 18:22:08 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g7CGM83h005390 for ietf-provreg-outgoing; Mon, 12 Aug 2002 18:22:08 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7CGM7o2005385 for <[e-mail]>; Mon, 12 Aug 2002 18:22:07 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id MAA05555 for <[e-mail]>; Mon, 12 Aug 2002 12:22:54 -0400 (EDT)
Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <PXVAKM1Y>; Mon, 12 Aug 2002 12:22:05 -0400
Message-ID: <[e-mail]>
From: "Gould, James" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "Hollenbeck, Scott" <[e-mail]>
Subject: RE: Response Code 2501
Date: Mon, 12 Aug 2002 12:22:00 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7CGBfo2005295 for <[e-mail]>; Mon, 12 Aug 2002 18:11:41 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g7CGBfOa005294 for ietf-provreg-outgoing; Mon, 12 Aug 2002 18:11:41 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ns01.afilias.info (ns01.afilias.info [66.45.25.225]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7CGBdo2005289 for <[e-mail]>; Mon, 12 Aug 2002 18:11:40 +0200 (MEST)
Received: from RAMLAPTOP (252.55.217.216.transedge.com [216.217.55.252]) (authenticated) by ns01.afilias.info (8.11.2/8.11.2) with ESMTP id g7CGBWF04088; Mon, 12 Aug 2002 12:11:32 -0400
Message-ID: <00fa01c2421a$ec3ed980$[e-mail]>
From: "Ram Mohan" <[e-mail]>
To: "Liu, Hong" <[e-mail]>, <[e-mail]>
References: <5E42C1C85C5D064A947CF92FADE6D82E08415A@STNTEXCH1>
Subject: Re: Response Code 2501
Date: Mon, 12 Aug 2002 12:11:18 -0400
Organization: Afilias
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk

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" <[e-mail]>
To: <[e-mail]>
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:[e-mail]]
> Sent: Monday, August 12, 2002 10:52 AM
> To: '[e-mail]'
> 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-
>




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7CG0So2005175 for <[e-mail]>; Mon, 12 Aug 2002 18:00:28 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g7CG0SNL005174 for ietf-provreg-outgoing; Mon, 12 Aug 2002 18:00:28 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7CG0Ro2005167 for <[e-mail]>; Mon, 12 Aug 2002 18:00:28 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id MAA04268; Mon, 12 Aug 2002 12:01:12 -0400 (EDT)
Received: by vsvapostalgw2.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <PX4QC23W>; Mon, 12 Aug 2002 12:00:23 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Robert Burbidge'" <[e-mail]>, "Ietf-Provreg (E-mail)" <[e-mail]>
Subject: RE: Header in TCP Mapping
Date: Mon, 12 Aug 2002 12:00:18 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7CFvio2005125 for <[e-mail]>; Mon, 12 Aug 2002 17:57:44 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g7CFvigO005124 for ietf-provreg-outgoing; Mon, 12 Aug 2002 17:57:44 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7CFvho2005119 for <[e-mail]>; Mon, 12 Aug 2002 17:57:43 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id LAA03976; Mon, 12 Aug 2002 11:58:25 -0400 (EDT)
Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <PXVAKLN2>; Mon, 12 Aug 2002 11:57:36 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Liu, Hong'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Response Code 2501
Date: Mon, 12 Aug 2002 11:57:30 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7CFeeo2005007 for <[e-mail]>; Mon, 12 Aug 2002 17:40:40 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g7CFee1e005006 for ietf-provreg-outgoing; Mon, 12 Aug 2002 17:40:40 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from popintmanex.poptel.org.uk (popintmanex.poptel.org.uk [213.55.9.22]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7CFeco2005001 for <[e-mail]>; Mon, 12 Aug 2002 17:40:39 +0200 (MEST)
Received: by exchange.poptel.net with Internet Mail Service (5.5.2653.19) id <QA2BV2T5>; Mon, 12 Aug 2002 16:40:35 +0100
Message-ID: <[e-mail]>
From: Robert Burbidge <[e-mail]>
To: "Ietf-Provreg (E-mail)" <[e-mail]>
Subject: Byte order marks and character sets
Date: Mon, 12 Aug 2002 16:40:32 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7CFaho2004980 for <[e-mail]>; Mon, 12 Aug 2002 17:36:43 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g7CFahK5004979 for ietf-provreg-outgoing; Mon, 12 Aug 2002 17:36:43 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7CFago2004974 for <[e-mail]>; Mon, 12 Aug 2002 17:36:42 +0200 (MEST)
Received: from stntimc1.va.neustar.com (stih650a-eth-s1p2c0.va.neustar.com [209.173.53.81]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id g7CFaeS14262 for <[e-mail]>; Mon, 12 Aug 2002 15:36:40 GMT
Received: by STNTIMC1 with Internet Mail Service (5.5.2653.19) id <306V451A>; Mon, 12 Aug 2002 11:37:33 -0400
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E08415A@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: Response Code 2501
Date: Mon, 12 Aug 2002 11:37:08 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Scott,

I 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:[e-mail]]
Sent: Monday, August 12, 2002 10:52 AM
To: '[e-mail]'
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-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7CFOGo2004904 for <[e-mail]>; Mon, 12 Aug 2002 17:24:16 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g7CFOG9J004903 for ietf-provreg-outgoing; Mon, 12 Aug 2002 17:24:16 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from popintmanex.poptel.org.uk (popintmanex.poptel.org.uk [213.55.9.22]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7CFOEo2004898 for <[e-mail]>; Mon, 12 Aug 2002 17:24:15 +0200 (MEST)
Received: by exchange.poptel.net with Internet Mail Service (5.5.2653.19) id <QA2BV2SA>; Mon, 12 Aug 2002 16:24:08 +0100
Message-ID: <[e-mail]>
From: Robert Burbidge <[e-mail]>
To: "Ietf-Provreg (E-mail)" <[e-mail]>
Subject: RE: Header in TCP Mapping
Date: Mon, 12 Aug 2002 16:24:08 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
Sent: 12 August 2002 13:13
To: '[e-mail]'
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-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7CF0fo2004769 for <[e-mail]>; Mon, 12 Aug 2002 17:00:41 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g7CF0edf004768 for ietf-provreg-outgoing; Mon, 12 Aug 2002 17:00:40 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7CF0do2004763 for <[e-mail]>; Mon, 12 Aug 2002 17:00:40 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id LAA29768 for <[e-mail]>; Mon, 12 Aug 2002 11:01:27 -0400 (EDT)
Received: by vsvapostalgw2.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <PX4QCHD6>; Mon, 12 Aug 2002 11:00:38 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Stephane Bortzmeyer'" <[e-mail]>, [e-mail]
Subject: RE: [[e-mail]: [open-eu] Open Registry Robot  / EPP transport layer]
Date: Mon, 12 Aug 2002 11:00:32 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7CEqKo2004694 for <[e-mail]>; Mon, 12 Aug 2002 16:52:20 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g7CEqKA5004693 for ietf-provreg-outgoing; Mon, 12 Aug 2002 16:52:20 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7CEqJo2004688 for <[e-mail]>; Mon, 12 Aug 2002 16:52:19 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id KAA29047 for <[e-mail]>; Mon, 12 Aug 2002 10:53:07 -0400 (EDT)
Received: by vsvapostalgw2.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <PX4QCG89>; Mon, 12 Aug 2002 10:52:17 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Response Code 2501
Date: Mon, 12 Aug 2002 10:52:12 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7CEpCo2004675 for <[e-mail]>; Mon, 12 Aug 2002 16:51:12 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g7CEpC8C004674 for ietf-provreg-outgoing; Mon, 12 Aug 2002 16:51:12 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7CEpBo2004669 for <[e-mail]>; Mon, 12 Aug 2002 16:51:11 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id KAA28941 for <[e-mail]>; Mon, 12 Aug 2002 10:51:59 -0400 (EDT)
Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <PXVAKJMK>; Mon, 12 Aug 2002 10:51:09 -0400
Message-ID: <[e-mail]>
From: "Gould, James" <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Header in TCP Mapping
Date: Mon, 12 Aug 2002 10:51:02 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
Sent: Monday, August 12, 2002 8:13 AM
To: '[e-mail]'
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-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7CEQio2004457 for <[e-mail]>; Mon, 12 Aug 2002 16:26:44 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g7CEQi8E004456 for ietf-provreg-outgoing; Mon, 12 Aug 2002 16:26:44 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from astrid2.nic.fr (astrid2.nic.fr [192.134.4.2]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7CEQho2004451 for <[e-mail]>; Mon, 12 Aug 2002 16:26:44 +0200 (MEST)
Received: from vespucci.nic.fr ([e-mail] [192.134.4.68]) by astrid2.nic.fr (8.9.1/jtpda-5.3.1) with ESMTP id QAA14276 for <[e-mail]>; Mon, 12 Aug 2002 16:26:38 +0200 (MET DST)
Received: by vespucci.nic.fr (Postfix, from userid 1000) id 0801C10D30; Mon, 12 Aug 2002 16:26:37 +0200 (CEST)
Date: Mon, 12 Aug 2002 16:26:37 +0200
From: Stephane Bortzmeyer <[e-mail]>
To: [e-mail]
Subject: [[e-mail]: [open-eu] Open Registry Robot / EPP transport layer]
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="PEIAKu/WMn1b1Hv9"
Content-Disposition: inline
User-Agent: Mutt/1.3.28i
Organization: NIC France
X-URL: http://www.nic.fr/
X-Operating-System: Debian GNU/Linux 3.0
X-Kernel: Linux 2.4.18-686 i686
Sender: [e-mail]
Precedence: bulk

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

Return-Path: <[e-mail]>
Received: from relay1.nic.fr [192.134.4.17]
	by localhost with POP3 (fetchmail-5.9.11)
	for bortzmeyer@localhost (single-drop); Fri, 09 Aug 2002 14:10:05 +0200 (CEST)
Received: from relay3.nic.fr ([e-mail] [192.134.4.28])
          by astrid2.nic.fr (8.9.1/jtpda-5.3.1) with ESMTP id OAA17192
          ; Fri, 9 Aug 2002 14:06:45 +0200 (MET DST)
Received: from localhost (localhost [127.0.0.1])
	by relay3.nic.fr (Postfix) with ESMTP
	id 0F88C6EF22; Fri,  9 Aug 2002 14:06:45 +0200 (CEST)
Received: from mail5.knipp.de (mail5.knipp.de [195.253.6.12])
	by relay3.nic.fr (Postfix) with ESMTP
	id 5E1606EF18; Fri,  9 Aug 2002 14:06:43 +0200 (CEST)
Received: (from mjdomo@localhost)
	by mail5.knipp.de (8.9.3/8.9.3) id OAA19914
	for ListOne-OutGoing; Fri, 9 Aug 2002 14:05:51 +0200 (METDST)
X-Authentication-Warning: mail5.knipp.de: mjdomo set sender to [e-mail] using -f
Received: from mail.net-design.net (mail.net-design.net [195.127.214.33])
	by mail5.knipp.de (8.9.3/8.9.3) with ESMTP id OAA19909
	for <[e-mail]>; Fri, 9 Aug 2002 14:05:45 +0200 (METDST)
Received: from (tullius.shw.com) [195.127.214.3] 
	by mail.net-design.net with esmtp (Exim 3.12 #1 (Debian))
	id 17d8WW-0001kX-00; Fri, 09 Aug 2002 14:05:44 +0200
Received: from lutetia.dss (localhost.localdomain) [172.29.101.129] (sven)
	by tullius.shw.com with esmtp (Exim 3.12 #1 (Debian))
	id 17d8W1-0007ft-00; Fri, 09 Aug 2002 14:05:13 +0200
Subject: [open-eu] Open Registry Robot / EPP transport layer
From: Sven-Holger Wabnitz <[e-mail]>
To: open-eu discuss <[e-mail]>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature";
	boundary="=-0YG9PI5W1amZCUT6xi5q"
X-Mailer: Ximian Evolution 1.0.5 
Date: 09 Aug 2002 14:05:11 +0200
Message-Id: <1028894713.8719.2100.camel@lutetia>
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
Reply-To: [e-mail]
X-Virus-Scanned: by AMaViS perl-11-foxtrot
X-UIDL: 3cf7ecceac3f4d6f1177e0bc54503e3a


--=-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 [phone]            **             fax [phone]
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

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8

iQA/AwUAPVOv9qPdS86CNWfsEQKb9wCg+Y5lCbPFJ0NBh367zmngcqDhkm8AnjHR
1li9U/Yt64OtaIh4DAIrsd26
=VQ/G
-----END PGP SIGNATURE-----

--=-0YG9PI5W1amZCUT6xi5q--

--
Wish to unsubscribe to [e-mail] or need other help?
echo "help" | mailx [e-mail]

--PEIAKu/WMn1b1Hv9--


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7CCDOo2003454 for <[e-mail]>; Mon, 12 Aug 2002 14:13:24 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g7CCDOJS003453 for ietf-provreg-outgoing; Mon, 12 Aug 2002 14:13:24 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7CCDMo2003448 for <[e-mail]>; Mon, 12 Aug 2002 14:13:23 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id IAA19744 for <[e-mail]>; Mon, 12 Aug 2002 08:14:07 -0400 (EDT)
Received: by vsvapostalgw2.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <PX4QC1HD>; Mon, 12 Aug 2002 08:13:17 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Header in TCP Mapping
Date: Mon, 12 Aug 2002 08:13:05 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g78Ax5o2006886 for <[e-mail]>; Thu, 8 Aug 2002 12:59:05 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g78Ax5lw006885 for ietf-provreg-outgoing; Thu, 8 Aug 2002 12:59:05 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from insan.co.id (mx.insan.co.id [202.138.225.178]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g78Awxo2006872 for <[e-mail]>; Thu, 8 Aug 2002 12:59:03 +0200 (MEST)
Received: from localhost (localhost [127.0.0.1]) by insan.co.id (Postfix) with ESMTP id 114C614998 for <[e-mail]>; Thu,  8 Aug 2002 17:59:46 +0700 (JAVT)
Received: by insan.co.id (Postfix, from userid 1037) id B7C7E14988; Thu,  8 Aug 2002 17:59:44 +0700 (JAVT)
Date: Thu, 8 Aug 2002 17:59:44 +0700
From: Budi Rahardjo <[e-mail]>
Cc: [e-mail]
Subject: Re: Sending the original (Unicode) domain name as well as the ACE ?
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Thu, Aug 08, 2002 at 10:11:32AM +0200
X-Mailer: GruWo OS Mutt
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g788GLo2006138 for <[e-mail]>; Thu, 8 Aug 2002 10:16:21 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g788GLXG006137 for ietf-provreg-outgoing; Thu, 8 Aug 2002 10:16:21 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from balsa.cetp.ipsl.fr (balsa.cetp.ipsl.fr [193.52.172.32]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g788GKo2006132 for <[e-mail]>; Thu, 8 Aug 2002 10:16:20 +0200 (MEST)
Received: (from porteneu@localhost) by balsa.cetp.ipsl.fr (8.9.3+Sun/8.9.1) id KAA19939; Thu, 8 Aug 2002 10:11:32 +0200 (MET DST)
Date: Thu, 8 Aug 2002 10:11:32 +0200 (MET DST)
From: Elisabeth Porteneuve <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Sending the original (Unicode) domain name as well as the ACE ?
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g77NAoo2003124 for <[e-mail]>; Thu, 8 Aug 2002 01:10:50 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g77NAoBA003123 for ietf-provreg-outgoing; Thu, 8 Aug 2002 01:10:50 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from insan.co.id (mx.insan.co.id [202.138.225.178]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g77NAio2003118 for <[e-mail]>; Thu, 8 Aug 2002 01:10:47 +0200 (MEST)
Received: from localhost (localhost [127.0.0.1]) by insan.co.id (Postfix) with ESMTP id 0B883149A4 for <[e-mail]>; Thu,  8 Aug 2002 06:11:27 +0700 (JAVT)
Received: by insan.co.id (Postfix, from userid 1037) id B795514998; Thu,  8 Aug 2002 06:11:25 +0700 (JAVT)
Date: Thu, 8 Aug 2002 06:11:25 +0700
From: Budi Rahardjo <[e-mail]>
To: [e-mail]
Subject: Re: Sending the original (Unicode) domain name as well as the ACE ?
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Wed, Aug 07, 2002 at 11:27:19AM -0400
X-Mailer: GruWo OS Mutt
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g77H3mo2000385 for <[e-mail]>; Wed, 7 Aug 2002 19:03:48 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g77H3mdb000384 for ietf-provreg-outgoing; Wed, 7 Aug 2002 19:03:48 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from astrid2.nic.fr (astrid2.nic.fr [192.134.4.2]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g77H3jo2000379 for <[e-mail]>; Wed, 7 Aug 2002 19:03:47 +0200 (MEST)
Received: from james.nic.fr (IDENT:[e-mail] [192.134.4.83]) by astrid2.nic.fr (8.9.1/jtpda-5.3.1) with ESMTP id TAA24879 ; Wed, 7 Aug 2002 19:03:42 +0200 (MET DST)
Received: (from guillard@localhost) by james.nic.fr (8.11.0/8.11.0) id g77HNUe21238; Wed, 7 Aug 2002 19:23:30 +0200
Date: Wed, 7 Aug 2002 19:23:30 +0200
From: Olivier Guillard / AFNIC <[e-mail]>
To: [e-mail]
Cc: Jim Reid <[e-mail]>
Subject: Re: Sending the original (Unicode) domain name as well as the ACE ?
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Wed, Aug 07, 2002 at 08:56:10AM -0700
Sender: [e-mail]
Precedence: bulk

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




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g77FuDo2029829 for <[e-mail]>; Wed, 7 Aug 2002 17:56:13 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g77FuDbb029828 for ietf-provreg-outgoing; Wed, 7 Aug 2002 17:56:13 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g77FuCo2029821 for <[e-mail]>; Wed, 7 Aug 2002 17:56:12 +0200 (MEST)
Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 78833137F05; Wed,  7 Aug 2002 08:56:10 -0700 (PDT)
To: Elisabeth Porteneuve <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: Sending the original (Unicode) domain name as well as the ACE ? 
In-Reply-To: Message from Elisabeth Porteneuve <[e-mail]>  of "Wed, 07 Aug 2002 17:20:16 +0200." <[e-mail]> 
Date: Wed, 07 Aug 2002 08:56:10 -0700
Message-ID: <[e-mail]>
From: Jim Reid <[e-mail]>
Sender: [e-mail]
Precedence: bulk

>>>>> "Elisabeth" == Elisabeth Porteneuve <[e-mail]> 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.


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g77FRTo2029534 for <[e-mail]>; Wed, 7 Aug 2002 17:27:29 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g77FRTBi029533 for ietf-provreg-outgoing; Wed, 7 Aug 2002 17:27:29 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g77FRSo2029528 for <[e-mail]>; Wed, 7 Aug 2002 17:27:28 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id LAA14431; Wed, 7 Aug 2002 11:28:08 -0400 (EDT)
Received: by vsvapostalgw2.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <PX4QAHC6>; Wed, 7 Aug 2002 11:27:19 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Elisabeth Porteneuve'" <[e-mail]>, [e-mail]
Subject: RE: Sending the original (Unicode) domain name as well as the ACE ?
Date: Wed, 7 Aug 2002 11:27:19 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g77FOGo2029503 for <[e-mail]>; Wed, 7 Aug 2002 17:24:16 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g77FOGZo029502 for ietf-provreg-outgoing; Wed, 7 Aug 2002 17:24:16 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from balsa.cetp.ipsl.fr (balsa.cetp.ipsl.fr [193.52.172.32]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g77FOEo2029497 for <[e-mail]>; Wed, 7 Aug 2002 17:24:15 +0200 (MEST)
Received: (from porteneu@localhost) by balsa.cetp.ipsl.fr (8.9.3+Sun/8.9.1) id RAA12785; Wed, 7 Aug 2002 17:20:16 +0200 (MET DST)
Date: Wed, 7 Aug 2002 17:20:16 +0200 (MET DST)
From: Elisabeth Porteneuve <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: RE: Sending the original (Unicode) domain name as well as the ACE ?
Sender: [e-mail]
Precedence: bulk

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" <[e-mail]>
> To: "'Stephane Bortzmeyer'" <[e-mail]>, [e-mail]
> 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-
> 


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g77EH5o2028881 for <[e-mail]>; Wed, 7 Aug 2002 16:17:05 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g77EH5YL028880 for ietf-provreg-outgoing; Wed, 7 Aug 2002 16:17:05 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g77EH4o2028875 for <[e-mail]>; Wed, 7 Aug 2002 16:17:04 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id KAA08641; Wed, 7 Aug 2002 10:17:50 -0400 (EDT)
Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <PXVAG5X5>; Wed, 7 Aug 2002 10:17:01 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Stephane Bortzmeyer'" <[e-mail]>, [e-mail]
Subject: RE: Sending the original (Unicode) domain name as well as the ACE ?
Date: Wed, 7 Aug 2002 10:17:01 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g77E9oo2028828 for <[e-mail]>; Wed, 7 Aug 2002 16:09:50 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g77E9oAx028827 for ietf-provreg-outgoing; Wed, 7 Aug 2002 16:09:50 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nohope.patoche.org (nohope.patoche.org [80.67.173.199]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g77E9no2028822 for <[e-mail]>; Wed, 7 Aug 2002 16:09:50 +0200 (MEST)
Received: from nohope.patoche.org (localhost.gandi.net [127.0.0.1]) by nohope.patoche.org (8.12.1/8.12.1/Debian -5) with ESMTP id g77E9mT8016934 for <[e-mail]>; Wed, 7 Aug 2002 16:09:48 +0200
Received: (from patrick@localhost) by nohope.patoche.org (8.12.1/8.12.1/Debian -5) id g77E9mlH016932 for [e-mail]; Wed, 7 Aug 2002 16:09:48 +0200
Date: Wed, 7 Aug 2002 16:09:48 +0200
From: Patrick <[e-mail]>
To: [e-mail]
Subject: Re: Sending the original (Unicode) domain name as well as the ACE?
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.24i
X-PGP-KeyID: A241FB6B
X-Request-PGP: http://www.keyserver.net:11371/pks/lookup?op=vindex&search=0xA241FB6B
Organization: Gandi
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g77Dgco2028619 for <[e-mail]>; Wed, 7 Aug 2002 15:42:38 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g77DgcJW028618 for ietf-provreg-outgoing; Wed, 7 Aug 2002 15:42:38 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from astrid2.nic.fr (astrid2.nic.fr [192.134.4.2]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g77Dgbo2028613 for <[e-mail]>; Wed, 7 Aug 2002 15:42:38 +0200 (MEST)
Received: from vespucci.nic.fr ([e-mail] [192.134.4.68]) by astrid2.nic.fr (8.9.1/jtpda-5.3.1) with ESMTP id PAA28770 for <[e-mail]>; Wed, 7 Aug 2002 15:42:36 +0200 (MET DST)
Received: by vespucci.nic.fr (Postfix, from userid 1000) id 90B1310CF1; Wed,  7 Aug 2002 15:42:36 +0200 (CEST)
Date: Wed, 7 Aug 2002 15:42:36 +0200
From: Stephane Bortzmeyer <[e-mail]>
To: [e-mail]
Subject: Re: Sending the original (Unicode) domain name as well as the ACE?
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.28i
Organization: NIC France
X-URL: http://www.nic.fr/
X-Operating-System: Debian GNU/Linux 3.0
X-Kernel: Linux 2.4.18-686 i686
Sender: [e-mail]
Precedence: bulk

On Tue, Aug 06, 2002 at 09:03:50AM +0200,
 Stephane Bortzmeyer <[e-mail]> 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?


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g77DI1o2028463 for <[e-mail]>; Wed, 7 Aug 2002 15:18:01 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g77DI1jt028462 for ietf-provreg-outgoing; Wed, 7 Aug 2002 15:18:01 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail.libertyrms.com ([216.94.172.167]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g77DHxo2028457 for <[e-mail]>; Wed, 7 Aug 2002 15:18:00 +0200 (MEST)
Received: from [10.1.1.139] (helo=dun220) by mail.libertyrms.com with esmtp (Exim 3.22 #3 (Debian)) id 17cQhK-0004AM-00 for <[e-mail]>; Wed, 07 Aug 2002 09:17:58 -0400
From: "Michael Young" <[e-mail]>
To: <[e-mail]>
Subject: FW: Lack of reference client Implementation for  EPP 6 / TCP 4
Date: Wed, 7 Aug 2002 09:17:44 -0400
Message-ID: <000f01c23e14$d12499a0$8b01010a@dun220>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Sender: [e-mail]
Precedence: bulk

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







Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g77D0lo2028308 for <[e-mail]>; Wed, 7 Aug 2002 15:00:47 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g77D0lad028307 for ietf-provreg-outgoing; Wed, 7 Aug 2002 15:00:47 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail.libertyrms.com ([216.94.172.167]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g77D0ko2028302 for <[e-mail]>; Wed, 7 Aug 2002 15:00:46 +0200 (MEST)
Received: from [10.1.1.139] (helo=dun220) by mail.libertyrms.com with esmtp (Exim 3.22 #3 (Debian)) id 17cQQf-0003tK-00 for <[e-mail]>; Wed, 07 Aug 2002 09:00:45 -0400
From: "Michael Young" <[e-mail]>
To: <[e-mail]>
Subject: RE: Lack of reference client Implementation for  EPP 6 / TCP 4
Date: Wed, 7 Aug 2002 09:00:31 -0400
Message-ID: <004d01c23e12$690da2f0$8b01010a@dun220>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
In-Reply-To: 
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Sender: [e-mail]
Precedence: bulk

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







Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g76Icbo2022756 for <[e-mail]>; Tue, 6 Aug 2002 20:38:37 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g76Icbv3022755 for ietf-provreg-outgoing; Tue, 6 Aug 2002 20:38:37 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nohope.patoche.org (nohope.patoche.org [80.67.173.199]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g76IcYo2022750 for <[e-mail]>; Tue, 6 Aug 2002 20:38:35 +0200 (MEST)
Received: from nohope.patoche.org (localhost.gandi.net [127.0.0.1]) by nohope.patoche.org (8.12.1/8.12.1/Debian -5) with ESMTP id g76IcWT8030755; Tue, 6 Aug 2002 20:38:32 +0200
Received: (from patrick@localhost) by nohope.patoche.org (8.12.1/8.12.1/Debian -5) id g76IcVkX030753; Tue, 6 Aug 2002 20:38:31 +0200
Date: Tue, 6 Aug 2002 20:38:31 +0200
From: Patrick <[e-mail]>
To: [e-mail]
Subject: Re: Lack of reference client Implementation for  EPP 6 / TCP 4
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.24i
X-PGP-KeyID: A241FB6B
X-Request-PGP: http://www.keyserver.net:11371/pks/lookup?op=vindex&search=0xA241FB6B
Organization: Gandi
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g76I3co2022540 for <[e-mail]>; Tue, 6 Aug 2002 20:03:38 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g76I3cKT022539 for ietf-provreg-outgoing; Tue, 6 Aug 2002 20:03:38 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from toronto.mail.tucows.com (bfos.tucows.com [207.136.98.11]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g76I3ao2022534 for <[e-mail]>; Tue, 6 Aug 2002 20:03:37 +0200 (MEST)
Received: from dmanley.pc.internal.tucows.com ([10.0.10.19] helo=tucows.com) by toronto.mail.tucows.com with esmtp (Exim 3.36 #3) id 17c8gA-0005JP-00 for [e-mail]; Tue, 06 Aug 2002 14:03:34 -0400
Message-ID: <[e-mail]>
Date: Tue, 06 Aug 2002 14:05:08 -0400
From: Daniel Manley <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020606
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Lack of reference client Implementation for  EPP 6 / TCP 4
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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





Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g76H01o2022149 for <[e-mail]>; Tue, 6 Aug 2002 19:00:01 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g76H01ZQ022148 for ietf-provreg-outgoing; Tue, 6 Aug 2002 19:00:01 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g76H00o2022137 for <[e-mail]>; Tue, 6 Aug 2002 19:00:00 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id NAA11408; Tue, 6 Aug 2002 13:00:36 -0400 (EDT)
Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <PXVAGCMH>; Tue, 6 Aug 2002 12:59:47 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Stuart Marsden'" <[e-mail]>, [e-mail]
Subject: RE: Lack of reference client Implementation for  EPP 6 / TCP 4 
Date: Tue, 6 Aug 2002 12:59:46 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g76GTBo2021925 for <[e-mail]>; Tue, 6 Aug 2002 18:29:11 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g76GTBYa021924 for ietf-provreg-outgoing; Tue, 6 Aug 2002 18:29:11 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail.srv.poptel.org.uk (mail1.srv.poptel.org.uk [213.55.4.13]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g76GT8o2021919 for <[e-mail]>; Tue, 6 Aug 2002 18:29:09 +0200 (MEST)
Received: (qmail 55434 invoked from network); 6 Aug 2002 15:01:58 -0000
Received: from host213-1-25-9.webport.bt.net (HELO martin) ([213.1.25.9]) (envelope-sender <[e-mail]>) by mail1.srv.poptel.org.uk (qmail-ldap-1.03) with SMTP for <[e-mail]>; 6 Aug 2002 15:01:58 -0000
From: "Stuart Marsden" <[e-mail]>
To: <[e-mail]>
Subject: Lack of reference client Implementation for  EPP 6 / TCP 4 
Date: Tue, 6 Aug 2002 17:29:59 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g76FVPo2021577 for <[e-mail]>; Tue, 6 Aug 2002 17:31:25 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g76FVPEh021576 for ietf-provreg-outgoing; Tue, 6 Aug 2002 17:31:25 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nohope.patoche.org (nohope.patoche.org [80.67.173.199]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g76FVMo2021571 for <[e-mail]>; Tue, 6 Aug 2002 17:31:24 +0200 (MEST)
Received: from nohope.patoche.org (localhost.gandi.net [127.0.0.1]) by nohope.patoche.org (8.12.1/8.12.1/Debian -5) with ESMTP id g76FVJT8025489 for <[e-mail]>; Tue, 6 Aug 2002 17:31:19 +0200
Received: (from patrick@localhost) by nohope.patoche.org (8.12.1/8.12.1/Debian -5) id g76FVInS025487 for [e-mail]; Tue, 6 Aug 2002 17:31:18 +0200
Date: Tue, 6 Aug 2002 17:31:18 +0200
From: Patrick <[e-mail]>
To: [e-mail]
Subject: Re: Sending the original (Unicode) domain name as well as the ACE?
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.24i
X-PGP-KeyID: A241FB6B
X-Request-PGP: http://www.keyserver.net:11371/pks/lookup?op=vindex&search=0xA241FB6B
Organization: Gandi
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g76DDmo2020639 for <[e-mail]>; Tue, 6 Aug 2002 15:13:48 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g76DDmDl020638 for ietf-provreg-outgoing; Tue, 6 Aug 2002 15:13:48 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g76DDko2020633 for <[e-mail]>; Tue, 6 Aug 2002 15:13:47 +0200 (MEST)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g769Cw23028334; Tue, 6 Aug 2002 09:12:58 GMT
Received: from [192.149.252.228] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id JAA06228; Tue, 6 Aug 2002 09:13:43 -0400 (EDT)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b03b9757933621c@[192.149.252.228]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Tue, 6 Aug 2002 09:09:31 -0400
To: "Hollenbeck, Scott" <[e-mail]>, "'Liu, Hong'" <[e-mail]>, [e-mail]
From: Edward Lewis <[e-mail]>
Subject: RE: Login Failure and Sessions
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g76C6Yo2020290 for <[e-mail]>; Tue, 6 Aug 2002 14:06:34 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g76C6YRF020289 for ietf-provreg-outgoing; Tue, 6 Aug 2002 14:06:34 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from astrid2.nic.fr (astrid2.nic.fr [192.134.4.2]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g76C6Xo2020284 for <[e-mail]>; Tue, 6 Aug 2002 14:06:33 +0200 (MEST)
Received: from vespucci.nic.fr ([e-mail] [192.134.4.68]) by astrid2.nic.fr (8.9.1/jtpda-5.3.1) with ESMTP id OAA09132 ; Tue, 6 Aug 2002 14:06:32 +0200 (MET DST)
Received: by vespucci.nic.fr (Postfix, from userid 1000) id 7DBE010CF1; Tue,  6 Aug 2002 14:06:32 +0200 (CEST)
Date: Tue, 6 Aug 2002 14:06:32 +0200
From: Stephane Bortzmeyer <[e-mail]>
To: Patrick <[e-mail]>
Cc: [e-mail]
Subject: Re: Sending the original (Unicode) domain name as well as the ACE?
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.28i
Organization: NIC France
X-URL: http://www.nic.fr/
X-Operating-System: Debian GNU/Linux 3.0
X-Kernel: Linux 2.4.18-686 i686
Sender: [e-mail]
Precedence: bulk

On Tue, Aug 06, 2002 at 12:47:56PM +0200,
 Patrick <[e-mail]> 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.



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g76Am5o2020052 for <[e-mail]>; Tue, 6 Aug 2002 12:48:05 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g76Am5Oh020051 for ietf-provreg-outgoing; Tue, 6 Aug 2002 12:48:05 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nohope.patoche.org (nohope.patoche.org [80.67.173.199]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g76Am0o2020046 for <[e-mail]>; Tue, 6 Aug 2002 12:48:03 +0200 (MEST)
Received: from nohope.patoche.org (localhost.gandi.net [127.0.0.1]) by nohope.patoche.org (8.12.1/8.12.1/Debian -5) with ESMTP id g76AlwT8020966; Tue, 6 Aug 2002 12:47:58 +0200
Received: (from patrick@localhost) by nohope.patoche.org (8.12.1/8.12.1/Debian -5) id g76Alu2r020964; Tue, 6 Aug 2002 12:47:56 +0200
Date: Tue, 6 Aug 2002 12:47:56 +0200
From: Patrick <[e-mail]>
To: [e-mail]
Subject: Re: Sending the original (Unicode) domain name as well as the ACE?
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.24i
X-PGP-KeyID: A241FB6B
X-Request-PGP: http://www.keyserver.net:11371/pks/lookup?op=vindex&search=0xA241FB6B
Organization: Gandi
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g767Tto2019124 for <[e-mail]>; Tue, 6 Aug 2002 09:29:55 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g767TtIa019123 for ietf-provreg-outgoing; Tue, 6 Aug 2002 09:29:55 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from astrid2.nic.fr (astrid2.nic.fr [192.134.4.2]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g767Tso2019118 for <[e-mail]>; Tue, 6 Aug 2002 09:29:54 +0200 (MEST)
Received: from vespucci.nic.fr ([e-mail] [192.134.4.68]) by astrid2.nic.fr (8.9.1/jtpda-5.3.1) with ESMTP id JAA18744 ; Tue, 6 Aug 2002 09:29:51 +0200 (MET DST)
Received: by vespucci.nic.fr (Postfix, from userid 1000) id 73AD910CDA; Tue,  6 Aug 2002 09:29:50 +0200 (CEST)
Date: Tue, 6 Aug 2002 09:29:50 +0200
From: Stephane Bortzmeyer <[e-mail]>
To: Dave Crocker <[e-mail]>
Cc: Stephane Bortzmeyer <[e-mail]>, [e-mail]
Subject: Re: Sending the original (Unicode) domain name as well as the ACE?
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.28i
Organization: NIC France
X-URL: http://www.nic.fr/
X-Operating-System: Debian GNU/Linux 3.0
X-Kernel: Linux 2.4.18-686 i686
Sender: [e-mail]
Precedence: bulk

On Tue, Aug 06, 2002 at 12:19:50AM -0700,
 Dave Crocker <[e-mail]> 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.


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g767ROo2019090 for <[e-mail]>; Tue, 6 Aug 2002 09:27:24 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g767RO4K019089 for ietf-provreg-outgoing; Tue, 6 Aug 2002 09:27:24 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from astrid2.nic.fr (astrid2.nic.fr [192.134.4.2]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g767RNo2019084 for <[e-mail]>; Tue, 6 Aug 2002 09:27:23 +0200 (MEST)
Received: from vespucci.nic.fr ([e-mail] [192.134.4.68]) by astrid2.nic.fr (8.9.1/jtpda-5.3.1) with ESMTP id JAA12805 ; Tue, 6 Aug 2002 09:27:19 +0200 (MET DST)
Received: by vespucci.nic.fr (Postfix, from userid 1000) id 7716810CDA; Tue,  6 Aug 2002 09:27:19 +0200 (CEST)
Date: Tue, 6 Aug 2002 09:27:19 +0200
From: Stephane Bortzmeyer <[e-mail]>
To: Rick Wesson <[e-mail]>
Cc: Stephane Bortzmeyer <[e-mail]>, [e-mail]
Subject: Re: Sending the original (Unicode) domain name as well as the ACE?
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.28i
Organization: NIC France
X-URL: http://www.nic.fr/
X-Operating-System: Debian GNU/Linux 3.0
X-Kernel: Linux 2.4.18-686 i686
Sender: [e-mail]
Precedence: bulk

On Tue, Aug 06, 2002 at 12:16:01AM -0700,
 Rick Wesson <[e-mail]> 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).




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g767K6o2019053 for <[e-mail]>; Tue, 6 Aug 2002 09:20:06 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g767K59I019052 for ietf-provreg-outgoing; Tue, 6 Aug 2002 09:20:05 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g767K4o2019047 for <[e-mail]>; Tue, 6 Aug 2002 09:20:04 +0200 (MEST)
Received: from bbprime.brandenburg.com (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id AAA03100; Tue, 6 Aug 2002 00:29:04 -0700
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta)
Date: Tue, 06 Aug 2002 00:19:50 -0700
To: Stephane Bortzmeyer <[e-mail]>
From: Dave Crocker <[e-mail]>
Subject: Re: Sending the original (Unicode) domain name as well as the ACE?
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk

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:[e-mail]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel [phone];  fax [phone]



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g767G2o2019018 for <[e-mail]>; Tue, 6 Aug 2002 09:16:02 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g767G2ea019017 for ietf-provreg-outgoing; Tue, 6 Aug 2002 09:16:02 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bean.ar.com (bean.ar.com [66.123.187.68]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g767G0o2019012 for <[e-mail]>; Tue, 6 Aug 2002 09:16:01 +0200 (MEST)
Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.2/8.12.0) with ESMTP id g767Fwlo000461; Tue, 6 Aug 2002 00:15:58 -0700 (PDT)
Date: Tue, 6 Aug 2002 00:16:01 -0700 (PDT)
From: Rick Wesson <[e-mail]>
To: Stephane Bortzmeyer <[e-mail]>
cc: <[e-mail]>
Subject: Re: Sending the original (Unicode) domain name as well as the ACE?
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7673vo2018958 for <[e-mail]>; Tue, 6 Aug 2002 09:03:57 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g7673v6P018957 for ietf-provreg-outgoing; Tue, 6 Aug 2002 09:03:57 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from astrid2.nic.fr (astrid2.nic.fr [192.134.4.2]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g7673to2018952 for <[e-mail]>; Tue, 6 Aug 2002 09:03:56 +0200 (MEST)
Received: from vespucci.nic.fr ([e-mail] [192.134.4.68]) by astrid2.nic.fr (8.9.1/jtpda-5.3.1) with ESMTP id JAA21448 for <[e-mail]>; Tue, 6 Aug 2002 09:03:50 +0200 (MET DST)
Received: by vespucci.nic.fr (Postfix, from userid 1000) id 6145310CDA; Tue,  6 Aug 2002 09:03:50 +0200 (CEST)
Date: Tue, 6 Aug 2002 09:03:50 +0200
From: Stephane Bortzmeyer <[e-mail]>
To: [e-mail]
Subject: Sending the original (Unicode) domain name as well as the ACE?
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.28i
Organization: NIC France
X-URL: http://www.nic.fr/
X-Operating-System: Debian GNU/Linux 3.0
X-Kernel: Linux 2.4.18-686 i686
Sender: [e-mail]
Precedence: bulk

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




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g75KbFo2015240 for <[e-mail]>; Mon, 5 Aug 2002 22:37:15 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g75KbFdi015239 for ietf-provreg-outgoing; Mon, 5 Aug 2002 22:37:15 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nohope.patoche.org (nohope.patoche.org [80.67.173.199]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g75KbEo2015234 for <[e-mail]>; Mon, 5 Aug 2002 22:37:14 +0200 (MEST)
Received: from nohope.patoche.org (localhost.gandi.net [127.0.0.1]) by nohope.patoche.org (8.12.1/8.12.1/Debian -5) with ESMTP id g75KbDT8008529 for <[e-mail]>; Mon, 5 Aug 2002 22:37:13 +0200
Received: (from patrick@localhost) by nohope.patoche.org (8.12.1/8.12.1/Debian -5) id g75KbDPt008527 for [e-mail]; Mon, 5 Aug 2002 22:37:13 +0200
Date: Mon, 5 Aug 2002 22:37:13 +0200
From: Patrick <[e-mail]>
To: [e-mail]
Subject: Re: Login Failure and Sessions
Message-ID: <[e-mail]>
References: <5E42C1C85C5D064A947CF92FADE6D82E08413D@STNTEXCH1>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5E42C1C85C5D064A947CF92FADE6D82E08413D@STNTEXCH1>
User-Agent: Mutt/1.3.24i
X-PGP-KeyID: A241FB6B
X-Request-PGP: http://www.keyserver.net:11371/pks/lookup?op=vindex&search=0xA241FB6B
Organization: Gandi
Sender: [e-mail]
Precedence: bulk

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.


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g75JkUo2014965 for <[e-mail]>; Mon, 5 Aug 2002 21:46:30 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g75JkUvw014964 for ietf-provreg-outgoing; Mon, 5 Aug 2002 21:46:30 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g75JkTo2014959 for <[e-mail]>; Mon, 5 Aug 2002 21:46:29 +0200 (MEST)
Received: from stntimc1.va.neustar.com (stih650a-eth-s1p2c0.va.neustar.com [209.173.53.81]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id g75Jk3x24817 for <[e-mail]>; Mon, 5 Aug 2002 19:46:18 GMT
Received: by STNTIMC1 with Internet Mail Service (5.5.2653.19) id <306V4TDX>; Mon, 5 Aug 2002 15:46:53 -0400
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E08413D@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: [e-mail]
Subject: RE: Login Failure and Sessions
Date: Mon, 5 Aug 2002 15:46:40 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
Sent: Monday, August 05, 2002 3:41 PM
To: 'Liu, Hong'; [e-mail]
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-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g75Jfno2014930 for <[e-mail]>; Mon, 5 Aug 2002 21:41:49 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g75JfnjD014929 for ietf-provreg-outgoing; Mon, 5 Aug 2002 21:41:49 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g75Jflo2014924 for <[e-mail]>; Mon, 5 Aug 2002 21:41:48 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id PAA09018; Mon, 5 Aug 2002 15:42:09 -0400 (EDT)
Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <PXVAFLD2>; Mon, 5 Aug 2002 15:41:20 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Liu, Hong'" <[e-mail]>, [e-mail]
Subject: RE: Login Failure and Sessions
Date: Mon, 5 Aug 2002 15:41:10 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g75JEpo2014764 for <[e-mail]>; Mon, 5 Aug 2002 21:14:51 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g75JEp4p014763 for ietf-provreg-outgoing; Mon, 5 Aug 2002 21:14:51 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g75JElo2014758 for <[e-mail]>; Mon, 5 Aug 2002 21:14:50 +0200 (MEST)
Received: from chiimc01.il.neustar.com (stih650a-eth-s1p2c0.va.neustar.com [209.173.53.81]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id g75JE6x23997 for <[e-mail]>; Mon, 5 Aug 2002 19:14:36 GMT
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <QCQWTHT6>; Mon, 5 Aug 2002 14:14:01 -0500
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E08413C@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: [e-mail]
Subject: RE: Login Failure and Sessions
Date: Mon, 5 Aug 2002 14:14:44 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Scott,

I 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:[e-mail]]
Sent: Monday, August 05, 2002 12:40 PM
To: 'Liu, Hong'; [e-mail]
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...


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g75GeZo2014025 for <[e-mail]>; Mon, 5 Aug 2002 18:40:35 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g75GeZdF014024 for ietf-provreg-outgoing; Mon, 5 Aug 2002 18:40:35 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g75GeXo2014019 for <[e-mail]>; Mon, 5 Aug 2002 18:40:34 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id MAA23083; Mon, 5 Aug 2002 12:41:15 -0400 (EDT)
Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <PXVAFGCL>; Mon, 5 Aug 2002 12:40:26 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Liu, Hong'" <[e-mail]>, [e-mail]
Subject: RE: Login Failure and Sessions
Date: Mon, 5 Aug 2002 12:40:22 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g75GJFo2013890 for <[e-mail]>; Mon, 5 Aug 2002 18:19:15 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g75GJFPJ013889 for ietf-provreg-outgoing; Mon, 5 Aug 2002 18:19:15 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g75GJDo2013884 for <[e-mail]>; Mon, 5 Aug 2002 18:19:14 +0200 (MEST)
Received: from chiimc01.il.neustar.com (stih650a-eth-s1p2c0.va.neustar.com [209.173.53.81]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id g75GIlx19947 for <[e-mail]>; Mon, 5 Aug 2002 16:19:02 GMT
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <QCQWTGHG>; Mon, 5 Aug 2002 11:18:42 -0500
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E08413A@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: [e-mail]
Subject: RE: Login Failure and Sessions
Date: Mon, 5 Aug 2002 11:19:20 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Scott,

I 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:[e-mail]]
Sent: Monday, August 05, 2002 10:55 AM
To: [e-mail]
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.


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g75Esoo2013446 for <[e-mail]>; Mon, 5 Aug 2002 16:54:50 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g75EsoS6013445 for ietf-provreg-outgoing; Mon, 5 Aug 2002 16:54:50 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nohope.patoche.org (nohope.patoche.org [80.67.173.199]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g75Esno2013440 for <[e-mail]>; Mon, 5 Aug 2002 16:54:49 +0200 (MEST)
Received: from nohope.patoche.org (localhost.gandi.net [127.0.0.1]) by nohope.patoche.org (8.12.1/8.12.1/Debian -5) with ESMTP id g75EsjT8002190; Mon, 5 Aug 2002 16:54:45 +0200
Received: (from patrick@localhost) by nohope.patoche.org (8.12.1/8.12.1/Debian -5) id g75Esjfu002188; Mon, 5 Aug 2002 16:54:45 +0200
Date: Mon, 5 Aug 2002 16:54:45 +0200
From: Patrick <[e-mail]>
To: [e-mail]
Subject: Re: Login Failure and Sessions
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.24i
X-PGP-KeyID: A241FB6B
X-Request-PGP: http://www.keyserver.net:11371/pks/lookup?op=vindex&search=0xA241FB6B
Organization: Gandi
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g75Dr5o2013179 for <[e-mail]>; Mon, 5 Aug 2002 15:53:05 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g75Dr5OH013178 for ietf-provreg-outgoing; Mon, 5 Aug 2002 15:53:05 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g75Dr3o2013173 for <[e-mail]>; Mon, 5 Aug 2002 15:53:04 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id JAA08208 for <[e-mail]>; Mon, 5 Aug 2002 09:53:50 -0400 (EDT)
Received: by vsvapostalgw2.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <PX4P0B79>; Mon, 5 Aug 2002 09:53:01 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Login Failure and Sessions
Date: Mon, 5 Aug 2002 09:52:59 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g747iIo2006707 for <[e-mail]>; Sun, 4 Aug 2002 09:44:18 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g747iItG006706 for ietf-provreg-outgoing; Sun, 4 Aug 2002 09:44:18 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail.srv.poptel.org.uk (mail1.srv.poptel.org.uk [213.55.4.13]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g747iGo2006701 for <[e-mail]>; Sun, 4 Aug 2002 09:44:17 +0200 (MEST)
Received: (qmail 40513 invoked from network); 4 Aug 2002 06:17:24 -0000
Received: from host213-1-11-89.webport.bt.net (HELO martin) ([213.1.11.89]) (envelope-sender <[e-mail]>) by mail1.srv.poptel.org.uk (qmail-ldap-1.03) with SMTP for <[e-mail]>; 4 Aug 2002 06:17:24 -0000
From: "Stuart Marsden" <[e-mail]>
To: <[e-mail]>
Subject:  EPP 6 / TCP 4 Implementation of epp-rtk-java
Date: Sun, 4 Aug 2002 08:45:28 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01C23B93.4AB08970"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

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: [phone]
Mob: [phone]

Fax: [phone] 
mail to: [e-mail]
<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: [phone] =
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:[e-mail]">[e-mail]</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--



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g72ICGo2027235 for <[e-mail]>; Fri, 2 Aug 2002 20:12:16 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g72ICFAk027234 for ietf-provreg-outgoing; Fri, 2 Aug 2002 20:12:15 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail.libertyrms.com ([216.94.172.167]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g72ICEo2027229 for <[e-mail]>; Fri, 2 Aug 2002 20:12:14 +0200 (MEST)
Received: from dev3.int.libertyrms.com ([10.1.1.204] helo=libertyrms.info) by mail.libertyrms.com with esmtp (Exim 3.22 #3 (Debian)) id 17aguG-0005yR-00; Fri, 02 Aug 2002 14:12:08 -0400
Message-ID: <[e-mail]>
Date: Fri, 02 Aug 2002 14:12:41 -0400
From: janusz sienkiewicz <[e-mail]>
Organization: LibertyRMS Co.
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Hollenbeck, Scott" <[e-mail]>, [e-mail]
Subject: Re: Proposed Document Changes
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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-



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g71Nsjo2021233 for <[e-mail]>; Fri, 2 Aug 2002 01:54:45 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g71NsjUL021232 for ietf-provreg-outgoing; Fri, 2 Aug 2002 01:54:45 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g71Nsho2021227 for <[e-mail]>; Fri, 2 Aug 2002 01:54:44 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id TAA08551 for <[e-mail]>; Thu, 1 Aug 2002 19:55:28 -0400 (EDT)
Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <PXVACTBF>; Thu, 1 Aug 2002 19:54:42 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
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 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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

-Scott-

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Thursday, August 01, 2002 5:44 PM
To: [e-mail]
Cc: [e-mail]
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:    [e-mail]
        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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

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

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  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.



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g71Npoo2021206 for <[e-mail]>; Fri, 2 Aug 2002 01:51:50 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g71NpoAl021205 for ietf-provreg-outgoing; Fri, 2 Aug 2002 01:51:50 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g71Npno2021200 for <[e-mail]>; Fri, 2 Aug 2002 01:51:49 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id TAA08420; Thu, 1 Aug 2002 19:52:33 -0400 (EDT)
Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <PXVACS9P>; Thu, 1 Aug 2002 19:51:47 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'janusz sienkiewicz'" <[e-mail]>, [e-mail]
Subject: RE: Proposed Document Changes
Date: Thu, 1 Aug 2002 19:51:46 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g71JTco2019743 for <[e-mail]>; Thu, 1 Aug 2002 21:29:38 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g71JTck6019742 for ietf-provreg-outgoing; Thu, 1 Aug 2002 21:29:38 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail.libertyrms.com ([216.94.172.167]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g71JTbo2019737 for <[e-mail]>; Thu, 1 Aug 2002 21:29:37 +0200 (MEST)
Received: from dev3.int.libertyrms.com ([10.1.1.204] helo=libertyrms.info) by mail.libertyrms.com with esmtp (Exim 3.22 #3 (Debian)) id 17aLdc-0002HY-00; Thu, 01 Aug 2002 15:29:32 -0400
Message-ID: <[e-mail]>
Date: Thu, 01 Aug 2002 15:30:01 -0400
From: janusz sienkiewicz <[e-mail]>
Organization: LibertyRMS Co.
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Hollenbeck, Scott" <[e-mail]>, [e-mail]
Subject: Re: Proposed Document Changes
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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-



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g71GFuo2018373 for <[e-mail]>; Thu, 1 Aug 2002 18:15:56 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g71GFuBt018372 for ietf-provreg-outgoing; Thu, 1 Aug 2002 18:15:56 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail.libertyrms.com ([216.94.172.167]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g71GFro2018367 for <[e-mail]>; Thu, 1 Aug 2002 18:15:54 +0200 (MEST)
Received: from dev3.int.libertyrms.com ([10.1.1.204] helo=libertyrms.info) by mail.libertyrms.com with esmtp (Exim 3.22 #3 (Debian)) id 17aIc3-0007cW-00; Thu, 01 Aug 2002 12:15:43 -0400
Message-ID: <[e-mail]>
Date: Thu, 01 Aug 2002 12:16:12 -0400
From: janusz sienkiewicz <[e-mail]>
Organization: LibertyRMS Co.
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Hollenbeck, Scott" <[e-mail]>
CC: [e-mail]
Subject: Re: Proposed Document Changes
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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-



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g71Fguo2018179 for <[e-mail]>; Thu, 1 Aug 2002 17:42:56 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g71Fgu3B018178 for ietf-provreg-outgoing; Thu, 1 Aug 2002 17:42:56 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g71Fgto2018173 for <[e-mail]>; Thu, 1 Aug 2002 17:42:55 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id LAA09454; Thu, 1 Aug 2002 11:43:39 -0400 (EDT)
Received: by vsvapostalgw2.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <PX4P8G2B>; Thu, 1 Aug 2002 11:42:53 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'janusz sienkiewicz'" <[e-mail]>, [e-mail]
Subject: RE: Proposed Document Changes
Date: Thu, 1 Aug 2002 11:42:52 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g71FA5o2017962 for <[e-mail]>; Thu, 1 Aug 2002 17:10:05 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g71FA4iG017961 for ietf-provreg-outgoing; Thu, 1 Aug 2002 17:10:04 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail.libertyrms.com ([216.94.172.167]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g71FA3o2017956 for <[e-mail]>; Thu, 1 Aug 2002 17:10:04 +0200 (MEST)
Received: from dev3.int.libertyrms.com ([10.1.1.204] helo=libertyrms.info) by mail.libertyrms.com with esmtp (Exim 3.22 #3 (Debian)) id 17aHaU-0006SK-00 for <[e-mail]>; Thu, 01 Aug 2002 11:10:02 -0400
Message-ID: <[e-mail]>
Date: Thu, 01 Aug 2002 11:10:30 -0400
From: janusz sienkiewicz <[e-mail]>
Organization: LibertyRMS Co.
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Proposed Document Changes
Content-Type: multipart/mixed; boundary="------------F636EB6F24D779C7E6BF8892"
Sender: [e-mail]
Precedence: bulk

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: <[e-mail]>
Date: Fri, 26 Jul 2002 14:30:23 -0400
From: janusz sienkiewicz <[e-mail]>
Organization: LibertyRMS Co.
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: RE: 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--



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g71Enho2017842 for <[e-mail]>; Thu, 1 Aug 2002 16:49:43 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g71EnhBF017841 for ietf-provreg-outgoing; Thu, 1 Aug 2002 16:49:43 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail.libertyrms.com ([216.94.172.167]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g71Engo2017836 for <[e-mail]>; Thu, 1 Aug 2002 16:49:42 +0200 (MEST)
Received: from dev3.int.libertyrms.com ([10.1.1.204] helo=libertyrms.info) by mail.libertyrms.com with esmtp (Exim 3.22 #3 (Debian)) id 17aHGn-000663-00 for <[e-mail]>; Thu, 01 Aug 2002 10:49:41 -0400
Message-ID: <[e-mail]>
Date: Thu, 01 Aug 2002 10:50:10 -0400
From: janusz sienkiewicz <[e-mail]>
Organization: LibertyRMS Co.
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "'[e-mail]'" <[e-mail]>
Subject: Re: I-D on Uniform Treatment of Pending Action Notification in EPP
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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-



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g71Em2o2017801 for <[e-mail]>; Thu, 1 Aug 2002 16:48:02 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g71Em2PK017800 for ietf-provreg-outgoing; Thu, 1 Aug 2002 16:48:02 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g71Em1o2017795 for <[e-mail]>; Thu, 1 Aug 2002 16:48:02 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id KAA05604; Thu, 1 Aug 2002 10:48:45 -0400 (EDT)
Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <PXVACDR6>; Thu, 1 Aug 2002 10:47:59 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Edward Lewis'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Stateless vs. Stateful
Date: Thu, 1 Aug 2002 10:47:58 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g71EhQo2017750 for <[e-mail]>; Thu, 1 Aug 2002 16:43:26 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g71EhPe2017749 for ietf-provreg-outgoing; Thu, 1 Aug 2002 16:43:25 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g71EhOo2017744 for <[e-mail]>; Thu, 1 Aug 2002 16:43:25 +0200 (MEST)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g71AgB23077060; Thu, 1 Aug 2002 10:42:11 GMT
Received: from [192.149.252.231] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id KAA16279; Thu, 1 Aug 2002 10:43:22 -0400 (EDT)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b00b96ef7db3cbd@[192.149.252.231]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Thu, 1 Aug 2002 10:37:44 -0400
To: "Hollenbeck, Scott" <[e-mail]>, "'[e-mail]'" <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: Re: Stateless vs. Stateful
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6VM3to2011366 for <[e-mail]>; Thu, 1 Aug 2002 00:03:55 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g6VM3tcK011365 for ietf-provreg-outgoing; Thu, 1 Aug 2002 00:03:55 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g6VM3so2011360 for <[e-mail]>; Thu, 1 Aug 2002 00:03:54 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id SAA29429; Wed, 31 Jul 2002 18:04:33 -0400 (EDT)
Received: by vsvapostalgw2.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <PX4P7YPY>; Wed, 31 Jul 2002 18:03:47 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Liu, Hong'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: I-D on Uniform Treatment of Pending Action Notification in EP P
Date: Wed, 31 Jul 2002 18:03:38 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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