Re: <msg> element

[Jens-Uwe Gaspar <jug@schlund.de>]

Lynette Khirallah wrote:
> 
> 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?

It may be a small overhead on the server side, if you must simply convert
an error-code, e.g. 2003 => "Required parameter missing". But often the
'error text' (MAY) contain more information about the specific error than
simply the EPP-error-code-TO-EPP-error-text. For example:

  2003 'Required parameter missing; missing email ...'
  2005 'Parameter value syntax error; FaxType:number:+49.183335255587x055'
  2306 'Parameter value policy error'; 'registrant required'

So i agree with Daniel.

Best regards,

Jens-Uwe Gaspar

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

________________________________________________________________________
Jens-Uwe Gaspar                              Schlund + Partner AG
E-Mail: jug@schlund.de                       Erbprinzenstr. 4 - 12
Tel. +49-721-91374-50                        76133 Karlsruhe, Germany
Fax  +49-721-91374-20                        http://www.schlund.de