To: "'Roger Castillo Cortazar'" <firstname.lastname@example.org>, email@example.com
From: "Hollenbeck, Scott" <firstname.lastname@example.org>
Date: Wed, 14 Aug 2002 09:48:22 -0400
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-