idnits 2.17.00 (12 Aug 2021) /tmp/idnits18961/draft-ietf-regext-validate-04.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 (October 11, 2018) is 1311 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: April 14, 2019 October 11, 2018 7 Validate Mapping for the Extensible Provisioning Protocol (EPP) 8 draft-ietf-regext-validate-04 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 April 14, 2019. 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 2.2. Validate Id . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.3. Validate PostalInfo, Voice, Fax, Email, AuthInfo . . . . 4 55 3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 4 56 3.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 4 57 3.1.1. EPP Command . . . . . . . . . . . . . . . . . 4 58 3.1.2. EPP Command . . . . . . . . . . . . . . . . . 8 59 3.1.3. EPP Command . . . . . . . . . . . . . . . 8 60 3.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 9 61 3.2.1. EPP Command . . . . . . . . . . . . . . . . 9 62 3.2.2. EPP Command . . . . . . . . . . . . . . . . 9 63 3.2.3. EPP Command . . . . . . . . . . . . . . . . . 9 64 3.2.4. EPP Command . . . . . . . . . . . . . . . 9 65 3.2.5. EPP Command . . . . . . . . . . . . . . . . 9 66 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 9 67 4.1. Validate Schema . . . . . . . . . . . . . . . . . . . . . 9 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 70 6.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 13 71 7. Implemntation Status . . . . . . . . . . . . . . . . . . . . 13 72 7.1. To Be Filled In . . . . . . . . . . . . . . . . . . . . . 14 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 74 9. Change History . . . . . . . . . . . . . . . . . . . . . . . 14 75 9.1. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 14 76 9.2. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 14 77 9.3. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 14 78 9.4. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 14 79 9.5. Change from carney-regext 01 to ietf-regext 00 . . . . . 15 80 10. Normative References . . . . . . . . . . . . . . . . . . . . 15 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 83 1. Introduction 85 This document describes a Validate mapping for version 1.0 of the 86 Extensible Provisioning Protocol (EPP) [RFC5730]. This EPP mapping 87 specifies a flexible schema by which EPP clients and servers can 88 reliably validate contact and eligibility data. 90 With the increased number of restrictions on contacts and required 91 data points (license, ids, etc.) to register a domain name, a way to 92 validate the data points prior to issuing a transform command is 93 becoming more important. 95 1.1. Conventions Used in This Document 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 99 "OPTIONAL" in this document are to be interpreted as described in BCP 100 14 [RFC2119] [RFC8174] when, and only when, they appear in all 101 capitals, as shown here. 103 XML is case sensitive. Unless stated otherwise, XML specifications 104 and examples provided in this document MUST be interpreted in the 105 character case presented in order to develop a conforming 106 implementation. 108 "validate" is used as an abbreviation for 109 "urn:ietf:params:xml:ns:validate-0.2". The XML namespace prefix 110 "validate" is used, but implementations MUST NOT depend on it and 111 instead employ a proper namespace-aware XML parser and serializer to 112 interpret and output the XML documents. 114 In examples, "C:" represents lines sent by a protocol client and "S:" 115 represents lines returned by a protocol server. Indentation and 116 white space in examples are provided only to illustrate element 117 relationships and are not a REQUIRED feature of this protocol. 119 (Note to RFC Editor: remove the following paragraph before 120 publication as an RFC.) 122 The XML namespace prefix above contains a version number, 123 specifically "0.2". This version number will increment with 124 successive versions of this document, and will reach 1.0 if and when 125 this document is published as an RFC. This permits clients to 126 distinguish which version of the extension a server has implemented. 128 2. Object Attributes 130 A EPP validation object has attributes and associated values that can 131 be viewed by the client. This section describes each attribute type 132 in detail. 134 2.1. Key Value 136 Key Value provides a flexible mechanism to share data between the 137 client and the server. The element defines the data, 138 with two required simple attributes, key and value, and an optional 139 contactType attribute for specificity in the response, more details 140 below. 142 o An example . 144 o An example . 147 2.2. Validate Id 149 The element is used in two different scenarios. 151 First if the is passed by itself with no other elements 152 (e.g. >validate:postalInfo>) then the client intent is that this is 153 an already existing contact and the server should handle the request 154 by looking up the associated data in its system and using that data 155 to validate against. 157 Second scenario would be if the request includes additional elements 158 then the server should treat the as a temporary contact 159 handle and should not perform a look on the contact but use the data 160 that is passed in the request to validate against. 162 2.3. Validate PostalInfo, Voice, Fax, Email, AuthInfo 164 These elements are intended to mirror the definitions in [RFC5733]. 166 3. EPP Command Mapping 168 A detailed description of the EPP syntax and semantics can be found 169 in [RFC5730]. The command mappings described here are specifically 170 for the Validate Extension. 172 3.1. EPP Query Commands 174 EPP provides three commands to retrieve object information: 175 to determine if an object is known to the server, to retrieve 176 detailed information associated with an object, and to 177 retrieve object transfer status information. 179 3.1.1. EPP Command 181 The EPP command is used to validate a list of contact 182 information. The command MUST contain a 183 element that identifies the validate namespace. The 184 element contains the following child elements: 186 o one or more element(s) for each contact that is 187 to be validated that contains the contact type of the contact to 188 be validated. 190 The element has two required attributes: 191 contactType, which describes the role (registrant, admin, tech, 192 billing, etc.) of the contact that the contact should be validated 193 for; and tld, which provides the top level domain to be validated 194 against. The element contains the following child 195 elements: 197 o one element (as described in section 2.2). 198 o an OPTIONAL element (as described in section 199 2.3). 200 o an OPTIONAL element (as described in section 201 2.3). 202 o an OPTIONAL element (as described in section 2.3). 203 o an OPTIONAL element (as described in section 204 2.3). 205 o an OPTIONAL element (as described in section 206 2.3). 207 o zero or more elements (as described in section 2.1). 209 The following is an example command where "sh8013" and 210 "sh8014" are both "new" contacts and "sh8012" is an existing contact 211 on the server. 213 C: 214 C: 217 C: 218 C: 219 C: 220 C: 221 C: sh8013 222 C: 223 C: John Doe 224 C: Example Inc. 225 C: 226 C: 123 Example Dr. 227 C: Suite 100 228 C: Dulles 229 C: VA 230 C: 20166-6503 231 C: US 232 C: 233 C: 234 C: +1.7035555555 235 C: +1.7035555556 236 C: jdoe@example.com 237 C: 238 C: 2fooBAR 239 C: 240 C: 241 C: 242 C: 243 C: sh8012 244 C: 245 C: 246 C: sh8014 247 C: 248 C: John Doe 249 C: Example Inc. 250 C: 251 C: 123 Example Dr. 252 C: Suite 100 253 C: Dulles 254 C: VA 255 C: 20166-6503 256 C: US 257 C: 258 C: 259 C: +1.7035555555 260 C: +1.7035555556 261 C: jdoe@example.com 262 C: 263 C: 2fooBAR 264 C: 265 C: 266 C: 267 C: sh8014 268 C: 269 C: John Doe 270 C: Example Inc. 271 C: 272 C: 123 Example Dr. 273 C: Suite 100 274 C: Dulles 275 C: VA 276 C: 20166-6503 277 C: US 278 C: 279 C: 280 C: +1.7035555555 281 C: +1.7035555556 282 C: jdoe@example.com 283 C: 284 C: 2fooBAR 285 C: 286 C: 287 C: 288 C: 289 C: ABC-12345 290 C: 291 C: 293 When the server receives a command with a 294 element that contains only a element the server will 295 process this as an existing contact. If the contact does not exist 296 the server MUST return an EPP error response for that specific 297 . 299 When a command has been processed succesfully, the EPP 300 element MUST contain a child element 301 that identifies the validate namespace. The 302 element MUST contain a element for each 303 element contained in the command. The 304 element contains the following child elements: 306 o one element. 307 o one element. 308 o zero or more elements. 310 The following is an example of the response. 312 S: 313 S: 314 S: 315 S: 316 S: Command completed successfully 317 S: 318 S: 319 S: 321 S: 322 S: sh8013 323 S: 1000 324 S: 325 S: 326 S: sh8014 327 S: 2306 328 S: 330 S: 332 S: 334 S: 335 S: 336 S: 337 S: 338 S: ABC-12345 339 S: 54321-ZYX 340 S: 341 S: 342 S: 344 3.1.2. EPP Command 346 Info semantics do not apply to validate objects, so there is no 347 mapping defined for the EPP command. 349 3.1.3. EPP Command 351 Transfer semantics do not apply to validate objects, so there is no 352 mapping defined for the EPP command. 354 3.2. EPP Transform Commands 356 EPP provides five commands to transform objects: to create 357 an instance of an object with a server, to remove an 358 instance of an object from a server, to extend the validity 359 period of an object, to manage changes in client 360 sponsorship of an object, and to change information. 362 3.2.1. EPP Command 364 Create semantics do not apply to validate objects, so there is no 365 mapping defined for the EPP command. 367 3.2.2. EPP Command 369 Delete semantics do not apply to validate objects, so there is no 370 mapping defined for the EPP command. 372 3.2.3. EPP Command 374 Renew semantics do not apply to validate objects, so there is no 375 mapping defined for the EPP command. 377 3.2.4. EPP Command 379 Transfer semantics do not apply to validate objects, so there is no 380 mapping defined for the EPP command. 382 3.2.5. EPP Command 384 Update semantics do not apply to validate objects, so there is no 385 mapping defined for the EPP command. 387 4. Formal Syntax 389 One schema is presented here that is the EPP Validate schema. 391 The formal syntax presented here is a complete schema representation 392 of the object mapping suitable for automated validation of EPP XML 393 instances. The BEGIN and END tags are not part of the schema; they 394 are used to note the beginning and ending of the schema for URI 395 registration purposes. 397 4.1. Validate Schema 399 Copyright (c) 2018 IETF Trust and the persons identified as authors 400 of the code. All rights reserved. 402 Redistribution and use in source and binary forms, with or without 403 modification, are permitted provided that the following conditions 404 are met: 406 o Redistributions of source code must retain the above copyright 407 notice, this list of conditions and the following disclaimer. 408 o Redistributions in binary form must reproduce the above copyright 409 notice, this list of conditions and the following disclaimer in 410 the documentation and/or other materials provided with the 411 distribution. 412 o Neither the name of Internet Society, IETF or IETF Trust, nor the 413 names of specific contributors, may be used to endorse or promote 414 products derived from this software without specific prior written 415 permission. 417 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 418 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 419 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 420 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 421 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 422 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 423 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 424 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 425 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 426 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 427 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 429 BEGIN 430 431 440 441 442 Extensible Provisioning Protocol v1.0 443 Validate Object 444 445 447 448 451 453 456 459 461 462 463 466 467 469 470 471 473 476 478 480 482 485 488 489 491 493 495 496 498 500 502 504 505 506 507 508 510 511 512 513 514 516 519 521 522 523 525 526 528 529 530 532 534 537 538 540 541 END 543 5. Security Considerations 545 The mapping described in this document do not provide any security 546 services beyond those described by EPP [RFC5730] and protocol layers 547 used by EPP. The security considerations described in these other 548 specifications apply to this specification as well. 550 6. IANA Considerations 552 6.1. XML Namespace 554 This document uses URNs to describe XML namespaces and XML schemas 555 conforming to a registry mechanism described in [RFC3688]. 557 Registration request for the validate namespace: 559 URI: urn:ietf:params:xml:ns:validate-1.0 561 Registrant Contact: IESG 563 XML: None. Namespace URIs do not represent an XML specification. 565 Registration request for the validate schema: 567 URI: urn:ietf:params:xml:schema:validate-1.0 569 Registrant Contact: IESG 571 XML: See the "Formal Syntax" section of this document. 573 7. Implemntation Status 575 Note to RFC Editor: Please remove this section and the reference to 576 [RFC7942] before publication. 578 This section records the status of known implementations of the 579 protocol defined by this specification at the time of posting of this 580 Internet-Draft, and is based on a proposal described in [RFC7942]. 581 The description of implementations in this section is intended to 582 assist the IETF in its decision processes in progressing drafts to 583 RFCs. Please note that the listing of any individual implementation 584 here does not imply endorsement by the IETF. Furthermore, no effort 585 has been spent to verify the information presented here that was 586 supplied by IETF contributors. This is not intended as, and must not 587 be construed to be, a catalog of available implementations or their 588 features. Readers are advised to note that other implementations may 589 exist. 591 According to [RFC7942], "this will allow reviewers and working groups 592 to assign due consideration to documents that have the benefit of 593 running code, which may serve as evidence of valuable experimentation 594 and feedback that have made the implemented protocols more mature. 595 It is up to the individual working groups to use this information as 596 they see fit". 598 7.1. To Be Filled In 600 Add implementation details once available. 602 8. Acknowledgements 604 The authors wish to thank the following persons for their feedback 605 and suggestions: 607 o Kevin Allendorf of GoDaddy Inc. 608 o Jody Kolker of GoDaddy Inc. 609 o James Gould of Verisign Inc 611 9. Change History 613 9.1. Change from 03 to 04 615 Removed the element from the command, moving 616 all sub-elements to the element to simplify. Also 617 removed the element as it was not needed in this context. 618 Also updated references to current versions of documents. 620 9.2. Change from 02 to 03 622 Corrected some formatting issues. 624 9.3. Change from 01 to 02 626 Corrected some formatting issues. 628 9.4. Change from 00 to 01 630 After review and broad feedback, extensive changes have been made 631 transforming the original document from a standalone extension 632 command to using the command and response framework. Stubbed 633 in an Implementation section for later documentation. 635 9.5. Change from carney-regext 01 to ietf-regext 00 637 Updated miscellaneous verbiage to reflect the change from an 638 extension and changed to ietf naming as REGEXT WG will assume this 639 work. 641 10. Normative References 643 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 644 Requirement Levels", BCP 14, RFC 2119, 645 DOI 10.17487/RFC2119, March 1997, 646 . 648 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 649 DOI 10.17487/RFC3688, January 2004, 650 . 652 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 653 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 654 . 656 [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 657 Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733, 658 August 2009, . 660 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 661 Code: The Implementation Status Section", BCP 205, 662 RFC 7942, DOI 10.17487/RFC7942, July 2016, 663 . 665 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 666 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 667 May 2017, . 669 Authors' Addresses 671 Roger Carney 672 GoDaddy Inc. 673 14455 N. Hayden Rd. #219 674 Scottsdale, AZ 85260 675 US 677 Email: rcarney@godaddy.com 678 URI: http://www.godaddy.com 679 Joseph Snitker 680 GoDaddy Inc. 681 14455 N. Hayden Rd. #219 682 Scottsdale, AZ 85260 683 US 685 Email: jsnitker@godaddy.com 686 URI: http://www.godaddy.com