draft-ietf-regext-validate-03.txt | draft-ietf-regext-validate-04.txt | |||
---|---|---|---|---|
Registration Protocols Extensions R. Carney | Registration Protocols Extensions R. Carney | |||
Internet-Draft J. Snitker | Internet-Draft J. Snitker | |||
Intended status: Standards Track GoDaddy Inc. | Intended status: Standards Track GoDaddy Inc. | |||
Expires: August 6, 2018 February 2, 2018 | Expires: April 14, 2019 October 11, 2018 | |||
Validate Mapping for the Extensible Provisioning Protocol (EPP) | Validate Mapping for the Extensible Provisioning Protocol (EPP) | |||
draft-ietf-regext-validate-03 | draft-ietf-regext-validate-04 | |||
Abstract | Abstract | |||
This document describes an Extensible Provisioning Protocol (EPP) | This document describes an Extensible Provisioning Protocol (EPP) | |||
mapping for the validation of contact and eligibility data. | mapping for the validation of contact and eligibility data. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
skipping to change at page 1, line 31 ¶ | skipping to change at page 1, line 31 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on August 6, 2018. | This Internet-Draft will expire on April 14, 2019. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2018 IETF Trust and the persons identified as the | Copyright (c) 2018 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 11 ¶ | skipping to change at page 2, line 11 ¶ | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
1.1. Conventions Used in This Document . . . . . . . . . . . . 3 | 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 | |||
2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2.1. Key Value . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2.1. Key Value . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 3 | 2.2. Validate Id . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
3.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 3 | 2.3. Validate PostalInfo, Voice, Fax, Email, AuthInfo . . . . 4 | |||
3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 4 | ||||
3.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 4 | ||||
3.1.1. EPP <check> Command . . . . . . . . . . . . . . . . . 4 | 3.1.1. EPP <check> Command . . . . . . . . . . . . . . . . . 4 | |||
3.1.2. EPP <info> Command . . . . . . . . . . . . . . . . . 7 | 3.1.2. EPP <info> Command . . . . . . . . . . . . . . . . . 8 | |||
3.1.3. EPP <transfer> Command . . . . . . . . . . . . . . . 7 | 3.1.3. EPP <transfer> Command . . . . . . . . . . . . . . . 8 | |||
3.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 8 | 3.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 9 | |||
3.2.1. EPP <create> Command . . . . . . . . . . . . . . . . 8 | 3.2.1. EPP <create> Command . . . . . . . . . . . . . . . . 9 | |||
3.2.2. EPP <delete> Command . . . . . . . . . . . . . . . . 8 | 3.2.2. EPP <delete> Command . . . . . . . . . . . . . . . . 9 | |||
3.2.3. EPP <renew> Command . . . . . . . . . . . . . . . . . 8 | 3.2.3. EPP <renew> Command . . . . . . . . . . . . . . . . . 9 | |||
3.2.4. EPP <transfer> Command . . . . . . . . . . . . . . . 8 | 3.2.4. EPP <transfer> Command . . . . . . . . . . . . . . . 9 | |||
3.2.5. EPP <update> Command . . . . . . . . . . . . . . . . 8 | 3.2.5. EPP <update> Command . . . . . . . . . . . . . . . . 9 | |||
4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 8 | 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
4.1. Validate Schema . . . . . . . . . . . . . . . . . . . . . 8 | 4.1. Validate Schema . . . . . . . . . . . . . . . . . . . . . 9 | |||
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | |||
6.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 11 | 6.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 13 | |||
7. Implemntation Status . . . . . . . . . . . . . . . . . . . . 12 | 7. Implemntation Status . . . . . . . . . . . . . . . . . . . . 13 | |||
7.1. To Be Filled In . . . . . . . . . . . . . . . . . . . . . 12 | 7.1. To Be Filled In . . . . . . . . . . . . . . . . . . . . . 14 | |||
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 | 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 | |||
9. Change History . . . . . . . . . . . . . . . . . . . . . . . 12 | 9. Change History . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
9.1. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 12 | 9.1. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 14 | |||
9.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 13 | 9.2. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 14 | |||
9.3. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 13 | 9.3. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 14 | |||
9.4. Change from carney-regext 01 to ietf-regext 00 . . . . . 13 | 9.4. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 14 | |||
10. Normative References . . . . . . . . . . . . . . . . . . . . 13 | 9.5. Change from carney-regext 01 to ietf-regext 00 . . . . . 15 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 | 10. Normative References . . . . . . . . . . . . . . . . . . . . 15 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 | ||||
1. Introduction | 1. Introduction | |||
This document describes a Validate mapping for version 1.0 of the | This document describes a Validate mapping for version 1.0 of the | |||
Extensible Provisioning Protocol (EPP) [RFC5730]. This EPP mapping | Extensible Provisioning Protocol (EPP) [RFC5730]. This EPP mapping | |||
specifies a flexible schema by which EPP clients and servers can | specifies a flexible schema by which EPP clients and servers can | |||
reliably validate contact and eligibility data. | reliably validate contact and eligibility data. | |||
With the increased number of restrictions on contacts and required | With the increased number of restrictions on contacts and required | |||
data points (license, ids, etc.) to register a domain name, a way to | data points (license, ids, etc.) to register a domain name, a way to | |||
validate the data points prior to issuing a transform command is | validate the data points prior to issuing a transform command is | |||
becoming more important. | becoming more important. | |||
1.1. Conventions Used in This Document | 1.1. Conventions Used in This Document | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
document are to be interpreted as described in RFC 2119 [RFC2119]. | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
14 [RFC2119] [RFC8174] when, and only when, they appear in all | ||||
capitals, as shown here. | ||||
XML is case sensitive. Unless stated otherwise, XML specifications | XML is case sensitive. Unless stated otherwise, XML specifications | |||
and examples provided in this document MUST be interpreted in the | and examples provided in this document MUST be interpreted in the | |||
character case presented in order to develop a conforming | character case presented in order to develop a conforming | |||
implementation. | implementation. | |||
"validate" is used as an abbreviation for | ||||
"urn:ietf:params:xml:ns:validate-0.2". The XML namespace prefix | ||||
"validate" is used, but implementations MUST NOT depend on it and | ||||
instead employ a proper namespace-aware XML parser and serializer to | ||||
interpret and output the XML documents. | ||||
In examples, "C:" represents lines sent by a protocol client and "S:" | In examples, "C:" represents lines sent by a protocol client and "S:" | |||
represents lines returned by a protocol server. Indentation and | represents lines returned by a protocol server. Indentation and | |||
white space in examples are provided only to illustrate element | white space in examples are provided only to illustrate element | |||
relationships and are not a REQUIRED feature of this protocol. | relationships and are not a REQUIRED feature of this protocol. | |||
(Note to RFC Editor: remove the following paragraph before | ||||
publication as an RFC.) | ||||
The XML namespace prefix above contains a version number, | ||||
specifically "0.2". This version number will increment with | ||||
successive versions of this document, and will reach 1.0 if and when | ||||
this document is published as an RFC. This permits clients to | ||||
distinguish which version of the extension a server has implemented. | ||||
2. Object Attributes | 2. Object Attributes | |||
A EPP validation object has attributes and associated values that can | A EPP validation object has attributes and associated values that can | |||
be viewed by the client. This section describes each attribute type | be viewed by the client. This section describes each attribute type | |||
in detail. | in detail. | |||
2.1. Key Value | 2.1. Key Value | |||
Key Value provides a flexible mechanism to share data between the | Key Value provides a flexible mechanism to share data between the | |||
client and the server. The <validate:kv> element defines the data, | client and the server. The <validate:kv> element defines the data, | |||
skipping to change at page 3, line 36 ¶ | skipping to change at page 4, line 4 ¶ | |||
2.1. Key Value | 2.1. Key Value | |||
Key Value provides a flexible mechanism to share data between the | Key Value provides a flexible mechanism to share data between the | |||
client and the server. The <validate:kv> element defines the data, | client and the server. The <validate:kv> element defines the data, | |||
with two required simple attributes, key and value, and an optional | with two required simple attributes, key and value, and an optional | |||
contactType attribute for specificity in the response, more details | contactType attribute for specificity in the response, more details | |||
below. | below. | |||
o An example <validate:kv key="VATID" value="0123456789"/>. | o An example <validate:kv key="VATID" value="0123456789"/>. | |||
o An example <validate:kv contactType="Admin" key="contact:cc" | o An example <validate:kv contactType="Admin" key="contact:cc" | |||
value="Invalid country code for admin contact, must be MX."/>. | value="Invalid country code for admin contact, must be MX."/>. | |||
2.2. Validate Id | ||||
The <validate:id> element is used in two different scenarios. | ||||
First if the <validate:id> is passed by itself with no other elements | ||||
(e.g. >validate:postalInfo>) then the client intent is that this is | ||||
an already existing contact and the server should handle the request | ||||
by looking up the associated data in its system and using that data | ||||
to validate against. | ||||
Second scenario would be if the request includes additional elements | ||||
then the server should treat the <validate:id> as a temporary contact | ||||
handle and should not perform a look on the contact but use the data | ||||
that is passed in the request to validate against. | ||||
2.3. Validate PostalInfo, Voice, Fax, Email, AuthInfo | ||||
These elements are intended to mirror the definitions in [RFC5733]. | ||||
3. EPP Command Mapping | 3. EPP Command Mapping | |||
A detailed description of the EPP syntax and semantics can be found | A detailed description of the EPP syntax and semantics can be found | |||
in [RFC5730]. The command mappings described here are specifically | in [RFC5730]. The command mappings described here are specifically | |||
for the Validate Extension. | for the Validate Extension. | |||
3.1. EPP Query Commands | 3.1. EPP Query Commands | |||
EPP provides three commands to retrieve object information: <check> | EPP provides three commands to retrieve object information: <check> | |||
to determine if an object is known to the server, <info> to retrieve | to determine if an object is known to the server, <info> to retrieve | |||
skipping to change at page 4, line 16 ¶ | skipping to change at page 4, line 51 ¶ | |||
The EPP <check> command is used to validate a list of contact | The EPP <check> command is used to validate a list of contact | |||
information. The <check> command MUST contain a <validate:check> | information. The <check> command MUST contain a <validate:check> | |||
element that identifies the validate namespace. The <validate:check> | element that identifies the validate namespace. The <validate:check> | |||
element contains the following child elements: | element contains the following child elements: | |||
o one or more <validate:contact> element(s) for each contact that is | o one or more <validate:contact> element(s) for each contact that is | |||
to be validated that contains the contact type of the contact to | to be validated that contains the contact type of the contact to | |||
be validated. | be validated. | |||
The <validate:contact> element MUST contain the following child | The <validate:contact> element has two required attributes: | |||
contactType, which describes the role (registrant, admin, tech, | ||||
billing, etc.) of the contact that the contact should be validated | ||||
for; and tld, which provides the top level domain to be validated | ||||
against. The <validate:contact> element contains the following child | ||||
elements: | elements: | |||
o one <validate:cd> element. | o one <validate:id> element (as described in section 2.2). | |||
o zero or more <validate:kv> elements. | o an OPTIONAL <validate:postalInfo> element (as described in section | |||
2.3). | ||||
The <validate:cd> element MUST contain the following child elements: | o an OPTIONAL <validate:voice> element (as described in section | |||
2.3). | ||||
o one <validate:id> element. | o an OPTIONAL <validate:fax> element (as described in section 2.3). | |||
o an OPTIONAL <validate:postalInfo> element. | o an OPTIONAL <validate:email> element (as described in section | |||
o an OPTIONAL <validate:voice> element. | 2.3). | |||
o an OPTIONAL <validate:fax> element. | o an OPTIONAL <validate:authInfo> element (as described in section | |||
o an OPTIONAL <validate:email> element. | 2.3). | |||
o an OPTIONAL <validate:authInfo> element. | o zero or more <validate:kv> elements (as described in section 2.1). | |||
o an OPTIONAL <validate:disclose> element. | ||||
The following is an example <check> command. | The following is an example <check> command where "sh8013" and | |||
"sh8014" are both "new" contacts and "sh8012" is an existing contact | ||||
on the server. | ||||
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> | C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> | |||
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" | C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" | |||
C: xmlns:validate="urn:ietf:params:xml:ns:validate-0.1" | C: xmlns:validate="urn:ietf:params:xml:ns:validate-0.2" | |||
C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> | C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> | |||
C: <command> | C: <command> | |||
C: <check> | C: <check> | |||
C: <validate:check> | C: <validate:check> | |||
C: <validate:contact contactType="registrant" tld="COM"> | C: <validate:contact contactType="registrant" tld="COM"> | |||
C: <validate:cd> | C: <validate:id>sh8013</validate:id> | |||
C: <validate:id>sh8013</validate:id> | C: <validate:postalInfo type="int"> | |||
C: <validate:postalInfo type="int"> | C: <contact:name>John Doe</contact:name> | |||
C: <contact:name>John Doe</contact:name> | C: <contact:org>Example Inc.</contact:org> | |||
C: <contact:org>Example Inc.</contact:org> | C: <contact:addr> | |||
C: <contact:addr> | C: <contact:street>123 Example Dr.</contact:street> | |||
C: <contact:street>123 Example Dr.</contact:street> | C: <contact:street>Suite 100</contact:street> | |||
C: <contact:street>Suite 100</contact:street> | C: <contact:city>Dulles</contact:city> | |||
C: <contact:city>Dulles</contact:city> | C: <contact:sp>VA</contact:sp> | |||
C: <contact:sp>VA</contact:sp> | C: <contact:pc>20166-6503</contact:pc> | |||
C: <contact:pc>20166-6503</contact:pc> | C: <contact:cc>US</contact:cc> | |||
C: <contact:cc>US</contact:cc> | C: </contact:addr> | |||
C: </contact:addr> | C: </validate:postalInfo> | |||
C: </validate:postalInfo> | C: <validate:voice>+1.7035555555</validate:voice> | |||
C: <validate:voice>+1.7035555555</validate:voice> | C: <validate:fax>+1.7035555556</validate:fax> | |||
C: <validate:fax>+1.7035555556</validate:fax> | C: <validate:email>jdoe@example.com</validate:email> | |||
C: <validate:email>jdoe@example.com</validate:email> | C: <validate:authInfo> | |||
C: <validate:authInfo> | C: <contact:pw>2fooBAR</contact:pw> | |||
C: <contact:pw>2fooBAR</contact:pw> | C: </validate:authInfo> | |||
C: </validate:authInfo> | ||||
C: <validate:disclose flag="0"> | ||||
C: <contact:voice/> | ||||
C: <contact:email/> | ||||
C: </validate:disclose> | ||||
C: </validate:cd> | ||||
C: <validate:kv key="VAT" value="1234567890"/> | C: <validate:kv key="VAT" value="1234567890"/> | |||
C: </validate:contact> | C: </validate:contact> | |||
C: <validate:contact contactType="tech" tld="COM"> | C: <validate:contact contactType="tech" tld="COM"> | |||
C: <validate:cd> | C: <validate:id>sh8012</validate:id> | |||
C: <validate:id>sh8013</validate:id> | ||||
C: </validate:cd> | ||||
C: </validate:contact> | C: </validate:contact> | |||
C: <validate:contact contactType="admin" tld="COM"> | C: <validate:contact contactType="admin" tld="COM"> | |||
C: <validate:cd> | C: <validate:id>sh8014</validate:id> | |||
C: <validate:id>sh8014</validate:id> | C: <validate:postalInfo type="int"> | |||
C: <validate:postalInfo type="int"> | C: <contact:name>John Doe</contact:name> | |||
C: <contact:name>John Doe</contact:name> | C: <contact:org>Example Inc.</contact:org> | |||
C: <contact:org>Example Inc.</contact:org> | C: <contact:addr> | |||
C: <contact:addr> | C: <contact:street>123 Example Dr.</contact:street> | |||
C: <contact:street>123 Example Dr.</contact:street> | C: <contact:street>Suite 100</contact:street> | |||
C: <contact:street>Suite 100</contact:street> | C: <contact:city>Dulles</contact:city> | |||
C: <contact:city>Dulles</contact:city> | C: <contact:sp>VA</contact:sp> | |||
C: <contact:sp>VA</contact:sp> | C: <contact:pc>20166-6503</contact:pc> | |||
C: <contact:pc>20166-6503</contact:pc> | C: <contact:cc>US</contact:cc> | |||
C: <contact:cc>US</contact:cc> | C: </contact:addr> | |||
C: </contact:addr> | C: </validate:postalInfo> | |||
C: </validate:postalInfo> | C: <validate:voice>+1.7035555555</validate:voice> | |||
C: <validate:voice>+1.7035555555</validate:voice> | C: <validate:fax>+1.7035555556</validate:fax> | |||
C: <validate:fax>+1.7035555556</validate:fax> | C: <validate:email>jdoe@example.com</validate:email> | |||
C: <validate:email>jdoe@example.com</validate:email> | C: <validate:authInfo> | |||
C: <validate:authInfo> | C: <contact:pw>2fooBAR</contact:pw> | |||
C: <contact:pw>2fooBAR</contact:pw> | C: </validate:authInfo> | |||
C: </validate:authInfo> | ||||
C: <validate:disclose flag="0"> | ||||
C: <contact:voice/> | ||||
C: <contact:email/> | ||||
C: </validate:disclose> | ||||
C: </validate:cd> | ||||
C: </validate:contact> | C: </validate:contact> | |||
C: <validate:contact contactType="billing" tld="COM"> | C: <validate:contact contactType="billing" tld="COM"> | |||
C: <validate:cd> | C: <validate:id>sh8014</validate:id> | |||
C: <validate:id>sh8014</validate:id> | C: <validate:postalInfo type="int"> | |||
C: </validate:cd> | C: <contact:name>John Doe</contact:name> | |||
C: <contact:org>Example Inc.</contact:org> | ||||
C: <contact:addr> | ||||
C: <contact:street>123 Example Dr.</contact:street> | ||||
C: <contact:street>Suite 100</contact:street> | ||||
C: <contact:city>Dulles</contact:city> | ||||
C: <contact:sp>VA</contact:sp> | ||||
C: <contact:pc>20166-6503</contact:pc> | ||||
C: <contact:cc>US</contact:cc> | ||||
C: </contact:addr> | ||||
C: </validate:postalInfo> | ||||
C: <validate:voice>+1.7035555555</validate:voice> | ||||
C: <validate:fax>+1.7035555556</validate:fax> | ||||
C: <validate:email>jdoe@example.com</validate:email> | ||||
C: <validate:authInfo> | ||||
C: <contact:pw>2fooBAR</contact:pw> | ||||
C: </validate:authInfo> | ||||
C: </validate:contact> | C: </validate:contact> | |||
C: </validate:check> | C: </validate:check> | |||
C: </check> | C: </check> | |||
C: <clTRID>ABC-12345</clTRID> | C: <clTRID>ABC-12345</clTRID> | |||
C: </command> | C: </command> | |||
C:</epp> | C:</epp> | |||
When the server receives a <check> command with a <validate:contact> | ||||
element that contains only a <validate:id> element the server will | ||||
process this as an existing contact. If the contact does not exist | ||||
the server MUST return an EPP error response for that specific | ||||
<validate:contact>. | ||||
When a <check> command has been processed succesfully, the EPP | When a <check> command has been processed succesfully, the EPP | |||
<resData> element MUST contain a child <validate:chkData> element | <resData> element MUST contain a child <validate:chkData> element | |||
that identifies the validate namespace. The <validate:chkData> | that identifies the validate namespace. The <validate:chkData> | |||
element MUST contain a <validate:cd> element for each | element MUST contain a <validate:cd> element for each | |||
<validate:check> element contained in the <check> command. The | <validate:check> element contained in the <check> command. The | |||
<validate:cd> element MUST contain the following child elements: | <validate:cd> element contains the following child elements: | |||
o one <validate:id> element. | o one <validate:id> element. | |||
o one <validate:response> element. | o one <validate:response> element. | |||
o zero or more <validate:kv> elements. | o zero or more <validate:kv> elements. | |||
The following is an example of the <check> response. | The following is an example of the <check> response. | |||
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> | S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> | |||
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> | S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> | |||
S: <response> | S: <response> | |||
S: <result code="1000"> | S: <result code="1000"> | |||
S: <msg>Command completed successfully</msg> | S: <msg>Command completed successfully</msg> | |||
S: </result> | S: </result> | |||
S: <resData> | S: <resData> | |||
S: <validate:chkData | S: <validate:chkData | |||
S: xmlns:validate="urn:ietf:params:xml:ns:validate-0.1"> | S: xmlns:validate="urn:ietf:params:xml:ns:validate-0.2"> | |||
S: <validate:cd> | S: <validate:cd> | |||
S: <validate:id>sh8013</validate:id> | S: <validate:id>sh8013</validate:id> | |||
S: <validate:response>1000</validate:response> | S: <validate:response>1000</validate:response> | |||
S: </validate:cd> | S: </validate:cd> | |||
S: <validate:cd> | S: <validate:cd> | |||
S: <validate:id>sh8014</validate:id> | S: <validate:id>sh8014</validate:id> | |||
S: <validate:response>2306</validate:response> | S: <validate:response>2306</validate:response> | |||
S: <validate:kv key="contact:city" value="City not valid | S: <validate:kv key="contact:city" value="City not valid | |||
S: for state."/> | S: for state."/> | |||
S: <validate:kv contactType="Admin" key="contact:cc" | S: <validate:kv contactType="Admin" key="contact:cc" | |||
skipping to change at page 8, line 50 ¶ | skipping to change at page 9, line 50 ¶ | |||
One schema is presented here that is the EPP Validate schema. | One schema is presented here that is the EPP Validate schema. | |||
The formal syntax presented here is a complete schema representation | The formal syntax presented here is a complete schema representation | |||
of the object mapping suitable for automated validation of EPP XML | of the object mapping suitable for automated validation of EPP XML | |||
instances. The BEGIN and END tags are not part of the schema; they | instances. The BEGIN and END tags are not part of the schema; they | |||
are used to note the beginning and ending of the schema for URI | are used to note the beginning and ending of the schema for URI | |||
registration purposes. | registration purposes. | |||
4.1. Validate Schema | 4.1. Validate Schema | |||
Copyright (c) 2018 IETF Trust and the persons identified as authors | ||||
of the code. All rights reserved. | ||||
Redistribution and use in source and binary forms, with or without | ||||
modification, are permitted provided that the following conditions | ||||
are met: | ||||
o Redistributions of source code must retain the above copyright | ||||
notice, this list of conditions and the following disclaimer. | ||||
o Redistributions in binary form must reproduce the above copyright | ||||
notice, this list of conditions and the following disclaimer in | ||||
the documentation and/or other materials provided with the | ||||
distribution. | ||||
o Neither the name of Internet Society, IETF or IETF Trust, nor the | ||||
names of specific contributors, may be used to endorse or promote | ||||
products derived from this software without specific prior written | ||||
permission. | ||||
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS | ||||
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT | ||||
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR | ||||
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT | ||||
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, | ||||
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT | ||||
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, | ||||
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY | ||||
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT | ||||
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE | ||||
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. | ||||
BEGIN | BEGIN | |||
<?xml version="1.0" encoding="UTF-8"?> | <?xml version="1.0" encoding="UTF-8"?> | |||
<schema | <schema | |||
targetNamespace="urn:ietf:params:xml:ns:validate-0.1" | targetNamespace="urn:ietf:params:xml:ns:validate-0.2" | |||
xmlns:validate="urn:ietf:params:xml:ns:validate-0.1" | xmlns:validate="urn:ietf:params:xml:ns:validate-0.2" | |||
xmlns:epp="urn:ietf:params:xml:ns:epp-1.0" | xmlns:epp="urn:ietf:params:xml:ns:epp-1.0" | |||
xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0" | xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0" | |||
xmlns:contact="urn:ietf:params:xml:ns:contact-1.0" | xmlns:contact="urn:ietf:params:xml:ns:contact-1.0" | |||
xmlns="http://www.w3.org/2001/XMLSchema" | xmlns="http://www.w3.org/2001/XMLSchema" | |||
elementFormDefault="qualified"> | elementFormDefault="qualified"> | |||
<annotation> | <annotation> | |||
<documentation> | <documentation> | |||
Extensible Provisioning Protocol v1.0 | Extensible Provisioning Protocol v1.0 | |||
Validate Object | Validate Object | |||
skipping to change at page 9, line 42 ¶ | skipping to change at page 11, line 25 ¶ | |||
<complexType name="checkType"> | <complexType name="checkType"> | |||
<sequence> | <sequence> | |||
<element name="contact" | <element name="contact" | |||
type="validate:validateContactType" | type="validate:validateContactType" | |||
maxOccurs="unbounded" /> | maxOccurs="unbounded" /> | |||
</sequence> | </sequence> | |||
</complexType> | </complexType> | |||
<complexType name="validateContactType"> | <complexType name="validateContactType"> | |||
<sequence> | <sequence> | |||
<element name="cd" | ||||
type="validate:checkDataType"/> | ||||
<element name="kv" | ||||
type="validate:kvType" minOccurs="0" | ||||
maxOccurs="unbounded" /> | ||||
</sequence> | ||||
<attribute name="contactType" type="eppcom:labelType" | ||||
use="required"/> | ||||
<attribute name="tld" | ||||
type="eppcom:labelType" use="required"/> | ||||
</complexType> | ||||
<complexType name="checkDataType"> | ||||
<sequence> | ||||
<element name="id" | <element name="id" | |||
type="eppcom:clIDType" /> | type="eppcom:clIDType" /> | |||
<element name="postalInfo" | <element name="postalInfo" | |||
type="contact:postalInfoType" | type="contact:postalInfoType" | |||
minOccurs="0" maxOccurs="2" /> | minOccurs="0" maxOccurs="2" /> | |||
<element name="voice" | <element name="voice" | |||
type="contact:e164Type" minOccurs="0" /> | type="contact:e164Type" minOccurs="0" /> | |||
<element name="fax" | <element name="fax" | |||
type="contact:e164Type" minOccurs="0" /> | type="contact:e164Type" minOccurs="0" /> | |||
<element name="email" | <element name="email" | |||
type="eppcom:minTokenType" minOccurs="0"/> | type="eppcom:minTokenType" minOccurs="0"/> | |||
<element name="authInfo" | <element name="authInfo" | |||
type="contact:authInfoType" | type="contact:authInfoType" | |||
minOccurs="0"/> | minOccurs="0"/> | |||
<element name="disclose" | <element name="kv" | |||
type="contact:discloseType" | type="validate:kvType" minOccurs="0" | |||
minOccurs="0" /> | maxOccurs="unbounded" /> | |||
</sequence> | </sequence> | |||
<attribute name="contactType" type="eppcom:labelType" | ||||
use="required"/> | ||||
<attribute name="tld" | ||||
type="eppcom:labelType" use="required"/> | ||||
</complexType> | </complexType> | |||
<complexType name="kvType"> | <complexType name="kvType"> | |||
<attribute name="contactType" | <attribute name="contactType" | |||
type="eppcom:labelType" use="optional" /> | type="eppcom:labelType" use="optional" /> | |||
<attribute name="key" | <attribute name="key" | |||
type="validate:keyType" use="required" /> | type="validate:keyType" use="required" /> | |||
<attribute name="value" | <attribute name="value" | |||
type="validate:valueType" use="required" /> | type="validate:valueType" use="required" /> | |||
</complexType> | </complexType> | |||
skipping to change at page 11, line 30 ¶ | skipping to change at page 13, line 7 ¶ | |||
type="validate:kvType" | type="validate:kvType" | |||
minOccurs="0" maxOccurs="unbounded" /> | minOccurs="0" maxOccurs="unbounded" /> | |||
</sequence> | </sequence> | |||
</complexType> | </complexType> | |||
</schema> | </schema> | |||
END | END | |||
5. Security Considerations | 5. Security Considerations | |||
The mapping extensions described in this document do not provide any | The mapping described in this document do not provide any security | |||
security services beyond those described by EPP [RFC5730] and | services beyond those described by EPP [RFC5730] and protocol layers | |||
protocol layers used by EPP. The security considerations described | used by EPP. The security considerations described in these other | |||
in these other specifications apply to this specification as well. | specifications apply to this specification as well. | |||
6. IANA Considerations | 6. IANA Considerations | |||
6.1. XML Namespace | 6.1. XML Namespace | |||
This document uses URNs to describe XML namespaces and XML schemas | This document uses URNs to describe XML namespaces and XML schemas | |||
conforming to a registry mechanism described in [RFC3688]. The | conforming to a registry mechanism described in [RFC3688]. | |||
following URI assignment is requested of IANA: | ||||
URI: ietf:params:xml:ns:validate-1.0 | Registration request for the validate namespace: | |||
Registrant Contact: See the "Author's Address" section of this | URI: urn:ietf:params:xml:ns:validate-1.0 | |||
document. | ||||
Registrant Contact: IESG | ||||
XML: None. Namespace URIs do not represent an XML specification. | ||||
Registration request for the validate schema: | ||||
URI: urn:ietf:params:xml:schema:validate-1.0 | ||||
Registrant Contact: IESG | ||||
XML: See the "Formal Syntax" section of this document. | XML: See the "Formal Syntax" section of this document. | |||
7. Implemntation Status | 7. Implemntation Status | |||
Note to RFC Editor: Please remove this section and the reference to | Note to RFC Editor: Please remove this section and the reference to | |||
[RFC6982] before publication. | [RFC7942] before publication. | |||
This section records the status of known implementations of the | This section records the status of known implementations of the | |||
protocol defined by this specification at the time of posting of this | protocol defined by this specification at the time of posting of this | |||
Internet-Draft, and is based on a proposal described in [RFC6982]. | Internet-Draft, and is based on a proposal described in [RFC7942]. | |||
The description of implementations in this section is intended to | The description of implementations in this section is intended to | |||
assist the IETF in its decision processes in progressing drafts to | assist the IETF in its decision processes in progressing drafts to | |||
RFCs. Please note that the listing of any individual implementation | RFCs. Please note that the listing of any individual implementation | |||
here does not imply endorsement by the IETF. Furthermore, no effort | here does not imply endorsement by the IETF. Furthermore, no effort | |||
has been spent to verify the information presented here that was | has been spent to verify the information presented here that was | |||
supplied by IETF contributors. This is not intended as, and must not | supplied by IETF contributors. This is not intended as, and must not | |||
be construed to be, a catalog of available implementations or their | be construed to be, a catalog of available implementations or their | |||
features. Readers are advised to note that other implementations may | features. Readers are advised to note that other implementations may | |||
exist. | exist. | |||
According to [RFC6982], "this will allow reviewers and working groups | According to [RFC7942], "this will allow reviewers and working groups | |||
to assign due consideration to documents that have the benefit of | to assign due consideration to documents that have the benefit of | |||
running code, which may serve as evidence of valuable experimentation | running code, which may serve as evidence of valuable experimentation | |||
and feedback that have made the implemented protocols more mature. | and feedback that have made the implemented protocols more mature. | |||
It is up to the individual working groups to use this information as | It is up to the individual working groups to use this information as | |||
they see fit". | they see fit". | |||
7.1. To Be Filled In | 7.1. To Be Filled In | |||
Add implementation details once available. | Add implementation details once available. | |||
skipping to change at page 12, line 45 ¶ | skipping to change at page 14, line 27 ¶ | |||
The authors wish to thank the following persons for their feedback | The authors wish to thank the following persons for their feedback | |||
and suggestions: | and suggestions: | |||
o Kevin Allendorf of GoDaddy Inc. | o Kevin Allendorf of GoDaddy Inc. | |||
o Jody Kolker of GoDaddy Inc. | o Jody Kolker of GoDaddy Inc. | |||
o James Gould of Verisign Inc | o James Gould of Verisign Inc | |||
9. Change History | 9. Change History | |||
9.1. Change from 02 to 03 | 9.1. Change from 03 to 04 | |||
Removed the <validate:cd> element from the <check> command, moving | ||||
all sub-elements to the <validate:contact> element to simplify. Also | ||||
removed the <disclose> element as it was not needed in this context. | ||||
Also updated references to current versions of documents. | ||||
9.2. Change from 02 to 03 | ||||
Corrected some formatting issues. | Corrected some formatting issues. | |||
9.2. Change from 01 to 02 | 9.3. Change from 01 to 02 | |||
Corrected some formatting issues. | Corrected some formatting issues. | |||
9.3. Change from 00 to 01 | 9.4. Change from 00 to 01 | |||
After review and broad feedback, extensive changes have been made | After review and broad feedback, extensive changes have been made | |||
transforming the original document from a standalone extension | transforming the original document from a standalone extension | |||
command to using the <check> command and response framework. Stubbed | command to using the <check> command and response framework. Stubbed | |||
in an Implementation section for later documentation. | in an Implementation section for later documentation. | |||
9.4. Change from carney-regext 01 to ietf-regext 00 | 9.5. Change from carney-regext 01 to ietf-regext 00 | |||
Updated miscellaneous verbiage to reflect the change from an | Updated miscellaneous verbiage to reflect the change from an | |||
extension and changed to ietf naming as REGEXT WG will assume this | extension and changed to ietf naming as REGEXT WG will assume this | |||
work. | work. | |||
10. Normative References | 10. Normative References | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, | [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, | |||
DOI 10.17487/RFC3688, January 2004, | DOI 10.17487/RFC3688, January 2004, | |||
<https://www.rfc-editor.org/info/rfc3688>. | <https://www.rfc-editor.org/info/rfc3688>. | |||
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", | [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", | |||
STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, | STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, | |||
<https://www.rfc-editor.org/info/rfc5730>. | <https://www.rfc-editor.org/info/rfc5730>. | |||
[RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) | ||||
Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733, | ||||
August 2009, <https://www.rfc-editor.org/info/rfc5733>. | ||||
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running | ||||
Code: The Implementation Status Section", BCP 205, | ||||
RFC 7942, DOI 10.17487/RFC7942, July 2016, | ||||
<https://www.rfc-editor.org/info/rfc7942>. | ||||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | ||||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | ||||
May 2017, <https://www.rfc-editor.org/info/rfc8174>. | ||||
Authors' Addresses | Authors' Addresses | |||
Roger Carney | Roger Carney | |||
GoDaddy Inc. | GoDaddy Inc. | |||
14455 N. Hayden Rd. #219 | 14455 N. Hayden Rd. #219 | |||
Scottsdale, AZ 85260 | Scottsdale, AZ 85260 | |||
US | US | |||
Email: rcarney@godaddy.com | Email: rcarney@godaddy.com | |||
URI: http://www.godaddy.com | URI: http://www.godaddy.com | |||
End of changes. 38 change blocks. | ||||
139 lines changed or deleted | 239 lines changed or added | |||
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |