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


To: "EPP Provreg" <ietf-provreg@cafax.se>
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
Date: Fri, 26 Mar 2010 12:57:12 -0400
Content-class: urn:content-classes:message
Sender: owner-ietf-provreg@cafax.se
Thread-Index: AcrNApnunDxRX9KsQDujaPs9dPrcggAAo4ow
Thread-Topic: Extending EPP Response Codes
Subject: [ietf-provreg] Extending EPP Response Codes

(Sorry to anyone who gets this twice - I sent it to the IRE list first
by mistake.)

During the Wednesday bar BOF some folks mentioned challenges in
extending the set of EPP response codes. I said it could be done.  Now
I'll describe how in more detail.  Readers should first understand RFC
3735 (this is the RFC that describes guidelines for extending EPP) and
section 2.7 of RFC 3730, 4930, or 5730.

Once you understand the basic principles of EPP extension, there's a
question to be answered before we can select the appropriate extension
type: are you trying to add new codes for use *in addition to* the
existing set, or are you trying to add new codes for use *instead of*
the existing set?  I'll describe both scenarios for completeness.

Given: response codes are a mandatory child element of the <response>
element.

"In addition to" use case: this requires definition of a data structure
to be included in the optional <extension> element that exists within
the <response> element.  Here's an example:

<response>
  <result code="1000">
    <msg lang="en">Command completed successfully</msg>
  </result>
  <extension>
    <addCodes:codeList
xmlns:addCodes="urn:ietf:params:xml:ns:addCodes-1.0">
      <addCodes:code code="1056">
        <msg lang="en">Account has been billed.</msg>
      </addCodes:code>
    </addCodes:infData>
  </extension>
  <trID>
    <clTRID>ABC-12345</clTRID>
    <svTRID>54321-XYZ</svTRID>
  </trID>
</response>

Note that the existing codes are still required.

"Instead of" use case: this requires definition of an extension data
structure to replace the existing <response> element.  A complete
example could get quite long, so instead I'll refer you to section 2.7.1
of the 3730/4930/5730 documents.  Here's what it could look like at a
high level:

<epp>
  <extension>
    <newResp:response
xmlns:newResp="urn:ietf:params:xml:ns:newResp-1.0">
      <newResp:result code="12345">
        <newResp:msg lang="en">This is a completely new response
code.</newResp:msg>
      </newResp:result>
      <!-- Other response elements. -->
    </newResp:response>
  </extension>
</epp>

This type of extension would require a lot more XML specification work
than changing the existing 1.0 schema and incrementing the version
number, but it's backward compatible and allows for opt-in processing.

Scott

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to ietf-provreg-request@cafax.se


Home | Date list | Subject list