<?xml version="1.0"	encoding="US-ASCII"?> version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [

<!ENTITY RFC3688 SYSTEM	"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3688.xml">
<!ENTITY RFC3743 SYSTEM	"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3743.xml">
<!ENTITY RFC4290 SYSTEM	"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4290.xml">
<!ENTITY RFC5730 SYSTEM	"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5730.xml">
<!ENTITY RFC5731 SYSTEM	"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5731.xml">
<!ENTITY RFC5890 SYSTEM	"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5890.xml">
<!ENTITY RFC5891 SYSTEM	"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5891.xml">
<!ENTITY RFC5892 SYSTEM	"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5892.xml">
<!ENTITY RFC7451 SYSTEM	"http://xml.resource.org/public/rfc/bibxml/reference.RFC.7451.xml">

]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt'?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes"	?>
<?rfc subcompact="no" ?> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" number="9095" docName="draft-yao-regext-bundling-registration-06" ipr="trust200902">
  <!-- category	values:	std, bcp, info,	exp, and historic --> ipr="trust200902" obsoletes="" updates="" submissionType="independent" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">

  <front>
    <title abbrev="EPP bundled names Bundled Names Mapping">
Extensible Provisioning	Protocol (EPP) Domain Name Mapping Extension for Strict Bundling Registration
    </title>
    <seriesInfo name="RFC" value="9095"/>
    <author fullname="Jiankang Yao" initials="J." surname="Yao" > surname="Yao">
      <organization>CNNIC</organization>
      <address>
        <postal>
          <street>4 South 4th	Street,Zhongguancun,Haidian Street, Zhongguancun, Haidian District</street>
          <city>Beijing</city>
          <region>Beijing</region>
          <code>100190</code>
          <country>China</country>
        </postal>
        <phone>+86 10 5881 3007</phone>
        <email>yaojk@cnnic.cn</email>
      </address>
    </author>
    <author fullname="Linlin Zhou" initials="L." surname="Zhou">
      <organization>CNNIC</organization>
      <address>
        <postal>
          <street>4 South 4th	Street,Zhongguancun,Haidian Street, Zhongguancun, Haidian District</street>
          <city>Beijing</city>
          <region>Beijing</region>
          <code>100190</code>
          <country>China</country>
        </postal>
        <phone>+86 10 5881 2677</phone>
        <email>zhoulinlin@cnnic.cn</email>
      </address>
    </author>
    <author fullname="Hongtao Li" initials="H." surname="Li">
      <organization>CNNIC</organization>
      <address>
        <postal>
          <street>4 South 4th	Street,Zhongguancun,Haidian Street, Zhongguancun, Haidian District</street>
          <city>Beijing</city>
          <region>Beijing</region>
          <code>100190</code>
          <country>China</country>
        </postal>
        <email>lihongtao@cnnic.cn</email>
      </address>
    </author>
    <author fullname="Ning Kong" initials="N" surname="Kong">
      <organization>Consultant</organization>
      <address>
        <email>ietfing@gmail.com</email>
      </address>
    </author>
    <author	fullname="Wil Tan" initials="W"	surname="Tan">
	  <organization>Cloud Registry</organization>
	  <address>
	  <postal>
		<street>Suite 32 Seabridge House, 377 Kent St</street>
		<city>Sydney</city>
		<region>NSW</region>
		<code>2000</code>
		<country>Australia</country>
	  </postal>
	  <phone>+61 414 710899</phone>
	  <email>wil@cloudregistry.net</email>
	  </address>
	</author>

		<author fullname="Jiagui Xie" initials="J" surname="Xie">
	  <organization></organization>
      <organization/>
      <address>
        <email>jiagui1984@163.com</email>
      </address>
    </author>
    <date month="June" year="2021" /> month="July" year="2021"/>
    <area>Internet</area>
    <workgroup>Internet	Engineering Task Force</workgroup>

	<keyword>epp bundled names mapping extension</keyword>
    <keyword>IDN</keyword>
    <abstract>
      <t>
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 non-standard nonstandard proprietary extension.
      </t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>
	  In RFC4290 RFC 4290 <xref target="RFC4290"></xref>, target="RFC4290" format="default"/>, 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 to be as
		  equivalent to each other according to the domain name registration policy.
	  Bundled domain names are those which that share the same Top Level Top-Level Domain (TLD) but whose second level second-level labels are
	  variants,
	  variants or those which that have identical second
	  level 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
	  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" "V-label.TLD", in which the second level second-level label (V-label) is a variant sharing the same TLD; TLD.
The second one is
in the form of "LABEL.V-tld" "LABEL.V-tld", in which the second level second-level label (LABEL) remains the same
but ending ends with a different TLD (V-tld), (V-tld) and
these different V-tlds are managed by the same entity.
</t>
      <t>
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 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.
</t>
      <t>

For the name variants, different registries have different policies. Some registries adopt
the policy that variant Internationalized Domain Name Names (IDNs) should be blocked. But some registries adopt the policy that variant IDNs
which
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	forms: form: Simplified Chinese (SC) form, Traditional Chinese (TC) form,	or other variant forms,
then the forms. The corresponding variant CDN in SC form and that 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 discuss discusses the situation that in which variant IDNs
which
that are identified as
equivalent are allocated or	delegated to the same registrant.
      </t>
      <t>
The basic Extensible Provisioning Protocol (EPP) domain name mapping
<xref target="RFC5731"></xref> target="RFC5731" format="default"/> provides the facility for single domain name registration.
It does not specify how to register
the strict bundled names which that share many of the attributes.
      </t>

      <t>
In order to	meet the above requirements	of strict bundled name registration, this document describes an
extension of the EPP domain name mapping
<xref target="RFC5731"></xref> target="RFC5731" format="default"/> for the provisioning	and	management of bundled names.
This document describes a non-standard nonstandard
proprietary extension. This extension is especially useful for registries of practicing performing Chinese domain name Domain Name registration.

This method is also useful for other language domain names that have similar issues with Chinese domain names. Domain Names.

This document
is specified using Extensible Markup Language (XML)	1.0	as described in
<xref target="W3C.REC-xml-20040204"></xref> target="W3C.REC-xml-20040204" format="default"/>	and	XML	Schema notation	as described in
<xref target="W3C.REC-xmlschema-1-20041028"></xref> target="W3C.REC-xmlschema-1-20041028" format="default"/>	and
<xref target="W3C.REC-xmlschema-2-20041028"></xref>. target="W3C.REC-xmlschema-2-20041028" format="default"/>.
      </t>
      <t>
The	EPP	core protocol specification	<xref target="RFC5730"></xref> target="RFC5730" format="default"/> 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.
      </t>
      <t>
This document uses many IDN concepts, so a thorough understanding of the IDNs for
Application	(IDNA, described in	<xref target="RFC5890"></xref>, target="RFC5890" format="default"/>,	<xref target="RFC5891"></xref>, target="RFC5891" format="default"/>,	and
<xref target="RFC5892"></xref>) target="RFC5892" format="default"/>)	and	the	variant	approach discussed in
<xref target="RFC4290"></xref> target="RFC4290" format="default"/> is assumed.
      </t>
    </section>
    <section title="Terminology"> numbered="true" toc="default">
      <name>Terminology</name>
      <t>
	Variants in this document are those strings that are treated to be as equivalent to each other according to the domain name registration policy for certain TLDs.
      </t>
      <t>
 Bundled domain names are bundled together according to the domain name registration policy.
 For example, many Chinese domain name Domain Name registries follow the principle described in RFC3743<xref target="RFC3743"></xref>. RFC 3743 <xref target="RFC3743" format="default"/>.

 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.
      </t>
      <t>
The terms Registered Domain Name(RDN) "registered domain name" (RDN) and Bundled Domain Name(BDN) "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 be kept to 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.

      </t>

      <t>

	 uLabel
	 The "uLabel" attribute in this document is used to express the U-label of an internationalized domain name Internationalized Domain Name as a series of characters
	 where non-ASCII characters will be represented in the format of "&amp;#xXXXX;" where XXXX is a UNICODE Unicode point by using the XML escaping mechanism.
	 U-Label
	 The U-label is defined in [RFC5890]. <xref target="RFC5890"/>. This document chooses this format of literal HTML ampersand codes, not the expected UNICODE native characters,
	 is because of that the UNICODE native Unicode character codes. Unicode characters may not be displayed correctly in some text file readers readers, while literal HTML ampersand codes numeric character references are easy for HTML processors. The implementation following this document should use UNICODE native Unicode characters directly.

      </t>
      <t>
 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, used and
 must employ a namespace-aware XML parser and serializer to interpret and output the XML documents.
      </t>
      <t>
In the examples, "C:" represents lines sent	by a protocol client client, and "S:" represents lines returned	by
a protocol server. Indentation and white space spacing in the examples are provided	only to	illustrate element
relationships and are not a	required feature of	this specification.
      </t>
      <t>
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.
      </t>
    </section>
    <section title="Overview"> numbered="true" toc="default">
      <name>Overview</name>
      <t>
Domain registries have traditionally 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, registration on which
operations such	as update, renewal renewal, and deletion	may	be performed.
      </t>
      <t>
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. (i.e.,	EPP	domain &lt;create&gt; 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.
      </t>
      <t>
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.
      </t>
    </section>
    <section title="Requirement numbered="true" toc="default">
      <name>Requirement for Bundling Registration of Names"> Names</name>
      <t>
The bundled names names, whether they are in the form of "V-label.TLD" or in the form of "LABEL.V-tld" "LABEL.V-tld", should share
some parameters or attributes associated with domain names. Typically, bundled names will share the following
parameters or attributes:<vspace blankLines="0" /></t>

   	  <t>
		 <list style="symbols">
			<t> attributes:</t>
      <ul spacing="normal">
        <li>
Registrar Ownership
			</t>
			<t> ownership
			</li>
        <li>
Registration and Expiry Dates
			</t>
			<t> expiry dates
			</li>
        <li>
Registrant, Admin, Billing, admin, billing, and Technical Contacts
			</t>

						<t> technical contacts
			</li>
        <li>
Name Server Association
			</t>
			<t> server association
			</li>
        <li>
Domain Status
			</t>
			<t> status
			</li>
        <li>
Applicable grace periods (Add Grace Period, Renewal Grace Period, Auto-Renewal Grace Period, Transfer Grace Period,
and Redemption Grace Period)
			</t>
		 </list>
	  </t> (add grace period, renew grace period, auto-renew grace period, transfer grace period, and redemption grace period) <xref target="RFC3915"/>
			</li>
      </ul>
      <t>
Because the domain names are bundled and share the same parameters or attributes, the EPP command should
do some processing for these requirements:<vspace blankLines="0" /> requirements:
</t>

   	  <t>
		 <list style="symbols">
			<t>
      <ul spacing="normal">
        <li>
When performing a Domain Check, domain &lt;check&gt; command, either the BDN or RDN can be queried for with the EPP command, command and
will return the same response.
			</t>
			<t>
			</li>
        <li>
When performing a Domain Info, domain &lt;info&gt; command, either the BDN or RDN can be queried, and
the same response will include both BDN and RDN information with the same attributes.
			</t>
			<t>
			</li>
        <li>
When performing a Domain Create, domain &lt;create&gt; command,
 if the domain name is available, both the BDN and RDN
 will be registered.
			</t>

						<t>
			</li>
        <li>
When performing a Domain Delete, domain &lt;delete&gt; command,
 either the BDN or RDN will be accepted. If the domain name is registered, both the BDN and RDN
 will be deleted.
			</t>
			<t>
			</li>
        <li>
When performing a Domain Renew, domain &lt;renew&gt; 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.
			</t>

			<t>When
			</li>
        <li>When performing a Domain Transfer, domain &lt;transfer&gt; 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.
</t>

<t>
</li>
        <li>
When performing a Domain Update, domain &lt;update&gt; command,
 either the BDN or RDN will be accepted. Any modifications to contact associations,
name server associations, domain status values values, and authorization information will be
 applied to both the BDN and RDN.
</t>
		 </list>
	  </t>
</li>
      </ul>
    </section>
    <section title="Object Attributes"> numbered="true" toc="default">
      <name>Object Attributes</name>
      <t>
This extension defines the following additional	elements to	the	EPP	domain name	mapping
<xref target="RFC5731"></xref>. target="RFC5731" format="default"/>.	All	of these additional	elements are returned from the &lt;domain:info&gt;
command.
      </t>
      <section title="RDN"> numbered="true" toc="default">
        <name>RDN</name>
        <t>
The	RDN is an ASCII name or an IDN with	the	A-label	<xref target="RFC5890"></xref> target="RFC5890" format="default"/> form.
In this	document, its corresponding	element	is &lt;b-dn:rdn&gt;. An optional attribute
"uLabel" associated	with &lt;b-dn:rdn&gt; is used to represent	the	U-label
<xref target="RFC5890"></xref> target="RFC5890" format="default"/> form. </t>
        <t>
For	example: &lt;b-dn:rdn uLabel="&amp;#x5B9E;&amp;#x4F8B;.example"&gt;
xn--fsq270a.example&lt;/b-dn:rdn&gt; </t>
   <sourcecode name="" type="xml"><![CDATA[
<b-dn:rdn uLabel="&#x5B9E;&#x4F8B;.example"> xn--
   fsq270a.example</b-dn:rdn>
]]></sourcecode>

      </section>
      <section title="BDN"> numbered="true" toc="default">
        <name>BDN</name>
        <t>
The	BDN is	an ASCII name or an IDN with the A-label	<xref target="RFC5890"></xref> target="RFC5890" format="default"/> form	which that is converted from	the
corresponding BDN.	In this	document, its corresponding	element	is &lt;b-dn:bdn&gt;. An optional attribute
"uLabel" associated	with &lt;b-dn:bdn&gt; is used to represent	the	U-label
<xref target="RFC5890"></xref> target="RFC5890" format="default"/> form.
        </t>
        <t>
For	example: &lt;b-dn:bdn uLabel="&amp;#x5BE6;&amp;#x4F8B;.example"&gt;
xn--fsqz41a.example&lt;/b-dn:bdn&gt; </t>
          <sourcecode name="" type="xml"><![CDATA[
<b-dn:bdn uLabel="&#x5BE6;&#x4F8B;.example"> xn--
   fsqz41a.example</b-dn:bdn>
]]></sourcecode>
      </section>
    </section>
    <section title="EPP numbered="true" toc="default">
      <name>EPP Command	Mapping"> Mapping</name>
      <t>
A detailed description of the EPP syntax and semantics can be found	in the EPP core	protocol
specification <xref	target="RFC5730"></xref>. target="RFC5730" format="default"/>. The command mappings described here are specifically
for	use	in provisioning	and	managing bundled names via EPP.
      </t>
      <section title="EPP numbered="true" toc="default">
        <name>EPP Query	Commands"> Commands</name>
        <t>
EPP	provides three commands	to retrieve	domain information:	&lt;check&gt; to determine if a	domain
object can be provisioned within a repository, &lt;info&gt;	to retrieve	detailed information
associated with	a domain object, and &lt;transfer&gt; to retrieve domain-object	transfer status
information.
        </t>
        <section title="EPP numbered="true" toc="default">
          <name>EPP &lt;check&gt; Command"> Command</name>
          <t>
This extension does	not	add	any	element	to the EPP &lt;check&gt; command or	&lt;check&gt; response described in the EPP domain name mapping <xref target="RFC5731"></xref>. target="RFC5731" format="default"/>. 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.
          </t>
<figure><artwork>
<![CDATA[
Example	<check> response:
<figure>
<name>Example &lt;check&gt; Response</name>
          <sourcecode name="Example &lt;check&gt; response" type="xml"><![CDATA[
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>
		]]></artwork>
]]></sourcecode>
</figure>
        </section>
        <section title="EPP numbered="true" toc="default">
          <name>EPP &lt;info&gt; Command"> Command</name>
          <t>
This extension does	not	add	any	element	to the EPP &lt;info&gt;	command	described in the EPP domain
mapping	<xref target="RFC5731"></xref>. target="RFC5731" format="default"/>.	However, additional	elements are defined for the
&lt;info&gt; response.
          </t>
          <t>
When an	&lt;info&gt; command has been processed	successfully, the EPP &lt;resData&gt; element must
contain	child elements as described	in the EPP domain mapping <xref	target="RFC5731"></xref>. target="RFC5731" format="default"/>. In
addition, unless some registration policy has some special processing, the EPP &lt;extension&gt; element should contain a child &lt;b-dn:infData&gt; element that
identifies the extension namespace if the domain object	has	data associated	with this extension	and
based on its registration policy. The &lt;b-dn:infData&gt; element contains the &lt;b-dn:bundle&gt; &lt;b-dn:bundle&gt;, which
has	the	following child	elements:
          </t>
		   <t>
			   <list style="symbols">
				 <t>
An
          <ul spacing="normal">
            <li>
A &lt;b-dn:rdn&gt; element that contains the RDN, along with the attribute described below.
				 </t>
				 <t>
				 </li>
            <li>
An optional	&lt;b-dn:bdn&gt; element that contains	the	BDN, along	with the attribute	described
below.
				 </t>

			   </list>
		   </t>
				 </li>
          </ul>
          <t>
The	above elements contain the following attribute:
		   <list style="symbols">
			  <t>
          </t>
          <ul spacing="normal">
            <li>
An optional "uLabel" attribute represents the U-label of the element.
			  </t>

		   </list>
		  </t>
			  </li>
          </ul>
<figure>
<artwork><![CDATA[
Example	<info> response
<name>Example &lt;info&gt; Response for an authorized client: Authorized Client</name>
          <sourcecode name="" type="xml"><![CDATA[
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>
		]]></artwork>
]]></sourcecode>
</figure>
          <t>
The &lt;info&gt; Response response for the unauthorized client has not been changed, see
<xref target="RFC5731"></xref> target="RFC5731" format="default"/> for detail. details.
          </t>
          <t>
An EPP error response must be returned if an &lt;info&gt; command cannot be	processed for any reason.
          </t>
        </section>
        <section title="EPP numbered="true" toc="default">
          <name>EPP &lt;transfer&gt; Query Command"> Command</name>
          <t>
This extension does	not	add	any	element	to the EPP &lt;transfer&gt;	command	or &lt;transfer&gt; response described in the EPP domain mapping <xref target="RFC5731"></xref>. target="RFC5731" format="default"/>.
          </t>
        </section>
      </section>
      <section title="EPP numbered="true" toc="default">
        <name>EPP Transform	Commands"> Commands</name>
        <t>
EPP	provides five commands to transform	domain objects:	&lt;create&gt; to create an	instance of	a
domain object, &lt;delete&gt; to delete	an instance	of a domain	object,	&lt;renew&gt; to extend	the
validity period	of a domain	object,	&lt;transfer&gt; to	manage domain object sponsorship changes,
and	&lt;update&gt; to change information associated	with a domain object.
        </t>
        <t>
When theses these commands have been processed successfully, the EPP &lt;resData&gt; element must
contain	child elements as described	in the EPP domain mapping <xref	target="RFC5731"></xref>. target="RFC5731" format="default"/>. Unless some registration policy has some special processing,
 this EPP &lt;extension&gt;	element	should contain
 the &lt;b-dn:bundle&gt; &lt;b-dn:bundle&gt;, which
has	the	following child	elements:
        </t>
		   <t>
			   <list style="symbols">
				 <t>
An
        <ul spacing="normal">
          <li>
A &lt;b-dn:rdn&gt; element that contains the RDN, along with the attribute described below.
				 </t>
				 <t>
				 </li>
          <li>
An optional	&lt;b-dn:bdn&gt; element that contains the BDN, along with the attribute described
below.
				 </t>

			   </list>
		   </t>
				 </li>
        </ul>
        <t>
The	above elements contain the following attribute:
		   <list style="symbols">
			  <t>
        </t>
        <ul spacing="normal">
          <li>
An optional "uLabel" attribute represents the U-label of the element.
			  </t>

		   </list>
		  </t>
			  </li>
        </ul>
        <section title="EPP numbered="true" toc="default">
          <name>EPP &lt;create&gt; Command"> Command</name>
          <t>
This extension defines additional elements to extend the EPP &lt;create&gt;	command	described in the
EPP	domain name	mapping	<xref target="RFC5731"></xref> target="RFC5731" format="default"/> for bundled names registration.
          </t>
          <t>
In addition	to the EPP command elements	described in the EPP domain	mapping
<xref target="RFC5731"></xref>, target="RFC5731" format="default"/>,	the	&lt;create&gt; command shall contain an	&lt;extension&gt;
element.

Unless some registration policy has some special processing, the &lt;extension&gt; element should contain a child &lt;b-dn:create&gt; element that
identifies the bundle namespace, namespace and a child &lt;b-dn:rdn&gt; element that identifies the U-Label U-label form
of the registered domain name with the uLabel "uLabel" attribute. U-Label The U-label is used for easy reading by the registrants and easy debugging by the registrars and the registries.
          </t>
<figure>
<artwork><![CDATA[
Example	<create> command:
<name>Example &lt;create&gt; Command</name>
          <sourcecode name="" type="xml"><![CDATA[
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>
		]]></artwork>
]]></sourcecode>
</figure>
          <t>
When a	&lt;create&gt; command has been	processed successfully,	the	EPP	&lt;creData&gt;	element
must contain child elements	as described in	the	EPP	domain mapping <xref target="RFC5731"></xref>. target="RFC5731" format="default"/>.

In addition, unless some registration policy has some special processing, the EPP &lt;extension&gt; element should contain a child &lt;b-dn:creData&gt; element
that identifies	the	extension namespace	if the domain object has data associated with this extension
and	based on its registration policy. The &lt;b-dn:creData&gt; element contains the &lt;b-dn:bundle&gt;
element.
          </t>
<figure>
<artwork><![CDATA[
Example	<create> response:
<name>Example &lt;create&gt; Response</name>
          <sourcecode name="" type="xml"><![CDATA[
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>
		]]></artwork>
]]></sourcecode>
</figure>
		   <!--<t>
&lt;create&gt; Response	for the unauthorized client has not been changed,see
<xref target="RFC5731"></xref> for detail.
		   </t>-->
		   <t>
An EPP error response must be returned if an a &lt;create&gt;      command cannot be processed     for     any
reason.
          </t>
        </section>
        <section title="EPP numbered="true" toc="default">
          <name>EPP &lt;delete&gt; Command"> Command</name>
          <t>
This extension does	not	add	any	element	to the EPP &lt;delete&gt; command described	in the EPP
domain mapping <xref target="RFC5731"></xref>. target="RFC5731" format="default"/>. However,	additional elements	are	defined	for	the
&lt;delete&gt; response.
          </t>
          <t>
When a &lt;delete&gt; command has been processed successfully, the EPP &lt;delData&gt; element must
contain	child elements as described	in the EPP domain mapping <xref	target="RFC5731"></xref>. target="RFC5731" format="default"/>.
In addition, unless some registration policy has some special processing, the EPP &lt;extension&gt; element should contain a child &lt;b-dn:delData&gt; element that
identifies the extension namespace if the domain object	has	data associated	with this extension	and
based on its registration policy. The &lt;b-dn:delData&gt; element should contain the &lt;b-dn:bundle&gt;
element.
          </t>
<figure>
<artwork><![CDATA[
Example	<delete> response:
<name>Example &lt;delete&gt; Response</name>
          <sourcecode name="" type="xml"><![CDATA[
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>
		]]></artwork>
]]></sourcecode>
</figure>
          <t>
An EPP error response must be returned if a	&lt;delete&gt; command cannot be processed for any
reason.
          </t>
        </section>
        <section title="EPP numbered="true" toc="default">
          <name>EPP &lt;renew&gt; Command"> Command</name>
          <t>

This extension does	not	add	any	element	to the EPP &lt;renew&gt; command
described in the EPP domain	name mapping <xref target="RFC5731"></xref>. target="RFC5731" format="default"/>. However, when either the RDN or BDN is sent for renew, renewal,
 the response should contain both RDN and BDN information.

 When the command has been processed successfully,
  the EPP &lt;extension&gt; 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 &lt;extension&gt; element should contain
 the &lt;b-dn:renData&gt; &lt;b-dn:renData&gt;, which contains the &lt;b-dn:bundle&gt; element.
          </t>
<figure>
<artwork><![CDATA[
Example	<renew> response:
<name>Example &lt;renew&gt; Response</name>
          <sourcecode name="" type="xml"><![CDATA[
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>
		]]></artwork>
]]></sourcecode>
</figure>
        </section>
        <section title="EPP numbered="true" toc="default">
          <name>EPP &lt;transfer&gt; Command"> Command</name>
          <t>

		 This extension does not add any element to the EPP &lt;transfer&gt; command
described in the EPP domain	name mapping <xref target="RFC5731"></xref>. target="RFC5731" format="default"/>.

However, additional elements are defined for the &lt;transfer&gt; response in the EPP object mapping.

  When the command has been processed successfully,
  the EPP &lt;extension&gt; 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 &lt;extension&gt; element should contain
 the &lt;b-dn:trnData&gt; &lt;b-dn:trnData&gt;, which contains the &lt;b-dn:bundle&gt; element.

          </t>
<figure>
<artwork><![CDATA[
Example	<transfer> response:
<name>Example &lt;transfer&gt; Response</name>
          <sourcecode name="" type="xml"><![CDATA[
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>
		]]></artwork>
]]></sourcecode>
</figure>
        </section>
        <section title="EPP numbered="true" toc="default">
          <name>EPP &lt;update&gt; Command"> Command</name>
          <t>

		 This extension does	not	add	any	element	to the EPP &lt;update&gt; command
described in the EPP domain	name mapping <xref target="RFC5731"></xref>. target="RFC5731" format="default"/>.
 However, additional elements are defined for the &lt;update&gt; response in the EPP object mapping.

  When the command has been processed successfully,
  the EPP &lt;extension&gt; 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 &lt;extension&gt; element should contain
 the &lt;b-dn:upData&gt; &lt;b-dn:upData&gt;, which contains the &lt;b-dn:bundle&gt; element.

          </t>
<figure>
<artwork><![CDATA[
Example	<update> response:
<name>Example &lt;update&gt; Response</name>
          <sourcecode name="" type="xml"><![CDATA[
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>
		]]></artwork>
]]></sourcecode>
</figure>
        </section>
      </section>
    </section>
    <section title="Formal Syntax"> anchor="formal" numbered="true" toc="default">
      <name>Formal Syntax</name>
      <t>
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.
      </t>
 <figure>
 <artwork><![CDATA[
BEGIN
      <sourcecode name="" type="xml" markers="true"><![CDATA[
<?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>

END
]]></artwork>
</figure>
]]></sourcecode>
    </section>
    <section title="Internationalization Considerations" anchor="Internationalization"> anchor="Internationalization" numbered="true" toc="default">
      <name>Internationalization Considerations</name>
      <t>
EPP	is represented in XML, which provides native support for encoding information using	the	Unicode
character set and its more compact representations 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 &lt;?xml?&gt; declaration, use of UTF-8 is
recommended.
      </t>
      <t>
As an extension	of the EPP domain name mapping,	the elements, 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.
      </t>
    </section>
    <section title="IANA Considerations" anchor="Iana"> anchor="Iana" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section title="XML anchor="Iana1" numbered="true" toc="default">
        <name>XML Namespace and XML Schema" anchor="Iana1"> Schema</name>
        <t>
   This document uses URNs to describe XML namespaces and XML schemas
   conforming to a registry mechanism described in [RFC3688]. <xref target="RFC3688"/>.
        </t>
        <section title="BDN Namespace" anchor="Iana11"> anchor="Iana11" numbered="true" toc="default">
          <name>BDN Namespace</name>
          <t>
   IANA is requested to make an assignment from has assigned the IETF XML Registry
   "ns" registry as follows following for the BDN namespace in the "ns" subregistry of the "IETF XML Registry", with this document
   as the reference:
          </t>

   	  <t>
		 <list style="symbols">
			<t>
URI: urn:ietf:params:xml:ns:epp:b-dn
			</t>
			<t>
          <dl spacing="compact">
            <dt>
URI:</dt><dd>urn:ietf:params:xml:ns:epp:b-dn</dd>
            <dt>
Registrant Contact:	See Contact:</dt><dd>See the	"Author's Address" "Authors' Addresses" section of this document.
			</t>
			<t>
XML: None. Namespace document.</dd>
            <dt>
XML:</dt><dd>None. The namespace URI does not represent an XML specification.
			</t>
		 </list>
	  </t>
</dd>
          </dl>
        </section>
        <section title="BDN anchor="Iana12" numbered="true" toc="default">
          <name>BDN XML Schema" anchor="Iana12"> Schema</name>
          <t>
   IANA is requested to make an has made the following  assignment from in the IETF XML Registry "schema" registry as follows subregistry of the "IETF XML Registry" for the BDN XML schema schema, with this
   document as the reference:
          </t>

   	  <t>
		 <list style="symbols">
			<t>
URI: urn:ietf:params:xml:schema:epp:b-dn
			</t>
			<t>
          <dl spacing="compact">
            <dt>
URI:</dt><dd>urn:ietf:params:xml:schema:epp:b-dn</dd>

            <dt>
Registrant Contact:	See Contact:</dt><dd>See	the	"Author's Address" "Authors' Addresses" section of this document.
			</t>
			<t>
XML: See the "Formal Syntax" document.</dd>
            <dt>
XML:</dt><dd>See the "<xref target="formal" format="title"/>" section of this document.
			</t>
		 </list>
	  </t>
			</dd>
          </dl>
        </section>
      </section>
      <section title="EPP Extension" anchor="Iana2"> anchor="Iana2" numbered="true" toc="default">
        <name>EPP Extension</name>
        <t>
   The
   IANA has registered the EPP extension described in this document should be registered by
   IANA
   in the "Extensions for the Extensible Provisioning Protocol
   (EPP)" registry described in [RFC7451]. <xref target="RFC7451"/>.  The details of the
   registration are as follows:
        </t>

   	  <t>
		 <list style="symbols">
			<t>
        <dl spacing="compact">
          <dt>
Name of Extension: "Domain Extension:</dt><dd>"Domain Name Mapping Extension for Strict Bundling Registration"
			</t>
			<t> Registration"</dd>

          <dt>
Document status: Informational
			</t>
			<t>
Reference: This Status:</dt><dd>Informational
			</dd>
          <dt>
Reference:</dt><dd>This document
			</t>

						<t>
			</dd>
          <dt>
Registrant Name and Email Address: Address:</dt><dd> See the	"Author's Address" "Authors' Addresses" section of this document.
			</t>

						<t>
Top-Level Domains (TLDs): Any
			</t>

							<t>
			</dd>
          <dt>
TLDs:</dt><dd>Any
			</dd>
          <dt>
IPR Disclosure: https://datatracker.ietf.org/ipr/2479
			</t>

								<t>
Status: Active
			</t>
							<t>
Notes: None
			</t>

		 </list>
	  </t> Disclosure:</dt><dd><eref target="https://datatracker.ietf.org/ipr/2479"/>
			</dd>
          <dt>
Status:</dt><dd>Active
			</dd>
          <dt>
Notes:</dt><dd>None
			</dd>
        </dl>
      </section>
    </section>
    <section title="Security Considerations" anchor="security"> anchor="security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
	  Normally, the EPP server will only be connected by the authorized EPP client client,
	  which knows whether the EPP server supports the extension described in this document via out of band out-of-band service.
	  The EPP client should avoid to send sending this extension to the unimplemented EPP server. In case that 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 the section 3 of RFC5730<xref target="RFC5730"></xref>.

Section 3 of RFC5730<xref target="RFC5730"></xref> <xref target="RFC5730" sectionFormat="of" section="3"/>.

<xref target="RFC5730" sectionFormat="of" section="3"/> has the following information for result code 2103.

 <figure>
 <artwork>

      </t>

<blockquote>
  <t> 2103    "Unimplemented extension" extension"</t>
   <t>
              This response code must <bcp14>MUST</bcp14> be returned when a server receives
              a valid EPP command element that contains a protocol
              command extension that is not implemented by the server.
			  </artwork>
</figure>
	</t> server.</t></blockquote>

      <t>
	 Some registries and registrars have more than 15 years years' experience of with the bundled registration of domain names (especially Chinese domain names). 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 doing some performing operations to these domain names.

<xref target="RFC5730"></xref> target="RFC5730" format="default"/> also introduces some security consideration.
      </t>
      <t> This document
does not take a position regarding whether or not the bundled domain names share a DS/DNSKEY key. 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.</t>
    </section>

		<section title="Implementation Status and some clarifications" anchor="status">
	  <t>
   Note to RFC Editor: Please remove this section before publication.
	  </t>
	<t>
		  <list	style="symbols">
	  <t>

	  The Chinese Domain Name Consortium(CDNC) including CNNIC, TWNIC, HKIRC, MONIC, SGNIC and more have followed the principles defined in this document for many years.

	   </t>

	  	  <t>

   CNNIC and TELEINFO have implemented this extension in their EPP based Chinese domain name registration system.
	  </t>

	  	  <t>
   Public Interest Registry, has requested to implement technical bundling of second level domains for .NGO and .ONG.
     This means that by registering and purchasing a domain in the .ngo TLD, for an example, the NGO registrant
   is also registering and purchasing the corresponding name in the .ong TLD (and vice-versa for registrations in .ong).
	  </t>

		  <t>
	 Patrick Mevzek has released a new version of Net::DRI, an EPP client (Perl library, free software)
implementing this extension.
	  </t>

	  	  <t>
	The idea and main texts of this document has passed IETF REGEXT WG review.
	  </t>
		  </list>
	   </t>
	</section>

	<section title="Acknowledgements" anchor="Acknowledgements">
	  <t>
The	authors	especially thank the authors of	<xref target="RFC5730"></xref> and
<xref target="RFC5731"></xref> and the following ones of CNNIC:	Weiping	Yang, Chao Qi.

	  </t>
	  <t>
Useful comments	were made by John Klensin, Scott Hollenbeck, Patrick Mevzek, Edward Lewis,and Adrian Farrel.

	  </t>
	</section>
  </middle>
  <back>
	<references	title="Normative References">

			&RFC3688;
			&RFC5730;
			&RFC5731;
			&RFC5890;
			&RFC5891;
			&RFC5892;
			&RFC7451;
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5730.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5731.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5890.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5891.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5892.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7451.xml"/>
        <reference anchor="W3C.REC-xml-20040204" target="http://www.w3.org/TR/2004/REC-xml-20040204">
          <front>
		  <title>"Extensible
            <title>Extensible Markup Language (XML) 1.0 (Third Edition)",
		  World	Wide Web Consortium	FirstEdition REC-xml-20040204</title> Edition)</title>
            <author initials="T" surname="Bray">
			<organization></organization>
              <organization/>
            </author>
            <author initials="J" surname="Paoli">
			<organization></organization>
              <organization/>
            </author>
            <author initials="C" initials="C.M." surname="Sperberg-McQueen">
			<organization></organization>
              <organization/>
            </author>
            <author initials="E" surname="Maler">
			<organization></organization>
              <organization/>
            </author>
            <author initials="F" surname="Yergeau">
			<organization></organization>
              <organization/>
            </author>
            <date month="February" year="2004" /> year="2004"/>
          </front>
          <refcontent>W3C Recommendation REC-xml-20040204</refcontent>
        </reference>

        <reference anchor="W3C.REC-xmlschema-1-20041028" target="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028">
          <front>
		  <title>"XML
            <title>XML Schema Part 1: Structures Second Edition", World Wide
		  Web Consortium Recommendation	REC-xmlschema-1-20041028</title> Edition</title>
            <author initials="H" surname="Thompson">
			<organization></organization>
              <organization/>
            </author>
            <author initials="D" surname="Beech">
			<organization></organization>
              <organization/>
            </author>
            <author initials="M" surname="Maloney">
			<organization></organization>
              <organization/>
            </author>
            <author initials="N" surname="Mendelsohn">
			<organization></organization>
              <organization/>
            </author>
            <date month="October"	year="2004"	/> year="2004"/>
          </front>
          <refcontent>W3C Recommendation REC-xmlschema-1-20041028</refcontent>
        </reference>

        <reference anchor="W3C.REC-xmlschema-2-20041028" target="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028">
          <front>
		  <title>"XML
            <title>XML Schema Part 2: Datatypes Second Edition",	World Wide
		  Web Consortium Recommendation	REC-xmlschema-2-20041028</title> Edition</title>
            <author initials="P" surname="Biron">
			<organization></organization>
              <organization/>
            </author>
            <author initials="A" surname="Malhotra">
			<organization></organization>
              <organization/>
            </author>
            <date month="October"	year="2004"	/> year="2004"/>
          </front>
          <refcontent>W3C Recommendation REC-xmlschema-2-20041028</refcontent>
        </reference>
      </references>

	<references	title="Informative References">
		&RFC4290;
		&RFC3743;
	  <!--<reference anchor="Final.Integrated.Issues.Report"
				 target="http://www.icann.org/en/topics/idn/idn-vip-integrated-issues-final-clean-20feb12-en.pdf">
		<front>
		  <title>The IDN Variant Issues	Project: A Study
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4290.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3915.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3743.xml"/>

	</references>
    </references>
    <section anchor="Acknowledgements" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>
The	authors	especially thank the authors of	Issues Related to	<xref target="RFC5730" format="default"/> and
<xref target="RFC5731" format="default"/> and the Management following members of
		  IDN Variant TLDs</title>
		  <author initials="" surname="">
			<organization>ICANN</organization>
		  </author>
		  <date	month="February" year="2012" />
		</front>
	  </reference>

	  <reference anchor="bundle.name"
				 target="https://www.icann.org/public-comments/rstep-technical-bundling-2014-07-29-en">
		<front>
		  <title>Registry Services Technical Evaluation Panel (RSTEP) Report
		  on Public Interest Registry's Request to Implement Technical Bundling in .NGO the China Internet Network Information Center (CNNIC):	<contact fullname="Weiping Yang"/>, <contact fullname="Chao Qi"/>.
      </t>
      <t>
Useful comments	were made by <contact fullname="John Klensin"/>, <contact fullname="Scott Hollenbeck"/>,  <contact fullname="Patrick Mevzek"/>,  <contact fullname="Edward Lewis"/>, <contact fullname="Wil Tan"/>, and .ONG</title>
		  <author initials="" surname="">
			<organization>ICANN</organization>
		  </author>
		  <date	month="July" year="2014" />
		</front>
	  </reference>	-->

	</references>  <contact fullname="Adrian Farrel"/>.
      </t>
    </section>
  </back>
</rfc>