Re: Provreg WG last call announcement

[Daniel Manley <dmanley@tucows.com>]

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