Re: [ietf-provreg] EPP and IDN

["Edmon Chung" <[e-mail]>]

Hi Klaus,

As Scott mentioned, I think you are right too.

My draft (draft-chung-idnop-epp-idn-00.txt) was created for registries who
are interested in handling character equivalency issues such as trad/simp
Chinese or Latin based character equivalencies.  The extension intends to
allow registries to announce character equivalency policies and
manageability as well as allow registrars/clients to further provision for
parameters within a set/bundle/package.

The concepts laid out in the draft I believe is currently tested at TWNIC's
IDN/EPP testbed.  Also, I will be updating the draft to -01 in a short while
with some corrections and also options on handling cases where large volumes
of equivalent domain sets are created by charprep policies.  The .BZ IDN
registry and perhaps the .SG registry (whom are still deciding on their
policies for IDN) will also try out the extension.

I understand that this is not currently a WG draft, but it would be great if
I could get some feedback and comments on it. :-)

Edmon



----- Original Message -----
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Klaus Malorny'" <[e-mail]>; <[e-mail]>
Sent: Thursday, July 31, 2003 7:14 AM
Subject: RE: [ietf-provreg] EPP and IDN


> > can anyone tell me something about the relation between EPP
> > and IDN? I
> > have seen that there are various drafts out there (like
> > draft-chung-idnop-epp-idn-00.txt) that deal with IDN issues like
> > variants et al. But is my assumption correct that the base protocol
> > itself does not limit the use of internationalized names in
> > domains and
> > host objects? I mean since XML is able to transport the full Unicode
> > character set, it should be possible to specify non-ASCII
> > characters in
> > domainname related elements. Or does the protocol require that those
> > names are transmitted in their Punycode equivalent, as it happens
> > (AFAIK) in Verisign's current RRP implementation? Is the
> > choice between
> > the "presentation form" and Punycode at descretion of the
> > implementing
> > registry?
>
> I think you've got it right, Klaus.  I'm finding that some communities and
> registries want more information than what is carried in the protocol
> currently, such as language tags and name bundles.  Those features can be
> added with extensions as described in drafts like Edmon's.
>
> The base protocol can handle any character encoding supported by XML.
Some
> registries like to work with the punycode representation to check for
> conversion errors as the name moves along the provisioning path, but
that's
> not a protocol requirement.
>
> -Scott-
>




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6VEsP8W025568 for <[e-mail]>; Thu, 31 Jul 2003 16:54:25 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6VEsPOX025567 for ietf-provreg-outgoing; Thu, 31 Jul 2003 16:54:25 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from neteka.com (www.namesbeyond.com [216.220.34.103]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with SMTP id h6VEsO8W025562 for <[e-mail]>; Thu, 31 Jul 2003 16:54:24 +0200 (MEST)
Message-ID: <00c601c35773$9b1f2130$[e-mail]>
From: "Edmon Chung" <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>, "'Klaus Malorny'" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: [ietf-provreg] EPP and IDN
Date: Thu, 31 Jul 2003 10:52:30 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk

Hi Klaus,

As Scott mentioned, I think you are right too.

My draft (draft-chung-idnop-epp-idn-00.txt) was created for registries who
are interested in handling character equivalency issues such as trad/simp
Chinese or Latin based character equivalencies.  The extension intends to
allow registries to announce character equivalency policies and
manageability as well as allow registrars/clients to further provision for
parameters within a set/bundle/package.

The concepts laid out in the draft I believe is currently tested at TWNIC's
IDN/EPP testbed.  Also, I will be updating the draft to -01 in a short while
with some corrections and also options on handling cases where large volumes
of equivalent domain sets are created by charprep policies.  The .BZ IDN
registry and perhaps the .SG registry (whom are still deciding on their
policies for IDN) will also try out the extension.

I understand that this is not currently a WG draft, but it would be great if
I could get some feedback and comments on it. :-)

Edmon



----- Original Message -----
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Klaus Malorny'" <[e-mail]>; <[e-mail]>
Sent: Thursday, July 31, 2003 7:14 AM
Subject: RE: [ietf-provreg] EPP and IDN


> > can anyone tell me something about the relation between EPP
> > and IDN? I
> > have seen that there are various drafts out there (like
> > draft-chung-idnop-epp-idn-00.txt) that deal with IDN issues like
> > variants et al. But is my assumption correct that the base protocol
> > itself does not limit the use of internationalized names in
> > domains and
> > host objects? I mean since XML is able to transport the full Unicode
> > character set, it should be possible to specify non-ASCII
> > characters in
> > domainname related elements. Or does the protocol require that those
> > names are transmitted in their Punycode equivalent, as it happens
> > (AFAIK) in Verisign's current RRP implementation? Is the
> > choice between
> > the "presentation form" and Punycode at descretion of the
> > implementing
> > registry?
>
> I think you've got it right, Klaus.  I'm finding that some communities and
> registries want more information than what is carried in the protocol
> currently, such as language tags and name bundles.  Those features can be
> added with extensions as described in drafts like Edmon's.
>
> The base protocol can handle any character encoding supported by XML.
Some
> registries like to work with the punycode representation to check for
> conversion errors as the name moves along the provisioning path, but
that's
> not a protocol requirement.
>
> -Scott-
>



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6VEWG8W025390 for <[e-mail]>; Thu, 31 Jul 2003 16:32:16 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6VEWGGt025389 for ietf-provreg-outgoing; Thu, 31 Jul 2003 16:32:16 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6VEWF8W025384 for <[e-mail]>; Thu, 31 Jul 2003 16:32:15 +0200 (MEST)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by heron.verisign.com (8.12.9/8.12.9) with ESMTP id h6VEXecf002103 for <[e-mail]>; Thu, 31 Jul 2003 10:33:40 -0400 (EDT)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <3D12FY71>; Thu, 31 Jul 2003 10:32:14 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: [ietf-provreg] FW: I-D ACTION:draft-hollenbeck-epp-rgp-01.txt
Date: Thu, 31 Jul 2003 10:32:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C35770.88D41560"
Sender: [e-mail]
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C35770.88D41560
Content-Type: text/plain;
	charset="iso-8859-1"

FYI to those folks having to implement ICANN's redemption grace period.  The
updated document doesn't appear to be on the web as of the time of this
writing (the URL doesn't work), but hopefully that'll be fixed shortly.
This version includes features for restore report submission as discussed
previously on this mailing list.

-Scott-

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Thursday, July 31, 2003 9:59 AM
To: IETF-Announce; @ietf.org
Subject: I-D ACTION:draft-hollenbeck-epp-rgp-01.txt


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


	Title		: Redemption Grace Period Mapping for the Extensible

                          Provisioning Protocol
	Author(s)	: S. Hollenbeck
	Filename	: draft-hollenbeck-epp-rgp-01.txt
	Pages		: 227
	Date		: 2003-7-31
	
This document describes an Extensible Provisioning Protocol (EPP)
extension mapping for the management of Domain Name System (DNS)
domain names subject to the Redemption Grace Period (RGP) policies
defined by the Internet Corporation for Assigned Names and Numbers
(ICANN).  Specified in XML, this mapping extends the EPP domain name
mapping to provide additional features required for RGP processing.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hollenbeck-epp-rgp-01.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-rgp-01.txt".

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


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

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



------_=_NextPart_000_01C35770.88D41560
Content-Type: message/rfc822

To: 
Subject: 
Date: Thu, 31 Jul 2003 10:32:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_002_01C35770.88D41560"


------_=_NextPart_002_01C35770.88D41560
Content-Type: text/plain



------_=_NextPart_002_01C35770.88D41560
Content-Type: application/octet-stream;
	name="ATT22561"
Content-Disposition: attachment;
	filename="ATT22561"

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-hollenbeck-epp-rgp-01.txt

------_=_NextPart_002_01C35770.88D41560
Content-Type: message/external-body;
	site="internet-drafts";
	dir="draft-hollenbeck-epp-rgp-01.txt";
	mode="ftp.ietf.org";
	access-type="anon-ftp"


------_=_NextPart_002_01C35770.88D41560--

------_=_NextPart_000_01C35770.88D41560--


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6VCwk8W024745 for <[e-mail]>; Thu, 31 Jul 2003 14:58:46 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6VCwkQH024744 for ietf-provreg-outgoing; Thu, 31 Jul 2003 14:58:46 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from sender2.jprs.co.jp (sender2.nic.ad.jp [61.120.151.69]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6VCwi8W024739 for <[e-mail]>; Thu, 31 Jul 2003 14:58:45 +0200 (MEST)
Received: from alias.jprs.co.jp (alias.jprs.co.jp [192.168.102.41]) by sender2.jprs.co.jp (8.11.6/8.11.6) with ESMTP id h6VCvIm25527; Thu, 31 Jul 2003 21:57:18 +0900
Received: from sv002.jprs.co.jp (sv002.jprs.co.jp [192.168.10.2]) by alias.jprs.co.jp (8.11.6+Sun/8.11.6) with ESMTP id h6VCvHB20752; Thu, 31 Jul 2003 21:57:18 +0900 (JST)
Received: from localhost (localhost [127.0.0.1]) by sv002.jprs.co.jp (8.8.8p2+Sun/8.8.8) with ESMTP id VAA15442; Thu, 31 Jul 2003 21:57:17 +0900 (JST)
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: [ietf-provreg] EPP and IDN
From: Kentaro Mori <[e-mail]>
In-Reply-To: Your message of "Thu, 31 Jul 2003 13:22:34 +0200" <[e-mail]>
References: <[e-mail]>
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Date: Thu, 31 Jul 2003 21:57:14 +0900
X-Dispatcher: imput version 990905(IM130)
Lines: 42
Sender: [e-mail]
Precedence: bulk

Hello, this is Mori of JPRS (Japan Registry Service, the domain name
registry in Japan).

I am very curious about this issue from the standpoint of a member of
registry who currently provides IDNs.

> [IMHO, IANAL and I never wrote an EPP server.]
> 
> On Thu, Jul 31, 2003 at 09:59:11AM +0200,
>  Klaus Malorny <[e-mail]> wrote 
>  a message of 30 lines which said:
> 
> > can anyone tell me something about the relation between EPP and IDN?
> 
> EPP itself (which I believe is Unicode-clean) or one of the mappings?
> The current domain mapping does not seem to allow IDN. domain-07 says:
> 
>   The syntax for domain and host names described in this document MUST
>   conform to [RFC952] as updated by [RFC1123].  These conformance
>   requirements might change as a result of progressing work in
>   developing standards for internationalized domain names.
> 
> <troll>Now that RFC 3490 is out, may be we should stop the draft
> documents and rewrite that part before resending them to the
> IESG?</troll>

I know now is slightly worse timing for rewrite the documents and also
know the extension can handle IDNs properly, but I believe there is
still a chance for rewriting the protocol itself.  I think registries
who sell IDNs essentially do not sell Punycode strings, so it seems to
be better that IDN itself can specified in the relevant tags such as:
- <domain:name>,<domain:hostObj> in domain-07
- <host:name> in host-07
and perhaps,
- <contact:email> in contact-07 (further future?)

Thanks in advance.

--
Kentaro Mori, Research and Development department
Japan Registry Service Co.,Ltd. (JPRS)
E-Mail: [e-mail]


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6VBwL8W024451 for <[e-mail]>; Thu, 31 Jul 2003 13:58:22 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6VBwLnT024450 for ietf-provreg-outgoing; Thu, 31 Jul 2003 13:58:21 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6VBwK8W024445 for <[e-mail]>; Thu, 31 Jul 2003 13:58:21 +0200 (MEST)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by heron.verisign.com (8.12.9/8.12.9) with ESMTP id h6VBxjcf028382; Thu, 31 Jul 2003 07:59:45 -0400 (EDT)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <3D12F46T>; Thu, 31 Jul 2003 07:58:20 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Stephane Bortzmeyer'" <[e-mail]>, Klaus Malorny <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: [ietf-provreg] EPP and IDN
Date: Thu, 31 Jul 2003 07:58: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

> EPP itself (which I believe is Unicode-clean) or one of the mappings?
> The current domain mapping does not seem to allow IDN. domain-07 says:
> 
>   The syntax for domain and host names described in this document MUST
>   conform to [RFC952] as updated by [RFC1123].  These conformance
>   requirements might change as a result of progressing work in
>   developing standards for internationalized domain names.
> 
> <troll>Now that RFC 3490 is out, may be we should stop the draft
> documents and rewrite that part before resending them to the
> IESG?</troll>

I forgot about that -- I'll add it to the list of things to fix when I have
my author's 48-hour editing opportunity.

BUT: IDNs per the RFCs require punycode, so the requirement is still met.  I
think I need to reword this so it separates exchange format (which can be
different encodings XML) from DNS format, perhaps by referencing RFC 3490.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6VBMh8W024042 for <[e-mail]>; Thu, 31 Jul 2003 13:22:43 +0200 (MEST)
Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6VBMh6S024041 for ietf-provreg-outgoing; Thu, 31 Jul 2003 13:22:43 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6VBMg8W024036 for <[e-mail]>; Thu, 31 Jul 2003 13:22:43 +0200 (MEST)
Received: from vespucci.nic.fr ([e-mail] [192.134.4.68]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id h6VBMYNl616638; Thu, 31 Jul 2003 13:22:34 +0200 (CEST)
Received: by vespucci.nic.fr (Postfix, from userid 1055) id 45B2E105A5; Thu, 31 Jul 2003 13:22:34 +0200 (CEST)
Date: Thu, 31 Jul 2003 13:22:34 +0200
From: Stephane Bortzmeyer <[e-mail]>
To: Klaus Malorny <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: Re: [ietf-provreg] EPP and IDN
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]>
X-Operating-System: Debian GNU/Linux testing/unstable
X-Kernel: Linux 2.4.21-3-686 i686
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: Mutt/1.5.4i
Sender: [e-mail]
Precedence: bulk

[IMHO, IANAL and I never wrote an EPP server.]

On Thu, Jul 31, 2003 at 09:59:11AM +0200,
 Klaus Malorny <[e-mail]> wrote 
 a message of 30 lines which said:

> can anyone tell me something about the relation between EPP and IDN?

EPP itself (which I believe is Unicode-clean) or one of the mappings?
The current domain mapping does not seem to allow IDN. domain-07 says:

  The syntax for domain and host names described in this document MUST
  conform to [RFC952] as updated by [RFC1123].  These conformance
  requirements might change as a result of progressing work in
  developing standards for internationalized domain names.

<troll>Now that RFC 3490 is out, may be we should stop the draft
documents and rewrite that part before resending them to the
IESG?</troll>

> But is my assumption correct that the base protocol itself does not
> limit the use of internationalized names in domains and host
> objects?

Yes.

> I mean since XML is able to transport the full Unicode character
> set, it should be possible to specify non-ASCII characters in
> domainname related elements.

Right, -09 says:

  EPP is represented in XML, which provides native support for encoding
  information using the Unicode character set and its more compact
  representations including UTF-8.  Conformant XML processors recognize
  both UTF-8 and UTF-16.

> Or does the protocol require that those names are transmitted in
> their Punycode equivalent, as it happens (AFAIK) in Verisign's
> current RRP implementation? Is the choice between the "presentation
> form" and Punycode at descretion of the implementing registry?

I believe so. Basically, it depends on what you sell and bill, Unicode
names or ACE strings. (It has a lot of consequences, for instance
legal ones: think of a normalization change, for instance, or a
dispute about a trademark expressed in Unicode.)





Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6VBEL8W023986 for <[e-mail]>; Thu, 31 Jul 2003 13:14:21 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6VBEKHq023985 for ietf-provreg-outgoing; Thu, 31 Jul 2003 13:14: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.237.102]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6VBEJ8W023980 for <[e-mail]>; Thu, 31 Jul 2003 13:14:20 +0200 (MEST)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by heron.verisign.com (8.12.9/8.12.9) with ESMTP id h6VBFhcf028008; Thu, 31 Jul 2003 07:15:43 -0400 (EDT)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <3D12F4RP>; Thu, 31 Jul 2003 07:14:17 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Klaus Malorny'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: [ietf-provreg] EPP and IDN
Date: Thu, 31 Jul 2003 07:14:16 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> can anyone tell me something about the relation between EPP 
> and IDN? I 
> have seen that there are various drafts out there (like 
> draft-chung-idnop-epp-idn-00.txt) that deal with IDN issues like 
> variants et al. But is my assumption correct that the base protocol 
> itself does not limit the use of internationalized names in 
> domains and 
> host objects? I mean since XML is able to transport the full Unicode 
> character set, it should be possible to specify non-ASCII 
> characters in 
> domainname related elements. Or does the protocol require that those 
> names are transmitted in their Punycode equivalent, as it happens 
> (AFAIK) in Verisign's current RRP implementation? Is the 
> choice between 
> the "presentation form" and Punycode at descretion of the 
> implementing 
> registry?

I think you've got it right, Klaus.  I'm finding that some communities and
registries want more information than what is carried in the protocol
currently, such as language tags and name bundles.  Those features can be
added with extensions as described in drafts like Edmon's.

The base protocol can handle any character encoding supported by XML.  Some
registries like to work with the punycode representation to check for
conversion errors as the name moves along the provisioning path, but that's
not a protocol requirement.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6V7xc8W023081 for <[e-mail]>; Thu, 31 Jul 2003 09:59:38 +0200 (MEST)
Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6V7xcvl023080 for ietf-provreg-outgoing; Thu, 31 Jul 2003 09:59:38 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail7.knipp.de (mail7.knipp.de [195.253.6.55]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6V7xb8W023075 for <[e-mail]>; Thu, 31 Jul 2003 09:59:37 +0200 (MEST)
Received: (from root@localhost) by mail7.knipp.de (8.11.1/8.11.1) id h6V7xXo14635; Thu, 31 Jul 2003 09:59:33 +0200 (METDST)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by mail7.knipp.de (8.11.1/8.11.1) with ESMTP id h6V7xVx14626; Thu, 31 Jul 2003 09:59:31 +0200 (METDST)
Received: from knipp.de (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (8.11.1/8.11.1) with ESMTP id h6V7xUn03675; Thu, 31 Jul 2003 09:59:30 +0200 (METDST)
Message-ID: <[e-mail]>
Date: Thu, 31 Jul 2003 09:59:11 +0200
From: Klaus Malorny <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030719
X-Accept-Language: en
MIME-Version: 1.0
To: "'[e-mail]'" <[e-mail]>
Subject: [ietf-provreg] EPP and IDN
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Hi all,

can anyone tell me something about the relation between EPP and IDN? I 
have seen that there are various drafts out there (like 
draft-chung-idnop-epp-idn-00.txt) that deal with IDN issues like 
variants et al. But is my assumption correct that the base protocol 
itself does not limit the use of internationalized names in domains and 
host objects? I mean since XML is able to transport the full Unicode 
character set, it should be possible to specify non-ASCII characters in 
domainname related elements. Or does the protocol require that those 
names are transmitted in their Punycode equivalent, as it happens 
(AFAIK) in Verisign's current RRP implementation? Is the choice between 
the "presentation form" and Punycode at descretion of the implementing 
registry?

Thanks in advance,

Klaus


___________________________________________________________________________
      |       |
      | knipp |                   Knipp  Medien und Kommunikation GmbH
       -------                           Technologiepark
                                         Martin-Schmeißer-Weg 9
      Dipl. Inf. Klaus Malorny           44227 Dortmund
      [e-mail]             Tel. [phone]





Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6G8blmb000851 for <[e-mail]>; Wed, 16 Jul 2003 10:37:47 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6G8blEr000850 for ietf-provreg-outgoing; Wed, 16 Jul 2003 10:37:47 +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.237.102]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6G8bjmb000845 for <[e-mail]>; Wed, 16 Jul 2003 10:37:46 +0200 (MEST)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by heron.verisign.com (8.12.9/8.12.9) with ESMTP id h6G8dAcf016911 for <[e-mail]>; Wed, 16 Jul 2003 04:39:10 -0400 (EDT)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <3D1H5554>; Wed, 16 Jul 2003 04:37:45 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: [ietf-provreg] RGP Restore Report Proposal
Date: Wed, 16 Jul 2003 04:37:44 -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 been playing around with options to add support for restoration report
delivery via EPP in my RGP extension draft [1].  Working from the report
requirements described on various ICANN web pages I've come up with
something that might work.  Does this look reasonable to the people who
care?

The report consists of several fields as follows:

<element name="preWhois" type="rgp:mixedType"/>
-- Whois data prior to deletion.

<element name="postWhois" type="rgp:mixedType"/>
-- Whois data after restoration.

<element name="delTime" type="dateTime"/>
-- Deletion date and time.

<element name="resTime" type="dateTime"/>
-- Restoration date and time.

<element name="resReason" type="rgp:reportTextType"/>
-- Text describing the reason the restore was made.

<element name="statements" type="rgp:reportTextType"
 minOccurs="0" maxOccurs="2"/>
-- Text describing two registrar statements required by ICANN.

<element name="other" type="rgp:mixedType"
 minOccurs="0"/>
-- Other supporting info (such as a copy of a court order) as required by
the given reason.

The text and whois fields are all defined to be mixed, meaning that both
free text and XML-formatted data can be included.  This sort of structure
provides some flexibility to support different data formats.  Here are the
structure definitions:

  <complexType name="mixedType">
    <complexContent mixed="true">
      <restriction base="anyType">
        <sequence>
          <any processContents="lax"
           minOccurs="0" maxOccurs="unbounded"/>
        </sequence>
      </restriction>
    </complexContent>
  </complexType>
  
  <complexType name="reportTextType">
    <complexContent mixed="true">
      <restriction base="anyType">
        <sequence>
          <any processContents="lax"
           minOccurs="0" maxOccurs="unbounded"/>
        </sequence>
        <attribute name="lang" type="language" default="en"/>
      </restriction>
    </complexContent>
  </complexType>

If this sort of report structure works I'll update the draft in the weeks
after the Vienna IETF meeting.  Comments, please

-Scott-

[1]
http://www.ietf.org/internet-drafts/draft-hollenbeck-epp-rgp-00.txt


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h67Jllmb027367 for <[e-mail]>; Mon, 7 Jul 2003 21:47:47 +0200 (MEST)
Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h67JllTH027366 for ietf-provreg-outgoing; Mon, 7 Jul 2003 21:47:47 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h67Jljmb027361 for <[e-mail]>; Mon, 7 Jul 2003 21:47:46 +0200 (MEST)
Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h67JlfBd017652 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 7 Jul 2003 12:47:41 -0700 (PDT)
Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by crowley.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h67Jlcix022527; Mon, 7 Jul 2003 12:47:39 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06001803bb2f7b6d793d@[129.46.227.161]>
In-Reply-To: <a05111b15bb2f72d2c1f8@[192.168.1.100]>
References: <a05111b15bb2f72d2c1f8@[192.168.1.100]>
Date: Mon, 7 Jul 2003 12:47:43 -0700
To: Edward Lewis <[e-mail]>, [e-mail]
From: [e-mail]
Subject: Re: [ietf-provreg] So what's the holdup?
Cc: [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

Michael's document was shifted to BCP, since it was a registration
procedure.   During the IESG discussion of it, some issues were
raised; the -05 addresses those concerns.  Bert has already
removed his discuss; Thomas, Russ, and Steve still need to review
the revision.  Here's the tracker link:

https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=6298&rfc_flag=0

				regards,
					Ted Hardie



At 3:03 PM -0400 7/7/03, Edward Lewis wrote:
>In case you are wondering what's happened to the documents...
>
>All of our remaining documents are in the RFC Editor's queue, which 
>can be viewed here: http://www.rfc-editor.org/queue.html.  Searching 
>for "epp" will show which documents are ours.
>
>It seems that the core documents are largely blocked on a reference 
>to this document - draft-mealling-iana-xmlns-registry-03.txt and 
>action within IANA.
>
>Michael Mealling's document (the one mentioned above) is also in the 
>editor's queue...although there's a 
>draft-mealling-iana-xmlns-registry-05.txt in the internet-drafts 
>directory.
>
>(Scott - any clues on what's going on with that?)
>--
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>Edward Lewis                                            [phone]
>ARIN Research Engineer
>
>...as graceful as a blindfolded bull in a china shop...



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h67JWhmb027197 for <[e-mail]>; Mon, 7 Jul 2003 21:32:43 +0200 (MEST)
Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h67JWhPd027196 for ietf-provreg-outgoing; Mon, 7 Jul 2003 21:32:43 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h67JWgmb027188 for <[e-mail]>; Mon, 7 Jul 2003 21:32:42 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by heron.verisign.com (8.12.9/8.12.9) with ESMTP id h67JY6cf020713; Mon, 7 Jul 2003 15:34:06 -0400 (EDT)
Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <3D1JWBY9>; Mon, 7 Jul 2003 15:32:39 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Edward Lewis'" <[e-mail]>, [e-mail]
Cc: [e-mail], "'Michael Mealling'" <[e-mail]>
Subject: RE: [ietf-provreg] So what's the holdup?
Date: Mon, 7 Jul 2003 15:32:39 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

> It seems that the core documents are largely blocked on a reference 
> to this document - draft-mealling-iana-xmlns-registry-03.txt and 
> action within IANA.
> 
> Michael Mealling's document (the one mentioned above) is also in the 
> editor's queue...although there's a 
> draft-mealling-iana-xmlns-registry-05.txt in the internet-drafts 
> directory.
> 
> (Scott - any clues on what's going on with that?)

I thought that the -05 version of Michael's document is the one that was
supposed to be approved by the IESG after -04 was found to need some edits:

https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=6298
&rfc_flag=0

-05 is what's showing up in the IESG's document tracker.  I've cc'd Michael
here to see if he cares to comment directly.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h67J3Qmb026913 for <[e-mail]>; Mon, 7 Jul 2003 21:03:26 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h67J3QKQ026912 for ietf-provreg-outgoing; Mon, 7 Jul 2003 21:03:26 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h67J3Pmb026907 for <[e-mail]>; Mon, 7 Jul 2003 21:03:25 +0200 (MEST)
Received: by smtp1.arin.net (Postfix, from userid 5003) id A255935A; Mon,  7 Jul 2003 15:03:24 -0400 (EDT)
Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id 4E20134F; Mon,  7 Jul 2003 15:03:24 -0400 (EDT)
Received: from [127.0.0.1] (HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1b8) with ESMTP id 449621; Mon, 07 Jul 2003 14:58:36 -0400
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b15bb2f72d2c1f8@[192.168.1.100]>
Date: Mon, 7 Jul 2003 15:03:24 -0400
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: [ietf-provreg] So what's the holdup?
Cc: [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,SIGNATURE_SHORT_SPARSE,SPAM_PHRASE_00_01 version=2.43-arin1
X-Spam-Level: 
Sender: [e-mail]
Precedence: bulk

In case you are wondering what's happened to the documents...

All of our remaining documents are in the RFC Editor's queue, which 
can be viewed here: http://www.rfc-editor.org/queue.html.  Searching 
for "epp" will show which documents are ours.

It seems that the core documents are largely blocked on a reference 
to this document - draft-mealling-iana-xmlns-registry-03.txt and 
action within IANA.

Michael Mealling's document (the one mentioned above) is also in the 
editor's queue...although there's a 
draft-mealling-iana-xmlns-registry-05.txt in the internet-drafts 
directory.

(Scott - any clues on what's going on with that?)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            [phone]
ARIN Research Engineer

...as graceful as a blindfolded bull in a china shop...


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h67DuUmb023603 for <[e-mail]>; Mon, 7 Jul 2003 15:56:30 +0200 (MEST)
Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h67DuU5D023602 for ietf-provreg-outgoing; Mon, 7 Jul 2003 15:56:30 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h67DuSmb023597 for <[e-mail]>; Mon, 7 Jul 2003 15:56:29 +0200 (MEST)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by heron.verisign.com (8.12.9/8.12.9) with ESMTP id h67Dvqcf024475; Mon, 7 Jul 2003 09:57:52 -0400 (EDT)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <3D1HVVRK>; Mon, 7 Jul 2003 09:56:26 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Bernie Hoeneisen'" <[e-mail]>, "Hollenbeck, Scott" <[e-mail]>
Cc: [e-mail]
Subject: RE: [ietf-provreg] Some EPP questions
Date: Mon, 7 Jul 2003 09:56:26 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> If the response code to the transfer command was 1000, the <trStatus>
> element of the response to the following transfer query 
> command contains
> 'pending' (as in the response to the transfer command itself).
> 
> But what does the <trStatus> contain in the response to the transfer
> query command, if the response code to the transfer command itself was
> 1001?

I believe that the appropriate response for an accepted transfer command
that requires confirmation or cross-client approval is 1001 because the
command has been accepted, but the actual transfer action is pending.  A
transfer that can be completed right away should be noted with a 1000
response.  A successful query should always return a 1000 response.

The <trStatus> response to the transfer query depends on the current state
of the transfer.  If a 1001 response was sent for the transfer command, the
transfer didn't happen right away.  Initially the value should be "pending".
>From there the value of <trStatus> depends on what happens between the time
the transfer was requested and the time the query is made.  It might be
"pending" if nothing has happened, but it could be any of the other values
if a client or the server have done something (such as approved, rejected,
or cancelled the request) since the original transfer command was processed.

> And one further question, what does the <trStatus> contain in the
> response to the transfer command itself, if its response code is 1001?

Now that I think about it, it should be "pending" if a 1001 response is
returned.

I think I see what's prompting your questions: the domain and core drafts
include an example with a 1000 response and a "pending" <trStatus>; those
should be fixed to return a 1001 response or a different status value.  I'd
prefer to change the response code when I do the 48-hour edits.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h62FM4mb022008 for <[e-mail]>; Wed, 2 Jul 2003 17:22:04 +0200 (MEST)
Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h62FM3aO022007 for ietf-provreg-outgoing; Wed, 2 Jul 2003 17:22:03 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from central.switch.ch (central.switch.ch [130.59.4.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h62FM3mb022001 for <[e-mail]>; Wed, 2 Jul 2003 17:22:03 +0200 (MEST)
Received: from machb.switch.ch ([130.59.4.143]) by central.switch.ch with esmtp (Exim 3.20 #1) id 19XjQn-0000WD-00; Wed, 02 Jul 2003 17:22:01 +0200
Date: Wed, 2 Jul 2003 17:20:05 +0200 (CEST)
From: Bernie Hoeneisen <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
cc: [e-mail]
Subject: RE: [ietf-provreg] Some EPP questions
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

Hi Scott!

Thanks for your really fast answer.

On Wed, 2 Jul 2003, Hollenbeck, Scott wrote:

> > Assuming the response to a transfer command is 1001 "Command completed
> > successfully; action pending". What would the server answer to a
> > transfer query command (assuming nothing concerning this transfer has
> > changed at server since the 1001 was sent)?
>
> There's nothing that should stop a query from being answered completely, so
> a 1000 response code is appropriate.  Remember that each response code is
> related directly to the command it is being sent for and it becomes easier
> to remember which code is appropriate.

I looks like that I have to refine my original question, as I am more
interested in the content of the <trStatus> field in the response to the
transfer query command.

Or in other words:

If the response code to the transfer command was 1000, the <trStatus>
element of the response to the following transfer query command contains
'pending' (as in the response to the transfer command itself).

But what does the <trStatus> contain in the response to the transfer
query command, if the response code to the transfer command itself was
1001?

And one further question, what does the <trStatus> contain in the
response to the transfer command itself, if its response code is 1001?

cheers,
 Bernie


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h62DK9mb020663 for <[e-mail]>; Wed, 2 Jul 2003 15:20:09 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h62DK93e020662 for ietf-provreg-outgoing; Wed, 2 Jul 2003 15:20:09 +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.237.102]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h62DK8mb020657 for <[e-mail]>; Wed, 2 Jul 2003 15:20:08 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by heron.verisign.com (8.12.9/8.12.9) with ESMTP id h62DLWcf023691; Wed, 2 Jul 2003 09:21:32 -0400 (EDT)
Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <3D1JRH2Q>; Wed, 2 Jul 2003 09:20:05 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Bernie Hoeneisen'" <[e-mail]>
Cc: [e-mail]
Subject: RE: [ietf-provreg] Some EPP questions
Date: Wed, 2 Jul 2003 09:20:06 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> I rather want to stress out, that future extensions might need such
> possibilities as provided by the 'op=__' command attribute of 
> the transfer
> command only. And if I understood the guidelines for epp 
> extensions draft
> correctly, it is not possible to add e.g. an 'op=__' command 
> attribute to
> the existing protocol commands (create, delete, update, ...), and thus
> either a new protocol level extension would have to be 
> defined, or some
> child element would have to be defined with different looking 
> syntax for
> the same semantics (as the 'op=__' command attribute) in the transfer.
> Please tell me if I understood things wrong.

You're right, and that's how it's supposed to work.  The functionality
you're describing can always be added as extensions if/when someone wants
them.
 
> Assuming the response to a transfer command is 1001 "Command completed
> successfully; action pending". What would the server answer to a
> transfer query command (assuming nothing concerning this transfer has
> changed at server since the 1001 was sent)?

There's nothing that should stop a query from being answered completely, so
a 1000 response code is appropriate.  Remember that each response code is
related directly to the command it is being sent for and it becomes easier
to remember which code is appropriate.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h62DDjmb020580 for <[e-mail]>; Wed, 2 Jul 2003 15:13:45 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h62DDjgr020579 for ietf-provreg-outgoing; Wed, 2 Jul 2003 15:13:45 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from central.switch.ch (central.switch.ch [130.59.4.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h62DDgmb020574 for <[e-mail]>; Wed, 2 Jul 2003 15:13:45 +0200 (MEST)
Received: from machb.switch.ch ([130.59.4.143]) by central.switch.ch with esmtp (Exim 3.20 #1) id 19XhQb-0006sh-00; Wed, 02 Jul 2003 15:13:41 +0200
Date: Wed, 2 Jul 2003 15:11:45 +0200 (CEST)
From: Bernie Hoeneisen <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
cc: [e-mail]
Subject: RE: [ietf-provreg] Some EPP questions
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

Hi Scott!

Thanks for your fast answers.

I have some further questions (inline).

cheers,
 Bernie

On Mon, 30 Jun 2003, Hollenbeck, Scott wrote:

> >1) epp-09, 2.9.3.4:
> >
> >   In the transfer command, there is a command attribute 'op=__' defined,
> >   which can take values 'request', 'cancel', 'approve', 'reject',
> >   'query'. In other transform commands such as 'delete', 'create', or
> >   'update' no such 'op=__' attribute is defined.
> >
> >   An example, where an "op=cancel" command attribute for a delete request
> >   is useful, could be:
> >
> >   A domain object is in a pendingDelete state, and the holder changes his
> >   mind (he wants to keep the domain name). In this case I see no EPP
> >   mechanism for the registrar to interact, i.e. cancel the delete
> >   request. Also an "op=query" to figure out the state of the request
> >   could be useful in such a case.
> >
> >   What is the reason, why the same command attributes 'op=cancel', etc.
> >   are not foreseen for other transform commands?
>
> All of the pother commands are typically processed in real time without
> cross-client interaction.  A transfer requires action from a second client.
> We debated the merits of allowing cancels of deletes etc., but I for one
> thought such facilities out of place for commands that don't require action
> from a second client.

Whereas this seams true for the current specifications, one never knows,
what local policies and extensions to EPP will bring in the future. It
might be that these other commands (create, delete, update, ...) also
need actions from a second client for a future extension.

In the following two examples of such possible extension:

i) Lets consider a policy, where e.g. a domain update (change of delegated
   nameservers) needs the approval of the sponsoring client(s) of the
   new delegated host(s) (assuming the sponsoring client(s) of the host(s)
   differ from the sponsoring client of the domain). Such an approval
   procedure could be defined (in an extension) similarly in the transfer.

ii) Another example could be deletion of a host object, which is delegated
    nameserver also from domains of other sponsoring clients. An extension
    could define a well-defined procedure for a graceful deletion of such
    hosts by asking the approval of the other involved sponsoring
    client(s) via EPP (extension).

I don't intend to discuss now the usefulness of such possible services as
described above.

I rather want to stress out, that future extensions might need such
possibilities as provided by the 'op=__' command attribute of the transfer
command only. And if I understood the guidelines for epp extensions draft
correctly, it is not possible to add e.g. an 'op=__' command attribute to
the existing protocol commands (create, delete, update, ...), and thus
either a new protocol level extension would have to be defined, or some
child element would have to be defined with different looking syntax for
the same semantics (as the 'op=__' command attribute) in the transfer.
Please tell me if I understood things wrong.


> > 2) epp-09, 3; epp-09, 2.9.3.4; epp-domain-07, 3.2.4;
> > epp-contact-07, 3.2.4
> >
> >    In section 3 (epp-09), in the result codes it is described:
> >
> >      Code    Response text in English
> >      ___________________________________
> >
> >      1000    "Command completed successfully"
> >      This is the usual response code for a successfully completed
> >      command that is not addressed by any other 1xxx-series response
> >      code.
> >
> >      1001    "Command completed successfully; action pending"
> >      This response code MUST be returned when responding to a command
> >      the requires offline activity before the requested action can be
> >      completed.  See section 2 for a description of other processing
> >      requirements.
> >
> >    In the examples epp-09, 2.9.3.4; epp-domain-07, 3.2.4;
> > epp-contact-07,
> >    3.2.4, (transfer command) the result code is "1000",
> > although further
> >    below there is <obj:trStatus>pending</obj:trStatus>.
> >
> >    What is the idea behind, that the response to the transfer
> > command is
> >    labled as 'completed successfully', but on the other hand it is
> >    pending?
>
> The difference is in command processing vs. action completion.  When a
> command is received and processed successfully, you get the 1000 response
> code.  When something has to happen out-of-band, you get the 1001 response.
> 1001 means that command has been received and processed, but some action
> related to the command wasn't completed before the response was sent.

Assuming the response to a transfer command is 1001 "Command completed
successfully; action pending". What would the server answer to a
transfer query command (assuming nothing concerning this transfer has
changed at server since the 1001 was sent)?


cheers,
 Bernie