RE: lastVerified: optional vs. extension

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

> >> Error codes are not extensible, with the
> >> consequence that some existing registries put additional
> >> error codes in the free
> >> text elements (which are not thought to be parsed).
> >
> > Again, not true.  Additional errors and error codes can be defined 
> > using the
> > extension mechanism.  If implementers are putting additional error 
> > codes in
> > inappropriate free text elements they're extending the protocol 
> > improperly.
> 
> Do you have any examples of how this works?
> 
> Suppose I want to add an additional server system failure result code 
> (say, 2309, "openreg-specific failure of some kind"). How could I add 
> that in such a way that clients connecting to me could distinguish it 
> from some future revision of the spec that defines 2309 
> differently, or 
> some other registry which makes its own use of 2309?

This will be kind of long because of the examples.  Please bear with me --
references to the WG archives are included and listed below.

Interestingly enough, this topic was also discussed on the mailing list this
past August.  Roger Castillo Cortazar [1] brought up the idea of adding an
error code value for extension-related errors; I countered [2] with a
suggestion for one or two response codes that meant "look at the <extension>
for details".  It might be a good idea to follow that thread for a bit
before reading further since the idea for the need didn't pass WG muster.

To answer your specific question: One would have to work from an existing
response code, and the fact that extensions are unique should ensure that
there is no conflict in interpreting code collisions as long as the
extension code value is unique within the extension itself.

For example, you could do this to add a new response code or additional
code-related data to a success response:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
     epp-1.0.xsd">
  <response>
    <result code="1000">
      <msg>Command completed successfully</msg>
    </result>
    <extension>
      <foo:extData xmlns:foo="urn:ietf:params:xml:ns:foo"
       xsi:schemaLocation="urn:ietf:params:xml:ns:foo foo.xsd">
        <foo:result code="1111">
          <foo:what>This is a sample</foo:what>
        </foo:result>
      </foo:extData>
    </extension>
    <trID>
      <clTRID>ABC-12345</clTRID>
      <svTRID>54321-XYZ</svTRID>
    </trID>
  </response>
</epp>

Extension code value 1111 MUST be unique within the "foo" namespace to avoid
collisions.  You could do something similar with an error response:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
     epp-1.0.xsd">
  <response>
    <result code="2400">
      <msg>Command failed</msg>
    </result>
    <extension>
      <foo:extData xmlns:foo="urn:ietf:params:xml:ns:foo"
       xsi:schemaLocation="urn:ietf:params:xml:ns:foo foo.xsd">
        <foo:result code="2111">
          <foo:what>This is a sample</foo:what>
        </foo:result>
      </foo:extData>
    </extension>
    <trID>
      <clTRID>ABC-12345</clTRID>
      <svTRID>54321-XYZ</svTRID>
    </trID>
  </response>
</epp>

One might argue that we really need a general error code that requires an
extension for additional information, but as I said above that idea didn't
pass WG muster earlier this year.

-Scott-

[1]
http://www.cafax.se/ietf-provreg/maillist/2002-08/msg00070.html

[2]
http://www.cafax.se/ietf-provreg/maillist/2002-08/msg00073.html