RE:<msg> element

["Lynette Khirallah" <lynettek@netnumber.com>]

We are new to this list but have been monitoring it for a while. This
suggestion came from NetNumber as we test an implementation of EPP.

You are free to translate the error code into a message at any time, and to
translate it into any language you want on the client. Yes, it is convenient
on the client side to get the message text with the error code, but
unnecessary overhead on the server side. Who should be spending cycles on
generating human-readable, langage specific error messages: the client or
the server?

-Lynette



> -----Original Message-----
> From: owner-ietf-provreg@cafax.se
> [mailto:owner-ietf-provreg@cafax.se]On
> Behalf Of Daniel Manley
> Sent: Wednesday, November 21, 2001 11:47 AM
> To: Hollenbeck, Scott
> Cc: ietf-provreg@cafax.se
> Subject: Re: Provreg WG last call announcement
>
>
> 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-
> >
>
>
>
>