[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: "'Roger Castillo Cortazar'" <castillo@mail.nic.mx>, ietf-provreg@cafax.se
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
Date: Wed, 14 Aug 2002 09:48:22 -0400
Sender: owner-ietf-provreg@cafax.se
Subject: RE: Result codes to handle protocol extension-related errors.

> Hi everybody.
> 
> Now that some folks in the list are talking about extensions.
> 
> We are working on a protocol extension for nic.mx, and we'll 
> be needing to 
> inform our clients about errors related to the features added 
> by the extension.
> 
> What if I need to handle an error that is not covered in the 
> core documents ?
> 
> Could we define a new category to handle this result codes ? 
> For example ...
> 
> x3zz   Data Management
> x4zz   Server System
> x5zz   Connection Management
> x6xx   Extension Related
> 
> ... and leave it open ? or maybe we need to identify specific 
> errors to be 
> added to the core docs using the existing categories?
> (I think this is the way the "Action Pending"  result code is 
> going to be 
> handled).

I'd much rather see extensions (including error extensions) left within the
boundaries of an <extension> element instead of trying to anticipate
extension errors in the core document, we might be able to define two new
response codes (like maybe 1600 and 2600) that means either "command
succeeded" or "command failed", and "look at the <extension> for details.
I'm not sure if there's much value in this, though, since extensions can
supplement existing response codes anyway.

-Scott-

Home | Date list | Subject list