diff options
Diffstat (limited to 'doc/rfc/rfc9095.txt')
| -rw-r--r-- | doc/rfc/rfc9095.txt | 1082 |
1 files changed, 1082 insertions, 0 deletions
diff --git a/doc/rfc/rfc9095.txt b/doc/rfc/rfc9095.txt new file mode 100644 index 0000000..ffcae46 --- /dev/null +++ b/doc/rfc/rfc9095.txt @@ -0,0 +1,1082 @@ + + + + +Independent Submission J. Yao +Request for Comments: 9095 L. Zhou +Category: Informational H. Li +ISSN: 2070-1721 CNNIC + N. Kong + Consultant + J. Xie + July 2021 + + +Extensible Provisioning Protocol (EPP) Domain Name Mapping Extension for + Strict Bundling Registration + +Abstract + + This document describes an extension of Extensible Provisioning + Protocol (EPP) domain name mapping for the provisioning and + management of strict bundling registration of domain names. + Specified in XML, this mapping extends the EPP domain name mapping to + provide additional features required for the provisioning of bundled + domain names. This is a nonstandard proprietary extension. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This is a contribution to the RFC Series, independently of any other + RFC stream. The RFC Editor has chosen to publish this document at + its discretion and makes no statement about its value for + implementation or deployment. Documents approved for publication by + the RFC Editor are not candidates for any level of Internet Standard; + see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9095. + +Copyright Notice + + Copyright (c) 2021 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. + +Table of Contents + + 1. Introduction + 2. Terminology + 3. Overview + 4. Requirement for Bundling Registration of Names + 5. Object Attributes + 5.1. RDN + 5.2. BDN + 6. EPP Command Mapping + 6.1. EPP Query Commands + 6.1.1. EPP <check> Command + 6.1.2. EPP <info> Command + 6.1.3. EPP <transfer> Query Command + 6.2. EPP Transform Commands + 6.2.1. EPP <create> Command + 6.2.2. EPP <delete> Command + 6.2.3. EPP <renew> Command + 6.2.4. EPP <transfer> Command + 6.2.5. EPP <update> Command + 7. Formal Syntax + 8. Internationalization Considerations + 9. IANA Considerations + 9.1. XML Namespace and XML Schema + 9.1.1. BDN Namespace + 9.1.2. BDN XML Schema + 9.2. EPP Extension + 10. Security Considerations + 11. References + 11.1. Normative References + 11.2. Informative References + Acknowledgements + Authors' Addresses + +1. Introduction + + In RFC 4290 [RFC4290], the "variant(s)" are character(s) and/or + string(s) that are treated as equivalent to the base character. In + this document, variants are those strings that are treated as + equivalent to each other according to the domain name registration + policy. Bundled domain names are those that share the same Top-Level + Domain (TLD) but whose second-level labels are variants or those that + have identical second-level labels for which certain parameters are + shared in different TLDs. For example, the Public Interest Registry + has requested to implement bundling of second-level domains for .NGO + and .ONG. So we have two kinds of bundled domain names. The first + one is in the form of "V-label.TLD", in which the second-level label + (V-label) is a variant sharing the same TLD. The second one is in + the form of "LABEL.V-tld", in which the second-level label (LABEL) + remains the same but ends with a different TLD (V-tld) and these + different V-tlds are managed by the same entity. + + Bundled domain names normally share some attributes. Policy-wise + bundling can be implemented in three ways. The first one is strict + bundling, which requires all bundled names to share many of the same + attributes. When creating, updating, or transferring any of the + bundled domain names, all bundled domain names will be created, + updated, or transferred atomically. The second one is partial + bundling, which requires the bundled domain names to be registered by + the same registrant. The third one is relaxed bundling, which has no + specific requirements on the domain registration. This document + mainly addresses the strict bundling name registration. + + For the name variants, different registries have different policies. + Some registries adopt the policy that variant Internationalized + Domain Names (IDNs) should be blocked. But some registries adopt the + policy that variant IDNs that are identified as equivalent are + allocated or delegated to the same registrant. For example, most + registries offering a Chinese Domain Name (CDN) adopt a registration + policy whereby a registrant can apply for an original CDN in any + form: Simplified Chinese (SC) form, Traditional Chinese (TC) form, or + other variant forms. The corresponding variant CDN in SC form and in + TC form will also be delegated to the same registrant. All variant + names in the same TLD share a common set of attributes. This + document mainly discusses the situation in which variant IDNs that + are identified as equivalent are allocated or delegated to the same + registrant. + + The basic Extensible Provisioning Protocol (EPP) domain name mapping + [RFC5731] provides the facility for single domain name registration. + It does not specify how to register the strict bundled names that + share many of the attributes. + + In order to meet the above requirements of strict bundled name + registration, this document describes an extension of the EPP domain + name mapping [RFC5731] for the provisioning and management of bundled + names. This document describes a nonstandard proprietary extension. + This extension is especially useful for registries performing Chinese + Domain Name registration. This method is also useful for other + language domain names that have similar issues with Chinese Domain + Names. This document is specified using Extensible Markup Language + (XML) 1.0 as described in [W3C.REC-xml-20040204] and XML Schema + notation as described in [W3C.REC-xmlschema-1-20041028] and + [W3C.REC-xmlschema-2-20041028]. + + The EPP core protocol specification [RFC5730] provides a complete + description of EPP command and response structures. A thorough + understanding of the base protocol specification is necessary to + understand the extension mapping described in this document. + + This document uses many IDN concepts, so a thorough understanding of + the IDNs for Application (IDNA, described in [RFC5890], [RFC5891], + and [RFC5892]) and the variant approach discussed in [RFC4290] is + assumed. + +2. Terminology + + Variants in this document are those strings that are treated as + equivalent to each other according to the domain name registration + policy for certain TLDs. + + Bundled domain names are bundled together according to the domain + name registration policy. For example, many Chinese Domain Name + registries follow the principle described in RFC 3743 [RFC3743]. + Bundled domain names should belong to the same owner. If bundled + domain names are under different TLDs, those TLDs should be managed + by the same entity. + + The terms "registered domain name" (RDN) and "bundled domain name" + (BDN) are used in this document. RDN represents the valid domain + name that registrants submitted for the initial registration. BDN + represents the bundled domain name produced according to the bundled + domain name registration policy. In current practice, the number of + BDNs is usually kept at one according to the registration policy set + by the registry. Both the RDN and BDN specified in this document + will be registered via EPP. All other domain names related to the + RDN will be blocked. + + The "uLabel" attribute in this document is used to express the + U-label of an Internationalized Domain Name as a series of characters + where non-ASCII characters will be represented in the format of + "&#xXXXX;" where XXXX is a Unicode point by using the XML escaping + mechanism. The U-label is defined in [RFC5890]. This document + chooses this format of literal HTML ampersand codes, not the expected + Unicode character codes. Unicode characters may not be displayed + correctly in some text file readers, while HTML numeric character + references are easy for HTML processors. The implementation + following this document should use Unicode characters directly. + + This document uses the prefix "b-dn" for the namespace + "urn:ietf:params:xml:ns:epp:b-dn" throughout. Implementations cannot + assume that any particular prefix is used and must employ a + namespace-aware XML parser and serializer to interpret and output the + XML documents. + + In the examples, "C:" represents lines sent by a protocol client, and + "S:" represents lines returned by a protocol server. Indentation and + spacing in the examples are provided only to illustrate element + relationships and are not a required feature of this specification. + + XML is case sensitive. Unless stated otherwise, the XML + specifications and examples provided in this document must be + interpreted in the character case presented to develop a conforming + implementation. + +3. Overview + + Domain registries have usually adopted a registration model whereby + metadata relating to a domain name, such as its expiration date and + sponsoring registrar, are stored as properties of the domain object. + The domain object is then considered an atomic unit of registration + on which operations such as update, renewal, and deletion may be + performed. + + Bundled names brought about the need for multiple domain names to be + registered and managed as a single package. In this model, the + registry typically accepts a domain registration request (i.e., EPP + domain <create> command) containing the domain name to be registered. + This domain name is referred to as the RDN in this document. As part + of the processing of the registration request, the registry generates + a set of bundled names that are related to the RDN, either + programmatically or with the guidance of registration policies, and + places them in the registration package together with the RDN. + + The bundled names share many properties, such as expiration date and + sponsoring registrar, by sharing the same domain object. So when + registrants update any property of a domain object within a bundle + package, that property will be updated at the same time for all other + domain objects in the bundle package. + +4. Requirement for Bundling Registration of Names + + The bundled names, whether they are in the form of "V-label.TLD" or + "LABEL.V-tld", should share some parameters or attributes associated + with domain names. Typically, bundled names will share the following + parameters or attributes: + + * Registrar ownership + + * Registration and expiry dates + + * Registrant, admin, billing, and technical contacts + + * Name server association + + * Domain status + + * Applicable grace periods (add grace period, renew grace period, + auto-renew grace period, transfer grace period, and redemption + grace period) [RFC3915] + + Because the domain names are bundled and share the same parameters or + attributes, the EPP command should do some processing for these + requirements: + + * When performing a domain <check> command, either the BDN or RDN + can be queried with the EPP command and will return the same + response. + + * When performing a domain <info> command, either the BDN or RDN can + be queried, and the same response will include both BDN and RDN + information with the same attributes. + + * When performing a domain <create> command, if the domain name is + available, both the BDN and RDN will be registered. + + * When performing a domain <delete> command, either the BDN or RDN + will be accepted. If the domain name is registered, both the BDN + and RDN will be deleted. + + * When performing a domain <renew> command, either the BDN or RDN + will be accepted. Upon a successful domain renewal, both the BDN + and RDN will have their expiry date extended by the requested + term. Upon a successful domain renewal, both the BDN and RDN will + conform to the same renew grace period. + + * When performing a domain <transfer> command, either the BDN or RDN + will be accepted. Upon successful completion of a domain transfer + request, both the BDN and RDN will enter a pendingTransfer status. + Upon approval of the transfer request, both the BDN and RDN will + be owned and managed by the same new registrant. + + * When performing a domain <update> command, either the BDN or RDN + will be accepted. Any modifications to contact associations, name + server associations, domain status values, and authorization + information will be applied to both the BDN and RDN. + +5. Object Attributes + + This extension defines the following additional elements to the EPP + domain name mapping [RFC5731]. All of these additional elements are + returned from the <domain:info> command. + +5.1. RDN + + The RDN is an ASCII name or an IDN with the A-label [RFC5890] form. + In this document, its corresponding element is <b-dn:rdn>. An + optional attribute "uLabel" associated with <b-dn:rdn> is used to + represent the U-label [RFC5890] form. + + For example: + + <b-dn:rdn uLabel="实例.example"> xn-- + fsq270a.example</b-dn:rdn> + +5.2. BDN + + The BDN is an ASCII name or an IDN with the A-label [RFC5890] form + that is converted from the corresponding BDN. In this document, its + corresponding element is <b-dn:bdn>. An optional attribute "uLabel" + associated with <b-dn:bdn> is used to represent the U-label [RFC5890] + form. + + For example: + + <b-dn:bdn uLabel="實例.example"> xn-- + fsqz41a.example</b-dn:bdn> + +6. EPP Command Mapping + + A detailed description of the EPP syntax and semantics can be found + in the EPP core protocol specification [RFC5730]. The command + mappings described here are specifically for use in provisioning and + managing bundled names via EPP. + +6.1. EPP Query Commands + + EPP provides three commands to retrieve domain information: <check> + to determine if a domain object can be provisioned within a + repository, <info> to retrieve detailed information associated with a + domain object, and <transfer> to retrieve domain-object transfer + status information. + +6.1.1. EPP <check> Command + + This extension does not add any element to the EPP <check> command or + <check> response described in the EPP domain name mapping [RFC5731]. + However, when either the RDN or BDN is sent for a check, the response + should contain both RDN and BDN information, which may also give some + explanation in the reason field to tell the registrant that the + associated domain name is a produced name according to some bundle + domain name policy. + + S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> + S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> + S: <response> + S: <result code="1000"> + S: <msg>Command completed successfully</msg> + S: </result> + S: <resData> + S: <domain:chkData + S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> + S: <domain:cd> + S: <domain:name avail="1"> + S: xn--fsq270a.example</domain:name> + S: </domain:cd> + S: <domain:cd> + S: <domain:name avail="1"> + S: xn--fsqz41a.example + S: </domain:name> + S: <domain:reason>This associated domain name is + S: a produced name based on bundle name policy. + S: </domain:reason> + S: </domain:cd> + S: </domain:chkData> + S: </resData> + S: <trID> + S: <clTRID>ABC-12345</clTRID> + S: <svTRID>54322-XYZ</svTRID> + S: </trID> + S: </response> + S:</epp> + + Figure 1: Example <check> Response + +6.1.2. EPP <info> Command + + This extension does not add any element to the EPP <info> command + described in the EPP domain mapping [RFC5731]. However, additional + elements are defined for the <info> response. + + When an <info> command has been processed successfully, the EPP + <resData> element must contain child elements as described in the EPP + domain mapping [RFC5731]. In addition, unless some registration + policy has some special processing, the EPP <extension> element + should contain a child <b-dn:infData> element that identifies the + extension namespace if the domain object has data associated with + this extension and based on its registration policy. The + <b-dn:infData> element contains the <b-dn:bundle>, which has the + following child elements: + + * A <b-dn:rdn> element that contains the RDN, along with the + attribute described below. + + * An optional <b-dn:bdn> element that contains the BDN, along with + the attribute described below. + + The above elements contain the following attribute: + + * An optional "uLabel" attribute represents the U-label of the + element. + + S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> + S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> + S: <response> + S: <result code="1000"> + S: <msg>Command completed successfully</msg> + S: </result> + S: <resData> + S: <domain:infData + S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> + S: <domain:name>xn--fsq270a.example</domain:name> + S: <domain:roid>58812678-domain</domain:roid> + S: <domain:status s="ok"/> + S: <domain:registrant>123</domain:registrant> + S: <domain:contact type="admin">123</domain:contact> + S: <domain:contact type="tech">123</domain:contact> + S: <domain:ns> + S: <domain:hostObj>ns1.example.cn + S: </domain:hostObj> + S: </domain:ns> + S: <domain:clID>ClientX</domain:clID> + S: <domain:crID>ClientY</domain:crID> + S: <domain:crDate>2019-04-03T22:00:00.0Z + S: </domain:crDate> + S: <domain:exDate>2022-04-03T22:00:00.0Z + S: </domain:exDate> + S: <domain:authInfo> + S: <domain:pw>2fooBAR</domain:pw> + S: </domain:authInfo> + S: </domain:infData> + S: </resData> + S: <extension> + S: <b-dn:infData + S: xmlns:b-dn="urn:ietf:params:xml:ns:epp:b-dn"> + S: <b-dn:bundle> + S: <b-dn:rdn uLabel="实例.example"> + S: xn--fsq270a.example + S: </b-dn:rdn> + S: <b-dn:bdn uLabel="實例.example"> + S: xn--fsqz41a.example + S: </b-dn:bdn> + S: </b-dn:bundle> + S: </b-dn:infData> + S: </extension> + S: <trID> + S: <clTRID>ABC-12345</clTRID> + S: <svTRID>54322-XYZ</svTRID> + S: </trID> + S: </response> + S:</epp> + + Figure 2: Example <info> Response for an Authorized Client + + The <info> response for the unauthorized client has not been changed, + see [RFC5731] for details. + + An EPP error response must be returned if an <info> command cannot be + processed for any reason. + +6.1.3. EPP <transfer> Query Command + + This extension does not add any element to the EPP <transfer> command + or <transfer> response described in the EPP domain mapping [RFC5731]. + +6.2. EPP Transform Commands + + EPP provides five commands to transform domain objects: <create> to + create an instance of a domain object, <delete> to delete an instance + of a domain object, <renew> to extend the validity period of a domain + object, <transfer> to manage domain object sponsorship changes, and + <update> to change information associated with a domain object. + + When these commands have been processed successfully, the EPP + <resData> element must contain child elements as described in the EPP + domain mapping [RFC5731]. Unless some registration policy has some + special processing, this EPP <extension> element should contain the + <b-dn:bundle>, which has the following child elements: + + * A <b-dn:rdn> element that contains the RDN, along with the + attribute described below. + + * An optional <b-dn:bdn> element that contains the BDN, along with + the attribute described below. + + The above elements contain the following attribute: + + * An optional "uLabel" attribute represents the U-label of the + element. + +6.2.1. EPP <create> Command + + This extension defines additional elements to extend the EPP <create> + command described in the EPP domain name mapping [RFC5731] for + bundled names registration. + + In addition to the EPP command elements described in the EPP domain + mapping [RFC5731], the <create> command shall contain an <extension> + element. Unless some registration policy has some special + processing, the <extension> element should contain a child + <b-dn:create> element that identifies the bundle namespace and a + child <b-dn:rdn> element that identifies the U-label form of the + registered domain name with the "uLabel" attribute. The U-label is + used for easy reading by the registrants and easy debugging by the + registrars and the registries. + + C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> + C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> + C: <command> + C: <create> + C: <domain:create + C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> + C: <domain:name>xn--fsq270a.example</domain:name> + C: <domain:period unit="y">2</domain:period> + C: <domain:registrant>123</domain:registrant> + C: <domain:contact type="admin">123</domain:contact> + C: <domain:contact type="tech">123</domain:contact> + C: <domain:authInfo> + C: <domain:pw>2fooBAR</domain:pw> + C: </domain:authInfo> + C: </domain:create> + C: </create> + C: <extension> + C: <b-dn:create + C: xmlns:b-dn="urn:ietf:params:xml:ns:epp:b-dn"> + C: <b-dn:rdn uLabel="实例.example"> + C: xn--fsq270a.example + C: </b-dn:rdn> + C: </b-dn:create> + C: </extension> + C: <clTRID>ABC-12345</clTRID> + C: </command> + C:</epp> + + Figure 3: Example <create> Command + + When a <create> command has been processed successfully, the EPP + <creData> element must contain child elements as described in the EPP + domain mapping [RFC5731]. In addition, unless some registration + policy has some special processing, the EPP <extension> element + should contain a child <b-dn:creData> element that identifies the + extension namespace if the domain object has data associated with + this extension and based on its registration policy. The + <b-dn:creData> element contains the <b-dn:bundle> element. + + S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> + S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> + S: <response> + S: <result code="1000"> + S: <msg>Command completed successfully</msg> + S: </result> + S: <resData> + S: <domain:creData + S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> + S: <domain:name>xn--fsq270a.example</domain:name> + S: <domain:crDate>2019-04-03T22:00:00.0Z</domain:crDate> + S: <domain:exDate>2021-04-03T22:00:00.0Z</domain:exDate> + S: </domain:creData> + S: </resData> + S: <extension> + S: <b-dn:creData + S: xmlns:b-dn="urn:ietf:params:xml:ns:epp:b-dn"> + S: <b-dn:bundle> + S: <b-dn:rdn uLabel="实例.example"> + S: xn--fsq270a.example + S: </b-dn:rdn> + S: <b-dn:bdn uLabel="實例.example" > + S: xn--fsqz41a.example + S: </b-dn:bdn> + S: </b-dn:bundle> + S: </b-dn:creData> + S: </extension> + S: <trID> + S: <clTRID>ABC-12345</clTRID> + S: <svTRID>54322-XYZ</svTRID> + S: </trID> + S: </response> + S:</epp> + + Figure 4: Example <create> Response + + An EPP error response must be returned if a <create> command cannot + be processed for any reason. + +6.2.2. EPP <delete> Command + + This extension does not add any element to the EPP <delete> command + described in the EPP domain mapping [RFC5731]. However, additional + elements are defined for the <delete> response. + + When a <delete> command has been processed successfully, the EPP + <delData> element must contain child elements as described in the EPP + domain mapping [RFC5731]. In addition, unless some registration + policy has some special processing, the EPP <extension> element + should contain a child <b-dn:delData> element that identifies the + extension namespace if the domain object has data associated with + this extension and based on its registration policy. The + <b-dn:delData> element should contain the <b-dn:bundle> element. + + S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> + S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> + S: <response> + S: <result code="1000"> + S: <msg>Command completed successfully</msg> + S: </result> + S: <extension> + S: <b-dn:delData + S: xmlns:b-dn="urn:ietf:params:xml:ns:epp:b-dn"> + S: <b-dn:bundle> + S: <b-dn:rdn uLabel="实例.example"> + S: xn--fsq270a.example + S: </b-dn:rdn> + S: <b-dn:bdn uLabel="實例.example"> + S: xn--fsqz41a.example + S: </b-dn:bdn> + S: </b-dn:bundle> + S: </b-dn:delData> + S: </extension> + S: <trID> + S: <clTRID>ABC-12345</clTRID> + S: <svTRID>54321-XYZ</svTRID> + S: </trID> + S: </response> + S:</epp> + + Figure 5: Example <delete> Response + + An EPP error response must be returned if a <delete> command cannot + be processed for any reason. + +6.2.3. EPP <renew> Command + + This extension does not add any element to the EPP <renew> command + described in the EPP domain name mapping [RFC5731]. However, when + either the RDN or BDN is sent for renewal, the response should + contain both RDN and BDN information. When the command has been + processed successfully, the EPP <extension> element shall be + contained in the response if the domain object has data associated + with bundled names. Unless some registration policy has some special + processing, this EPP <extension> element should contain the + <b-dn:renData>, which contains the <b-dn:bundle> element. + + S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> + S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> + S: <response> + S: <result code="1000"> + S: <msg>Command completed successfully</msg> + S: </result> + S: <resData> + S: <domain:renData + S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> + S: <domain:name>xn--fsq270a.example</domain:name> + S: <domain:exDate>2022-04-03T22:00:00.0Z</domain:exDate> + S: </domain:renData> + S: </resData> + S: <extension> + S: <b-dn:renData + S: xmlns:b-dn="urn:ietf:params:xml:ns:epp:b-dn"> + S: <b-dn:bundle> + S: <b-dn:rdn uLabel="实例.example"> + S: xn--fsq270a.example + S: </b-dn:rdn> + S: <b-dn:bdn uLabel="實例.example" > + S: xn--fsqz41a.example + S: </b-dn:bdn> + S: </b-dn:bundle> + S: </b-dn:renData> + S: </extension> + S: <trID> + S: <clTRID>ABC-12345</clTRID> + S: <svTRID>54322-XYZ</svTRID> + S: </trID> + S: </response> + S:</epp> + + Figure 6: Example <renew> Response + +6.2.4. EPP <transfer> Command + + This extension does not add any element to the EPP <transfer> command + described in the EPP domain name mapping [RFC5731]. However, + additional elements are defined for the <transfer> response in the + EPP object mapping. When the command has been processed + successfully, the EPP <extension> element shall be contained in the + response if the domain object has data associated with bundled names. + Unless some registration policy has some special processing, this EPP + <extension> element should contain the <b-dn:trnData>, which contains + the <b-dn:bundle> element. + + S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> + S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> + S: <response> + S: <result code="1001"> + S: <msg>Command completed successfully; action pending</msg> + S: </result> + S: <resData> + S: <domain:trnData + S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> + S: <domain:name>xn--fsq270a.example</domain:name> + S: <domain:trStatus>pending</domain:trStatus> + S: <domain:reID>ClientX</domain:reID> + S: <domain:reDate>2021-04-03T22:00:00.0Z</domain:reDate> + S: <domain:acID>ClientY</domain:acID> + S: <domain:acDate>2021-04-08T22:00:00.0Z</domain:acDate> + S: <domain:exDate>2022-04-03T22:00:00.0Z</domain:exDate> + S: </domain:trnData> + S: </resData> + S: <extension> + S: <b-dn:trnData + S: xmlns:b-dn="urn:ietf:params:xml:ns:epp:b-dn"> + S: <b-dn:bundle> + S: <b-dn:rdn uLabel="实例.example"> + S: xn--fsq270a.example + S: </b-dn:rdn> + S: <b-dn:bdn uLabel="實例.example"> + S: xn--fsqz41a.example + S: </b-dn:bdn> + S: </b-dn:bundle> + S: </b-dn:trnData> + S: </extension> + S: <trID> + S: <clTRID>ABC-12345</clTRID> + S: <svTRID>54322-XYZ</svTRID> + S: </trID> + S: </response> + S:</epp> + + Figure 7: Example <transfer> Response + +6.2.5. EPP <update> Command + + This extension does not add any element to the EPP <update> command + described in the EPP domain name mapping [RFC5731]. However, + additional elements are defined for the <update> response in the EPP + object mapping. When the command has been processed successfully, + the EPP <extension> element shall be contained in the response if the + domain object has data associated with bundled names. Unless some + registration policy has some special processing, this EPP <extension> + element should contain the <b-dn:upData>, which contains the + <b-dn:bundle> element. + + S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> + S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> + S: <response> + S: <result code="1000"> + S: <msg>Command completed successfully</msg> + S: </result> + S: <extension> + S: <b-dn:upData + S: xmlns:b-dn="urn:ietf:params:xml:ns:epp:b-dn"> + S: <b-dn:bundle> + S: <b-dn:rdn uLabel="实例.example" > + S: xn--fsq270a.example + S: </b-dn:rdn> + S: <b-dn:bdn uLabel="實例.example"> + S: xn--fsqz41a.example + S: </b-dn:bdn> + S: </b-dn:bundle> + S: </b-dn:upData> + S: </extension> + S: <trID> + S: <clTRID>ABC-12345</clTRID> + S: <svTRID>54322-XYZ</svTRID> + S: </trID> + S: </response> + S:</epp> + + Figure 8: Example <update> Response + +7. Formal Syntax + + An EPP object name mapping extension for bundled names is specified + in XML Schema notation. The formal syntax presented here is a + complete schema representation of the object mapping suitable for + automated validation of EPP XML 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 registration purposes. + + <CODE BEGINS> + <?xml version="1.0" encoding="UTF-8"?> + + <schema targetNamespace="urn:ietf:params:xml:ns:epp:b-dn" + xmlns:b-dn="urn:ietf:params:xml:ns:epp:b-dn" + xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0" + xmlns="http://www.w3.org/2001/XMLSchema" + elementFormDefault="qualified"> + + <!-- + Import common element types. + --> + <import namespace="urn:iana:xml:ns:eppcom-1.0"/> + + <annotation> + <documentation> + Extensible Provisioning Protocol v1.0 + Bundle Domain Extension Schema v1.0 + </documentation> + </annotation> + + <!-- + Child elements found in EPP commands. + --> + <element name="create" type="b-dn:createDataType"/> + + <!-- + Child elements of the <b-dn:create> command. + All elements must be present at time of creation + --> + <complexType name="createDataType"> + <sequence> + <element name="rdn" type="b-dn:rdnType" + minOccurs="0"/> + </sequence> + </complexType> + + <!-- + Child response elements in <b-dn:infData>, <b-dn:delData>, + <b-dn:creData>, <b-dn:renData>, <b-dn:trnData> and <b-dn:upData>. + --> + <element name="infData" type="b-dn:bundleDataType"/> + <element name="delData" type="b-dn:bundleDataType"/> + <element name="creData" type="b-dn:bundleDataType"/> + <element name="renData" type="b-dn:bundleDataType"/> + <element name="trnData" type="b-dn:bundleDataType"/> + <element name="upData" type="b-dn:bundleDataType"/> + + <complexType name="bundleDataType"> + <sequence> + <element name="bundle" type="b-dn:bundleType" /> + </sequence> + </complexType> + + <complexType name="bundleType"> + <sequence> + <element name="rdn" type="b-dn:rdnType" /> + <element name="bdn" type="b-dn:rdnType" + minOccurs="0" maxOccurs="unbounded" /> + </sequence> + </complexType> + + <complexType name="rdnType"> + <simpleContent> + <extension base="eppcom:labelType"> + <attribute name="uLabel" type="eppcom:labelType"/> + </extension> + </simpleContent> + </complexType> + + <!-- + End of schema. + --> + </schema> + <CODE ENDS> + +8. Internationalization Considerations + + EPP is represented in XML, which provides support for encoding + information using the Unicode character set and its more compact + representations, including UTF-8. Conformant XML processors + recognize both UTF-8 and UTF-16. Though XML includes provisions to + identify and use other character encodings through use of an + "encoding" attribute in an <?xml?> declaration, use of UTF-8 is + recommended. + + As an extension of the EPP domain name mapping, the elements and + element content described in this document must inherit the + internationalization conventions used to represent higher-layer + domain and core protocol structures present in an XML instance that + includes this extension. + +9. IANA Considerations + +9.1. XML Namespace and XML Schema + + This document uses URNs to describe XML namespaces and XML schemas + conforming to a registry mechanism described in [RFC3688]. + +9.1.1. BDN Namespace + + IANA has assigned the following for the BDN namespace in the "ns" + subregistry of the "IETF XML Registry", with this document as the + reference: + + URI: urn:ietf:params:xml:ns:epp:b-dn + Registrant Contact: See the "Authors' Addresses" section of this + document. + XML: None. The namespace URI does not represent an XML + specification. + +9.1.2. BDN XML Schema + + IANA has made the following assignment in the "schema" subregistry of + the "IETF XML Registry" for the BDN XML schema, with this document as + the reference: + + URI: urn:ietf:params:xml:schema:epp:b-dn + Registrant Contact: See the "Authors' Addresses" section of this + document. + XML: See the "Formal Syntax" section of this document. + +9.2. EPP Extension + + IANA has registered the EPP extension described in this document in + the "Extensions for the Extensible Provisioning Protocol (EPP)" + registry described in [RFC7451]. The details of the registration are + as follows: + + Name of Extension: "Domain Name Mapping Extension for Strict + Bundling Registration" + Document Status: Informational + Reference: This document + Registrant Name and Email Address: See the "Authors' Addresses" + section of this document. + TLDs: Any + IPR Disclosure: https://datatracker.ietf.org/ipr/2479 + Status: Active + Notes: None + +10. Security Considerations + + Normally, the EPP server will only be connected by the authorized EPP + client, which knows whether the EPP server supports the extension + described in this document via out-of-band service. The EPP client + should avoid sending this extension to the unimplemented EPP server. + In case a client that supports this document sends a request to a + server that does not support this document, the server will return + the result code 2103 according to Section 3 of [RFC5730]. Section 3 + of [RFC5730] has the following information for result code 2103. + + | 2103 "Unimplemented extension" + | + | This response code MUST be returned when a server receives a valid + | EPP command element that contains a protocol command extension + | that is not implemented by the server. + + Some registries and registrars have more than 15 years' experience + with the bundled registration of domain names (especially Chinese + Domain Names). They have not found any significant security issues. + One principle that the registry and registrar should let the + registrants know is that bundled registered domain names will be + created, transferred, updated, and deleted together as a group. The + registrants for bundled domain names should remember this principle + when performing operations to these domain names. [RFC5730] also + introduces some security consideration. + + This document does not take a position regarding whether or not the + bundled domain names share a key for Delegation Signer (DS) and/or + DNS Public Key (DNSKEY) resource records. The DNS administrator can + choose whether DS/DNSKEY information can be shared or not. If a DS/ + DNSKEY key is shared, then the bundled domain names share fate if + there is a key compromise. + +11. References + +11.1. Normative References + + [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, + DOI 10.17487/RFC3688, January 2004, + <https://www.rfc-editor.org/info/rfc3688>. + + [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", + STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, + <https://www.rfc-editor.org/info/rfc5730>. + + [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) + Domain Name Mapping", STD 69, RFC 5731, + DOI 10.17487/RFC5731, August 2009, + <https://www.rfc-editor.org/info/rfc5731>. + + [RFC5890] Klensin, J., "Internationalized Domain Names for + Applications (IDNA): Definitions and Document Framework", + RFC 5890, DOI 10.17487/RFC5890, August 2010, + <https://www.rfc-editor.org/info/rfc5890>. + + [RFC5891] Klensin, J., "Internationalized Domain Names in + Applications (IDNA): Protocol", RFC 5891, + DOI 10.17487/RFC5891, August 2010, + <https://www.rfc-editor.org/info/rfc5891>. + + [RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and + Internationalized Domain Names for Applications (IDNA)", + RFC 5892, DOI 10.17487/RFC5892, August 2010, + <https://www.rfc-editor.org/info/rfc5892>. + + [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible + Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, + February 2015, <https://www.rfc-editor.org/info/rfc7451>. + + [W3C.REC-xml-20040204] + Bray, T., Paoli, J., Sperberg-McQueen, C.M., Maler, E., + and F. Yergeau, "Extensible Markup Language (XML) 1.0 + (Third Edition)", W3C Recommendation REC-xml-20040204, + February 2004, + <http://www.w3.org/TR/2004/REC-xml-20040204>. + + [W3C.REC-xmlschema-1-20041028] + Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, + "XML Schema Part 1: Structures Second Edition", W3C + Recommendation REC-xmlschema-1-20041028, October 2004, + <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>. + + [W3C.REC-xmlschema-2-20041028] + Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes + Second Edition", W3C Recommendation REC-xmlschema- + 2-20041028, October 2004, + <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>. + +11.2. Informative References + + [RFC3743] Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint + Engineering Team (JET) Guidelines for Internationalized + Domain Names (IDN) Registration and Administration for + Chinese, Japanese, and Korean", RFC 3743, + DOI 10.17487/RFC3743, April 2004, + <https://www.rfc-editor.org/info/rfc3743>. + + [RFC3915] Hollenbeck, S., "Domain Registry Grace Period Mapping for + the Extensible Provisioning Protocol (EPP)", RFC 3915, + DOI 10.17487/RFC3915, September 2004, + <https://www.rfc-editor.org/info/rfc3915>. + + [RFC4290] Klensin, J., "Suggested Practices for Registration of + Internationalized Domain Names (IDN)", RFC 4290, + DOI 10.17487/RFC4290, December 2005, + <https://www.rfc-editor.org/info/rfc4290>. + +Acknowledgements + + The authors especially thank the authors of [RFC5730] and [RFC5731] + and the following members of the China Internet Network Information + Center (CNNIC): Weiping Yang, Chao Qi. + + Useful comments were made by John Klensin, Scott Hollenbeck, Patrick + Mevzek, Edward Lewis, Wil Tan, and Adrian Farrel. + +Authors' Addresses + + Jiankang Yao + CNNIC + 4 South 4th Street, Zhongguancun, Haidian District + Beijing + Beijing, 100190 + China + + Phone: +86 10 5881 3007 + Email: yaojk@cnnic.cn + + + Linlin Zhou + CNNIC + 4 South 4th Street, Zhongguancun, Haidian District + Beijing + Beijing, 100190 + China + + Phone: +86 10 5881 2677 + Email: zhoulinlin@cnnic.cn + + + Hongtao Li + CNNIC + 4 South 4th Street, Zhongguancun, Haidian District + Beijing + Beijing, 100190 + China + + Email: lihongtao@cnnic.cn + + + Ning Kong + Consultant + + Email: ietfing@gmail.com + + + Jiagui Xie + + Email: jiagui1984@163.com |