idnits 2.17.1 

draft-ietf-regext-validate-00.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 (December 2, 2016) is 2699 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: June 5, 2017                                   December 2, 2016

7	    Validate Mapping for the Extensible Provisioning Protocol (EPP)
8	                     draft-ietf-regext-validate-00

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 http://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 June 5, 2017.

32	Copyright Notice

34	   Copyright (c) 2016 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	   (http://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 . . . . . . . . . . . .   2
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 <check> Command . . . . . . . . . . . . . . . . .   3
56	       3.1.2.  EPP <info> Command  . . . . . . . . . . . . . . . . .   7
57	       3.1.3.  EPP <transfer> Command  . . . . . . . . . . . . . . .   7
58	     3.2.  EPP Transform Commands  . . . . . . . . . . . . . . . . .   7
59	       3.2.1.  EPP <create> Command  . . . . . . . . . . . . . . . .   7
60	       3.2.2.  EPP <delete> Command  . . . . . . . . . . . . . . . .   7
61	       3.2.3.  EPP <renew> Command . . . . . . . . . . . . . . . . .   7
62	       3.2.4.  EPP <transfer> Command  . . . . . . . . . . . . . . .   7
63	       3.2.5.  EPP <update> Command  . . . . . . . . . . . . . . . .   7
64	   4.  Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . .   7
65	     4.1.  Validate Extension Schema . . . . . . . . . . . . . . . .   8
66	   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
67	     5.1.  XML Namespace . . . . . . . . . . . . . . . . . . . . . .  10
68	   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
69	   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
70	   8.  Change History  . . . . . . . . . . . . . . . . . . . . . . .  11
71	     8.1.  Change from 00 to 01  . . . . . . . . . . . . . . . . . .  11
72	     8.2.  Change from carney-regext 01 to ietf-regext 00  . . . . .  11
73	   9.  Normative References  . . . . . . . . . . . . . . . . . . . .  11
74	   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

76	1.  Introduction

78	   This document describes a Validate mapping for version 1.0 of the
79	   Extensible Provisioning Protocol (EPP) [RFC5730].  This EPP mapping
80	   specifies a flexible schema by which EPP clients and servers can
81	   reliably validate contact and eligibility data.

83	   With the increased number of restrictions on contacts and required
84	   data points (license, ids, etc.) to register a domain name, a way to
85	   validate the data points prior to issuing a transform command is
86	   becoming more important.

88	1.1.  Conventions Used in This Document

90	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
91	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
92	   document are to be interpreted as described in RFC 2119 [RFC2119].

94	   XML is case sensitive.  Unless stated otherwise, XML specifications
95	   and examples provided in this document MUST be interpreted in the
96	   character case presented in order to develop a conforming
97	   implementation.

99	   In examples, "C:" represents lines sent by a protocol client and "S:"
100	   represents lines returned by a protocol server.  Indentation and
101	   white space in examples are provided only to illustrate element
102	   relationships and are not a REQUIRED feature of this protocol.

104	2.  Object Attributes

106	   A EPP validation object has attributes and associated values that can
107	   be viewed by the client.  This section describes each attribute type
108	   in detail.

110	2.1.  Key Value

112	   Key Value provides a flexible mechanism to share data between the
113	   client and the server.  The <validate:kv> element defines the data,
114	   with two required simple attributes, key and value, and an optional
115	   contactType attribute for specificity in the response, more details
116	   below.

118	   o  An example <validate:kv key="VATID" value="0123456789"/>.
119	   o  An example <validate:kv contactType="Admin" key="contact:cc"
120	      value="Invalid country code for admin contact, must be MX."/>.

122	3.  EPP Command Mapping

124	   A detailed description of the EPP syntax and semantics can be found
125	   in [RFC5730].  The command mappings described here are specifically
126	   for the Validate Extension

128	3.1.  EPP Query Commands

130	   EPP provides three commands to retrieve object information: <check>
131	   to determine if an object is known to the server, <info> to retrieve
132	   detailed information associated with an object, and <transfer> to
133	   retrieve object transfer status information.

135	3.1.1.  EPP <check> Command

137	   The EPP <check> command is used to validate a list of contact
138	   information.  The <check> command MUST contain a <validate:check>
139	   element that identifies the validate namespace.  The <validate:check>
140	   element contains the following child elements:

142	   o  one or more <validate:contact> element(s) for each contact that is
143	      to be validated that contains the contact type of the contact to
144	      be validated.

146	   The <validate:contact> element MUST contain the following child
147	   elements:

149	   o  one <validate:cd> element.
150	   o  zero or more <validate:kv> elements.

152	   The <validate:cd> element MUST contain the following child elements:

154	   o  one <validate:id> element.
155	   o  an OPTIONAL <validate:postalInfo> element.
156	   o  an OPTIONAL <validate:voice> element.
157	   o  an OPTIONAL <validate:fax> element.
158	   o  an OPTIONAL <validate:email> element.
159	   o  an OPTIONAL <validate:authInfo> element.
160	   o  an OPTIONAL <validate:disclose> element.

162	   The following is an example <check> command.

164	   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
165	   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
166	   C:  xmlns:validate="urn:ietf:params:xml:ns:validate-0.1"
167	   C:  xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
168	   C:  <command>
169	   C:    <check>
170	   C:      <validate:check>
171	   C:        <validate:contact contactType="registrant" tld="COM">
172	   C:          <validate:cd>
173	   C:            <validate:id>sh8013</validate:id>
174	   C:            <validate:postalInfo type="int">
175	   C:              <contact:name>John Doe</contact:name>
176	   C:              <contact:org>Example Inc.</contact:org>
177	   C:              <contact:addr>
178	   C:                <contact:street>123 Example Dr.</contact:street>
179	   C:                <contact:street>Suite 100</contact:street>
180	   C:                <contact:city>Dulles</contact:city>
181	   C:                <contact:sp>VA</contact:sp>
182	   C:                <contact:pc>20166-6503</contact:pc>
183	   C:                <contact:cc>US</contact:cc>
184	   C:              </contact:addr>
185	   C:          </validate:postalInfo>
186	   C:          <validate:voice>+1.7035555555</validate:voice>
187	   C:          <validate:fax>+1.7035555556</validate:fax>
188	   C:          <validate:email>jdoe@example.com</validate:email>
189	   C:          <validate:authInfo>
190	   C:            <contact:pw>2fooBAR</contact:pw>
191	   C:          </validate:authInfo>
192	   C:          <validate:disclose flag="0">
193	   C:            <contact:voice/>
194	   C:            <contact:email/>
195	   C:          </validate:disclose>
196	   C:        </validate:cd>
197	   C:        <validate:kv key="VAT" value="1234567890"/>
198	   C:      </validate:contact>
199	   C:      <validate:contact contactType="tech" tld="COM">
200	   C:        <validate:cd>
201	   C:          <validate:id>sh8013</validate:id>
202	   C:        </validate:cd>
203	   C:      </validate:contact>
204	   C:      <validate:contact contactType="admin" tld="COM">
205	   C:        <validate:cd>
206	   C:          <validate:id>sh8014</validate:id>
207	   C:          <validate:postalInfo type="int">
208	   C:            <contact:name>John Doe</contact:name>
209	   C:            <contact:org>Example Inc.</contact:org>
210	   C:            <contact:addr>
211	   C:              <contact:street>123 Example Dr.</contact:street>
212	   C:              <contact:street>Suite 100</contact:street>
213	   C:              <contact:city>Dulles</contact:city>
214	   C:              <contact:sp>VA</contact:sp>
215	   C:              <contact:pc>20166-6503</contact:pc>
216	   C:              <contact:cc>US</contact:cc>
217	   C:            </contact:addr>
218	   C:          </validate:postalInfo>
219	   C:          <validate:voice>+1.7035555555</validate:voice>
220	   C:          <validate:fax>+1.7035555556</validate:fax>
221	   C:          <validate:email>jdoe@example.com</validate:email>
222	   C:          <validate:authInfo>
223	   C:            <contact:pw>2fooBAR</contact:pw>
224	   C:          </validate:authInfo>
225	   C:          <validate:disclose flag="0">
226	   C:            <contact:voice/>
227	   C:            <contact:email/>
228	   C:          </validate:disclose>
229	   C:        </validate:cd>
230	   C:      </validate:contact>
231	   C:      <validate:contact contactType="billing" tld="COM">
232	   C:        <validate:cd>
233	   C:          <validate:id>sh8014</validate:id>
234	   C:        </validate:cd>
235	   C:      </validate:contact>
236	   C:    </validate:check>
237	   C:    </check>
238	   C:    <clTRID>ABC-12345</clTRID>
239	   C:  </command>
240	   C:</epp>

242	   When a <check> command has been processed succesfully, the EPP
243	   <resData> element MUST contain a child <validate:chkData> element
244	   that identifies the validate namespace.  The <validate:chkData>
245	   element MUST contain a <validate:cd> element for each
246	   <validate:check> element contained in the <check> command.  The
247	   <validate:cd> element MUST contain the following child elements:

249	   o  one <validate:id> element.
250	   o  one <validate:response> element.
251	   o  zero or more <validate:kv> elements.

253	   The following is an example of the <check> response.

255	   S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
256	   S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
257	   S:  <response>
258	   S:    <result code="1000">
259	   S:      <msg>Command completed successfully</msg>
260	   S:    </result>
261	   S:    <resData>
262	   S:      <validate:chkData
263	   S:        xmlns:validate="urn:ietf:params:xml:ns:validate-0.1">
264	   S:        <validate:cd>
265	   S:          <validate:id>sh8013</validate:id>
266	   S:          <validate:response>1000</validate:response>
267	   S:        </validate:cd>
268	   S:        <validate:cd>
269	   S:          <validate:id>sh8014</validate:id>
270	   S:          <validate:response>2306</validate:response>
271	   S:          <validate:kv key="contact:city" value="City not valid
272	   S:            for state."/>
273	   S:          <validate:kv contactType="Admin" key="contact:cc"
274	   S:            value="Invalid country code for admin, must be mx."/>
275	   S:          <validate:kv contactType="Billing" key="VAT" value="VAT
276	   S:            required for Billing contact."/>
277	   S:        </validate:cd>
278	   S:      </validate:chkData>
279	   S:    </resData>
280	   S:    <trID>
281	   S:      <clTRID>ABC-12345</clTRID>
282	   S:      <svTRID>54321-ZYX</svTRID>
283	   S:    </trID>
284	   S:  </response>
285	   S:</epp>

287	3.1.2.  EPP <info> Command

289	   Info semantics do not apply to validate objects, so there is no
290	   mapping defined for the EPP <info> command.

292	3.1.3.  EPP <transfer> Command

294	   Transfer semantics do not apply to validate objects, so there is no
295	   mapping defined for the EPP <transfer> command.

297	3.2.  EPP Transform Commands

299	   EPP provides five commands to transform objects: <create> to create
300	   an instance of an object with a server, <delete> to remove an
301	   instance of an object from a server, <renew> to extend the validity
302	   period of an object, <transfer> to manage changes in client
303	   sponsorship of an object, and <update> to change information.

305	3.2.1.  EPP <create> Command

307	   Create semantics do not apply to validate objects, so there is no
308	   mapping defined for the EPP <create> command.

310	3.2.2.  EPP <delete> Command

312	   Delete semantics do not apply to validate objects, so there is no
313	   mapping defined for the EPP <delete> command.

315	3.2.3.  EPP <renew> Command

317	   Renew semantics do not apply to validate objects, so there is no
318	   mapping defined for the EPP <renew> command.

320	3.2.4.  EPP <transfer> Command

322	   Transfer semantics do not apply to validate objects, so there is no
323	   mapping defined for the EPP <transfer> command.

325	3.2.5.  EPP <update> Command

327	   Update semantics do not apply to validate objects, so there is no
328	   mapping defined for the EPP <update> command.

330	4.  Formal Syntax

332	   One schema is presented here that is the EPP Validate Extension
333	   schema.

335	   The formal syntax presented here is a complete schema representation
336	   of the object mapping suitable for automated validation of EPP XML
337	   instances.  The BEGIN and END tags are not part of the schema; they
338	   are used to note the beginning and ending of the schema for URI
339	   registration purposes.

341	4.1.  Validate Extension Schema

343	   BEGIN
344	   <?xml version="1.0" encoding="UTF-8"?>
345	   <schema
346	      targetNamespace="urn:ietf:params:xml:ns:validate-0.1"
347	      xmlns:validate="urn:ietf:params:xml:ns:validate-0.1"
348	      xmlns:epp="urn:ietf:params:xml:ns:epp-1.0"
349	      xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
350	      xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"
351	      xmlns="http://www.w3.org/2001/XMLSchema"
352	      elementFormDefault="qualified">

354	      <annotation>
355	        <documentation>
356	          Extensible Provisioning Protocol v1.0
357	          Validate Object Extension
358	        </documentation>
359	      </annotation>

361	      <!-- Import common element types. -->
362	      <import namespace="urn:ietf:params:xml:ns:eppcom-1.0"
363	        schemaLocation="eppcom-1.0.xsd"/>
364	      <import namespace="urn:ietf:params:xml:ns:epp-1.0"
365	        schemaLocation="epp-1.0.xsd"/>
366	      <import namespace="urn:ietf:params:xml:ns:contact-1.0"
367	        schemaLocation="contact-1.0.xsd"/>

369	   <!--
370	   Child elements of the <check> command.
371	   -->
372	      <element name="check" type="validate:checkType"/>

374	      <complexType name="checkType">
375	        <sequence>
376	          <element name="contact"
377	            type="validate:validateContactType"
378	            maxOccurs="unbounded" />
379	        </sequence>
380	      </complexType>

382	      <complexType name="validateContactType">
383	        <sequence>
384	          <element name="cd"
385	            type="validate:checkDataType"/>
386	          <element name="kv"
387	            type="validate:kvType" minOccurs="0"
388	            maxOccurs="unbounded" />
389	        </sequence>
390	        <attribute name="contactType" type="eppcom:labelType"
391	          use="required"/>
392	        <attribute name="tld"
393	          type="eppcom:labelType" use="required"/>
394	      </complexType>

396	      <complexType name="checkDataType">
397	        <sequence>
398	          <element name="id"
399	            type="eppcom:clIDType" />
400	          <element name="postalInfo"
401	            type="contact:postalInfoType"
402	            minOccurs="0" maxOccurs="2" />
403	          <element name="voice"
404	            type="contact:e164Type" minOccurs="0" />
405	          <element name="fax"
406	            type="contact:e164Type" minOccurs="0" />
407	          <element name="email"
408	            type="eppcom:minTokenType" minOccurs="0"/>
409	          <element name="authInfo"
410	            type="contact:authInfoType"
411	            minOccurs="0"/>
412	          <element name="disclose"
413	            type="contact:discloseType"
414	            minOccurs="0" />
415	        </sequence>
416	      </complexType>

418	      <complexType name="kvType">
419	        <attribute name="contactType"
420	          type="eppcom:labelType" use="optional" />
421	        <attribute name="key"
422	          type="validate:keyType" use="required" />
423	       <attribute name="value"
424	          type="validate:valueType" use="required" />
425	      </complexType>

427	      <simpleType name="keyType">
428	        <restriction base="token">
429	          <minLength value="1" />
430	        </restriction>

432	      </simpleType>

434	      <simpleType name="valueType">
435	        <restriction base="token">
436	          <minLength value="0" />
437	        </restriction>
438	      </simpleType>

440	   <!--
441	   Child elements of the <check> response.
442	   -->
443	      <element name="chkData" type="validate:chkDataType" />

445	      <complexType name="chkDataType">
446	        <sequence>
447	          <element name="cd"
448	            type="validate:resCreateDataType" maxOccurs="unbounded" />
449	        </sequence>
450	      </complexType>

452	      <complexType name="resCreateDataType">
453	        <sequence>
454	          <element name="id"
455	            type="eppcom:clIDType" />
456	          <element name="response"
457	            type="epp:resultCodeType" />
458	          <element name="kv"
459	            type="validate:kvType"
460	            minOccurs="0" maxOccurs="unbounded" />
461	        </sequence>
462	      </complexType>

464	   </schema>
465	   END

467	5.  IANA Considerations

469	5.1.  XML Namespace

471	   This document uses URNs to describe XML namespaces and XML schemas
472	   conforming to a registry mechanism described in [RFC3688].  The
473	   following URI assignment is requested of IANA:

475	   URI: ietf:params:xml:ns:validate-1.0

477	   Registrant Contact: See the "Author's Address" section of this
478	   document.

480	   XML: See the "Formal Syntax" section of this document.

482	6.  Security Considerations

484	   The mapping extensions described in this document do not provide any
485	   security services beyond those described by EPP [RFC5730] and
486	   protocol layers used by EPP.  The security considerations described
487	   in these other specifications apply to this specification as well.

489	7.  Acknowledgements

491	   The authors wish to thank the following persons for their feedback
492	   and suggestions:

494	   o  Kevin Allendorf of GoDaddy Inc.
495	   o  Jody Kolker of GoDaddy Inc.
496	   o  James Gould of Verisign Inc

498	8.  Change History

500	8.1.  Change from 00 to 01

502	   After review and broad feedback, extensive changes have been made
503	   transforming the original document from a standalone extension
504	   command to an extension using the <check> command and response
505	   framework.

507	8.2.  Change from carney-regext 01 to ietf-regext 00

509	   Updated miscellaneous verbiage to reflect the change from an
510	   extension and changed to ietf naming as REGEXT WG will assume this
511	   work.

513	9.  Normative References

515	   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
516	              Requirement Levels", BCP 14, RFC 2119,
517	              DOI 10.17487/RFC2119, March 1997,
518	              <http://www.rfc-editor.org/info/rfc2119>.

520	   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
521	              DOI 10.17487/RFC3688, January 2004,
522	              <http://www.rfc-editor.org/info/rfc3688>.

524	   [RFC5730]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
525	              STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
526	              <http://www.rfc-editor.org/info/rfc5730>.

528	Authors' Addresses

530	   Roger Carney
531	   GoDaddy Inc.
532	   14455 N. Hayden Rd. #219
533	   Scottsdale, AZ  85260
534	   US

536	   Email: rcarney@godaddy.com
537	   URI:   http://www.godaddy.com

539	   Joseph Snitker
540	   GoDaddy Inc.
541	   14455 N. Hayden Rd. #219
542	   Scottsdale, AZ  85260
543	   US

545	   Email: jsnitker@godaddy.com
546	   URI:   http://www.godaddy.com