RE: Provreg WG last call announcement

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

> -----Original Message-----
> From: Sheer El-Showk [mailto:sheer@saraf.com]
> Sent: Monday, November 26, 2001 3:34 PM
> To: Daniel Manley
> Cc: Hollenbeck, Scott; ietf-provreg@cafax.se
> Subject: Re: Provreg WG last call announcement
> 
> 
> Well there is another concern with the message being specified directly
> in the protocol itself and that is internationalization.  While status
> values, xml elements, etc have to be specified in some language to make a
> meaningful protocol I think we should avoid specifying error string
> values.
> 
> An alternative suggestion, and one that might be more meaningful to
> automated registrar systems, would be to include a second, more detailed
> response code.  This would involve adding a second <minor-code> tag that
> would display a numerical subcode to any of the existing EPP codes.  Thus
> a response object would now include two different codes:
> 
> main Epp Code:	2003    "Required parameter missing"
> Epp subcode:	2003-4	"ID required for contact create"

There's a problem with the above suggestion: you've just mixed an
object-specific subcode into the object-agnostic base protocol.  Plus, isn't
the idea of trying to specify policy-specific error situations is something
we covered (and rejected) quite some time ago?

I really don't think it possible to identify a subcode for every possible
error situation.  Even if we tried to create object-specific subcodes to put
the object-specific semantics where they belong, I can't see a way to come
up with a completely unambiguous set of codes.  All we'd be doing is adding
an additional layer of codes, and we'd _still_ have a list that is either
over-specified for someone or under-specified for someone else.

> I think this would make for much cleaner error handling on the part of the
> registrar.
> 
> Of course this could be done in the <value> tags and in either case it
> would need to be extensible to reflect different registry rules, but I
> think a basic framework for a minor code in the base protocol would go a
> long way towards making client-side epp implementations more standardized
> (ie provide consistant error handling in the protocol rather than rely on
> parsing registry-dependent data out of <value> tags).

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.

-Scott-

[1] From section 2.5 of epp-05:

"- Zero or more OPTIONAL <value> elements that echo client-provided values
that caused server error conditions."