[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: ietf-provreg@cafax.se
From: "Owen Borseth" <owen@name.com>
Date: Tue, 30 Jan 2007 09:45:58 -0700
Content-Disposition: inline
In-Reply-To: <C1E3B5E3.2FBFB%jgould@verisign.com>
Sender: owner-ietf-provreg@cafax.se
Subject: Re: [ietf-provreg] RFC 3730 (EPP)

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

On 1/29/07, James Gould <jgould@verisign.com> wrote:
> 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
> jgould@verisign.com
> 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 <andrew@ca.afilias.info>
> > Reply-To: Andrew Sullivan <andrew@ca.afilias.info>
> > Date: Mon, 29 Jan 2007 13:38:48 -0500
> > To: <ietf-provreg@cafax.se>
> > Subject: Re: [ietf-provreg] RFC 3730 (EPP)
> >
> > On Mon, Jan 29, 2007 at 11:20:55AM -0700, Owen Borseth wrote:
> >> 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.
> >
> > 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
> >
> > --
> > Andrew Sullivan                         204-4141 Yonge Street
> > Afilias Canada                        Toronto, Ontario Canada
> > <andrew@ca.afilias.info>                              M2P 2A8
> > jabber: ajsaf@jabber.org                 +1 416 646 3304 x4110
>
>

Home | Date list | Subject list