1 Internet Engineering Task Force (IETF) J. Gould
2 Request for Comments: 8590 VeriSign, Inc.
3 Category: Standards Track K. Feher
4 ISSN: 2070-1721 Neustar
5 May 2019
6
7
8 Change Poll Extension for the Extensible Provisioning Protocol (EPP)
9
10 Abstract
11
12 This document describes an Extensible Provisioning Protocol (EPP)
13 extension for notifying clients of operations on client-sponsored
14 objects that were not initiated by the client through EPP. These
15 operations may include contractual or policy requirements including,
16 but not limited to, regular batch processes, customer support
17 actions, Uniform Domain-Name Dispute-Resolution Policy (UDRP) or
18 Uniform Rapid Suspension (URS) actions, court-directed actions, and
19 bulk updates based on customer requests. Since the client is not
20 directly involved or knowledgable of these operations, the extension
21 is used along with an EPP object mapping to provide the resulting
22 state of the postoperation object, and optionally a preoperation
23 object, with the operation metadata of what, when, who, and why.
24
25 Status of This Memo
26
27 This is an Internet Standards Track document.
28
29 This document is a product of the Internet Engineering Task Force
30 (IETF). It represents the consensus of the IETF community. It has
31 received public review and has been approved for publication by the
32 Internet Engineering Steering Group (IESG). Further information on
33 Internet Standards is available in Section 2 of RFC 7841.
34
35 Information about the current status of this document, any errata,
36 and how to provide feedback on it may be obtained at
37 https://www.rfc-editor.org/info/rfc8590.
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52 Gould & Feher Standards Track [Page 1]
53 RFC 8590 changePoll May 2019
54
55
56 Copyright Notice
57
58 Copyright (c) 2019 IETF Trust and the persons identified as the
59 document authors. All rights reserved.
60
61 This document is subject to BCP 78 and the IETF Trust's Legal
62 Provisions Relating to IETF Documents
63 (https://trustee.ietf.org/license-info) in effect on the date of
64 publication of this document. Please review these documents
65 carefully, as they describe your rights and restrictions with respect
66 to this document. Code Components extracted from this document must
67 include Simplified BSD License text as described in Section 4.e of
68 the Trust Legal Provisions and are provided without warranty as
69 described in the Simplified BSD License.
70
71 Table of Contents
72
73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
74 1.1. Conventions Used in This Document . . . . . . . . . . . . 3
75 2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 4
76 2.1. Operation . . . . . . . . . . . . . . . . . . . . . . . . 4
77 2.2. State . . . . . . . . . . . . . . . . . . . . . . . . . . 5
78 2.3. Who . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
79 2.4. Dates and Times . . . . . . . . . . . . . . . . . . . . . 5
80 3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 6
81 3.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 6
82 3.1.1. EPP <check> Command . . . . . . . . . . . . . . . . . 6
83 3.1.2. EPP <info> Command . . . . . . . . . . . . . . . . . 6
84 3.1.3. EPP <transfer> Command . . . . . . . . . . . . . . . 14
85 3.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 14
86 3.2.1. EPP <create> Command . . . . . . . . . . . . . . . . 14
87 3.2.2. EPP <delete> Command . . . . . . . . . . . . . . . . 14
88 3.2.3. EPP <renew> Command . . . . . . . . . . . . . . . . . 14
89 3.2.4. EPP <transfer> Command . . . . . . . . . . . . . . . 14
90 3.2.5. EPP <update> Command . . . . . . . . . . . . . . . . 14
91 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 15
92 4.1. Change Poll Extension Schema . . . . . . . . . . . . . . 15
93 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
94 5.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 18
95 5.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 18
96 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
97 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
98 7.1. Normative References . . . . . . . . . . . . . . . . . . 19
99 7.2. Informative References . . . . . . . . . . . . . . . . . 20
100 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20
101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
102
103
104
105
106
107 Gould & Feher Standards Track [Page 2]
108 RFC 8590 changePoll May 2019
109
110
111 1. Introduction
112
113 This document describes an extension mapping for version 1.0 of the
114 Extensible Provisioning Protocol (EPP) [RFC5730]. This mapping, an
115 extension to EPP object mappings like the EPP domain name mapping
116 [RFC5731], is used to notify clients of operations they are not
117 directly involved in, on objects that the client sponsors. It is up
118 to server policy to determine what transform operations and clients
119 to notify. Using this extension, clients can more easily keep their
120 systems in sync with the objects stored in the server. When a change
121 occurs that a client needs to be notified of, a poll message can be
122 inserted by the server for consumption by the client using the EPP
123 <poll> command and response defined in [RFC5730]. The extension
124 supports including a "before" operation poll message and an "after"
125 operation poll message. The extension only extends the EPP <poll>
126 response in [RFC5730] and does not extend the EPP <poll> command.
127 Please refer to [RFC5730] for information and examples of the EPP
128 <poll> command.
129
130 1.1. Conventions Used in This Document
131
132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
134 "OPTIONAL" in this document are to be interpreted as described in
135 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
136 capitals, as shown here.
137
138 XML is case sensitive. Unless stated otherwise, XML specifications
139 and examples provided in this document MUST be interpreted in the
140 character case presented in order to develop a conforming
141 implementation.
142
143 In examples, "C:" represents lines sent by a protocol client, and
144 "S:" represents lines returned by a protocol server. Indentation and
145 white space in examples are provided only to illustrate element
146 relationships and are not a REQUIRED feature of this protocol.
147
148 The XML namespace prefix "changePoll" is used for the namespace
149 "urn:ietf:params:xml:ns:changePoll-1.0", but implementations MUST NOT
150 depend on it; instead, they should employ a proper namespace-aware
151 XML parser and serializer to interpret and output the XML documents.
152
153
154
155
156
157
158
159
160
161
162 Gould & Feher Standards Track [Page 3]
163 RFC 8590 changePoll May 2019
164
165
166 2. Object Attributes
167
168 This extension adds additional elements to EPP object mappings like
169 the EPP domain name mapping [RFC5731]. Only those new elements are
170 described here.
171
172 2.1. Operation
173
174 An operation consists of any transform operation that impacts objects
175 that the client sponsors and should be notified of. The
176 <changePoll:operation> element defines the operation. The OPTIONAL
177 "op" attribute is an identifier, represented in the 7-bit US-ASCII
178 character set defined in [RFC20], that is used to define a sub-
179 operation or the name of a "custom" operation. The enumerated list
180 of <changePoll:operation> values is:
181
182 "create": Create operation as defined in [RFC5730].
183
184 "delete": Delete operation as defined in [RFC5730]. If the delete
185 operation results in an immediate purge of the object, then the
186 "op" attribute MUST be set to "purge".
187
188 "renew": Renew operation as defined in [RFC5730].
189
190 "transfer": Transfer operation as defined in [RFC5730] that MUST set
191 the "op" attribute with one of the possible transfer-type values;
192 these include "request", "approve", "cancel", or "reject".
193
194 "update": Update operation as defined in [RFC5730].
195
196 "restore": Restore operation as defined in [RFC3915] that MUST set
197 the "op" attribute with one of the possible restore-type values;
198 these include "request" or "report".
199
200 "autoRenew": Auto renew operation executed by the server.
201
202 "autoDelete": Auto delete operation executed by the server. If the
203 "autoDelete" operation results in an immediate purge of the
204 object, then the "op" attribute MUST be set to "purge".
205
206 "autoPurge": Auto purge operation executed by the server when
207 removing the object after it has had the status "pendingDelete".
208
209 "custom": Custom operation that MUST set the "op" attribute with the
210 custom operation name. The custom operations supported are up to
211 server policy.
212
213
214
215
216
217 Gould & Feher Standards Track [Page 4]
218 RFC 8590 changePoll May 2019
219
220
221 2.2. State
222
223 The state attribute reflects the state of the object "before" or
224 "after" the operation. The state is defined using the OPTIONAL
225 "state" attribute of the <changePoll:changeData> element, with the
226 possible values "before" or "after" and a default value of "after".
227 The server MAY support both the "before" state and the "after" state
228 of the operation by using one poll message for the "before" state and
229 one poll message for the "after" state. The "before" state poll
230 message MUST be inserted into the message queue prior to the "after"
231 state poll message.
232
233 For operations in Section 2.1 that don't have an "after" state, the
234 server MUST use the "before" state poll message. For example, for
235 the "delete" operation with the "op" attribute set to "purge", or the
236 "autoPurge" operation, the server includes the state of the object
237 prior to being purged in the "before" state poll message.
238
239 For operations in Section 2.1 that don't have a "before" state, the
240 server MUST use the "after" state poll message. For example, for the
241 "create" operation, the server includes the state of the object after
242 creation in the "after" state poll message.
243
244 2.3. Who
245
246 The <changePoll:who> element defines who executed the operation, for
247 audit purposes. It is a free-form value that is meant strictly for
248 audit purposes and not to drive client-side logic. The scheme used
249 for the possible set of <changePoll:who> element values is up to
250 server policy. The server MAY identify the <changePoll:who> element
251 value based on:
252
253 "Identifier": Unique user identifier of the user that executed the
254 operation. An example is "ClientX".
255
256 "Name": Name of the user that executed the operation. An example is
257 "John Doe".
258
259 "Role": Role of the user that executed operation. An example is
260 "CSR" for a Customer Support Representative or "Batch" for a
261 server batch.
262
263 2.4. Dates and Times
264
265 Date and time attribute values MUST be represented in Universal
266 Coordinated Time (UTC) using the Gregorian calendar. The extended
267 date-time form using uppercase "T" and "Z" characters defined in
268
269
270
271
272 Gould & Feher Standards Track [Page 5]
273 RFC 8590 changePoll May 2019
274
275
276 [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time
277 values, as XML Schema does not support truncated date-time forms or
278 lowercase "T" and "Z" characters.
279
280 3. EPP Command Mapping
281
282 A detailed description of the EPP syntax and semantics can be found
283 in the EPP core protocol specification [RFC5730].
284
285 3.1. EPP Query Commands
286
287 EPP provides three commands to retrieve object information: <check>
288 to determine if an object is known to the server, <info> to retrieve
289 detailed information associated with an object, and <transfer> to
290 retrieve object-transfer status information.
291
292 3.1.1. EPP <check> Command
293
294 This extension does not add any elements to the EPP <check> command
295 or <check> response described in [RFC5730].
296
297 3.1.2. EPP <info> Command
298
299 This extension does not add any elements to the EPP <info> command
300 described in [RFC5730].
301
302 This extension adds operational detail of EPP object-mapping
303 operations (Section 2.1) to an EPP poll response, as described in
304 [RFC5730]. It is an extension of the EPP object-mapping info
305 response. Any transform operation to an object defined in an EPP
306 object mapping by a client other than the sponsoring client MAY
307 result in extending the <info> response of the object for inserting
308 an EPP poll message with the operation detail. The sponsoring client
309 will then receive the state of the object with operation detail like
310 what, who, when, and why the object was changed. The
311 <changePoll:changeData> element contains the operation detail along
312 with an indication of whether the object reflects the state before or
313 after the operation as defined in Section 2.2. The
314 <changePoll:changeData> element includes the operation detail with
315 the following child elements:
316
317 <changePoll:operation>: Transform operation executed on the object,
318 as defined in Section 2.1.
319
320 <changePoll:date>: Date and time when the operation was executed.
321
322 <changePoll:svTRID>: Server transaction identifier of the operation.
323
324
325
326
327 Gould & Feher Standards Track [Page 6]
328 RFC 8590 changePoll May 2019
329
330
331 <changePoll:who>: Who executed the operation, as defined in
332 Section 2.3.
333
334 <changePoll:caseId>: OPTIONAL case identifier associated with the
335 operation. The required "type" attribute defines the type of
336 case. The OPTIONAL "name" attribute is an identifier,
337 represented in the 7-bit US-ASCII character set defined in
338 [RFC20], that is used to define the name of the "custom" case
339 type. The enumerated list of case types is:
340
341 udrp: A Uniform Domain-Name Dispute-Resolution Policy (UDRP)
342 case.
343
344 urs: A Uniform Rapid Suspension (URS) case.
345
346 custom: A custom case that is defined using the "name"
347 attribute.
348
349 <changePoll:reason>: OPTIONAL reason for executing the operation.
350 If present, this element contains the server-specific text to
351 help explain the reason the operation was executed. This text
352 MUST be represented in the response language previously
353 negotiated with the client; an OPTIONAL "lang" attribute MAY be
354 present to identify the language if the negotiated value is
355 something other than the default value of "en" (English).
356
357 The following is an example poll <info> response with the
358 <changePoll:changeData> extension for a URS lock transaction on the
359 domain.example domain name, with the "before" state. The "before"
360 state is reflected in the <resData> block:
361
362 S:<?xml version="1.0" encoding="UTF-8"?>
363 S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
364 S: <response>
365 S: <result code="1301">
366 S: <msg lang="en-US">
367 S: Command completed successfully; ack to dequeue</msg>
368 S: </result>
369 S: <msgQ id="201" count="1">
370 S: <qDate>2013-10-22T14:25:57.0Z</qDate>
371 S: <msg>Registry initiated update of domain.</msg>
372 S: </msgQ>
373 S: <resData>
374 S: <domain:infData
375 S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
376 S: <domain:name>domain.example</domain:name>
377 S: <domain:roid>EXAMPLE1-REP</domain:roid>
378 S: <domain:status s="ok"/>
379
380
381
382 Gould & Feher Standards Track [Page 7]
383 RFC 8590 changePoll May 2019
384
385
386 S: <domain:registrant>jd1234</domain:registrant>
387 S: <domain:contact type="admin">sh8013</domain:contact>
388 S: <domain:contact type="tech">sh8013</domain:contact>
389 S: <domain:clID>ClientX</domain:clID>
390 S: <domain:crID>ClientY</domain:crID>
391 S: <domain:crDate>2012-04-03T22:00:00.0Z</domain:crDate>
392 S: <domain:exDate>2014-04-03T22:00:00.0Z</domain:exDate>
393 S: </domain:infData>
394 S: </resData>
395 S: <extension>
396 S: <changePoll:changeData
397 S: xmlns:changePoll="urn:ietf:params:xml:ns:changePoll-1.0"
398 S: state="before">
399 S: <changePoll:operation>update</changePoll:operation>
400 S: <changePoll:date>2013-10-22T14:25:57.0Z</changePoll:date>
401 S: <changePoll:svTRID>12345-XYZ</changePoll:svTRID>
402 S: <changePoll:who>URS Admin</changePoll:who>
403 S: <changePoll:caseId type="urs">urs123</changePoll:caseId>
404 S: <changePoll:reason>URS Lock</changePoll:reason>
405 S: </changePoll:changeData>
406 S: </extension>
407 S: <trID>
408 S: <clTRID>ABC-12345</clTRID>
409 S: <svTRID>54321-XYZ</svTRID>
410 S: </trID>
411 S: </response>
412 S:</epp>
413
414 The following is an example poll <info> response with the
415 <changePoll:changeData> extension for a URS lock transaction on the
416 domain.example domain name, with the "after" state. The "after"
417 state is reflected in the <resData> block:
418
419 S:<?xml version="1.0" encoding="UTF-8"?>
420 S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
421 S: <response>
422 S: <result code="1301">
423 S: <msg lang="en-US">
424 S: Command completed successfully; ack to dequeue</msg>
425 S: </result>
426 S: <msgQ id="202" count="1">
427 S: <qDate>2013-10-22T14:25:57.0Z</qDate>
428 S: <msg>Registry initiated update of domain.</msg>
429 S: </msgQ>
430 S: <resData>
431 S: <domain:infData
432 S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
433 S: <domain:name>domain.example</domain:name>
434
435
436
437 Gould & Feher Standards Track [Page 8]
438 RFC 8590 changePoll May 2019
439
440
441 S: <domain:roid>EXAMPLE1-REP</domain:roid>
442 S: <domain:status s="serverUpdateProhibited"/>
443 S: <domain:status s="serverDeleteProhibited"/>
444 S: <domain:status s="serverTransferProhibited"/>
445 S: <domain:registrant>jd1234</domain:registrant>
446 S: <domain:contact type="admin">sh8013</domain:contact>
447 S: <domain:contact type="tech">sh8013</domain:contact>
448 S: <domain:clID>ClientX</domain:clID>
449 S: <domain:crID>ClientY</domain:crID>
450 S: <domain:crDate>2012-04-03T22:00:00.0Z</domain:crDate>
451 S: <domain:upID>ClientZ</domain:upID>
452 S: <domain:upDate>2013-10-22T14:25:57.0Z</domain:upDate>
453 S: <domain:exDate>2014-04-03T22:00:00.0Z</domain:exDate>
454 S: </domain:infData>
455 S: </resData>
456 S: <extension>
457 S: <changePoll:changeData
458 S: xmlns:changePoll="urn:ietf:params:xml:ns:changePoll-1.0"
459 S: state="after">
460 S: <changePoll:operation>update</changePoll:operation>
461 S: <changePoll:date>2013-10-22T14:25:57.0Z</changePoll:date>
462 S: <changePoll:svTRID>12345-XYZ</changePoll:svTRID>
463 S: <changePoll:who>URS Admin</changePoll:who>
464 S: <changePoll:caseId type="urs">urs123</changePoll:caseId>
465 S: <changePoll:reason>URS Lock</changePoll:reason>
466 S: </changePoll:changeData>
467 S: </extension>
468 S: <trID>
469 S: <clTRID>ABC-12345</clTRID>
470 S: <svTRID>54321-XYZ</svTRID>
471 S: </trID>
472 S: </response>
473 S:</epp>
474
475 The following is an example poll <info> response with the
476 <changePoll:changeData> extension for a custom "sync" operation on
477 the domain.example domain name, with the default "after" state. The
478 "after" state is reflected in the <resData> block:
479
480 S:<?xml version="1.0" encoding="UTF-8"?>
481 S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
482 S: <response>
483 S: <result code="1301">
484 S: <msg>Command completed successfully; ack to dequeue</msg>
485 S: </result>
486 S: <msgQ id="201" count="1">
487 S: <qDate>2013-10-22T14:25:57.0Z</qDate>
488 S: <msg>Registry initiated Sync of Domain Expiration Date</msg>
489
490
491
492 Gould & Feher Standards Track [Page 9]
493 RFC 8590 changePoll May 2019
494
495
496 S: </msgQ>
497 S: <resData>
498 S: <domain:infData
499 S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
500 S: <domain:name>domain.example</domain:name>
501 S: <domain:roid>EXAMPLE1-REP</domain:roid>
502 S: <domain:status s="ok"/>
503 S: <domain:registrant>jd1234</domain:registrant>
504 S: <domain:contact type="admin">sh8013</domain:contact>
505 S: <domain:contact type="tech">sh8013</domain:contact>
506 S: <domain:clID>ClientX</domain:clID>
507 S: <domain:crID>ClientY</domain:crID>
508 S: <domain:crDate>2012-04-03T22:00:00.0Z</domain:crDate>
509 S: <domain:upID>ClientZ</domain:upID>
510 S: <domain:upDate>2013-10-22T14:25:57.0Z</domain:upDate>
511 S: <domain:exDate>2014-04-03T22:00:00.0Z</domain:exDate>
512 S: </domain:infData>
513 S: </resData>
514 S: <extension>
515 S: <changePoll:changeData
516 S: xmlns:changePoll="urn:ietf:params:xml:ns:changePoll-1.0">
517 S: <changePoll:operation op="sync">custom
518 S: </changePoll:operation>
519 S: <changePoll:date>2013-10-22T14:25:57.0Z</changePoll:date>
520 S: <changePoll:svTRID>12345-XYZ</changePoll:svTRID>
521 S: <changePoll:who>CSR</changePoll:who>
522 S: <changePoll:reason lang="en">Customer sync request
523 S: </changePoll:reason>
524 S: </changePoll:changeData>
525 S: </extension>
526 S: <trID>
527 S: <clTRID>ABC-12345</clTRID>
528 S: <svTRID>54321-XYZ</svTRID>
529 S: </trID>
530 S: </response>
531 S:</epp>
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547 Gould & Feher Standards Track [Page 10]
548 RFC 8590 changePoll May 2019
549
550
551 The following is an example poll <info> response with the
552 <changePoll:changeData> extension for a "delete" operation on the
553 domain.example domain name that is immediately purged, with the
554 "before" state. The "before" state is reflected in the <resData>
555 block:
556
557 S:<?xml version="1.0" encoding="UTF-8"?>
558 S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
559 S: <response>
560 S: <result code="1301">
561 S: <msg>Command completed successfully; ack to dequeue</msg>
562 S: </result>
563 S: <msgQ id="200" count="1">
564 S: <qDate>2013-10-22T14:25:57.0Z</qDate>
565 S: <msg>Registry initiated delete of
566 S: domain resulting in immediate purge.</msg>
567 S: </msgQ>
568 S: <resData>
569 S: <domain:infData
570 S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
571 S: <domain:name>domain.example</domain:name>
572 S: <domain:roid>EXAMPLE1-REP</domain:roid>
573 S: <domain:clID>ClientX</domain:clID>
574 S: </domain:infData>
575 S: </resData>
576 S: <extension>
577 S: <changePoll:changeData
578 S: xmlns:changePoll="urn:ietf:params:xml:ns:changePoll-1.0"
579 S: state="before">
580 S: <changePoll:operation op="purge">delete
581 S: </changePoll:operation>
582 S: <changePoll:date>2013-10-22T14:25:57.0Z
583 S: </changePoll:date>
584 S: <changePoll:svTRID>12345-XYZ
585 S: </changePoll:svTRID>
586 S: <changePoll:who>ClientZ
587 S: </changePoll:who>
588 S: <changePoll:reason>Court order
589 S: </changePoll:reason>
590 S: </changePoll:changeData>
591 S: </extension>
592 S: <trID>
593 S: <clTRID>ABC-12345</clTRID>
594 S: <svTRID>54321-XYZ</svTRID>
595 S: </trID>
596 S: </response>
597 S:</epp>
598
599
600
601
602 Gould & Feher Standards Track [Page 11]
603 RFC 8590 changePoll May 2019
604
605
606 The following is an example poll <info> response with the
607 <changePoll:changeData> extension for an "autoPurge" operation on the
608 domain.example domain name that previously had the "pendingDelete"
609 status, with the "before" state. The "before" state is reflected in
610 the <resData> block:
611
612 S:<?xml version="1.0" encoding="UTF-8"?>
613 S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
614 S: <response>
615 S: <result code="1301">
616 S: <msg>Command completed successfully; ack to dequeue
617 S: </msg>
618 S: </result>
619 S: <msgQ id="200" count="1">
620 S: <qDate>2013-10-22T14:25:57.0Z</qDate>
621 S: <msg>Registry purged domain with pendingDelete status.
622 S: </msg>
623 S: </msgQ>
624 S: <resData>
625 S: <domain:infData
626 S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
627 S: <domain:name>domain.example</domain:name>
628 S: <domain:roid>EXAMPLE1-REP</domain:roid>
629 S: <domain:status s="pendingDelete"/>
630 S: <domain:clID>ClientX</domain:clID>
631 S: </domain:infData>
632 S: </resData>
633 S: <extension>
634 S: <changePoll:changeData
635 S: xmlns:changePoll="urn:ietf:params:xml:ns:changePoll-1.0"
636 S: state="before">
637 S: <changePoll:operation>autoPurge
638 S: </changePoll:operation>
639 S: <changePoll:date>2013-10-22T14:25:57.0Z
640 S: </changePoll:date>
641 S: <changePoll:svTRID>12345-XYZ
642 S: </changePoll:svTRID>
643 S: <changePoll:who>Batch
644 S: </changePoll:who>
645 S: <changePoll:reason>Past pendingDelete 5 day period
646 S: </changePoll:reason>
647 S: </changePoll:changeData>
648 S: </extension>
649 S: <trID>
650 S: <clTRID>ABC-12345</clTRID>
651 S: <svTRID>54321-XYZ</svTRID>
652 S: </trID>
653
654
655
656
657 Gould & Feher Standards Track [Page 12]
658 RFC 8590 changePoll May 2019
659
660
661 S: </response>
662 S:</epp>
663
664 The following is an example poll <info> response with the
665 <changePoll:changeData> extension for an "update" operation on the
666 ns1.domain.example host, with the default "after" state. The "after"
667 state is reflected in the <resData> block:
668
669 S:<?xml version="1.0" encoding="UTF-8"?>
670 S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
671 S: <response>
672 S: <result code="1301">
673 S: <msg>Command completed successfully; ack to dequeue</msg>
674 S: </result>
675 S: <msgQ id="201" count="1">
676 S: <qDate>2013-10-22T14:25:57.0Z</qDate>
677 S: <msg>Registry initiated update of host.</msg>
678 S: </msgQ>
679 S: <resData>
680 S: <host:infData
681 S: xmlns:host="urn:ietf:params:xml:ns:host-1.0">
682 S: <host:name>ns1.domain.example</host:name>
683 S: <host:roid>NS1_EXAMPLE1-REP</host:roid>
684 S: <host:status s="linked"/>
685 S: <host:status s="serverUpdateProhibited"/>
686 S: <host:status s="serverDeleteProhibited"/>
687 S: <host:addr ip="v4">192.0.2.2</host:addr>
688 S: <host:addr ip="v6">2001:db8:0:0:1:0:0:1</host:addr>
689 S: <host:clID>ClientX</host:clID>
690 S: <host:crID>ClientY</host:crID>
691 S: <host:crDate>2012-04-03T22:00:00.0Z</host:crDate>
692 S: <host:upID>ClientY</host:upID>
693 S: <host:upDate>2013-10-22T14:25:57.0Z</host:upDate>
694 S: </host:infData>
695 S: </resData>
696 S: <extension>
697 S: <changePoll:changeData
698 S: xmlns:changePoll="urn:ietf:params:xml:ns:changePoll-1.0">
699 S: <changePoll:operation>update</changePoll:operation>
700 S: <changePoll:date>2013-10-22T14:25:57.0Z</changePoll:date>
701 S: <changePoll:svTRID>12345-XYZ</changePoll:svTRID>
702 S: <changePoll:who>ClientZ</changePoll:who>
703 S: <changePoll:reason>Host Lock</changePoll:reason>
704 S: </changePoll:changeData>
705 S: </extension>
706 S: <trID>
707 S: <clTRID>ABC-12345</clTRID>
708 S: <svTRID>54321-XYZ</svTRID>
709
710
711
712 Gould & Feher Standards Track [Page 13]
713 RFC 8590 changePoll May 2019
714
715
716 S: </trID>
717 S: </response>
718 S:</epp>
719
720 3.1.3. EPP <transfer> Command
721
722 This extension does not add any elements to the EPP <transfer> query
723 command or <transfer> response described in the [RFC5730].
724
725 3.2. EPP Transform Commands
726
727 EPP provides five commands to transform objects: <create> to create
728 an instance of an object, <delete> to delete an instance of an
729 object, <renew> to extend the validity period of an object,
730 <transfer> to manage object-sponsorship changes, and <update> to
731 change information associated with an object.
732
733 3.2.1. EPP <create> Command
734
735 This extension does not add any elements to the EPP <create> command
736 or <create> response described in [RFC5730].
737
738 3.2.2. EPP <delete> Command
739
740 This extension does not add any elements to the EPP <delete> command
741 or <delete> response described in [RFC5730].
742
743 3.2.3. EPP <renew> Command
744
745 This extension does not add any elements to the EPP <renew> command
746 or <renew> response described in [RFC5730].
747
748 3.2.4. EPP <transfer> Command
749
750 This extension does not add any elements to the EPP <transfer>
751 command or <transfer> response described in [RFC5730].
752
753 3.2.5. EPP <update> Command
754
755 This extension does not add any elements to the EPP <update> command
756 or <update> response described in [RFC5730].
757
758
759
760
761
762
763
764
765
766
767 Gould & Feher Standards Track [Page 14]
768 RFC 8590 changePoll May 2019
769
770
771 4. Formal Syntax
772
773 One schema is presented here: the EPP Change Poll Extension schema.
774
775 The formal syntax presented here is a complete schema representation
776 of the object mapping suitable for automated validation of EPP XML
777 instances. The BEGIN and END tags are not part of the schema; they
778 are used to note the beginning and ending of the schema for URI
779 registration purposes.
780
781 4.1. Change Poll Extension Schema
782
783 BEGIN
784 <?xml version="1.0" encoding="UTF-8"?>
785 <schema targetNamespace="urn:ietf:params:xml:ns:changePoll-1.0"
786 xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
787 xmlns:epp="urn:ietf:params:xml:ns:epp-1.0"
788 xmlns:changePoll="urn:ietf:params:xml:ns:changePoll-1.0"
789 xmlns="http://www.w3.org/2001/XMLSchema"
790 elementFormDefault="qualified">
791
792 <!--
793 Import common element types.
794 -->
795 <import namespace="urn:ietf:params:xml:ns:eppcom-1.0"/>
796 <import namespace="urn:ietf:params:xml:ns:epp-1.0"/>
797
798
799 <annotation>
800 <documentation>
801 Extensible Provisioning Protocol v1.0
802 Change Poll Mapping Schema.
803 </documentation>
804 </annotation>
805
806 <!--
807 Change element.
808 -->
809 <element name="changeData" type="changePoll:changeDataType"/>
810
811 <!--
812 Attributes associated with the change.
813 -->
814 <complexType name="changeDataType">
815 <sequence>
816 <element name="operation" type="changePoll:operationType"/>
817 <element name="date" type="dateTime"/>
818 <element name="svTRID" type="epp:trIDStringType"/>
819
820
821
822 Gould & Feher Standards Track [Page 15]
823 RFC 8590 changePoll May 2019
824
825
826 <element name="who" type="changePoll:whoType"/>
827 <element name="caseId" type="changePoll:caseIdType"
828 minOccurs="0"/>
829 <element name="reason" type="eppcom:reasonType"
830 minOccurs="0"/>
831 </sequence>
832 <attribute name="state" type="changePoll:stateType"
833 default="after"/>
834 </complexType>
835
836 <!--
837 Enumerated list of operations, with extensibility via "custom".
838 -->
839 <simpleType name="operationEnum">
840 <restriction base="token">
841 <enumeration value="create"/>
842 <enumeration value="delete"/>
843 <enumeration value="renew"/>
844 <enumeration value="transfer"/>
845 <enumeration value="update"/>
846 <enumeration value="restore"/>
847 <enumeration value="autoRenew"/>
848 <enumeration value="autoDelete"/>
849 <enumeration value="autoPurge"/>
850 <enumeration value="custom"/>
851 </restriction>
852 </simpleType>
853
854 <!--
855 Enumerated state of the object in the poll message.
856 -->
857 <simpleType name="stateType">
858 <restriction base="token">
859 <enumeration value="before"/>
860 <enumeration value="after"/>
861 </restriction>
862 </simpleType>
863
864 <!--
865 Transform operation type
866 -->
867 <complexType name="operationType">
868 <simpleContent>
869 <extension base="changePoll:operationEnum">
870 <attribute name="op" type="token"/>
871 </extension>
872 </simpleContent>
873 </complexType>
874
875
876
877 Gould & Feher Standards Track [Page 16]
878 RFC 8590 changePoll May 2019
879
880
881 <!--
882 Case identifier type
883 -->
884 <complexType name="caseIdType">
885 <simpleContent>
886 <extension base="token">
887 <attribute name="type" type="changePoll:caseTypeEnum"
888 use="required"/>
889 <attribute name="name" type="token"
890 use="optional"/>
891 </extension>
892 </simpleContent>
893 </complexType>
894
895 <!--
896 Enumerated list of case identifier types
897 -->
898 <simpleType name="caseTypeEnum">
899 <restriction base="token">
900 <enumeration value="udrp"/>
901 <enumeration value="urs"/>
902 <enumeration value="custom"/>
903 </restriction>
904 </simpleType>
905
906 <!--
907 Who type
908 -->
909 <simpleType name="whoType">
910 <restriction base="normalizedString">
911 <minLength value="1"/>
912 <maxLength value="255"/>
913 </restriction>
914 </simpleType>
915
916 <!--
917 End of schema.
918 -->
919 </schema>
920 END
921
922
923
924
925
926
927
928
929
930
931
932 Gould & Feher Standards Track [Page 17]
933 RFC 8590 changePoll May 2019
934
935
936 5. IANA Considerations
937
938 5.1. XML Namespace
939
940 This document uses URNs to describe XML namespaces and XML schemas
941 conforming to a registry mechanism described in [RFC3688]. The
942 following URI assignment has been made by IANA:
943
944 Registration for the changePoll namespace:
945
946 URI: urn:ietf:params:xml:ns:changePoll-1.0
947
948 Registrant Contact: IESG
949
950 XML: None. Namespace URIs do not represent an XML specification.
951
952 Registration for the changePoll XML schema:
953
954 URI: urn:ietf:params:xml:ns:changePoll-1.0
955
956 Registrant Contact: IESG
957
958 XML: See the "Formal Syntax" section of this document.
959
960 5.2. EPP Extension Registry
961
962 The EPP extension described in this document has been registered by
963 the IANA in the Extensions for the "Extensible Provisioning Protocol
964 (EPP)" registry described in [RFC7451]. The details of the
965 registration are as follows:
966
967 Name of Extension: Change Poll Extension for the Extensible
968 Provisioning Protocol (EPP)
969
970 Document Status: Standards Track
971
972 Reference: RFC 8590
973
974 Registrant Name and Email Address: IESG <iesg@ietf.org>
975
976 TLDs: Any
977
978 IPR Disclosure: None
979
980 Status: Active
981
982 Notes: None
983
984
985
986
987 Gould & Feher Standards Track [Page 18]
988 RFC 8590 changePoll May 2019
989
990
991 6. Security Considerations
992
993 The mapping extensions described in this document do not provide any
994 security services beyond those described by EPP [RFC5730] and
995 protocol layers used by EPP. The security considerations described
996 in these other specifications apply to this specification as well.
997
998 7. References
999
1000 7.1. Normative References
1001
1002 [RFC20] Cerf, V., "ASCII format for network interchange", STD 80,
1003 RFC 20, DOI 10.17487/RFC0020, October 1969,
1004 <https://www.rfc-editor.org/info/rfc20>.
1005
1006 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1007 Requirement Levels", BCP 14, RFC 2119,
1008 DOI 10.17487/RFC2119, March 1997,
1009 <https://www.rfc-editor.org/info/rfc2119>.
1010
1011 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
1012 DOI 10.17487/RFC3688, January 2004,
1013 <https://www.rfc-editor.org/info/rfc3688>.
1014
1015 [RFC3915] Hollenbeck, S., "Domain Registry Grace Period Mapping for
1016 the Extensible Provisioning Protocol (EPP)", RFC 3915,
1017 DOI 10.17487/RFC3915, September 2004,
1018 <https://www.rfc-editor.org/info/rfc3915>.
1019
1020 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
1021 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
1022 <https://www.rfc-editor.org/info/rfc5730>.
1023
1024 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
1025 Domain Name Mapping", STD 69, RFC 5731,
1026 DOI 10.17487/RFC5731, August 2009,
1027 <https://www.rfc-editor.org/info/rfc5731>.
1028
1029 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1030 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1031 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
1032
1033 [W3C.REC-xmlschema-2-20041028]
1034 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
1035 Second Edition", World Wide Web Consortium Recommendation
1036 REC-xmlschema-2-20041028, October 2004,
1037 <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
1038
1039
1040
1041
1042 Gould & Feher Standards Track [Page 19]
1043 RFC 8590 changePoll May 2019
1044
1045
1046 7.2. Informative References
1047
1048 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible
1049 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451,
1050 February 2015, <https://www.rfc-editor.org/info/rfc7451>.
1051
1052 Acknowledgments
1053
1054 The authors wish to acknowledge the original concept for this
1055 document and the efforts in the initial versions of this document by
1056 Trung Tran and Sharon Wodjenski.
1057
1058 Special suggestions that have been incorporated into this document
1059 were provided by Scott Hollenbeck, Michael Holloway, and Patrick
1060 Mevzek.
1061
1062 Authors' Addresses
1063
1064 James Gould
1065 VeriSign, Inc.
1066 12061 Bluemont Way
1067 Reston, VA 20190
1068 United States of America
1069
1070 Email: jgould@verisign.com
1071 URI: http://www.verisign.com
1072
1073
1074 Kal Feher
1075 Neustar
1076 lvl 8/10 Queens Road
1077 Melbourne, VIC 3004
1078 Australia
1079
1080 Email: ietf@feherfamily.org
1081 URI: http://www.neustar.biz
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097 Gould & Feher Standards Track [Page 20]
1098
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.