From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc9095.txt | 1082 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1082 insertions(+) create mode 100644 doc/rfc/rfc9095.txt (limited to 'doc/rfc/rfc9095.txt') 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 Command + 6.1.2. EPP Command + 6.1.3. EPP Query Command + 6.2. EPP Transform Commands + 6.2.1. EPP Command + 6.2.2. EPP Command + 6.2.3. EPP Command + 6.2.4. EPP Command + 6.2.5. EPP 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 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 command, either the BDN or RDN + can be queried with the EPP command and will return the same + response. + + * When performing a domain 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 command, if the domain name is + available, both the BDN and RDN will be registered. + + * When performing a domain 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 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 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 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 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 . An + optional attribute "uLabel" associated with is used to + represent the U-label [RFC5890] form. + + For example: + + xn-- + fsq270a.example + +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 . An optional attribute "uLabel" + associated with is used to represent the U-label [RFC5890] + form. + + For example: + + xn-- + fsqz41a.example + +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: + to determine if a domain object can be provisioned within a + repository, to retrieve detailed information associated with a + domain object, and to retrieve domain-object transfer + status information. + +6.1.1. EPP Command + + This extension does not add any element to the EPP command or + 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: + S: + S: + S: + S: Command completed successfully + S: + S: + S: + S: + S: + S: xn--fsq270a.example + S: + S: + S: + S: xn--fsqz41a.example + S: + S: This associated domain name is + S: a produced name based on bundle name policy. + S: + S: + S: + S: + S: + S: ABC-12345 + S: 54322-XYZ + S: + S: + S: + + Figure 1: Example Response + +6.1.2. EPP Command + + This extension does not add any element to the EPP command + described in the EPP domain mapping [RFC5731]. However, additional + elements are defined for the response. + + When an command has been processed successfully, the EPP + 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 element + should contain a child element that identifies the + extension namespace if the domain object has data associated with + this extension and based on its registration policy. The + element contains the , which has the + following child elements: + + * A element that contains the RDN, along with the + attribute described below. + + * An optional 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: + S: + S: + S: + S: Command completed successfully + S: + S: + S: + S: xn--fsq270a.example + S: 58812678-domain + S: + S: 123 + S: 123 + S: 123 + S: + S: ns1.example.cn + S: + S: + S: ClientX + S: ClientY + S: 2019-04-03T22:00:00.0Z + S: + S: 2022-04-03T22:00:00.0Z + S: + S: + S: 2fooBAR + S: + S: + S: + S: + S: + S: + S: + S: xn--fsq270a.example + S: + S: + S: xn--fsqz41a.example + S: + S: + S: + S: + S: + S: ABC-12345 + S: 54322-XYZ + S: + S: + S: + + Figure 2: Example Response for an Authorized Client + + The response for the unauthorized client has not been changed, + see [RFC5731] for details. + + An EPP error response must be returned if an command cannot be + processed for any reason. + +6.1.3. EPP Query Command + + This extension does not add any element to the EPP command + or response described in the EPP domain mapping [RFC5731]. + +6.2. EPP Transform Commands + + EPP provides five commands to transform domain objects: to + create an instance of a domain object, to delete an instance + of a domain object, to extend the validity period of a domain + object, to manage domain object sponsorship changes, and + to change information associated with a domain object. + + When these commands have been processed successfully, the EPP + element must contain child elements as described in the EPP + domain mapping [RFC5731]. Unless some registration policy has some + special processing, this EPP element should contain the + , which has the following child elements: + + * A element that contains the RDN, along with the + attribute described below. + + * An optional 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 Command + + This extension defines additional elements to extend the EPP + 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 command shall contain an + element. Unless some registration policy has some special + processing, the element should contain a child + element that identifies the bundle namespace and a + child 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: + C: + C: + C: + C: + C: xn--fsq270a.example + C: 2 + C: 123 + C: 123 + C: 123 + C: + C: 2fooBAR + C: + C: + C: + C: + C: + C: + C: xn--fsq270a.example + C: + C: + C: + C: ABC-12345 + C: + C: + + Figure 3: Example Command + + When a command has been processed successfully, the EPP + 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 element + should contain a child element that identifies the + extension namespace if the domain object has data associated with + this extension and based on its registration policy. The + element contains the element. + + S: + S: + S: + S: + S: Command completed successfully + S: + S: + S: + S: xn--fsq270a.example + S: 2019-04-03T22:00:00.0Z + S: 2021-04-03T22:00:00.0Z + S: + S: + S: + S: + S: + S: + S: xn--fsq270a.example + S: + S: + S: xn--fsqz41a.example + S: + S: + S: + S: + S: + S: ABC-12345 + S: 54322-XYZ + S: + S: + S: + + Figure 4: Example Response + + An EPP error response must be returned if a command cannot + be processed for any reason. + +6.2.2. EPP Command + + This extension does not add any element to the EPP command + described in the EPP domain mapping [RFC5731]. However, additional + elements are defined for the response. + + When a command has been processed successfully, the EPP + 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 element + should contain a child element that identifies the + extension namespace if the domain object has data associated with + this extension and based on its registration policy. The + element should contain the element. + + S: + S: + S: + S: + S: Command completed successfully + S: + S: + S: + S: + S: + S: xn--fsq270a.example + S: + S: + S: xn--fsqz41a.example + S: + S: + S: + S: + S: + S: ABC-12345 + S: 54321-XYZ + S: + S: + S: + + Figure 5: Example Response + + An EPP error response must be returned if a command cannot + be processed for any reason. + +6.2.3. EPP Command + + This extension does not add any element to the EPP 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 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 element should contain the + , which contains the element. + + S: + S: + S: + S: + S: Command completed successfully + S: + S: + S: + S: xn--fsq270a.example + S: 2022-04-03T22:00:00.0Z + S: + S: + S: + S: + S: + S: + S: xn--fsq270a.example + S: + S: + S: xn--fsqz41a.example + S: + S: + S: + S: + S: + S: ABC-12345 + S: 54322-XYZ + S: + S: + S: + + Figure 6: Example Response + +6.2.4. EPP Command + + This extension does not add any element to the EPP command + described in the EPP domain name mapping [RFC5731]. However, + additional elements are defined for the response in the + EPP object mapping. When the command has been processed + successfully, the EPP 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 + element should contain the , which contains + the element. + + S: + S: + S: + S: + S: Command completed successfully; action pending + S: + S: + S: + S: xn--fsq270a.example + S: pending + S: ClientX + S: 2021-04-03T22:00:00.0Z + S: ClientY + S: 2021-04-08T22:00:00.0Z + S: 2022-04-03T22:00:00.0Z + S: + S: + S: + S: + S: + S: + S: xn--fsq270a.example + S: + S: + S: xn--fsqz41a.example + S: + S: + S: + S: + S: + S: ABC-12345 + S: 54322-XYZ + S: + S: + S: + + Figure 7: Example Response + +6.2.5. EPP Command + + This extension does not add any element to the EPP command + described in the EPP domain name mapping [RFC5731]. However, + additional elements are defined for the response in the EPP + object mapping. When the command has been processed successfully, + the EPP 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 + element should contain the , which contains the + element. + + S: + S: + S: + S: + S: Command completed successfully + S: + S: + S: + S: + S: + S: xn--fsq270a.example + S: + S: + S: xn--fsqz41a.example + S: + S: + S: + S: + S: + S: ABC-12345 + S: 54322-XYZ + S: + S: + S: + + Figure 8: Example 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. + + + + + + + + + + + + Extensible Provisioning Protocol v1.0 + Bundle Domain Extension Schema v1.0 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +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 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, + . + + [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", + STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, + . + + [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) + Domain Name Mapping", STD 69, RFC 5731, + DOI 10.17487/RFC5731, August 2009, + . + + [RFC5890] Klensin, J., "Internationalized Domain Names for + Applications (IDNA): Definitions and Document Framework", + RFC 5890, DOI 10.17487/RFC5890, August 2010, + . + + [RFC5891] Klensin, J., "Internationalized Domain Names in + Applications (IDNA): Protocol", RFC 5891, + DOI 10.17487/RFC5891, August 2010, + . + + [RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and + Internationalized Domain Names for Applications (IDNA)", + RFC 5892, DOI 10.17487/RFC5892, August 2010, + . + + [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible + Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, + February 2015, . + + [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, + . + + [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, + . + + [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, + . + +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, + . + + [RFC3915] Hollenbeck, S., "Domain Registry Grace Period Mapping for + the Extensible Provisioning Protocol (EPP)", RFC 3915, + DOI 10.17487/RFC3915, September 2004, + . + + [RFC4290] Klensin, J., "Suggested Practices for Registration of + Internationalized Domain Names (IDN)", RFC 4290, + DOI 10.17487/RFC4290, December 2005, + . + +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 -- cgit v1.2.3