Subject: [ietf-provreg] RFC 3730 (EPP)

From: "Owen Borseth" <[email-masked]>
Date: Mon, 29 Jan 2007 09:47:29 -0700

Hello. My name is Owen Borseth and I do work for several ICANN
accredited registrars. I'm trying to get a consensus on what the
proper response code should be from a registry for a particular domain
update command. If this is the improper location to try and get this
information please let me know.

In particular, what should be the proper response code to a domain
update command where the domain itself exists but the item being
updated for the domain does not exist?

The specific incident in question involves removing a status from an
existing domain but where the status itself does not exist for the
domain. For instance, what would be the proper response code if we
attempted to remove the "CLIENT UPDATE PROHIBITED" status from an
existing domain that did not already have that status? Hopefully this
explanation makes sense.

Any help that can be given as to what the proper response code should
be would be very much appreciated.

Thank you,
Owen Borseth

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 29 Jan 2007 12:21:05 -0500

> updated for the domain does not exist?

The general answer to this, I think, is that it is dependent on the
case in question.  For the most part, I'd expect error codes in the
23xx series.  That said. . .

> existing domain that did not already have that status? Hopefully this

. . .it seems to me that this case is either a 2304 (because local
policy could decide you can't remove a status that isn't there) or
e;se a 2002 (because the status has to be set before it can be
removed).  I'm not sure the current RFCs (or their proposed
replacements) gives one a reason to prefer one of these answers to the
other.

-- 
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
jabber: [email-masked]                 +1 416 646 3304 x4110

---

From: "Owen Borseth" <[email-masked]>
Date: Mon, 29 Jan 2007 11:20:55 -0700

OK. Thank you very much. Just to clarify something on my end, in the
particular case of attempting to remove a status from a domain where
the domain does exists but the status does not exist for that domain,
would:

   2303    "Object does not exist"
   This response code MUST be returned when a server receives a command
   to query or transform an object that does not exist in the repository.

ever be a proper response code? My assumption is that this response
code would only be valid if the domain itself did not exist.

- Owen

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 29 Jan 2007 13:38:48 -0500

> code would only be valid if the domain itself did not exist.

I can't see how it could be.  The RFCs (and their replacements -- the
bis docs are wending their way through final publication hurdles at
the IETF, but have been accepted) are pretty clear that a repository
object is one for which there is a mapping.  There is no mapping for
status values.  Status values are applied, instead, to repository
objects.

A

---

From: James Gould <[email-masked]>
Date: Mon, 29 Jan 2007 14:32:03 -0500

We return a 2306 "Parameter value policy error" for this use case, but I can
see how 2303 "Object does not exist" might be considered as long as you
qualified which object does not exist in the error response.

JG 

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Information Services
[email-masked]
Direct: 703.948.3271
Mobile: 703.628.7063

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, proprietary and/or
Registry  Sensitive information intended solely for the recipient and, thus
may not be  retransmitted, reproduced or disclosed without the prior written
consent of  VeriSign Naming and Directory Services.  If you have received
this e-mail message in error, please notify the sender immediately by
telephone or reply e-mail and destroy the original message without making a
copy.  Thank you.

> From: Andrew Sullivan <[email-masked]>
> Reply-To: Andrew Sullivan <[email-masked]>
> Date: Mon, 29 Jan 2007 13:38:48 -0500
> To: <[email-masked]>
> Subject: Re: [ietf-provreg] RFC 3730 (EPP)
>

---

From: "Owen Borseth" <[email-masked]>
Date: Tue, 30 Jan 2007 09:45:58 -0700

I wonder if that would be a little vague from a client side
programming perspective. If 2303 was allowed in this case then there
would be two scenarios where 2303 might be returned. 1) if the domain
didn't exist and 2) if the domain existed but the status wasn't
applied to the domain. You would not be able to rely on the status
code alone to determine if the object being modified (the domain) did
exist or not and you would have to attempt to parse the text error
message, which could vary between implementations, to find out what
happened. One registry that I have found does return 2303 in this
scenario but it seems non-compliant since the object really being
modified is the domain and not the status applied to the domain.

Also, is there a way to view the RFC replacement documents that are
pending publication? I poked around the IETF website but didn't really
find anything.

- Owen

---

From: Joe Abley <[email-masked]>
Date: Tue, 30 Jan 2007 12:10:56 -0500

> pending publication? I poked around the IETF website but didn't really

See attached message for the individual draft names. Google knows how  
to find them by name, or you can try:

http://www.ietf.org/internet-drafts/draft-hollenbeck-epp- 
rfc3734bis-05.txt
http://www.ietf.org/internet-drafts/draft-hollenbeck-epp- 
rfc3730bis-04.tx
http://www.ietf.org/internet-drafts/draft-hollenbeck-epp- 
rfc3731bis-05.txt
http://www.ietf.org/internet-drafts/draft-hollenbeck-epp- 
rfc3732bis-04.txt
http://www.ietf.org/internet-drafts/draft-hollenbeck-epp- 
rfc3733bis-06.txt

Joe

Begin forwarded message:

> From: The IESG <[email-masked]>
> Date: 29 January 2007 14:12:07 EST (CA)
> To: IETF-Announce <[email-masked]>
> Cc: Internet Architecture Board <[email-masked]>, RFC Editor <rfc- 
> [email-masked]>
> Subject: Protocol Action: 'Extensible Provisioning Protocol  (EPP)'  
> to Draft Standard
>
> The IESG has approved the following documents:
>
> - 'Extensible Provisioning Protocol (EPP) Transport Over TCP '
>    <draft-hollenbeck-epp-rfc3734bis-05.txt> as a Draft Standard
> - 'Extensible Provisioning Protocol (EPP) '
>    <draft-hollenbeck-epp-rfc3730bis-04.txt> as a Draft Standard
> - 'Extensible Provisioning Protocol (EPP) Domain Name Mapping '
>    <draft-hollenbeck-epp-rfc3731bis-05.txt> as a Draft Standard
> - 'Extensible Provisioning Protocol (EPP) Host Mapping '
>    <draft-hollenbeck-epp-rfc3732bis-04.txt> as a Draft Standard
> - 'Extensible Provisioning Protocol (EPP) Contact Mapping '
>    <draft-hollenbeck-epp-rfc3733bis-06.txt> as a Draft Standard
>
> These documents have been reviewed in the IETF but are not the  
> products of
> an IETF Working Group.
>
> The IESG contact person is Ted Hardie.
>
> A URL of this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-hollenbeck-epp- 
> rfc3730bis-04.txt
>
> Technical Summary
>
>  This set of documents advances EPP to draft standard and documents  
> the
>   implementations used to make that advancement.
>
> Working Group Summary
>
>  This is the product of an individual submitter, though the working  
> group
>   mailing list of PROVREG (now closed) was used to collect  
> implementation
>  reports and discuss the implementations.
>
> Protocol Quality
>
>  This document was reviewed for the IESG by Ted Hardie.This ballot
> includes a down reference to RFC 2246 which was called out in the last
> call as required by RFC 3967.  Because the dependency between EPP  
> and TLS
> follows a well-defined modular interface, the IESG has chosen to allow
> this down reference under RFC 3967.
>
> Note to RFC Editor
>
> In Section 2.3, draft-hollenbeck-epp-rfc3730bis-04
>
> OLD:
> "An EPP client MAY request a <greeting> from an EPP server at any  
> time by
> sending a <hello> to a server."
>
> NEW:
> "An EPP client MAY request a <greeting> from an EPP server at any time
> between a successful <login> command and a <logout> command by  
> sending a
> <hello> to a server."
>
> In draft-hollenbeck-epp-rfc3734bis, Section 4:
>
> OLD:
>
>   The data field of the TCP header MUST contain an EPP data unit.  The
>   EPP data unit contains two fields: a 32-bit header that describes  
> the
>   total length of the data unit, and the EPP XML instance.  The length
>   of the EPP XML instance is determined by subtracting four octets  
> from
>   the total length of the data unit.  A receiver must successfully  
> read
>   that many octets to retrieve the complete EPP XML instance before
>   processing the EPP message.
>
>
> NEW:
>
>   The EPP data unit contains two fields: a 32-bit header that  
> describes
>   the total length of the data unit, and the EPP XML instance.  The
>   length of the EPP XML instance is determined by subtracting four
>   octets from the total length of the data unit.  A receiver must
>   successfully read that many octets to retrieve the complete EPP XML
>   instance before processing the EPP message.
>
>
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce
>

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 30 Jan 2007 12:27:42 -0500

On Tue, Jan 30, 2007 at 09:45:58AM -0700, Owen Borseth wrote:
> would be two scenarios where 2303 might be returned. 

That is my view, yes, although I defer to those on this list (which
is, I assure you, everybody) who are smarter about these things than I
am.

> pending publication? I poked around the IETF website but didn't really

https://datatracker.ietf.org/public/idindex.cgi will help you.  If you
search just on the title string "hollenbeck", the first listings are
the bis docs.

A

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 30 Jan 2007 12:32:27 -0500

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Owen Borseth
> Sent: Tuesday, January 30, 2007 11:46 AM
> To: [email-masked]

[snip]

> pending publication? I poked around the IETF website but didn't really

They are plain old Internet-Drafts.  Use the I-D tracker to look for the
documents (copy "draft-hollenbeck-epp" (without the quotes) into the
Filename field and hit "SEARCH"):

https://datatracker.ietf.org/public/pidtracker.cgi

-Scott-