doc: Add RFC documents

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="&#x5B9E;&#x4F8B;.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="&#x5BE6;&#x4F8B;.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="&#x5B9E;&#x4F8B;.example">
+   S:            xn--fsq270a.example
+   S:          </b-dn:rdn>
+   S:          <b-dn:bdn uLabel="&#x5BE6;&#x4F8B;.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="&#x5B9E;&#x4F8B;.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="&#x5B9E;&#x4F8B;.example">
+   S:            xn--fsq270a.example
+   S:          </b-dn:rdn>
+   S:          <b-dn:bdn uLabel="&#x5BE6;&#x4F8B;.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="&#x5B9E;&#x4F8B;.example">
+   S:            xn--fsq270a.example
+   S:          </b-dn:rdn>
+   S:          <b-dn:bdn uLabel="&#x5BE6;&#x4F8B;.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="&#x5B9E;&#x4F8B;.example">
+   S:            xn--fsq270a.example
+   S:          </b-dn:rdn>
+   S:          <b-dn:bdn uLabel="&#x5BE6;&#x4F8B;.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="&#x5B9E;&#x4F8B;.example">
+   S:            xn--fsq270a.example
+   S:          </b-dn:rdn>
+   S:          <b-dn:bdn uLabel="&#x5BE6;&#x4F8B;.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="&#x5B9E;&#x4F8B;.example" >
+   S:            xn--fsq270a.example
+   S:          </b-dn:rdn>
+   S:          <b-dn:bdn uLabel="&#x5BE6;&#x4F8B;.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