1 Internet Engineering Task Force (IETF) J. Gould
2 Request for Comments: 9038 VeriSign, Inc.
3 Category: Standards Track M. Casanova
4 ISSN: 2070-1721 SWITCH
5 May 2021
6
7
8 Extensible Provisioning Protocol (EPP) Unhandled Namespaces
9
10 Abstract
11
12 The Extensible Provisioning Protocol (EPP), as defined in RFC 5730,
13 includes a method for the client and server to determine the objects
14 to be managed during a session and the object extensions to be used
15 during a session. The services are identified using namespace URIs,
16 and an "unhandled namespace" is one that is associated with a service
17 not supported by the client. This document defines an operational
18 practice that enables the server to return information associated
19 with unhandled namespace URIs and that maintains compliance with the
20 negotiated services defined in RFC 5730.
21
22 Status of This Memo
23
24 This is an Internet Standards Track document.
25
26 This document is a product of the Internet Engineering Task Force
27 (IETF). It represents the consensus of the IETF community. It has
28 received public review and has been approved for publication by the
29 Internet Engineering Steering Group (IESG). Further information on
30 Internet Standards is available in Section 2 of RFC 7841.
31
32 Information about the current status of this document, any errata,
33 and how to provide feedback on it may be obtained at
34 https://www.rfc-editor.org/info/rfc9038.
35
36 Copyright Notice
37
38 Copyright (c) 2021 IETF Trust and the persons identified as the
39 document authors. All rights reserved.
40
41 This document is subject to BCP 78 and the IETF Trust's Legal
42 Provisions Relating to IETF Documents
43 (https://trustee.ietf.org/license-info) in effect on the date of
44 publication of this document. Please review these documents
45 carefully, as they describe your rights and restrictions with respect
46 to this document. Code Components extracted from this document must
47 include Simplified BSD License text as described in Section 4.e of
48 the Trust Legal Provisions and are provided without warranty as
49 described in the Simplified BSD License.
50
51 Table of Contents
52
53 1. Introduction
54 1.1. Conventions Used in This Document
55 2. Unhandled Namespaces
56 3. Use of EPP <extValue> for Unhandled Namespace Data
57 3.1. Unhandled Object-Level Extension
58 3.2. Unhandled Command-Response Extension
59 4. Signaling Client and Server Support
60 5. Usage with General EPP Responses
61 6. Usage with Poll-Message EPP Responses
62 7. Implementation Considerations
63 7.1. Client Implementation Considerations
64 7.2. Server Implementation Considerations
65 8. IANA Considerations
66 8.1. XML Namespace
67 8.2. EPP Extension Registry
68 9. Security Considerations
69 10. References
70 10.1. Normative References
71 10.2. Informative References
72 Acknowledgements
73 Authors' Addresses
74
75 1. Introduction
76
77 The Extensible Provisioning Protocol (EPP), as defined in [RFC5730],
78 includes a method for the client and server to determine the objects
79 to be managed during a session and the object extensions to be used
80 during a session. The services are identified using namespace URIs.
81 How should the server handle service data that needs to be returned
82 in the response when the client does not support the required service
83 namespace URI, which is referred to as an "unhandled namespace"? An
84 unhandled namespace is a significant issue for the processing of the
85 poll messages described in [RFC5730], since poll messages are
86 inserted by the server prior to knowing the supported client
87 services, and the client needs to be capable of processing all poll
88 messages. Returning an unhandled namespace poll message is not
89 compliant with the negotiated services defined in [RFC5730], and
90 returning an error makes the unhandled namespace poll message a
91 poison message by halting the processing of the poll queue. An
92 unhandled namespace is also an issue for general EPP responses when
93 the server has information that it cannot return to the client due to
94 the client's supported services. The server should be able to return
95 unhandled namespace information that the client can process later.
96 This document defines an operational practice that enables the server
97 to return information associated with unhandled namespace URIs and
98 that maintains compliance with the negotiated services defined in
99 [RFC5730].
100
101 1.1. Conventions Used in This Document
102
103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
105 "OPTIONAL" in this document are to be interpreted as described in
106 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
107 capitals, as shown here.
108
109 XML [W3C.REC-xml11-20060816] is case sensitive. Unless stated
110 otherwise, XML specifications and examples provided in this document
111 MUST be interpreted in the character case presented in order to
112 develop a conforming implementation.
113
114 In examples, "S:" represents lines returned by a protocol server.
115 Indentation and white space in examples are provided only to
116 illustrate element relationships and are not required features of
117 this protocol.
118
119 The examples reference XML namespace prefixes that are used for the
120 associated XML namespaces. Implementations MUST NOT depend on the
121 example XML namespaces and instead employ a proper namespace-aware
122 XML parser and serializer to interpret and output the XML documents.
123 The example namespace prefixes used and their associated XML
124 namespaces include:
125
126 changePoll: urn:ietf:params:xml:ns:changePoll-1.0
127
128 domain: urn:ietf:params:xml:ns:domain-1.0
129
130 secDNS: urn:ietf:params:xml:ns:secDNS-1.1
131
132 In the template example XML, placeholder content is represented by
133 the following variables:
134
135 [NAMESPACE-XML]: XML content associated with a login service
136 namespace URI. An example is the <domain:infData> element
137 content in [RFC5731].
138
139 [NAMESPACE-URI]: XML namespace URI associated with the [NAMESPACE-
140 XML] XML content. An example is "urn:ietf:params:xml:ns:domain-
141 1.0" in [RFC5731].
142
143 2. Unhandled Namespaces
144
145 An unhandled namespace is an XML namespace that is associated with a
146 response extension that is not included in the client-specified EPP
147 login services of [RFC5730]. The EPP login services consist of the
148 set of XML namespace URIs included in the <objURI> or <extURI>
149 elements of the EPP <login> command [RFC5730]. The services
150 supported by the server are included in the <objURI> and <extURI>
151 elements of the EPP <greeting> [RFC5730], which should be a superset
152 of the login services included in the EPP <login> command. A server
153 may have information associated with a specific namespace that it
154 needs to return in the response to a client. The unhandled
155 namespaces problem exists when the server has information that it
156 needs to return to the client, but the namespace of the information
157 is not supported by the client based on the negotiated EPP <login>
158 command services.
159
160 3. Use of EPP <extValue> for Unhandled Namespace Data
161
162 In [RFC5730], the <extValue> element is used to provide additional
163 error diagnostic information, including the <value> element that
164 identifies the client-provided element that caused a server error
165 condition and the <reason> element containing the human-readable
166 message that describes the reason for the error. This operational
167 practice extends the use of the <extValue> element for the purpose of
168 returning unhandled namespace information in a successful response.
169
170 When a server has data to return to the client that the client does
171 not support based on the login services, the server MAY return a
172 successful response with the data for each unsupported namespace
173 moved into an <extValue> element [RFC5730]. The unhandled namespace
174 will not cause an error response, but the unhandled namespace data
175 will instead be moved to an <extValue> element, along with a reason
176 why the unhandled namespace data could not be included in the
177 appropriate location of the response. The <extValue> element will
178 not be processed by the XML processor. The <extValue> element
179 contains the following child elements:
180
181 <value>: Contains a child element with the unhandled namespace XML.
182 The unhandled namespace MUST be declared in the child element or
183 any containing element, including the root element. XML
184 processing of the <value> element is disabled by the XML schema
185 in [RFC5730], so the information can safely be returned in the
186 <value> element.
187
188 <reason>: A formatted, human-readable message that indicates the
189 reason the unhandled namespace data was not returned in the
190 appropriate location of the response. The formatted reason
191 SHOULD follow the Augmented Backus-Naur Form (ABNF) grammar
192 [RFC5234] format: NAMESPACE-URI " not in login services", where
193 NAMESPACE-URI is the unhandled XML namespace like
194 "urn:ietf:params:xml:ns:domain-1.0" in [RFC5731].
195
196 This document applies to the handling of unsupported namespaces for
197 object-level extensions and command-response extensions [RFC3735].
198 This document does not apply to the handling of unsupported
199 namespaces for protocol-level extensions or authentication-
200 information extensions [RFC3735]. Refer to the following sections on
201 how to handle an unsupported object-level extension namespace or an
202 unsupported command-response extension namespace.
203
204 3.1. Unhandled Object-Level Extension
205
206 An object-level extension in [RFC5730] is a child element of the
207 <resData> element. If the client does not handle the namespace of
208 the object-level extension, then the <resData> element is removed and
209 its object-level extension child element is moved into an <extValue>
210 <value> element [RFC5730], with the namespace URI included in the
211 corresponding <extValue> <reason> element. The response becomes a
212 general EPP response without the <resData> element.
213
214 Below is a template response for a supported object-level extension.
215 The [NAMESPACE-XML] variable represents the object-level extension
216 XML.
217
218 S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
219 S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
220 S: <response>
221 S: <result code="1000">
222 S: <msg>Command completed successfully</msg>
223 S: </result>
224 S: <resData>
225 S: [NAMESPACE-XML]
226 S: </resData>
227 S: <trID>
228 S: <clTRID>ABC-12345</clTRID>
229 S: <svTRID>54322-XYZ</svTRID>
230 S: </trID>
231 S: </response>
232 S:</epp>
233
234 Below is a template for an unhandled namespace response for an
235 unsupported object-level extension. The [NAMESPACE-XML] variable
236 represents the object-level extension XML, and the [NAMESPACE-URI]
237 variable represents the object-level extension XML namespace URI.
238
239 S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
240 S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
241 S: <response>
242 S: <result code="1000">
243 S: <msg>Command completed successfully</msg>
244 S: <extValue>
245 S: <value>
246 S: [NAMESPACE-XML]
247 S: </value>
248 S: <reason>
249 S: [NAMESPACE-URI] not in login services
250 S: </reason>
251 S: </extValue>
252 S: </result>
253 S: <trID>
254 S: <clTRID>ABC-12345</clTRID>
255 S: <svTRID>54322-XYZ</svTRID>
256 S: </trID>
257 S: </response>
258 S:</epp>
259
260 The EPP response is converted from an object response to a general
261 EPP response by the server when the client does not support the
262 object-level extension namespace URI.
263
264 Below is an example of a <transfer> query response (see Section 3.1.3
265 of [RFC5731]) converted into an unhandled namespace response.
266
267 S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
268 S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
269 S: <response>
270 S: <result code="1000">
271 S: <msg>Command completed successfully</msg>
272 S: <extValue>
273 S: <value>
274 S: <domain:trnData
275 S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
276 S: <domain:name>example.com</domain:name>
277 S: <domain:trStatus>pending</domain:trStatus>
278 S: <domain:reID>ClientX</domain:reID>
279 S: <domain:reDate>2000-06-06T22:00:00.0Z</domain:reDate>
280 S: <domain:acID>ClientY</domain:acID>
281 S: <domain:acDate>2000-06-11T22:00:00.0Z</domain:acDate>
282 S: <domain:exDate>2002-09-08T22:00:00.0Z</domain:exDate>
283 S: </domain:trnData>
284 S: </value>
285 S: <reason>
286 S: urn:ietf:params:xml:ns:domain-1.0 not in login services
287 S: </reason>
288 S: </extValue>
289 S: </result>
290 S: <trID>
291 S: <clTRID>ABC-12345</clTRID>
292 S: <svTRID>54322-XYZ</svTRID>
293 S: </trID>
294 S: </response>
295 S:</epp>
296
297 3.2. Unhandled Command-Response Extension
298
299 A command-response extension in [RFC5730] is a child element of the
300 <extension> element. If the client does not handle the namespace of
301 the command-response extension, the command-response child element is
302 moved into an <extValue> <value> element [RFC5730], with the
303 namespace URI included in the corresponding <extValue> <reason>
304 element. Afterwards, if there are no additional command-response
305 child elements, the <extension> element MUST be removed.
306
307 Below is a template response for a supported command-response
308 extension. The [NAMESPACE-XML] variable represents the command-
309 response extension XML.
310
311 S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
312 S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
313 S: <response>
314 S: <result code="1000">
315 S: <msg>Command completed successfully</msg>
316 S: </result>
317 S: <extension>
318 S: [NAMESPACE-XML]
319 S: </extension>
320 S: <trID>
321 S: <clTRID>ABC-12345</clTRID>
322 S: <svTRID>54322-XYZ</svTRID>
323 S: </trID>
324 S: </response>
325 S:</epp>
326
327 Below is a template of an unhandled namespace response for an
328 unsupported command-response extension. The [NAMESPACE-XML] variable
329 represents the command-response extension XML, and the [NAMESPACE-
330 URI] variable represents the command-response extension XML namespace
331 URI.
332
333 S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
334 S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
335 S: <response>
336 S: <result code="1000">
337 S: <msg>Command completed successfully</msg>
338 S: <extValue>
339 S: <value>
340 S: [NAMESPACE-XML]
341 S: </value>
342 S: <reason>
343 S: [NAMESPACE-URI] not in login services
344 S: </reason>
345 S: </extValue>
346 S: </result>
347 S: <trID>
348 S: <clTRID>ABC-12345</clTRID>
349 S: <svTRID>54322-XYZ</svTRID>
350 S: </trID>
351 S: </response>
352 S:</epp>
353
354 The EPP response is converted to an unhandled namespace response by
355 moving the unhandled command-response extension from under the
356 <extension> to an <extValue> element.
357
358 Below is example of the Delegation Signer (DS) Data Interface <info>
359 response (see Section 5.1.2 of [RFC5910]) converted to an unhandled
360 namespace response.
361
362 S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
363 S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
364 S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
365 S: <response>
366 S: <result code="1000">
367 S: <msg>Command completed successfully</msg>
368 S: <extValue>
369 S: <value>
370 S: <secDNS:infData
371 S: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
372 S: <secDNS:dsData>
373 S: <secDNS:keyTag>12345</secDNS:keyTag>
374 S: <secDNS:alg>3</secDNS:alg>
375 S: <secDNS:digestType>1</secDNS:digestType>
376 S: <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
377 S: </secDNS:dsData>
378 S: </secDNS:infData>
379 S: </value>
380 S: <reason>
381 S: urn:ietf:params:xml:ns:secDNS-1.1 not in login services
382 S: </reason>
383 S: </extValue>
384 S: </result>
385 S: <resData>
386 S: <domain:infData
387 S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
388 S: <domain:name>example.com</domain:name>
389 S: <domain:roid>EXAMPLE1-REP</domain:roid>
390 S: <domain:status s="ok"/>
391 S: <domain:registrant>jd1234</domain:registrant>
392 S: <domain:contact type="admin">sh8013</domain:contact>
393 S: <domain:contact type="tech">sh8013</domain:contact>
394 S: <domain:ns>
395 S: <domain:hostObj>ns1.example.com</domain:hostObj>
396 S: <domain:hostObj>ns2.example.com</domain:hostObj>
397 S: </domain:ns>
398 S: <domain:host>ns1.example.com</domain:host>
399 S: <domain:host>ns2.example.com</domain:host>
400 S: <domain:clID>ClientX</domain:clID>
401 S: <domain:crID>ClientY</domain:crID>
402 S: <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate>
403 S: <domain:upID>ClientX</domain:upID>
404 S: <domain:upDate>1999-12-03T09:00:00.0Z</domain:upDate>
405 S: <domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate>
406 S: <domain:trDate>2000-04-08T09:00:00.0Z</domain:trDate>
407 S: <domain:authInfo>
408 S: <domain:pw>2fooBAR</domain:pw>
409 S: </domain:authInfo>
410 S: </domain:infData>
411 S: </resData>
412 S: <trID>
413 S: <clTRID>ABC-12345</clTRID>
414 S: <svTRID>54322-XYZ</svTRID>
415 S: </trID>
416 S: </response>
417 S:</epp>
418
419 4. Signaling Client and Server Support
420
421 This document does not define new EPP protocol elements but rather
422 specifies an operational practice using the existing EPP protocol,
423 where the client and the server can signal support for the
424 operational practice using a namespace URI in the login and greeting
425 extension services. The namespace URI
426 "urn:ietf:params:xml:ns:epp:unhandled-namespaces-1.0" is used to
427 signal support for the operational practice. The client includes the
428 namespace URI in an <svcExtension> <extURI> element of the <login>
429 command [RFC5730]. The server includes the namespace URI in an
430 <svcExtension> <extURI> element of the greeting [RFC5730].
431
432 A client that receives the namespace URI in the server's greeting
433 extension services can expect the following supported behavior by the
434 server:
435
436 * support unhandled namespace object-level extensions and command-
437 response extensions in EPP poll messages, per Section 6
438
439 * support the option of unhandled namespace command-response
440 extensions in general EPP responses, per Section 5
441
442 A server that receives the namespace URI in the client's <login>
443 command extension services can expect the following supported
444 behavior by the client:
445
446 * support monitoring the EPP poll messages and general EPP responses
447 for unhandled namespaces
448
449 5. Usage with General EPP Responses
450
451 The unhandled namespace approach defined in Section 3 MAY be used for
452 a general EPP response to an EPP command. A general EPP response
453 includes any EPP response that is not a poll message. The use of the
454 unhandled namespace approach for poll-message EPP responses is
455 defined in Section 6. The server MAY exclude the unhandled namespace
456 information in the general EPP response or MAY include it using the
457 unhandled namespace approach.
458
459 The unhandled namespace approach for general EPP responses SHOULD
460 only be applicable to command-response extensions, defined in
461 Section 3.2, since the server SHOULD NOT accept an object-level EPP
462 command if the client did not include the object-level namespace URI
463 in the login services. An object-level EPP response extension is
464 returned when the server successfully executes an object-level EPP
465 command extension. The server MAY return an unhandled object-level
466 extension to the client, as defined in Section 3.1.
467
468 Returning domain name Redemption Grace Period (RGP) data, based on
469 [RFC3915], provides an example of applying the unhandled namespace
470 approach for a general EPP response. If the client does not include
471 the "urn:ietf:params:xml:ns:rgp-1.0" namespace URI in the login
472 services and the domain <info> response of a domain name does have
473 RGP information, the server MAY exclude the <rgp:infData> element
474 from the EPP response or MAY include it under the <extValue> element,
475 per Section 3.2.
476
477 Below is an example of a domain name <info> response [RFC5731]
478 converted to an unhandled <rgp:infData> element (see Section 4.1.1 of
479 [RFC3915]) included under an <extValue> element:
480
481 S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
482 S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
483 S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
484 S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
485 S: epp-1.0.xsd">
486 S: <response>
487 S: <result code="1000">
488 S: <msg>Command completed successfully</msg>
489 S: <extValue>
490 S: <value>
491 S: <rgp:infData xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0"
492 S: xsi:schemaLocation="urn:ietf:params:xml:ns:rgp-1.0
493 S: rgp-1.0.xsd">
494 S: <rgp:rgpStatus s="redemptionPeriod"/>
495 S: </rgp:infData>
496 S: </value>
497 S: <reason>
498 S: urn:ietf:params:xml:ns:rgp-1.0 not in login services
499 S: </reason>
500 S: </extValue>
501 S: </result>
502 S: <resData>
503 S: <domain:infData
504 S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
505 S: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
506 S: domain-1.0.xsd">
507 S: <domain:name>example.com</domain:name>
508 S: <domain:roid>EXAMPLE1-REP</domain:roid>
509 S: <domain:status s="pendingDelete"/>
510 S: <domain:registrant>jd1234</domain:registrant>
511 S: <domain:contact type="admin">sh8013</domain:contact>
512 S: <domain:contact type="tech">sh8013</domain:contact>
513 S: <domain:ns>
514 S: <domain:hostObj>ns1.example.com</domain:hostObj>
515 S: <domain:hostObj>ns1.example.net</domain:hostObj>
516 S: </domain:ns>
517 S: <domain:host>ns1.example.com</domain:host>
518 S: <domain:host>ns2.example.com</domain:host>
519 S: <domain:clID>ClientX</domain:clID>
520 S: <domain:crID>ClientY</domain:crID>
521 S: <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate>
522 S: <domain:upID>ClientX</domain:upID>
523 S: <domain:upDate>1999-12-03T09:00:00.0Z</domain:upDate>
524 S: <domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate>
525 S: <domain:trDate>2000-04-08T09:00:00.0Z</domain:trDate>
526 S: <domain:authInfo>
527 S: <domain:pw>2fooBAR</domain:pw>
528 S: </domain:authInfo>
529 S: </domain:infData>
530 S: </resData>
531 S: <trID>
532 S: <clTRID>ABC-12345</clTRID>
533 S: <svTRID>54322-XYZ</svTRID>
534 S: </trID>
535 S: </response>
536 S:</epp>
537
538 6. Usage with Poll-Message EPP Responses
539
540 The unhandled namespace approach, defined in Section 3, MUST be used
541 if there is unhandled namespace information included in a <poll>
542 response. The server inserts poll messages into the client's poll
543 queue independent of knowing the supported client login services;
544 therefore, there may be unhandled object-level extensions and
545 command-response extensions included in a client's poll queue. In
546 [RFC5730], the <poll> command is used by the client to retrieve and
547 acknowledge poll messages that have been inserted by the server. The
548 <poll> response is an EPP response that includes the <msgQ> element
549 that provides poll queue metadata about the message. The unhandled
550 namespace approach, defined in Section 3, is used for an unhandled
551 object-level extension and for each of the unhandled command-response
552 extensions attached to the <poll> response. The resulting <poll>
553 response MAY have either or both the object-level extension or
554 command-response extensions moved to <extValue> elements, as defined
555 in Section 3.
556
557 The change poll message, as defined in Section 3.1.2 of [RFC8590],
558 which is an extension of any EPP object, is an example of applying
559 the unhandled namespace approach for <poll> responses. Below are
560 examples of converting the domain name <info> response example in
561 Section 3.1.2 of [RFC8590] to an unhandled namespace response. The
562 object that will be used in the examples is a domain name object
563 [RFC5731].
564
565 Below is a domain name <info> <poll> response [RFC5731] with the
566 unhandled <changePoll:changeData> element [RFC8590] included under an
567 <extValue> element.
568
569 S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
570 S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
571 S: <response>
572 S: <result code="1301">
573 S: <msg lang="en-US">
574 S: Command completed successfully; ack to dequeue</msg>
575 S: <extValue>
576 S: <value>
577 S: <changePoll:changeData
578 S: xmlns:changePoll="urn:ietf:params:xml:ns:changePoll-1.0"
579 S: state="after">
580 S: <changePoll:operation>update</changePoll:operation>
581 S: <changePoll:date>
582 S: 2013-10-22T14:25:57.0Z</changePoll:date>
583 S: <changePoll:svTRID>12345-XYZ</changePoll:svTRID>
584 S: <changePoll:who>URS Admin</changePoll:who>
585 S: <changePoll:caseId type="urs">urs123
586 S: </changePoll:caseId>
587 S: <changePoll:reason>URS Lock</changePoll:reason>
588 S: </changePoll:changeData>
589 S: </value>
590 S: <reason>
591 S: urn:ietf:params:xml:ns:changePoll-1.0 not in login services
592 S: </reason>
593 S: </extValue>
594 S: </result>
595 S: <msgQ count="201" id="1">
596 S: <qDate>2013-10-22T14:25:57.0Z</qDate>
597 S: <msg>Registry initiated update of domain.</msg>
598 S: </msgQ>
599 S: <resData>
600 S: <domain:infData
601 S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
602 S: <domain:name>domain.example</domain:name>
603 S: <domain:roid>EXAMPLE1-REP</domain:roid>
604 S: <domain:status s="ok"/>
605 S: <domain:registrant>jd1234</domain:registrant>
606 S: <domain:contact type="admin">sh8013</domain:contact>
607 S: <domain:contact type="tech">sh8013</domain:contact>
608 S: <domain:clID>ClientX</domain:clID>
609 S: <domain:crID>ClientY</domain:crID>
610 S: <domain:crDate>2012-04-03T22:00:00.0Z</domain:crDate>
611 S: <domain:exDate>2014-04-03T22:00:00.0Z</domain:exDate>
612 S: </domain:infData>
613 S: </resData>
614 S: <trID>
615 S: <clTRID>ABC-12345</clTRID>
616 S: <svTRID>54322-XYZ</svTRID>
617 S: </trID>
618 S: </response>
619 S:</epp>
620
621 Below is an unhandled domain name <info> <poll> response [RFC5731]
622 and the unhandled <changePoll:changeData> element [RFC8590] included
623 under an <extValue> element.
624
625 S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
626 S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
627 S: <response>
628 S: <result code="1301">
629 S: <msg>Command completed successfully; ack to dequeue</msg>
630 S: <extValue>
631 S: <value>
632 S: <domain:infData
633 S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
634 S: <domain:name>domain.example</domain:name>
635 S: <domain:roid>EXAMPLE1-REP</domain:roid>
636 S: <domain:status s="ok"/>
637 S: <domain:registrant>jd1234</domain:registrant>
638 S: <domain:contact type="admin">sh8013</domain:contact>
639 S: <domain:contact type="tech">sh8013</domain:contact>
640 S: <domain:clID>ClientX</domain:clID>
641 S: <domain:crID>ClientY</domain:crID>
642 S: <domain:crDate>2012-04-03T22:00:00.0Z</domain:crDate>
643 S: <domain:exDate>2014-04-03T22:00:00.0Z</domain:exDate>
644 S: </domain:infData>
645 S: </value>
646 S: <reason>
647 S: urn:ietf:params:xml:ns:domain-1.0 not in login services
648 S: </reason>
649 S: </extValue>
650 S: <extValue>
651 S: <value>
652 S: <changePoll:changeData
653 S: xmlns:changePoll=
654 S: "urn:ietf:params:xml:ns:changePoll-1.0"
655 S: state="after">
656 S: <changePoll:operation>update</changePoll:operation>
657 S: <changePoll:date>
658 S: 2013-10-22T14:25:57.0Z</changePoll:date>
659 S: <changePoll:svTRID>12345-XYZ</changePoll:svTRID>
660 S: <changePoll:who>URS Admin</changePoll:who>
661 S: <changePoll:caseId type="urs">urs123
662 S: </changePoll:caseId>
663 S: <changePoll:reason>URS Lock</changePoll:reason>
664 S: </changePoll:changeData>
665 S: </value>
666 S: <reason>
667 S: urn:ietf:params:xml:ns:changePoll-1.0 not in login services
668 S: </reason>
669 S: </extValue>
670 S: </result>
671 S: <msgQ count="201" id="1">
672 S: <qDate>2013-10-22T14:25:57.0Z</qDate>
673 S: <msg>Registry initiated update of domain.</msg>
674 S: </msgQ>
675 S: <trID>
676 S: <clTRID>ABC-12345</clTRID>
677 S: <svTRID>54322-XYZ</svTRID>
678 S: </trID>
679 S: </response>
680 S:</epp>
681
682 7. Implementation Considerations
683
684 There are implementation considerations for the client and the server
685 to help address the risk of the client ignoring unhandled namespace
686 information included in an EPP response that is needed to meet
687 technical, policy, or legal requirements.
688
689 7.1. Client Implementation Considerations
690
691 To reduce the likelihood of a client receiving unhandled namespace
692 information, the client should consider implementing the following:
693
694 1. Ensure that the client presents the complete set of what it
695 supports when presenting its login services. If there are gaps
696 between the services supported by the client and the login
697 services included in the login command, the client may receive
698 unhandled namespace information that the client could have
699 supported.
700
701 2. Support all of the services included in the server greeting
702 services that may be included in an EPP response, including the
703 <poll> responses. The client should evaluate the gaps between
704 the greeting services and the login services provided in the
705 login command to identify extensions that need to be supported.
706
707 3. Proactively monitor for unhandled namespace information in the
708 EPP responses by looking for the inclusion of the <extValue>
709 element in successful responses, record the unsupported namespace
710 included in the <reason> element, and record the unhandled
711 namespace information included in the <value> element for later
712 processing. The unhandled namespace should be implemented by the
713 client to ensure that information is processed fully in future
714 EPP responses.
715
716 7.2. Server Implementation Considerations
717
718 To assist the clients in recognizing unhandled namespaces, the server
719 should consider implementing the following:
720
721 1. Monitor for returning unhandled namespace information to clients
722 and report it to the clients out of band to EPP, so the clients
723 can add support for the unhandled namespaces.
724
725 2. Look for the unhandled namespace support in the login services
726 when returning optional unhandled namespace information in
727 general EPP responses.
728
729 8. IANA Considerations
730
731 8.1. XML Namespace
732
733 This document uses URNs to describe XML namespaces conforming to a
734 registry mechanism described in [RFC3688]. The following URI
735 assignment has been made by IANA.
736
737 URI: urn:ietf:params:xml:ns:epp:unhandled-namespaces-1.0
738 Registrant Contact: IESG
739 XML: None. Namespace URIs do not represent an XML specification.
740
741 8.2. EPP Extension Registry
742
743 The EPP operational practice described in this document has been
744 registered by IANA in the "Extensions for the Extensible Provisioning
745 Protocol (EPP)" registry described in [RFC7451]. The details of the
746 registration are as follows:
747
748 Name of Extension: "Extensible Provisioning Protocol (EPP) Unhandled
749 Namespaces"
750 Document Status: Standards Track
751 Reference: RFC 9038
752 Registrant: IETF, <iesg@ietf.org>
753 TLDs: Any
754 IPR Disclosure: None
755 Status: Active
756 Notes: None
757
758 9. Security Considerations
759
760 This document does not provide any security services beyond those
761 described by EPP [RFC5730] and protocol layers used by EPP. The
762 security considerations described in these other specifications apply
763 to this specification as well. Since the unhandled namespace content
764 is XML that is not processed in the first pass by the XML parser, the
765 client SHOULD validate the XML when the content is processed to
766 protect against the inclusion of malicious content.
767
768 10. References
769
770 10.1. Normative References
771
772 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
773 Requirement Levels", BCP 14, RFC 2119,
774 DOI 10.17487/RFC2119, March 1997,
775 <https://www.rfc-editor.org/info/rfc2119>.
776
777 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
778 DOI 10.17487/RFC3688, January 2004,
779 <https://www.rfc-editor.org/info/rfc3688>.
780
781 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
782 Specifications: ABNF", STD 68, RFC 5234,
783 DOI 10.17487/RFC5234, January 2008,
784 <https://www.rfc-editor.org/info/rfc5234>.
785
786 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
787 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
788 <https://www.rfc-editor.org/info/rfc5730>.
789
790 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
791 Domain Name Mapping", STD 69, RFC 5731,
792 DOI 10.17487/RFC5731, August 2009,
793 <https://www.rfc-editor.org/info/rfc5731>.
794
795 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
796 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
797 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
798
799 [W3C.REC-xml11-20060816]
800 Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E.,
801 Yergeau, F., and J. Cowan, "Extensible Markup Language
802 (XML) 1.1 (Second Edition)", World Wide Web Consortium
803 Recommendation REC-xml11-20060816, 16 August 2006,
804 <https://www.w3.org/TR/2006/REC-xml11-20060816>.
805
806 10.2. Informative References
807
808 [RFC3735] Hollenbeck, S., "Guidelines for Extending the Extensible
809 Provisioning Protocol (EPP)", RFC 3735,
810 DOI 10.17487/RFC3735, March 2004,
811 <https://www.rfc-editor.org/info/rfc3735>.
812
813 [RFC3915] Hollenbeck, S., "Domain Registry Grace Period Mapping for
814 the Extensible Provisioning Protocol (EPP)", RFC 3915,
815 DOI 10.17487/RFC3915, September 2004,
816 <https://www.rfc-editor.org/info/rfc3915>.
817
818 [RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS)
819 Security Extensions Mapping for the Extensible
820 Provisioning Protocol (EPP)", RFC 5910,
821 DOI 10.17487/RFC5910, May 2010,
822 <https://www.rfc-editor.org/info/rfc5910>.
823
824 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible
825 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451,
826 February 2015, <https://www.rfc-editor.org/info/rfc7451>.
827
828 [RFC8590] Gould, J. and K. Feher, "Change Poll Extension for the
829 Extensible Provisioning Protocol (EPP)", RFC 8590,
830 DOI 10.17487/RFC8590, May 2019,
831 <https://www.rfc-editor.org/info/rfc8590>.
832
833 Acknowledgements
834
835 The authors wish to thank the following people for their feedback and
836 suggestions: Thomas Corte, Scott Hollenbeck, Patrick Mevzek, and
837 Marcel Parodi.
838
839 Authors' Addresses
840
841 James Gould
842 VeriSign, Inc.
843 12061 Bluemont Way
844 Reston, VA 20190
845 United States of America
846
847 Email: jgould@verisign.com
848 URI: http://www.verisign.com
849
850
851 Martin Casanova
852 SWITCH
853 P.O. Box
854 CH-8021 Zurich
855 Switzerland
856
857 Email: martin.casanova@switch.ch
858 URI: http://www.switch.ch
859
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.