Re: Provreg WG last call announcement

[Sheer El-Showk <sheer@saraf.com>]

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"

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

Regards,
Sheer

On Wed, 21 Nov 2001, Daniel Manley wrote:

> It would be a shame to lose the msg in the response.  It's very
> convenient to just pass the server's message along to upstream
> subsystems in the registrar's systems.  Sure, the end user usually
> doesn't see "Parameter value syntax error", but intermediate debugging
> or transaction logging with the msg automatically there is nice to have.
>
> Dan
>
> Hollenbeck, Scott wrote:
>
> >Here's my list of things that need to be fixed:
> >
> >- The E.164 number recognition pattern in the contact mapping needs to be
> >fixed.  As it is right now, it incorrectly rejects numbers that contain more
> >than 12 characters in the local part if the country code contains less than
> >3 characters.  I'll forward a description of the problem and the proposed
> >fix to the list shortly.
> >
> >- Text edits in the domain document to explain that the trailing dot
> >required to form a fully qualified DNS name is implicit rather then
> >required.
> >
> >- Text edits to the domain document to add text to the <delete> description
> >to suggest that messages SHOULD be queued to all of the clients that manage
> >objects that are impacted by <delete> requests.
> >
> >- Changing the postalLineLength limit in the contact document from 64 to 256
> >to provide more headroom for growth.  I know we talked about 64 vs. 255 on
> >the list, but I like working with powers of 2. ;-)
> >
> >- Adding elements to the domain mapping to support delegation to hosts that
> >do not or should not need to exist as host objects.
> >
> >- Fixing the schemas where <choice> is currently used to allow <add>, <rem>,
> >and <chg> elements.
> >
> >I've also had a private suggestion to make the <msg> element OPTIONAL in the
> ><result> element that's returned in each response.  This element is
> >currently used to provide a human-readable description of the response code;
> >the suggestion I received is that this isn't absolutely necessary if the
> >code itself is specified.  I can see where this text might be useful for
> >debugging, but maybe not as useful in normal everyday operations, so I'm
> >inclined to incorporate this suggestion, too.
> >
> >-Scott-
> >
>
>
>