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