Re: <msg> element

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

Well I think the extra info you mentioned is supposed to go in the <value>
tags.  As I understood it the <msg> tags were supposed to be statically
mapped to the response code numbers.  I just posted a suggestion about
including more detailed numerical sub-codes and allowing registries to
extend them.  I think this would address what you describe but in a manner
that is more pleasant to implement (ie using a sub-code rather than
parsing response texts).  A large subset of these sub-codes would be
registry independent (ie they would reflect Epp requirements, not registry
local policy) so a client implementation (RTK or Neulevel's) could
provide a fair amount of support for a more detailed level of error
handling without requiring per-registry customization.

Regards,
Sheer

On Mon, 26 Nov 2001, Jens-Uwe Gaspar wrote:

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