idnits 2.17.1 draft-ietf-regext-validate-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 2, 2018) is 2276 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC6982' is mentioned on line 510, but not defined ** Obsolete undefined reference: RFC 6982 (Obsoleted by RFC 7942) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Registration Protocols Extensions R. Carney 3 Internet-Draft J. Snitker 4 Intended status: Standards Track GoDaddy Inc. 5 Expires: August 6, 2018 February 2, 2018 7 Validate Mapping for the Extensible Provisioning Protocol (EPP) 8 draft-ietf-regext-validate-03 10 Abstract 12 This document describes an Extensible Provisioning Protocol (EPP) 13 mapping for the validation of contact and eligibility data. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on August 6, 2018. 32 Copyright Notice 34 Copyright (c) 2018 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 51 2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 3 52 2.1. Key Value . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 3 54 3.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 3 55 3.1.1. EPP Command . . . . . . . . . . . . . . . . . 4 56 3.1.2. EPP Command . . . . . . . . . . . . . . . . . 7 57 3.1.3. EPP Command . . . . . . . . . . . . . . . 7 58 3.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 8 59 3.2.1. EPP Command . . . . . . . . . . . . . . . . 8 60 3.2.2. EPP Command . . . . . . . . . . . . . . . . 8 61 3.2.3. EPP Command . . . . . . . . . . . . . . . . . 8 62 3.2.4. EPP Command . . . . . . . . . . . . . . . 8 63 3.2.5. EPP Command . . . . . . . . . . . . . . . . 8 64 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 8 65 4.1. Validate Schema . . . . . . . . . . . . . . . . . . . . . 8 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 6.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 11 69 7. Implemntation Status . . . . . . . . . . . . . . . . . . . . 12 70 7.1. To Be Filled In . . . . . . . . . . . . . . . . . . . . . 12 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 72 9. Change History . . . . . . . . . . . . . . . . . . . . . . . 12 73 9.1. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 12 74 9.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 13 75 9.3. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 13 76 9.4. Change from carney-regext 01 to ietf-regext 00 . . . . . 13 77 10. Normative References . . . . . . . . . . . . . . . . . . . . 13 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 80 1. Introduction 82 This document describes a Validate mapping for version 1.0 of the 83 Extensible Provisioning Protocol (EPP) [RFC5730]. This EPP mapping 84 specifies a flexible schema by which EPP clients and servers can 85 reliably validate contact and eligibility data. 87 With the increased number of restrictions on contacts and required 88 data points (license, ids, etc.) to register a domain name, a way to 89 validate the data points prior to issuing a transform command is 90 becoming more important. 92 1.1. Conventions Used in This Document 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in RFC 2119 [RFC2119]. 98 XML is case sensitive. Unless stated otherwise, XML specifications 99 and examples provided in this document MUST be interpreted in the 100 character case presented in order to develop a conforming 101 implementation. 103 In examples, "C:" represents lines sent by a protocol client and "S:" 104 represents lines returned by a protocol server. Indentation and 105 white space in examples are provided only to illustrate element 106 relationships and are not a REQUIRED feature of this protocol. 108 2. Object Attributes 110 A EPP validation object has attributes and associated values that can 111 be viewed by the client. This section describes each attribute type 112 in detail. 114 2.1. Key Value 116 Key Value provides a flexible mechanism to share data between the 117 client and the server. The element defines the data, 118 with two required simple attributes, key and value, and an optional 119 contactType attribute for specificity in the response, more details 120 below. 122 o An example . 123 o An example . 126 3. EPP Command Mapping 128 A detailed description of the EPP syntax and semantics can be found 129 in [RFC5730]. The command mappings described here are specifically 130 for the Validate Extension. 132 3.1. EPP Query Commands 134 EPP provides three commands to retrieve object information: 135 to determine if an object is known to the server, to retrieve 136 detailed information associated with an object, and to 137 retrieve object transfer status information. 139 3.1.1. EPP Command 141 The EPP command is used to validate a list of contact 142 information. The command MUST contain a 143 element that identifies the validate namespace. The 144 element contains the following child elements: 146 o one or more element(s) for each contact that is 147 to be validated that contains the contact type of the contact to 148 be validated. 150 The element MUST contain the following child 151 elements: 153 o one element. 154 o zero or more elements. 156 The element MUST contain the following child elements: 158 o one element. 159 o an OPTIONAL element. 160 o an OPTIONAL element. 161 o an OPTIONAL element. 162 o an OPTIONAL element. 163 o an OPTIONAL element. 164 o an OPTIONAL element. 166 The following is an example command. 168 C: 169 C: 172 C: 173 C: 174 C: 175 C: 176 C: 177 C: sh8013 178 C: 179 C: John Doe 180 C: Example Inc. 181 C: 182 C: 123 Example Dr. 183 C: Suite 100 184 C: Dulles 185 C: VA 186 C: 20166-6503 187 C: US 188 C: 189 C: 190 C: +1.7035555555 191 C: +1.7035555556 192 C: jdoe@example.com 193 C: 194 C: 2fooBAR 195 C: 196 C: 197 C: 198 C: 199 C: 200 C: 201 C: 202 C: 203 C: 204 C: 205 C: sh8013 206 C: 207 C: 208 C: 209 C: 210 C: sh8014 211 C: 212 C: John Doe 213 C: Example Inc. 214 C: 215 C: 123 Example Dr. 216 C: Suite 100 217 C: Dulles 218 C: VA 219 C: 20166-6503 220 C: US 221 C: 222 C: 223 C: +1.7035555555 224 C: +1.7035555556 225 C: jdoe@example.com 226 C: 227 C: 2fooBAR 228 C: 229 C: 230 C: 231 C: 232 C: 233 C: 234 C: 235 C: 236 C: 237 C: sh8014 238 C: 239 C: 240 C: 241 C: 242 C: ABC-12345 243 C: 244 C: 246 When a command has been processed succesfully, the EPP 247 element MUST contain a child element 248 that identifies the validate namespace. The 249 element MUST contain a element for each 250 element contained in the command. The 251 element MUST contain the following child elements: 253 o one element. 254 o one element. 255 o zero or more elements. 257 The following is an example of the response. 259 S: 260 S: 261 S: 262 S: 263 S: Command completed successfully 264 S: 265 S: 266 S: 268 S: 269 S: sh8013 270 S: 1000 271 S: 272 S: 273 S: sh8014 274 S: 2306 275 S: 277 S: 279 S: 281 S: 282 S: 283 S: 284 S: 285 S: ABC-12345 286 S: 54321-ZYX 287 S: 288 S: 289 S: 291 3.1.2. EPP Command 293 Info semantics do not apply to validate objects, so there is no 294 mapping defined for the EPP command. 296 3.1.3. EPP Command 298 Transfer semantics do not apply to validate objects, so there is no 299 mapping defined for the EPP command. 301 3.2. EPP Transform Commands 303 EPP provides five commands to transform objects: to create 304 an instance of an object with a server, to remove an 305 instance of an object from a server, to extend the validity 306 period of an object, to manage changes in client 307 sponsorship of an object, and to change information. 309 3.2.1. EPP Command 311 Create semantics do not apply to validate objects, so there is no 312 mapping defined for the EPP command. 314 3.2.2. EPP Command 316 Delete semantics do not apply to validate objects, so there is no 317 mapping defined for the EPP command. 319 3.2.3. EPP Command 321 Renew semantics do not apply to validate objects, so there is no 322 mapping defined for the EPP command. 324 3.2.4. EPP Command 326 Transfer semantics do not apply to validate objects, so there is no 327 mapping defined for the EPP command. 329 3.2.5. EPP Command 331 Update semantics do not apply to validate objects, so there is no 332 mapping defined for the EPP command. 334 4. Formal Syntax 336 One schema is presented here that is the EPP Validate schema. 338 The formal syntax presented here is a complete schema representation 339 of the object mapping suitable for automated validation of EPP XML 340 instances. The BEGIN and END tags are not part of the schema; they 341 are used to note the beginning and ending of the schema for URI 342 registration purposes. 344 4.1. Validate Schema 346 BEGIN 347 348 357 358 359 Extensible Provisioning Protocol v1.0 360 Validate Object 361 362 364 365 367 369 372 375 377 378 379 382 383 385 386 387 389 392 393 395 398 400 401 402 404 407 409 411 413 416 419 420 422 423 425 427 429 431 432 433 434 435 437 438 439 440 441 443 446 448 449 450 452 453 455 456 457 459 461 464 465 467 468 END 470 5. Security Considerations 472 The mapping extensions described in this document do not provide any 473 security services beyond those described by EPP [RFC5730] and 474 protocol layers used by EPP. The security considerations described 475 in these other specifications apply to this specification as well. 477 6. IANA Considerations 479 6.1. XML Namespace 481 This document uses URNs to describe XML namespaces and XML schemas 482 conforming to a registry mechanism described in [RFC3688]. The 483 following URI assignment is requested of IANA: 485 URI: ietf:params:xml:ns:validate-1.0 487 Registrant Contact: See the "Author's Address" section of this 488 document. 490 XML: See the "Formal Syntax" section of this document. 492 7. Implemntation Status 494 Note to RFC Editor: Please remove this section and the reference to 495 [RFC6982] before publication. 497 This section records the status of known implementations of the 498 protocol defined by this specification at the time of posting of this 499 Internet-Draft, and is based on a proposal described in [RFC6982]. 500 The description of implementations in this section is intended to 501 assist the IETF in its decision processes in progressing drafts to 502 RFCs. Please note that the listing of any individual implementation 503 here does not imply endorsement by the IETF. Furthermore, no effort 504 has been spent to verify the information presented here that was 505 supplied by IETF contributors. This is not intended as, and must not 506 be construed to be, a catalog of available implementations or their 507 features. Readers are advised to note that other implementations may 508 exist. 510 According to [RFC6982], "this will allow reviewers and working groups 511 to assign due consideration to documents that have the benefit of 512 running code, which may serve as evidence of valuable experimentation 513 and feedback that have made the implemented protocols more mature. 514 It is up to the individual working groups to use this information as 515 they see fit". 517 7.1. To Be Filled In 519 Add implementation details once available. 521 8. Acknowledgements 523 The authors wish to thank the following persons for their feedback 524 and suggestions: 526 o Kevin Allendorf of GoDaddy Inc. 527 o Jody Kolker of GoDaddy Inc. 528 o James Gould of Verisign Inc 530 9. Change History 532 9.1. Change from 02 to 03 534 Corrected some formatting issues. 536 9.2. Change from 01 to 02 538 Corrected some formatting issues. 540 9.3. Change from 00 to 01 542 After review and broad feedback, extensive changes have been made 543 transforming the original document from a standalone extension 544 command to using the command and response framework. Stubbed 545 in an Implementation section for later documentation. 547 9.4. Change from carney-regext 01 to ietf-regext 00 549 Updated miscellaneous verbiage to reflect the change from an 550 extension and changed to ietf naming as REGEXT WG will assume this 551 work. 553 10. Normative References 555 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 556 Requirement Levels", BCP 14, RFC 2119, 557 DOI 10.17487/RFC2119, March 1997, 558 . 560 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 561 DOI 10.17487/RFC3688, January 2004, 562 . 564 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 565 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 566 . 568 Authors' Addresses 570 Roger Carney 571 GoDaddy Inc. 572 14455 N. Hayden Rd. #219 573 Scottsdale, AZ 85260 574 US 576 Email: rcarney@godaddy.com 577 URI: http://www.godaddy.com 578 Joseph Snitker 579 GoDaddy Inc. 580 14455 N. Hayden Rd. #219 581 Scottsdale, AZ 85260 582 US 584 Email: jsnitker@godaddy.com 585 URI: http://www.godaddy.com