Subject: RE: [ietf-provreg] EPP and IDN

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 31 Jul 2003 07:14:16 -0400

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

---

From: "Edmon Chung" <[email-masked]>
Date: Thu, 31 Jul 2003 10:52:30 -0400

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" <[email-masked]>
To: "'Klaus Malorny'" <[email-masked]>; <[email-masked]>
Sent: Thursday, July 31, 2003 7:14 AM
Subject: RE: [ietf-provreg] EPP and IDN

> not a protocol requirement.

From: "Edmon Chung" <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>, "'Klaus Malorny'" <[email-masked]>, <[email-masked]>
Subject: Re: [ietf-provreg] EPP and IDN
Date: Thu, 31 Jul 2003 10:52:30 -0400
Sender: [email-masked]

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" <[email-masked]>
To: "'Klaus Malorny'" <[email-masked]>; <[email-masked]>
Sent: Thursday, July 31, 2003 7:14 AM
Subject: RE: [ietf-provreg] EPP and IDN

> not a protocol requirement.

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: [ietf-provreg] FW: I-D ACTION:draft-hollenbeck-epp-rgp-01.txt
Date: Thu, 31 Jul 2003 10:32:14 -0400
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
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:
	[email-masked].
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="[email-masked]"

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

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

To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [ietf-provreg] EPP and IDN
From: Kentaro Mori <[email-masked]>
Date: Thu, 31 Jul 2003 21:57:14 +0900
Lines: 42
Sender: [email-masked]

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 <[email-masked]> 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: [email-masked]

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Stephane Bortzmeyer'" <[email-masked]>, Klaus Malorny <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: [ietf-provreg] EPP and IDN
Date: Thu, 31 Jul 2003 07:58:19 -0400
Sender: [email-masked]

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

Date: Thu, 31 Jul 2003 13:22:34 +0200
From: Stephane Bortzmeyer <[email-masked]>
To: Klaus Malorny <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: [ietf-provreg] EPP and IDN
Organization: NIC France
Sender: [email-masked]

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

On Thu, Jul 31, 2003 at 09:59:11AM +0200,
 Klaus Malorny <[email-masked]> 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.)

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Klaus Malorny'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: [ietf-provreg] EPP and IDN
Date: Thu, 31 Jul 2003 07:14:16 -0400
Sender: [email-masked]

-Scott-

Date: Thu, 31 Jul 2003 09:59:11 +0200
From: Klaus Malorny <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: [ietf-provreg] EPP and IDN
Sender: [email-masked]

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
      [email-masked]             Tel. +49 231 9703 0

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: [ietf-provreg] RGP Restore Report Proposal
Date: Wed, 16 Jul 2003 04:37:44 -0400
Sender: [email-masked]

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

Date: Mon, 7 Jul 2003 12:47:43 -0700
To: Edward Lewis <[email-masked]>, [email-masked]
From: [email-masked]
Subject: Re: [ietf-provreg] So what's the holdup?
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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                                            +1-703-227-9854
>ARIN Research Engineer
>
>...as graceful as a blindfolded bull in a china shop...

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>, [email-masked]
Cc: [email-masked], "'Michael Mealling'" <[email-masked]>
Subject: RE: [ietf-provreg] So what's the holdup?
Date: Mon, 7 Jul 2003 15:32:39 -0400 
Sender: [email-masked]

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

Date: Mon, 7 Jul 2003 15:03:24 -0400
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: [ietf-provreg] So what's the holdup?
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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                                            +1-703-227-9854
ARIN Research Engineer

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

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Bernie Hoeneisen'" <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>
Cc: [email-masked]
Subject: RE: [ietf-provreg] Some EPP questions
Date: Mon, 7 Jul 2003 09:56:26 -0400 
Sender: [email-masked]

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

Date: Wed, 2 Jul 2003 17:20:05 +0200 (CEST)
From: Bernie Hoeneisen <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
cc: [email-masked]
Subject: RE: [ietf-provreg] Some EPP questions
Sender: [email-masked]

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

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Bernie Hoeneisen'" <[email-masked]>
Cc: [email-masked]
Subject: RE: [ietf-provreg] Some EPP questions
Date: Wed, 2 Jul 2003 09:20:06 -0400 
Sender: [email-masked]

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

Date: Wed, 2 Jul 2003 15:11:45 +0200 (CEST)
From: Bernie Hoeneisen <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
cc: [email-masked]
Subject: RE: [ietf-provreg] Some EPP questions
Sender: [email-masked]

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