To:
ietf-provreg@cafax.se
From:
Roger Castillo Cortazar <castillo@mail.nic.mx>
Date:
Mon, 19 Aug 2002 17:05:59 -0500
In-Reply-To:
<5.1.1.6.0.20020814125551.0333ba00@mail.nic.mx>
Sender:
owner-ietf-provreg@cafax.se
Subject:
RE: Result codes to handle protocol extension-related errors.
Some clarifications. >>The trouble with a code that means "look in the extension" is that a client >>must know how to interpret the extension to find the supplementary error >>information. Since formats will vary from one extension to another, the >>client will have to have built-in knowledge about what elements in extension >>to look at. So why not just return the generic EPP command failure status >>code(s) and let the client look at the extension if it wants to? This allows >>for a fairly smooth degradation in functionality in cases where the >>extension element isn't understood. > >Exactly !!! A little bit more .... >The use of extensions have to be with an agreemente between the parts. >IMHO there has to be a previous arrangemente between registry and >registrar to use >a particular protocol extension. A client must have buitl-in knowledge in >order >to use an extension, and a registry may requiere that a registrar >implements that >knowledge to do bussiness with him. > >I'd go with the generic EPP command failure status code(s), to indicate the >client to look in the extension element for details. I mean the 1600 and 2600 generic result codes for protocol extensions, as suggested by Scott. Any comments ? I'd appreciate some some directions if I'm getting off the right track ? >Greetings. More Greetings. Roger Castillo Cortazar NIC-Mexico http://www.nic.mx Top Level Domain .MX