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


To: "'Patrick'" <patrick@gandi.net>, ietf-provreg@cafax.se
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
Date: Mon, 26 Nov 2001 16:52:42 -0500
Sender: owner-ietf-provreg@cafax.se
Subject: RE: Provreg WG last call announcement

> -----Original Message-----
> From: Patrick [mailto:patrick@gandi.net]
> Sent: Monday, November 26, 2001 3:33 PM
> To: ietf-provreg@cafax.se
> Subject: Re: Provreg WG last call announcement
> 
> 
> On Mon, Nov 26, 2001 at 03:03:16PM -0500, Hollenbeck, Scott 
> took time to write:
> > No, it can't be done in the <value> element.  That element exists to
> > identify the data that caused the error situation [1], not to carry
> > customized error responses.  If someone is passing registry-dependent
data
> > in the <value> element, the element is being misused.
> 
> Here is one example of messages from Neulevel's server:

[snip]

As I said, passing registry-defined error codes in the <value> element isn't
the way the <value> element is defined in the specs.  Thinking about this a
bit more, though, I can see where it would be helpful to provide more than
just the offending data in error situations - perhaps it makes more sense to
pass back the whole offending element, with data included.  In the case of
missing elements, or elements that are missing data, the server can just
pass back an empty element (including the object namespace, if needed) to
identify the problem.  In the example Sheer provided, it could look like
this:

<value><contact:id/></value>

to note that a <contact:id> element is missing.

If additional response codes are needed, the best place to define them would
be in the protocol's extension mechanism.

-Scott-

Home | Date list | Subject list