Diff: rfc9095xml2.original.xml

	rfc9095xml2.original.xml	rfc9095.xml

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

	<!ENTITY RFC3688 SYSTEM "http://xml.resource.org/public/rfc/bibxml/refere
	nce.RFC.3688.xml">
	<!ENTITY RFC3743 SYSTEM "http://xml.resource.org/public/rfc/bibxml/refere
	nce.RFC.3743.xml">
	<!ENTITY RFC4290 SYSTEM "http://xml.resource.org/public/rfc/bibxml/refere
	nce.RFC.4290.xml">
	<!ENTITY RFC5730 SYSTEM "http://xml.resource.org/public/rfc/bibxml/refere
	nce.RFC.5730.xml">
	<!ENTITY RFC5731 SYSTEM "http://xml.resource.org/public/rfc/bibxml/refere
	nce.RFC.5731.xml">
	<!ENTITY RFC5890 SYSTEM "http://xml.resource.org/public/rfc/bibxml/refere
	nce.RFC.5890.xml">
	<!ENTITY RFC5891 SYSTEM "http://xml.resource.org/public/rfc/bibxml/refere
	nce.RFC.5891.xml">
	<!ENTITY RFC5892 SYSTEM "http://xml.resource.org/public/rfc/bibxml/refere
	nce.RFC.5892.xml">
	<!ENTITY RFC7451 SYSTEM "http://xml.resource.org/public/rfc/bibxml/refere
	nce.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" ?>


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

	<front>	<front>

	<title abbrev="EPP bundled names Mapping">	<title abbrev="EPP Bundled Names Mapping">
	Extensible Provisioning Protocol (EPP) Domain Name Mapping Extension for Strict Bundling Registration	Extensible Provisioning Protocol (EPP) Domain Name Mapping Extension for Strict Bundling Registration

	</title>	</title>
		<seriesInfo name="RFC" value="9095"/>
	<author fullname="Jiankang Yao" initials="J." surname="Yao" >	<author fullname="Jiankang Yao" initials="J." surname="Yao">
	<organization>CNNIC</organization>	<organization>CNNIC</organization>
	<address>	<address>
	<postal>	<postal>
	<street>4 South 4th Street,Zhongguancun,Haidian District</str	<street>4 South 4th Street, Zhongguancun, Haidian District</street>
	eet>	<city>Beijing</city>
	<city>Beijing</city>	<region>Beijing</region>
	<region>Beijing</region>	<code>100190</code>
	<code>100190</code>	<country>China</country>
	<country>China</country>	</postal>
	</postal>	<phone>+86 10 5881 3007</phone>
	<phone>+86 10 5881 3007</phone>	<email>yaojk@cnnic.cn</email>
	<email>yaojk@cnnic.cn</email>	</address>
	</address>	</author>
	</author>	<author fullname="Linlin Zhou" initials="L." surname="Zhou">
		<organization>CNNIC</organization>
	<author fullname="Linlin Zhou" initials="L." surname="Zhou">	<address>
	<organization>CNNIC</organization>	<postal>
	<address>	<street>4 South 4th Street, Zhongguancun, Haidian District</street>
	<postal>	<city>Beijing</city>
	<street>4 South 4th Street,Zhongguancun,Haidian District</str	<region>Beijing</region>
	eet>	<code>100190</code>
	<city>Beijing</city>	<country>China</country>
	<region>Beijing</region>	</postal>
	<code>100190</code>	<phone>+86 10 5881 2677</phone>
	<country>China</country>	<email>zhoulinlin@cnnic.cn</email>
	</postal>	</address>
	<phone>+86 10 5881 2677</phone>	</author>
	<email>zhoulinlin@cnnic.cn</email>	<author fullname="Hongtao Li" initials="H." surname="Li">
	</address>	<organization>CNNIC</organization>
	</author>	<address>
		<postal>
	<author fullname="Hongtao Li" initials="H." surname="Li">	<street>4 South 4th Street, Zhongguancun, Haidian District</street>
	<organization>CNNIC</organization>	<city>Beijing</city>
	<address>	<region>Beijing</region>
	<postal>	<code>100190</code>
	<street>4 South 4th Street,Zhongguancun,Haidian District</str	<country>China</country>
	eet>	</postal>
	<city>Beijing</city>	<email>lihongtao@cnnic.cn</email>
	<region>Beijing</region>	</address>
	<code>100190</code>	</author>
	<country>China</country>	<author fullname="Ning Kong" initials="N" surname="Kong">
	</postal>	<organization>Consultant</organization>
		<address>
	<email>lihongtao@cnnic.cn</email>	<email>ietfing@gmail.com</email>
	</address>	</address>
	</author>	</author>
		<author fullname="Jiagui Xie" initials="J" surname="Xie">
	<author fullname="Ning Kong" initials="N" surname="Kong">	<organization/>
	<organization>Consultant</organization>	<address>
	<address>	<email>jiagui1984@163.com</email>
		</address>
	<email>ietfing@gmail.com</email>	</author>
	</address>	<date month="July" year="2021"/>
	</author>	<area>Internet</area>
		<workgroup>Internet Engineering Task Force</workgroup>
	<author fullname="Wil Tan" initials="W" surname="Tan">	<keyword>IDN</keyword>
	<organization>Cloud Registry</organization>	<abstract>
	<address>	<t>
	<postal>	This document describes an extension of Extensible Provisioning Protocol (EPP) d
	<street>Suite 32 Seabridge House, 377 Kent St</street>	omain name mapping for the provisioning and management of strict bundling regis
	<city>Sydney</city>	tration of domain names. Specified in XML, this mapping extends the EPP domain n
	<region>NSW</region>	ame mapping to provide additional features required for
	<code>2000</code>	the provisioning of bundled domain names. This is a nonstandard proprietary exte
	<country>Australia</country>	nsion.
	</postal>	</t>
	<phone>+61 414 710899</phone>	</abstract>
	<email>wil@cloudregistry.net</email>
	</address>
	</author>

	<author fullname="Jiagui Xie" initials="J" surname="Xie">
	<organization></organization>
	<address>

	<email>jiagui1984@163.com</email>
	</address>
	</author>

	<date month="June" year="2021" />

	<area>Internet</area>

	<workgroup>Internet Engineering Task Force</workgroup>

	<keyword>epp bundled names mapping extension</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 o
	f domain names. Specified in
	XML, this mapping extends the EPP domain name mapping to provide additional f
	eatures required for
	the provisioning of bundled domain names. This is a non-standard proprietary
	extension.
	</t>
	</abstract>
	</front>	</front>


	<middle>	<middle>

	<section title="Introduction">	<section numbered="true" toc="default">
	<t>	<name>Introduction</name>
	In RFC4290 <xref target="RFC4290"></xref>, the "variant(s)" are charact	<t>
	er(s) and/or string(s) that are	In RFC 4290 <xref target="RFC4290" format="default"/>, the "variant(s)"
	treated as equivalent to the base character. In this document, variant	are character(s) and/or string(s) that are
	s are those strings that are treated to be	treated as equivalent to the base character. In this document, variant
		s are those strings that are treated as
	equivalent to each other according to the domain name registrat ion policy.	equivalent to each other according to the domain name registrat ion policy.

	Bundled domain names are those which share the same Top Level Domain (T	Bundled domain names are those that share the same Top-Level Domain (TL
	LD) but whose second level labels are	D) but whose second-level labels are
	variants, or those which have identical second	variants or those that have identical second-level labels for which cer
	level labels for which certain parameters are shared in different TLDs.	tain parameters are shared in different TLDs.
	For example, Public Interest Registry has requested to implement bundli	For example, the Public Interest Registry has requested to implement bu
	ng of	ndling of
	second level domains for .NGO and .ONG. So we have two kinds of bundled	second-level domains for .NGO and .ONG. So we have two kinds of bundled
	domain names. The first one is	domain names. The first one is
	in the form of "V-label.TLD" in which the second level label (V-label) is a vari	in the form of "V-label.TLD", in which the second-level label (V-label) is a var
	ant sharing the same TLD;	iant sharing the same TLD.
	The second one is	The second one is

	in the form of "LABEL.V-tld" in which the second level label (LABEL) remains the	in the form of "LABEL.V-tld", in which the second-level label (LABEL) remains th
	same	e same
	but ending with a different TLD (V-tld), and	but ends with a different TLD (V-tld) and
	these different V-tlds are managed by the same entity.	these different V-tlds are managed by the same entity.
	</t>	</t>

		<t>
	<t>
	Bundled domain names normally share some attributes. Policy-wise	Bundled domain names normally share some attributes. Policy-wise
	bundling can be implemented in three ways. The first one	bundling can be implemented in three ways. The first one
	is strict bundling, which	is strict bundling, which
	requires all bundled names to share many of the same attributes. When creating,	requires all bundled names to share many of the same attributes. When creating,
	updating, or transferring any of the bundled domain names,	updating, or transferring any of the bundled domain names,

	all bundled domain names will be created, updated or transferred atomically.	all bundled domain names will be created, updated, or transferred atomically.
	The second one is partial bundling, which requires	The second one is partial bundling, which requires
	the bundled domain names to be registered by the	the bundled domain names to be registered by the
	same registrant.	same registrant.
	The third one is relaxed bundling, which has no specific requirements on the do main	The third one is relaxed bundling, which has no specific requirements on the do main
	registration.	registration.

	This document mainly addresses the strict bundling name registration.	This document mainly addresses the strict bundling name registration.
	</t>	</t>

		<t>
	<t>

	For the name variants, different registries have different policies. Some regist ries adopt	For the name variants, different registries have different policies. Some regist ries adopt

	the policy that variant Internationalized Domain Name (IDNs) should be blocked.	the policy that variant Internationalized Domain Names (IDNs) should be blocked.
	But some registries adopt the policy that variant IDNs	But some registries adopt the policy that variant IDNs
	which are identified as	that are identified as
	equivalent are allocated or delegated to the same registrant. For example, mo	equivalent are allocated or delegated to the same registrant. For example, mo
	st registries offering	st registries offering a Chinese Domain Name (CDN) adopt a registration policy w
	Chinese Domain Name (CDN) adopt a registration policy whereby a registrant can a	hereby a registrant can apply for an original CDN in
	pply for an original CDN in	any form: Simplified Chinese (SC) form, Traditional Chinese (TC) form, or other
	any forms: Simplified Chinese (SC) form, Traditional Chinese (TC) form, o	variant forms. The corresponding variant CDN in SC form and in TC form will also
	r other variant forms,	be delegated to the
	then the corresponding variant CDN in SC form and that in TC form will also b
	e delegated to the
	same registrant. All variant names in the same TLD share a common set of attribu tes.	same registrant. All variant names in the same TLD share a common set of attribu tes.

	This document mainly discuss the situation that variant IDNs	This document mainly discusses the situation in which variant IDNs
	which are identified as	that are identified as
	equivalent are allocated or delegated to the same registrant.	equivalent are allocated or delegated to the same registrant.

	</t>	</t>
		<t>
	<t>
	The basic Extensible Provisioning Protocol (EPP) domain name mapping	The basic Extensible Provisioning Protocol (EPP) domain name mapping

	<xref target="RFC5731"></xref> provides the facility for single domain name regi stration.	<xref target="RFC5731" format="default"/> provides the facility for single domai n name registration.
	It does not specify how to register	It does not specify how to register

	the strict bundled names which share many of the attributes.	the strict bundled names that share many of the attributes.
	</t>	</t>


	<t>	<t>
	In order to meet the above requirements of strict bundled name registrati on, this document describes an	In order to meet the above requirements of strict bundled name registrati on, this document describes an
	extension of the EPP domain name mapping	extension of the EPP domain name mapping

	<xref target="RFC5731"></xref> for the provisioning and management of bun	<xref target="RFC5731" format="default"/> for the provisioning and managemen
	dled names.	t of bundled names.
	This document describes a non-standard	This document describes a nonstandard
	proprietary extension. This extension is especially useful for registries of pra	proprietary extension. This extension is especially useful for registries perfor
	cticing Chinese domain name registration.	ming Chinese Domain Name registration.


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

	This document	This document
	is specified using Extensible Markup Language (XML) 1.0 as described in	is specified using Extensible Markup Language (XML) 1.0 as described in

	<xref target="W3C.REC-xml-20040204"></xref> and XML Schema notation a	<xref target="W3C.REC-xml-20040204" format="default"/> and XML Schema no
	s described in	tation as described in
	<xref target="W3C.REC-xmlschema-1-20041028"></xref> and	<xref target="W3C.REC-xmlschema-1-20041028" format="default"/> and
	<xref target="W3C.REC-xmlschema-2-20041028"></xref>.	<xref target="W3C.REC-xmlschema-2-20041028" format="default"/>.
	</t>	</t>
	<t>	<t>
	The EPP core protocol specification <xref target="RFC5730"></xref> pr	The EPP core protocol specification <xref target="RFC5730" format="de
	ovides a complete description	fault"/> provides a complete description
	of EPP command and response structures. A thorough understanding of t he base protocol specification	of EPP command and response structures. A thorough understanding of t he base protocol specification
	is necessary to understand the extension mapping described in this docume nt.	is necessary to understand the extension mapping described in this docume nt.

	</t>	</t>
	<t>	<t>
	This document uses many IDN concepts, so a thorough understanding of the IDNs fo r	This document uses many IDN concepts, so a thorough understanding of the IDNs fo r

	Application (IDNA, described in <xref target="RFC5890"></xref>, <xref tar	Application (IDNA, described in <xref target="RFC5890" format="default"/>
	get="RFC5891"></xref>, and	, <xref target="RFC5891" format="default"/>, and
	<xref target="RFC5892"></xref>) and the variant approach discusse	<xref target="RFC5892" format="default"/>) and the variant approach
	d in	discussed in
	<xref target="RFC4290"></xref> is assumed.	<xref target="RFC4290" format="default"/> is assumed.
	</t>	</t>
	</section>	</section>
		<section numbered="true" toc="default">
	<section title="Terminology">	<name>Terminology</name>
	<t>	<t>
	Variants in this document are those strings that are treated to be	Variants in this document are those strings that are treated as equivalen
	equivalent to each other according to the domain name registrat	t to each other according to the domain name registration policy for certain TLD
	ion policy for certain TLDs.	s.
	</t>	</t>
		<t>
	<t>
	Bundled domain names are bundled together according to the domain name registra tion policy.	Bundled domain names are bundled together according to the domain name registra tion policy.

	For example, many Chinese domain name registries follow the principle described in RFC3743<xref target="RFC3743"></xref>.	For example, many Chinese Domain Name registries follow the principle described in RFC 3743 <xref target="RFC3743" format="default"/>.

	Bundled domain names should belong to the same owner. If bundled domain names a re under different TLDs, those TLDs should	Bundled domain names should belong to the same owner. If bundled domain names a re under different TLDs, those TLDs should
	be managed by the same entity.	be managed by the same entity.

	</t>	</t>
		<t>
	<t>	The terms "registered domain name" (RDN) and "bundled domain name" (BDN) are use
	The terms Registered Domain Name(RDN) and Bundled Domain Name(BDN) are used i	d in this document.
	n this document.
	RDN represents the valid domain name that registrants submitted for	RDN represents the valid domain name that registrants submitted for
	the initial registration.	the initial registration.
	BDN represents the bundled domain name produced according to the bundled domain name	BDN represents the bundled domain name produced according to the bundled domain name
	registration policy.	registration policy.

	In current practice, the number of BDNs is	In current practice, the number of BDNs is

	usually be kept to one according to the registration policy set by	usually kept at one according to the registration policy set by
	the registry.	the registry.


	Both RDN and BDN specified in this document will be registered via EPP. All oth er domain names related to	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 RDN will be blocked.


	</t>	</t>
	<t>

	uLabel in this document is used to express the U-label of an internation
	alized domain name as a series of characters
	where non-ASCII characters will be represented in the format of "&#x
	XXXX;" where XXXX is a UNICODE point by using the XML escaping mechanism.
	U-Label is defined in [RFC5890]. This document chooses this format of li
	teral HTML ampersand codes, not the expected UNICODE native characters,
	is because of that the UNICODE native characters may not be displayed co
	rrectly in some text file readers
	while literal HTML ampersand codes are easy for HTML processors. The imp
	lementation following this document should use UNICODE native characters directl
	y.


	</t>	<t>
		The "uLabel" attribute in this document is used to express the U-label o
		f an Internationalized Domain Name as a series of characters
		where non-ASCII characters will be represented in the format of "&#x
		XXXX;" where XXXX is a Unicode point by using the XML escaping mechanism.
		The U-label is defined in <xref target="RFC5890"/>. This document choose
		s this format of literal HTML ampersand codes, not the expected Unicode characte
		r codes. Unicode characters may not be displayed correctly in some text file rea
		ders, while HTML numeric character references are easy for HTML processors. The
		implementation following this document should use Unicode characters directly.


	<t>	</t>
		<t>
	This document uses the prefix "b-dn" for the namespace "urn:ietf:params:xml:ns: epp:b-dn" throughout.	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	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.	must employ a namespace-aware XML parser and serializer to interpret and output the XML documents.

	</t>	</t>
	<t>	<t>
	In examples, "C:" represents lines sent by a protocol client and "S:" rep	In the examples, "C:" represents lines sent by a protocol client, and "S:" re
	resents lines returned by	presents lines returned by
	a protocol server. Indentation and white space in examples are provided o	a protocol server. Indentation and spacing in the examples are provided o
	nly to illustrate element	nly to illustrate element
	relationships and are not a required feature of this specification.	relationships and are not a required feature of this specification.

	</t>	</t>
	<t>	<t>
	XML is case sensitive. Unless stated otherwise, XML specifications a	XML is case sensitive. Unless stated otherwise, the XML specifications a
	nd examples provided in this	nd examples provided in this
	document must be interpreted in the character case presented to d evelop a conforming implementation.	document must be interpreted in the character case presented to d evelop a conforming implementation.

	</t>	</t>
	</section>	</section>
		<section numbered="true" toc="default">
	<section title="Overview">	<name>Overview</name>
	<t>	<t>
	Domain registries have traditionally adopted a registration model whereby met	Domain registries have usually adopted a registration model whereby metadata rel
	adata relating to a	ating to a
	domain name, such as its expiration date and sponsoring registrar, are st ored as properties of the	domain name, such as its expiration date and sponsoring registrar, are st ored as properties of the

	domain object. The domain object is then considered an atomic unit of registr	domain object. The domain object is then considered an atomic unit of registr
	ation, on which	ation on which
	operations such as update, renewal and deletion may be performed.	operations such as update, renewal, and deletion may be perfor
	</t>	med.
	<t>	</t>
		<t>
	Bundled names brought about the need for multiple domain names to be registered and	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	managed as a single package. In this model, the registry typically accepts

	a domain registration request (i.e. EPP domain <create> command) co ntaining the domain name	a domain registration request (i.e., EPP domain <create> command) co ntaining the domain name
	to be registered. This domain name is referred to as the RDN in this document. A s part of the	to be registered. This domain name is referred to as the RDN in this document. A s part of the
	processing of the registration request, the registry generates a set of bundled names that	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 regis tration policies, and	are related to the RDN, either programmatically or with the guidance of regis tration policies, and
	places them in the registration package together with the RDN.	places them in the registration package together with the RDN.

	</t>	</t>
		<t>
	<t>
	The bundled names share many properties, such as expiration date and sponsori ng	The bundled names share many properties, such as expiration date and sponsori ng
	registrar, by sharing the same domain object.	registrar, by sharing the same domain object.
	So when registrants update any property of a domain object within a bundle packa ge,	So when registrants update any property of a domain object within a bundle packa ge,

	that property will be updated at the same time for all other domain	that property will be updated at the same time for all other domain
	objects in the bundle package.	objects in the bundle package.

	</t>	</t>
	</section>	</section>
		<section numbered="true" toc="default">
	<section title="Requirement for Bundling Registration of Names">	<name>Requirement for Bundling Registration of Names</name>
	<t>	<t>
	The bundled names whether they are in the form of "V-label.TLD" or in the form o	The bundled names, whether they are in the form of "V-label.TLD" or "LABEL.V-tld
	f "LABEL.V-tld" should share	", should share
	some parameters or attributes associated with domain names. Typically, bundled n ames will share the following	some parameters or attributes associated with domain names. Typically, bundled n ames will share the following

	parameters or attributes:<vspace blankLines="0" /></t>	parameters or attributes:</t>
		<ul spacing="normal">
	<t>	<li>
	<list style="symbols">	Registrar ownership
	<t>	</li>
	Registrar Ownership	<li>
	</t>	Registration and expiry dates
	<t>	</li>
	Registration and Expiry Dates	<li>
	</t>	Registrant, admin, billing, and technical contacts
	<t>	</li>
	Registrant, Admin, Billing, and Technical Contacts	<li>
	</t>	Name server association
		</li>
	<t>	<li>
	Name Server Association	Domain status
	</t>	</li>
	<t>	<li>
	Domain Status	Applicable grace periods (add grace period, renew grace period, auto-renew grace
	</t>	period, transfer grace period, and redemption grace period) <xref target="RFC39
	<t>	15"/>
	Applicable grace periods (Add Grace Period, Renewal Grace Period, Auto-Renewal G	</li>
	race Period, Transfer Grace Period,	</ul>
	and Redemption Grace Period)	<t>
	</t>
	</list>
	</t>

	<t>
	Because the domain names are bundled and share the same parameters or attributes , the EPP command should	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" />	do some processing for these requirements:
	</t>	</t>

		<ul spacing="normal">
	<t>	<li>
	<list style="symbols">	When performing a domain <check> command, either the BDN or RDN can be que
	<t>	ried with the EPP command and
	When performing a Domain Check, either BDN or RDN can be queried for the EPP com
	mand, and
	will return the same response.	will return the same response.

	</t>	</li>
	<t>	<li>
	When performing a Domain Info, either BDN or RDN can be queried,	When performing a domain <info> command, either the BDN or RDN can be quer
		ied, and
	the same response will include both BDN and RDN information with the same attrib utes.	the same response will include both BDN and RDN information with the same attrib utes.

	</t>	</li>
	<t>	<li>
	When performing a Domain Create,	When performing a domain <create> command,
	if the domain name is available, both BDN and RDN	if the domain name is available, both the BDN and RDN
	will be registered.	will be registered.

	</t>	</li>
		<li>
	<t>	When performing a domain <delete> command,
	When performing a Domain Delete,	either the BDN or RDN will be accepted. If the domain name is registered, both
	either BDN or RDN will be accepted. If the domain name is registered, both BDN	the BDN and RDN
	and RDN
	will be deleted.	will be deleted.

	</t>	</li>
	<t>	<li>
	When performing a Domain Renew,	When performing a domain <renew> command,
	either BDN or RDN will be accepted. Upon a successful domain renewal, both BDN	either the BDN or RDN will be accepted. Upon a successful domain renewal, both
	and RDN	the BDN and RDN
	will have their expiry date extended by the requested term. Upon a successful d omain	will have their expiry date extended by the requested term. Upon a successful d omain

	renewal, both BDN and RDN will conform to the same renew grace period.	renewal, both the BDN and RDN will conform to the same renew grace period.
	</t>	</li>
		<li>When performing a domain <transfer> command,
	<t>When performing a Domain Transfer,	either the BDN or RDN will be accepted. Upon successful completion of a domain
	either 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
	transfer request, both BDN and RDN will enter a pendingTransfer status. Upon app	approval of the
	roval of the	transfer request, both the BDN and RDN will be owned and managed by the same new
	transfer request, both BDN and RDN will be owned and managed by the same new reg	registrant.
	istrant.	</li>
	</t>	<li>
		When performing a domain <update> command,
	<t>	either the BDN or RDN will be accepted. Any modifications to contact associatio
	When performing a Domain Update,	ns,
	either BDN or RDN will be accepted. Any modifications to contact associations,	name server associations, domain status values, and authorization information wi
	name server associations, domain status values and authorization information wil	ll be
	l be	applied to both the BDN and RDN.
	applied to both BDN and RDN.	</li>
	</t>	</ul>
	</list>	</section>
	</t>	<section numbered="true" toc="default">
		<name>Object Attributes</name>
	</section>	<t>
		This extension defines the following additional elements to the E
	<section title="Object Attributes">	PP domain name mapping
	<t>	<xref target="RFC5731" format="default"/>. All of these additional e
	This extension defines following additional elements to the EPP d	lements are returned from the <domain:info>
	omain name mapping
	<xref target="RFC5731"></xref>. All of these additional elements
	are returned from <domain:info>
	command.	command.

	</t>	</t>
	<section title="RDN">	<section numbered="true" toc="default">
	<t>	<name>RDN</name>
	The RDN is an ASCII name or an IDN with the A-label <xref target="RFC	<t>
	5890"></xref> form.	The RDN is an ASCII name or an IDN with the A-label <xref target="RFC
		5890" format="default"/> form.
	In this document, its corresponding element is <b-dn:rdn>. An o ptional attribute	In this document, its corresponding element is <b-dn:rdn>. An o ptional attribute
	"uLabel" associated with <b-dn:rdn> is used to represent the U -label	"uLabel" associated with <b-dn:rdn> is used to represent the U -label

	<xref target="RFC5890"></xref> form. </t>	<xref target="RFC5890" format="default"/> form. </t>
	<t>	<t>
	For example: <b-dn:rdn uLabel="&#x5B9E;&#x4F8B;.example">	For example: </t>
	xn--fsq270a.example</b-dn:rdn>	<sourcecode name="" type="xml"><![CDATA[
	</t>	<b-dn:rdn uLabel="实例.example"> xn--
	</section>	fsq270a.example</b-dn:rdn>
	<section title="BDN">	]]></sourcecode>
	<t>
	The BDN is an ASCII name or an IDN with the A-label <xref target="RFC	</section>
	5890"></xref> form which is converted from the	<section numbered="true" toc="default">
		<name>BDN</name>
		<t>
		The BDN is an ASCII name or an IDN with the A-label <xref target="RFC
		5890" format="default"/> form that is converted from the
	corresponding BDN. In this document, its corresponding element is <b- dn:bdn>. An optional attribute	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	"uLabel" associated with <b-dn:bdn> is used to represent the U -label

	<xref target="RFC5890"></xref> form.	<xref target="RFC5890" format="default"/> form.
	</t>	</t>
	<t>	<t>
	For example: <b-dn:bdn uLabel="&#x5BE6;&#x4F8B;.example">	For example: </t>
	xn--fsqz41a.example</b-dn:bdn>	<sourcecode name="" type="xml"><![CDATA[
	</t>	<b-dn:bdn uLabel="實例.example"> xn--
	</section>	fsqz41a.example</b-dn:bdn>
		]]></sourcecode>
	</section>	</section>
		</section>
	<section title="EPP Command Mapping">	<section numbered="true" toc="default">
	<t>	<name>EPP Command Mapping</name>
		<t>
	A detailed description of the EPP syntax and semantics can be found in the EP P core protocol	A detailed description of the EPP syntax and semantics can be found in the EP P core protocol

	specification <xref target="RFC5730"></xref>. The command mappings described here are specifically	specification <xref target="RFC5730" format="default"/>. The command mappings de scribed here are specifically
	for use in provisioning and managing bundled names via EPP.	for use in provisioning and managing bundled names via EPP.

	</t>	</t>
	<section title="EPP Query Commands">	<section numbered="true" toc="default">
	<t>	<name>EPP Query Commands</name>
		<t>
	EPP provides three commands to retrieve domain information: <check > to determine if a domain	EPP provides three commands to retrieve domain information: <check > to determine if a domain
	object can be provisioned within a repository, <info> to retrieve d etailed information	object can be provisioned within a repository, <info> to retrieve d etailed information
	associated with a domain object, and <transfer> to retrieve domain- object transfer status	associated with a domain object, and <transfer> to retrieve domain- object transfer status
	information.	information.

	</t>	</t>
	<section title="EPP <check> Command">	<section numbered="true" toc="default">
	<t>	<name>EPP <check> Command</name>
	This extension does not add any element to the EPP <check>	<t>
	command or <check> response described in the EPP domain name mapping <	This extension does not add any element to the EPP <check>
	xref target="RFC5731"></xref>. However, when either RDN or BDN is sent for check	command or <check> response described in the EPP domain name mapping <
	, response should contain both RDN and BDN information, which may also give some	xref target="RFC5731" format="default"/>. However, when either the RDN or BDN is
	explanation in the reason field to tell the registrant that the associated doma	sent for a check, the response should contain both RDN and BDN information, whi
	in name is a produced name according to some bundle domain name policy.	ch may also give some explanation in the reason field to tell the registrant tha
	</t>	t the associated domain name is a produced name according to some bundle domain
	<figure><artwork>	name policy.
	<![CDATA[	</t>
	Example <check> response:	<figure>
	S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>	<name>Example <check> Response</name>
		<sourcecode name="Example <check> 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:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	S: <response>	S: <response>
	S: <result code="1000">	S: <result code="1000">
	S: <msg>Command completed successfully</msg>	S: <msg>Command completed successfully</msg>
	S: </result>	S: </result>
	S: <resData>	S: <resData>
	S: <domain:chkData	S: <domain:chkData
	S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">	S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
	S: <domain:cd>	S: <domain:cd>
	S: <domain:name avail="1">	S: <domain:name avail="1">

	skipping to change at line 456 ¶	skipping to change at line 386 ¶
	S: </domain:reason>	S: </domain:reason>
	S: </domain:cd>	S: </domain:cd>
	S: </domain:chkData>	S: </domain:chkData>
	S: </resData>	S: </resData>
	S: <trID>	S: <trID>
	S: <clTRID>ABC-12345</clTRID>	S: <clTRID>ABC-12345</clTRID>
	S: <svTRID>54322-XYZ</svTRID>	S: <svTRID>54322-XYZ</svTRID>
	S: </trID>	S: </trID>
	S: </response>	S: </response>
	S:</epp>	S:</epp>

	]]></artwork>	]]></sourcecode>
	</figure>	</figure>
		</section>
	</section>	<section numbered="true" toc="default">
	<section title="EPP <info> Command">	<name>EPP <info> Command</name>
	<t>	<t>
	This extension does not add any element to the EPP <info> c ommand described in the EPP domain	This extension does not add any element to the EPP <info> c ommand described in the EPP domain

	mapping <xref target="RFC5731"></xref>. However, additional elements are defined for the	mapping <xref target="RFC5731" format="default"/>. However, addition al elements are defined for the
	<info> response.	<info> response.

	</t>	</t>
	<t>	<t>
	When an <info> command has been processed successfully, the EPP &lt ;resData> element must	When an <info> command has been processed successfully, the EPP &lt ;resData> element must

	contain child elements as described in the EPP domain mapping <xref t arget="RFC5731"></xref>. In	contain child elements as described in the EPP domain mapping <xref t arget="RFC5731" format="default"/>. In
	addition, unless some registration policy has some special processing, the EPP & lt;extension> element should contain a child <b-dn:infData> element tha t	addition, unless some registration policy has some special processing, the EPP & lt;extension> element should contain a child <b-dn:infData> element tha t
	identifies the extension namespace if the domain object has data asso ciated with this extension and	identifies the extension namespace if the domain object has data asso ciated with this extension and

	based on its registration policy. The <b-dn:infData> element contains the <b-dn:bundle> which	based on its registration policy. The <b-dn:infData> element contains the <b-dn:bundle>, which
	has the following child elements:	has the following child elements:

	</t>	</t>
	<t>	<ul spacing="normal">
	<list style="symbols">	<li>
	<t>	A <b-dn:rdn> element that contains the RDN, along with the attribute descr
	An <b-dn:rdn> element that contains the RDN, along with the attribute desc	ibed below.
	ribed below.	</li>
	</t>	<li>
	<t>
	An optional <b-dn:bdn> element that contains the BDN, along w ith the attribute described	An optional <b-dn:bdn> element that contains the BDN, along w ith the attribute described
	below.	below.

	</t>	</li>
		</ul>
	</list>	<t>
	</t>
	<t>
	The above elements contain the following attribute:	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.	An optional "uLabel" attribute represents the U-label of the element.

	</t>	</li>
		</ul>
	</list>
	</t>
	<figure>	<figure>

	<artwork><![CDATA[	<name>Example <info> Response for an Authorized Client</name>
	Example <info> response for an authorized client:	<sourcecode name="" type="xml"><![CDATA[
		S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
	S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
	S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">	S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	S: <response>	S: <response>
	S: <result code="1000">	S: <result code="1000">
	S: <msg>Command completed successfully</msg>	S: <msg>Command completed successfully</msg>
	S: </result>	S: </result>
	S: <resData>	S: <resData>
	S: <domain:infData	S: <domain:infData
	S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">	S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
	S: <domain:name>xn--fsq270a.example</domain:name>	S: <domain:name>xn--fsq270a.example</domain:name>
	S: <domain:roid>58812678-domain</domain:roid>	S: <domain:roid>58812678-domain</domain:roid>

	skipping to change at line 548 ¶	skipping to change at line 473 ¶
	S: </b-dn:bdn>	S: </b-dn:bdn>
	S: </b-dn:bundle>	S: </b-dn:bundle>
	S: </b-dn:infData>	S: </b-dn:infData>
	S: </extension>	S: </extension>
	S: <trID>	S: <trID>
	S: <clTRID>ABC-12345</clTRID>	S: <clTRID>ABC-12345</clTRID>
	S: <svTRID>54322-XYZ</svTRID>	S: <svTRID>54322-XYZ</svTRID>
	S: </trID>	S: </trID>
	S: </response>	S: </response>
	S:</epp>	S:</epp>

	]]></artwork>	]]></sourcecode>
	</figure>	</figure>
	<t>	<t>
	<info> Response for the unauthorized client has not been changed, see	The <info> response for the unauthorized client has not been changed, see
	<xref target="RFC5731"></xref> for detail.	<xref target="RFC5731" format="default"/> for details.
	</t>	</t>
	<t>	<t>
	An EPP error response must be returned if an <info> command cannot be p rocessed for any reason.	An EPP error response must be returned if an <info> command cannot be p rocessed for any reason.

	</t>	</t>
	</section>	</section>
	<section title="EPP <transfer> Query Command">	<section numbered="true" toc="default">
	<t>	<name>EPP <transfer> Query Command</name>
	This extension does not add any element to the EPP <transfer&g	<t>
	t; command or <transfer> response described in the EPP domain mapping	This extension does not add any element to the EPP <transfer&g
	<xref target="RFC5731"></xref>.	t; command or <transfer> response described in the EPP domain mapping
	</t>	<xref target="RFC5731" format="default"/>.
	</section>	</t>
	</section>	</section>
		</section>
	<section title="EPP Transform Commands">	<section numbered="true" toc="default">
	<t>	<name>EPP Transform Commands</name>
		<t>
	EPP provides five commands to transform domain objects: <create> to create an instance of a	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 o bject, <renew> to extend the	domain object, <delete> to delete an instance of a domain o bject, <renew> to extend the
	validity period of a domain object, <transfer> to manage do main object sponsorship changes,	validity period of a domain object, <transfer> to manage do main object sponsorship changes,
	and <update> to change information associated with a domain object.	and <update> to change information associated with a domain object.

	</t>	</t>
		<t>
	<t>	When these commands have been processed successfully, the EPP <resData> el
	When theses commands have been processed successfully, the EPP <resData> e	ement must
	lement must	contain child elements as described in the EPP domain mapping <xref t
	contain child elements as described in the EPP domain mapping <xref t	arget="RFC5731" format="default"/>. Unless some registration policy has some spe
	arget="RFC5731"></xref>. Unless some registration policy has some special proces	cial processing,
	sing,
	this EPP <extension> element should contain	this EPP <extension> element should contain

	the <b-dn:bundle> which	the <b-dn:bundle>, which
	has the following child elements:	has the following child elements:

	</t>	</t>
	<t>	<ul spacing="normal">
	<list style="symbols">	<li>
	<t>	A <b-dn:rdn> element that contains the RDN, along with the attribute descr
	An <b-dn:rdn> element that contains the RDN, along with the attribute desc	ibed below.
	ribed below.	</li>
	</t>	<li>
	<t>
	An optional <b-dn:bdn> element that contains the BDN, along with the at tribute described	An optional <b-dn:bdn> element that contains the BDN, along with the at tribute described
	below.	below.

	</t>	</li>
		</ul>
	</list>	<t>
	</t>
	<t>
	The above elements contain the following attribute:	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.	An optional "uLabel" attribute represents the U-label of the element.

	</t>	</li>
		</ul>
	</list>	<section numbered="true" toc="default">
	</t>	<name>EPP <create> Command</name>
		<t>
	<section title="EPP <create> Command">
	<t>
	This extension defines additional elements to extend the EPP <create> c ommand described in the	This extension defines additional elements to extend the EPP <create> c ommand described in the

	EPP domain name mapping <xref target="RFC5731"></xref> for bundled names	EPP domain name mapping <xref target="RFC5731" format="default"/> for bun
	registration.	dled names registration.
	</t>	</t>
	<t>	<t>
	In addition to the EPP command elements described in the EPP domain m apping	In addition to the EPP command elements described in the EPP domain m apping

	<xref target="RFC5731"></xref>, the <create> command shall cont ain an <extension>	<xref target="RFC5731" format="default"/>, the <create> command sh all contain an <extension>
	element.	element.

	Unless some registration policy has some special processing, the <extension&g t; element should contain a child <b-dn:create> element that	Unless some registration policy has some special processing, the <extension&g t; element should contain a child <b-dn:create> element that

	identifies the bundle namespace, and a child <b-dn:rdn> element that ident	identifies the bundle namespace and a child <b-dn:rdn> element that identi
	ifies the U-Label form	fies the U-label form
	of the registered domain name with the uLabel attribute. U-Label is used for eas	of the registered domain name with the "uLabel" attribute. The U-label is used f
	y reading by the registrants and easy debugging by the registrars and the regist	or easy reading by the registrants and easy debugging by the registrars and the
	ries.	registries.
		</t>
	</t>
	<figure>	<figure>

	<artwork><![CDATA[	<name>Example <create> Command</name>
	Example <create> command:	<sourcecode name="" type="xml"><![CDATA[
		C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
	C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
	C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">	C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	C: <command>	C: <command>
	C: <create>	C: <create>
	C: <domain:create	C: <domain:create
	C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">	C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
	C: <domain:name>xn--fsq270a.example</domain:name>	C: <domain:name>xn--fsq270a.example</domain:name>
	C: <domain:period unit="y">2</domain:period>	C: <domain:period unit="y">2</domain:period>
	C: <domain:registrant>123</domain:registrant>	C: <domain:registrant>123</domain:registrant>
	C: <domain:contact type="admin">123</domain:contact>	C: <domain:contact type="admin">123</domain:contact>
	C: <domain:contact type="tech">123</domain:contact>	C: <domain:contact type="tech">123</domain:contact>

	skipping to change at line 648 ¶	skipping to change at line 567 ¶
	C: <b-dn:create	C: <b-dn:create
	C: xmlns:b-dn="urn:ietf:params:xml:ns:epp:b-dn">	C: xmlns:b-dn="urn:ietf:params:xml:ns:epp:b-dn">
	C: <b-dn:rdn uLabel="实例.example">	C: <b-dn:rdn uLabel="实例.example">
	C: xn--fsq270a.example	C: xn--fsq270a.example
	C: </b-dn:rdn>	C: </b-dn:rdn>
	C: </b-dn:create>	C: </b-dn:create>
	C: </extension>	C: </extension>
	C: <clTRID>ABC-12345</clTRID>	C: <clTRID>ABC-12345</clTRID>
	C: </command>	C: </command>
	C:</epp>	C:</epp>

	]]></artwork>	]]></sourcecode>
	</figure>	</figure>
		<t>
	<t>
	When a <create> command has been processed successfully, the EPP & lt;creData> element	When a <create> command has been processed successfully, the EPP & lt;creData> element

	must contain child elements as described in the EPP domain mapping <x ref target="RFC5731"></xref>.	must contain child elements as described in the EPP domain mapping <x ref target="RFC5731" format="default"/>.

	In addition, unless some registration policy has some special processing, the EP P <extension> element should contain a child <b-dn:creData> element	In addition, unless some registration policy has some special processing, the EP P <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	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 contai ns the <b-dn:bundle>	and based on its registration policy. The <b-dn:creData> element contai ns the <b-dn:bundle>
	element.	element.

	</t>	</t>

	<figure>	<figure>

	<artwork><![CDATA[	<name>Example <create> Response</name>
	Example <create> response:	<sourcecode name="" type="xml"><![CDATA[
		S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
	S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
	S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">	S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	S: <response>	S: <response>
	S: <result code="1000">	S: <result code="1000">
	S: <msg>Command completed successfully</msg>	S: <msg>Command completed successfully</msg>
	S: </result>	S: </result>
	S: <resData>	S: <resData>
	S: <domain:creData	S: <domain:creData
	S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">	S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
	S: <domain:name>xn--fsq270a.example</domain:name>	S: <domain:name>xn--fsq270a.example</domain:name>
	S: <domain:crDate>2019-04-03T22:00:00.0Z</domain:crDate>	S: <domain:crDate>2019-04-03T22:00:00.0Z</domain:crDate>

	skipping to change at line 698 ¶	skipping to change at line 614 ¶
	S: </b-dn:bdn>	S: </b-dn:bdn>
	S: </b-dn:bundle>	S: </b-dn:bundle>
	S: </b-dn:creData>	S: </b-dn:creData>
	S: </extension>	S: </extension>
	S: <trID>	S: <trID>
	S: <clTRID>ABC-12345</clTRID>	S: <clTRID>ABC-12345</clTRID>
	S: <svTRID>54322-XYZ</svTRID>	S: <svTRID>54322-XYZ</svTRID>
	S: </trID>	S: </trID>
	S: </response>	S: </response>
	S:</epp>	S:</epp>

	]]></artwork>	]]></sourcecode>
	</figure>	</figure>
	<!--<t>
	<create> Response for the unauthorized client has not been changed,
	see
	<xref target="RFC5731"></xref> for detail.
	</t>-->
	<t>	<t>

	An EPP error response must be returned if an <create> command cannot be processed for any	An EPP error response must be returned if a <create> command cannot b e processed for any
	reason.	reason.

	</t>	</t>
	</section>	</section>
		<section numbered="true" toc="default">
	<section title="EPP <delete> Command">	<name>EPP <delete> Command</name>
	<t>	<t>
	This extension does not add any element to the EPP <delete> command described in the EPP	This extension does not add any element to the EPP <delete> command described in the EPP

	domain mapping <xref target="RFC5731"></xref>. However, additional elemen ts are defined for the	domain mapping <xref target="RFC5731" format="default"/>. However, additiona l elements are defined for the
	<delete> response.	<delete> response.

	</t>	</t>
	<t>	<t>
	When a <delete> command has been processed successfully, the EPP <delDa ta> element must	When a <delete> command has been processed successfully, the EPP <delDa ta> element must

	contain child elements as described in the EPP domain mapping <xref t arget="RFC5731"></xref>.	contain child elements as described in the EPP domain mapping <xref t arget="RFC5731" format="default"/>.
	In addition, unless some registration policy has some special processing, the EP P <extension> element should contain a child <b-dn:delData> element that	In addition, unless some registration policy has some special processing, the EP P <extension> element should contain a child <b-dn:delData> element that
	identifies the extension namespace if the domain object has data asso ciated with this extension and	identifies the extension namespace if the domain object has data asso ciated with this extension and
	based on its registration policy. The <b-dn:delData> element should contai n the <b-dn:bundle>	based on its registration policy. The <b-dn:delData> element should contai n the <b-dn:bundle>
	element.	element.

	</t>	</t>

	<figure>	<figure>

	<artwork><![CDATA[	<name>Example <delete> Response</name>
	Example <delete> response:	<sourcecode name="" type="xml"><![CDATA[
		S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
	S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
	S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">	S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	S: <response>	S: <response>
	S: <result code="1000">	S: <result code="1000">
	S: <msg>Command completed successfully</msg>	S: <msg>Command completed successfully</msg>
	S: </result>	S: </result>
	S: <extension>	S: <extension>
	S: <b-dn:delData	S: <b-dn:delData
	S: xmlns:b-dn="urn:ietf:params:xml:ns:epp:b-dn">	S: xmlns:b-dn="urn:ietf:params:xml:ns:epp:b-dn">
	S: <b-dn:bundle>	S: <b-dn:bundle>
	S: <b-dn:rdn uLabel="实例.example">	S: <b-dn:rdn uLabel="实例.example">

	skipping to change at line 754 ¶	skipping to change at line 664 ¶
	S: </b-dn:bdn>	S: </b-dn:bdn>
	S: </b-dn:bundle>	S: </b-dn:bundle>
	S: </b-dn:delData>	S: </b-dn:delData>
	S: </extension>	S: </extension>
	S: <trID>	S: <trID>
	S: <clTRID>ABC-12345</clTRID>	S: <clTRID>ABC-12345</clTRID>
	S: <svTRID>54321-XYZ</svTRID>	S: <svTRID>54321-XYZ</svTRID>
	S: </trID>	S: </trID>
	S: </response>	S: </response>
	S:</epp>	S:</epp>

	]]></artwork>	]]></sourcecode>
	</figure>	</figure>
	<t>	<t>
	An EPP error response must be returned if a <delete> command cannot be processed for any	An EPP error response must be returned if a <delete> command cannot be processed for any
	reason.	reason.

	</t>	</t>
	</section>	</section>
		<section numbered="true" toc="default">
	<section title="EPP <renew> Command">	<name>EPP <renew> Command</name>
	<t>	<t>

	This extension does not add any element to the EPP <renew> command	This extension does not add any element to the EPP <renew> command

	described in the EPP domain name mapping <xref target="RFC5731"></xref>. Howe	described in the EPP domain name mapping <xref target="RFC5731" format="defau
	ver, when either RDN or BDN is sent for renew,	lt"/>. However, when either the RDN or BDN is sent for renewal,
	response should contain both RDN and BDN information.	the response should contain both RDN and BDN information.

	When the command has been processed successfully,	When the command has been processed successfully,
	the EPP <extension> element shall be contained in the response if the do main object has data associated with bundled names.	the EPP <extension> element shall be contained in the response if the do main object has data associated with bundled names.
	Unless some registration policy has some special processing, this EPP <exte nsion> element should contain	Unless some registration policy has some special processing, this EPP <exte nsion> element should contain

	the <b-dn:renData> which contains <b-dn:bundle> element.	the <b-dn:renData>, which contains the <b-dn:bundle> element.
		</t>
	</t>

	<figure>	<figure>

	<artwork><![CDATA[	<name>Example <renew> Response</name>
	Example <renew> response:	<sourcecode name="" type="xml"><![CDATA[

	S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>	S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
	S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">	S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	S: <response>	S: <response>
	S: <result code="1000">	S: <result code="1000">
	S: <msg>Command completed successfully</msg>	S: <msg>Command completed successfully</msg>
	S: </result>	S: </result>
	S: <resData>	S: <resData>
	S: <domain:renData	S: <domain:renData
	S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">	S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
	S: <domain:name>xn--fsq270a.example</domain:name>	S: <domain:name>xn--fsq270a.example</domain:name>

	skipping to change at line 812 ¶	skipping to change at line 719 ¶
	S: </b-dn:bdn>	S: </b-dn:bdn>
	S: </b-dn:bundle>	S: </b-dn:bundle>
	S: </b-dn:renData>	S: </b-dn:renData>
	S: </extension>	S: </extension>
	S: <trID>	S: <trID>
	S: <clTRID>ABC-12345</clTRID>	S: <clTRID>ABC-12345</clTRID>
	S: <svTRID>54322-XYZ</svTRID>	S: <svTRID>54322-XYZ</svTRID>
	S: </trID>	S: </trID>
	S: </response>	S: </response>
	S:</epp>	S:</epp>

	]]></artwork>	]]></sourcecode>
	</figure>	</figure>
		</section>
	</section>	<section numbered="true" toc="default">
		<name>EPP <transfer> Command</name>
	<section title="EPP <transfer> Command">	<t>
	<t>

	This extension does not add any element to the EPP <transfer& gt; command	This extension does not add any element to the EPP <transfer& gt; command

	described in the EPP domain name mapping <xref target="RFC5731"></xref>.	described in the EPP domain name mapping <xref target="RFC5731" format="defau lt"/>.

	However, additional elements are defined for the <transfer> response in th e EPP object mapping.	However, additional elements are defined for the <transfer> response in th e EPP object mapping.

	When the command has been processed successfully,	When the command has been processed successfully,
	the EPP <extension> element shall be contained in the response if the do main object has data associated with bundled names.	the EPP <extension> element shall be contained in the response if the do main object has data associated with bundled names.
	Unless some registration policy has some special processing, this EPP <exte nsion> element should contain	Unless some registration policy has some special processing, this EPP <exte nsion> element should contain

	the <b-dn:trnData> which contains <b-dn:bundle> element.	the <b-dn:trnData>, which contains the <b-dn:bundle> element.

	</t>


		</t>
	<figure>	<figure>

	<artwork><![CDATA[	<name>Example <transfer> Response</name>
	Example <transfer> response:	<sourcecode name="" type="xml"><![CDATA[

	S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>	S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
	S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">	S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	S: <response>	S: <response>
	S: <result code="1001">	S: <result code="1001">
	S: <msg>Command completed successfully; action pending</msg>	S: <msg>Command completed successfully; action pending</msg>
	S: </result>	S: </result>
	S: <resData>	S: <resData>
	S: <domain:trnData	S: <domain:trnData
	S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">	S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
	S: <domain:name>xn--fsq270a.example</domain:name>	S: <domain:name>xn--fsq270a.example</domain:name>

	skipping to change at line 873 ¶	skipping to change at line 777 ¶
	S: </b-dn:bdn>	S: </b-dn:bdn>
	S: </b-dn:bundle>	S: </b-dn:bundle>
	S: </b-dn:trnData>	S: </b-dn:trnData>
	S: </extension>	S: </extension>
	S: <trID>	S: <trID>
	S: <clTRID>ABC-12345</clTRID>	S: <clTRID>ABC-12345</clTRID>
	S: <svTRID>54322-XYZ</svTRID>	S: <svTRID>54322-XYZ</svTRID>
	S: </trID>	S: </trID>
	S: </response>	S: </response>
	S:</epp>	S:</epp>

	]]></artwork>	]]></sourcecode>
	</figure>	</figure>
		</section>
	</section>	<section numbered="true" toc="default">
		<name>EPP <update> Command</name>
	<section title="EPP <update> Command">	<t>

	<t>

	This extension does not add any element to the EP P <update> command	This extension does not add any element to the EP P <update> command

	described in the EPP domain name mapping <xref target="RFC5731"></xref>.	described in the EPP domain name mapping <xref target="RFC5731" format="defau lt"/>.
	However, additional elements are defined for the <update> response in the EPP object mapping.	However, additional elements are defined for the <update> response in the EPP object mapping.

	When the command has been processed successfully,	When the command has been processed successfully,
	the EPP <extension> element shall be contained in the response if the do main object has data associated with bundled names.	the EPP <extension> element shall be contained in the response if the do main object has data associated with bundled names.
	Unless some registration policy has some special processing, this EPP <exte nsion> element should contain	Unless some registration policy has some special processing, this EPP <exte nsion> element should contain

	the <b-dn:upData> which contains <b-dn:bundle> element.	the <b-dn:upData>, which contains the <b-dn:bundle> element.

	</t>


		</t>
	<figure>	<figure>

	<artwork><![CDATA[	<name>Example <update> Response</name>
	Example <update> response:	<sourcecode name="" type="xml"><![CDATA[

	S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>	S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
	S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">	S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	S: <response>	S: <response>
	S: <result code="1000">	S: <result code="1000">
	S: <msg>Command completed successfully</msg>	S: <msg>Command completed successfully</msg>
	S: </result>	S: </result>
	S: <extension>	S: <extension>
	S: <b-dn:upData	S: <b-dn:upData
	S: xmlns:b-dn="urn:ietf:params:xml:ns:epp:b-dn">	S: xmlns:b-dn="urn:ietf:params:xml:ns:epp:b-dn">
	S: <b-dn:bundle>	S: <b-dn:bundle>

	skipping to change at line 922 ¶	skipping to change at line 822 ¶
	S: </b-dn:bdn>	S: </b-dn:bdn>
	S: </b-dn:bundle>	S: </b-dn:bundle>
	S: </b-dn:upData>	S: </b-dn:upData>
	S: </extension>	S: </extension>
	S: <trID>	S: <trID>
	S: <clTRID>ABC-12345</clTRID>	S: <clTRID>ABC-12345</clTRID>
	S: <svTRID>54322-XYZ</svTRID>	S: <svTRID>54322-XYZ</svTRID>
	S: </trID>	S: </trID>
	S: </response>	S: </response>
	S:</epp>	S:</epp>

	]]></artwork>	]]></sourcecode>
	</figure>	</figure>
		</section>
	</section>	</section>
	</section>	</section>
	</section>	<section anchor="formal" numbered="true" toc="default">
		<name>Formal Syntax</name>
	<section title="Formal Syntax">	<t>
	<t>
	An EPP object name mapping extension for bundled names is specified in XML Schem a notation. The	An EPP object name mapping extension for bundled names is specified in XML Schem a notation. The
	formal syntax presented here is a complete schema representation of t he object mapping suitable for	formal syntax presented here is a complete schema representation of t he object mapping suitable for
	automated validation of EPP XML instances. The BEGIN and END tags are not part of the schema; they	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 r egistration purposes.	are used to note the beginning and ending of the schema for URI r egistration purposes.

	</t>	</t>
	<figure>	<sourcecode name="" type="xml" markers="true"><![CDATA[
	<artwork><![CDATA[
	BEGIN
	<?xml version="1.0" encoding="UTF-8"?>	<?xml version="1.0" encoding="UTF-8"?>

	<schema targetNamespace="urn:ietf:params:xml:ns:epp:b-dn"	<schema targetNamespace="urn:ietf:params:xml:ns:epp:b-dn"
	xmlns:b-dn="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:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
	xmlns="http://www.w3.org/2001/XMLSchema"	xmlns="http://www.w3.org/2001/XMLSchema"
	elementFormDefault="qualified">	elementFormDefault="qualified">

	<!--	<!--
	Import common element types.	Import common element types.

	skipping to change at line 1012 ¶	skipping to change at line 909 ¶
	<extension base="eppcom:labelType">	<extension base="eppcom:labelType">
	<attribute name="uLabel" type="eppcom:labelType"/>	<attribute name="uLabel" type="eppcom:labelType"/>
	</extension>	</extension>
	</simpleContent>	</simpleContent>
	</complexType>	</complexType>

	<!--	<!--
	End of schema.	End of schema.
	-->	-->
	</schema>	</schema>

		]]></sourcecode>
	END	</section>
	]]></artwork>	<section anchor="Internationalization" numbered="true" toc="default">
	</figure>	<name>Internationalization Considerations</name>
	</section>	<t>
		EPP is represented in XML, which provides support for encoding information us
	<section title="Internationalization Considerations" anchor="Internationa	ing the Unicode
	lization">	character set and its more compact representations, including UTF-8. Conforman
	<t>	t XML processors
	EPP is represented in XML, which provides native support for encoding informa
	tion using the Unicode
	character set and its more compact representations including UTF-8. Conforman
	t XML processors
	recognize both UTF-8 and UTF-16. Though XML includes provisions t o identify and use other character	recognize both UTF-8 and UTF-16. Though XML includes provisions t o identify and use other character
	encodings through use of an "encoding" attribute in an <?xml?> declarat ion, use of UTF-8 is	encodings through use of an "encoding" attribute in an <?xml?> declarat ion, use of UTF-8 is
	recommended.	recommended.

	</t>	</t>
	<t>	<t>
	As an extension of the EPP domain name mapping, the elements, and element	As an extension of the EPP domain name mapping, the elements and element
	content described in this	content described in this
	document must inherit the internationalization conventions used to repres ent higher-layer domain	document must inherit the internationalization conventions used to repres ent higher-layer domain
	and core protocol structures present in an XML instance that includes thi s extension.	and core protocol structures present in an XML instance that includes thi s extension.

	</t>	</t>
	</section>	</section>
		<section anchor="Iana" numbered="true" toc="default">
	<section title="IANA Considerations" anchor="Iana">	<name>IANA Considerations</name>
		<section anchor="Iana1" numbered="true" toc="default">
	<section title="XML Namespace and XML Schema" anchor="Iana1">	<name>XML Namespace and XML Schema</name>
		<t>
	<t>
	This document uses URNs to describe XML namespaces and XML schemas	This document uses URNs to describe XML namespaces and XML schemas

	conforming to a registry mechanism described in [RFC3688].	conforming to a registry mechanism described in <xref target="RFC3688"/>.
	</t>	</t>
	<section title="BDN Namespace" anchor="Iana11">	<section anchor="Iana11" numbered="true" toc="default">
		<name>BDN Namespace</name>
	<t>	<t>
	IANA is requested to make an assignment from the IETF XML Registry	IANA has assigned the following for the BDN namespace in the "ns" subregistry
	"ns" registry as follows for the BDN namespace with this document	of the "IETF XML Registry", with this document
	as the reference:	as the reference:

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

	<section title="BDN XML Schema" anchor="Iana12">

	<t>
	IANA is requested to make an assignment from the IETF XML Registry
	"schema" registry as follows for the BDN XML schema with this
	document as the reference:	document as the reference:

	</t>	</t>
		<dl spacing="compact">
	<t>	<dt>
	<list style="symbols">	URI:</dt><dd>urn:ietf:params:xml:schema:epp:b-dn</dd>
	<t>
	URI: urn:ietf:params:xml:schema:epp:b-dn
	</t>
	<t>
	Registrant Contact: See the "Author's Address" section of this docume
	nt.
	</t>
	<t>
	XML: See the "Formal Syntax" section of this document.
	</t>
	</list>
	</t>

	</section>

	</section>


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

	</t>	</t>
		<dl spacing="compact">
	<t>	<dt>
	<list style="symbols">	Name of Extension:</dt><dd>"Domain Name Mapping Extension for Strict Bundling Re
	<t>	gistration"</dd>
	Name of Extension: "Domain Name Mapping Extension for Strict Bundling Registrati
	on"
	</t>
	<t>
	Document status: Informational
	</t>
	<t>
	Reference: This document
	</t>

	<t>
	Registrant Name and Email Address: See the "Author's Address" sectio
	n of this document.
	</t>

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

	<t>
	IPR Disclosure: https://datatracker.ietf.org/ipr/2479
	</t>

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

	</list>
	</t>
	</section>
	</section>

	<section title="Security Considerations" anchor="security">

	<t>
	Normally, the EPP server will only be connected by the authorized EPP c
	lient
	which knows whether the EPP server supports the extension described in
	this document via out of band service.
	The EPP client should avoid to send this extension to the unimplemented
	EPP server. In case that
	a client that supports this document sends a request to a server that doe
	s not support this document, the server will return the result code 2103 accordi
	ng to the section 3 of RFC5730<xref target="RFC5730"></xref>.


	Section 3 of RFC5730<xref target="RFC5730"></xref> has the following information	<dt>
	for result code 2103.	Document Status:</dt><dd>Informational
		</dd>
		<dt>
		Reference:</dt><dd>This document
		</dd>
		<dt>
		Registrant Name and Email Address:</dt><dd> See the "Authors' Addresses" section
		of this document.
		</dd>
		<dt>
		TLDs:</dt><dd>Any
		</dd>
		<dt>
		IPR 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 anchor="security" numbered="true" toc="default">
		<name>Security Considerations</name>
		<t>
		Normally, the EPP server will only be connected by the authorized EPP c
		lient,
		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 s
		erver that does not support this document, the server will return the result cod
		e 2103 according to <xref target="RFC5730" sectionFormat="of" section="3"/>.


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


	2103 "Unimplemented extension"	</t>


	This response code must be returned when a server receives	<blockquote>
		<t> 2103 "Unimplemented extension"</t>
		<t>
		This response code <bcp14>MUST</bcp14> be returned when a server r
		eceives
	a valid EPP command element that contains a protocol	a valid EPP command element that contains a protocol

	command extension that is not implemented by the server.	command extension that is not implemented by the server.</t></bloc
	</artwork>	kquote>
	</figure>
	</t>


	<t>	<t>
	Some registries and registrars have more than 15 years experience of the	Some registries and registrars have more than 15 years' experience with
	bundled registration of domain names (especially Chinese domain names).	the bundled registration of domain names (especially Chinese Domain Names).
	They have not found any significant security issues. One principle that	They have not found any significant security issues. One principle that
	the registry and registrar should let the registrants know is 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.	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	The registrants for bundled domain names should remember this principle
	when doing some operations to these domain names.	when performing operations to these domain names.

	<xref target="RFC5730"></xref> also introduces some security consideration.
	</t>


	<t> This document	<xref target="RFC5730" format="default"/> also introduces some security consider
	does not take a position regarding whether or not the bundled domain names share	ation.
	a DS/DNSKEY key.	</t>
		<t> 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 record
		s.
	The DNS administrator can choose whether DS/DNSKEY information can be shared or not.	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	If a DS/DNSKEY key is shared, then the bundled domain names share fate if there is a key
	compromise.</t>	compromise.</t>

	</section>	</section>

	<section title="Implementation Status and some clarifications" an
	chor="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 se
	cond 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 (an
	d vice-versa for registrations in .ong).
	</t>

	<t>
	Patrick Mevzek has released a new version of Net::DRI, an EPP client (Pe
	rl 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> an
	d
	<xref target="RFC5731"></xref> and the following ones of CNNIC: Weiping Y
	ang, Chao Qi.

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

	</t>
	</section>

	</middle>	</middle>


	<back>	<back>

	<references title="Normative References">	<references>
		<name>References</name>
	&RFC3688;	<references>
	&RFC5730;	<name>Normative References</name>
	&RFC5731;	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	&RFC5890;	FC.3688.xml"/>
	&RFC5891;	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	&RFC5892;	FC.5730.xml"/>
	&RFC7451;	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.5731.xml"/>
	<reference anchor="W3C.REC-xml-20040204"	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	target="http://www.w3.org/TR/2004/REC-xml-200402	FC.5890.xml"/>
	04">	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<front>	FC.5891.xml"/>
	<title>"Extensible Markup Language (XML) 1.0 (Third Edition	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	)",	FC.5892.xml"/>
	World Wide Web Consortium FirstEdition REC-xml-20040204</ti	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	tle>	FC.7451.xml"/>
	<author initials="T" surname="Bray">	<reference anchor="W3C.REC-xml-20040204" target="http://www.w3.org/TR/20
	<organization></organization>	04/REC-xml-20040204">
	</author>	<front>
	<author initials="J" surname="Paoli">	<title>Extensible Markup Language (XML) 1.0 (Third Edition)</title>
	<organization></organization>	<author initials="T" surname="Bray">
	</author>	<organization/>
	<author initials="C" surname="Sperberg-McQueen">	</author>
	<organization></organization>	<author initials="J" surname="Paoli">
	</author>	<organization/>
	<author initials="E" surname="Maler">	</author>
	<organization></organization>	<author initials="C.M." surname="Sperberg-McQueen">
	</author>	<organization/>
	<author initials="F" surname="Yergeau">	</author>
	<organization></organization>	<author initials="E" surname="Maler">
	</author>	<organization/>
	<date month="February" year="2004" />	</author>
	</front>	<author initials="F" surname="Yergeau">
	</reference>	<organization/>
		</author>
	<reference anchor="W3C.REC-xmlschema-1-20041028"	<date month="February" year="2004"/>
	target="http://www.w3.org/TR/2004/REC-xmlschema-	</front>
	1-20041028">	<refcontent>W3C Recommendation REC-xml-20040204</refcontent>
	<front>	</reference>
	<title>"XML Schema Part 1: Structures Second Edition", World Wi
	de
	Web Consortium Recommendation REC-xmlschema-1-20041028</title>
	<author initials="H" surname="Thompson">
	<organization></organization>
	</author>
	<author initials="D" surname="Beech">
	<organization></organization>
	</author>
	<author initials="M" surname="Maloney">
	<organization></organization>
	</author>
	<author initials="N" surname="Mendelsohn">
	<organization></organization>
	</author>
	<date month="October" year="2004" />
	</front>
	</reference>

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


	<references title="Informative References">	<reference anchor="W3C.REC-xmlschema-1-20041028" target="http://www.w3.o
	&RFC4290;	rg/TR/2004/REC-xmlschema-1-20041028">
	&RFC3743;	<front>
	<!--<reference anchor="Final.Integrated.Issues.Report"	<title>XML Schema Part 1: Structures Second Edition</title>
	target="http://www.icann.org/en/topics/idn/idn-v	<author initials="H" surname="Thompson">
	ip-integrated-issues-final-clean-20feb12-en.pdf">	<organization/>
	<front>	</author>
	<title>The IDN Variant Issues Project: A Study of Issues Re	<author initials="D" surname="Beech">
	lated to the Management of	<organization/>
	IDN Variant TLDs</title>	</author>
	<author initials="" surname="">	<author initials="M" surname="Maloney">
	<organization>ICANN</organization>	<organization/>
	</author>	</author>
	<date month="February" year="2012" />	<author initials="N" surname="Mendelsohn">
	</front>	<organization/>
	</reference>	</author>
		<date month="October" year="2004"/>
		</front>
		<refcontent>W3C Recommendation REC-xmlschema-1-20041028</refcontent>
		</reference>


	<reference anchor="bundle.name"	<reference anchor="W3C.REC-xmlschema-2-20041028" target="http://www.w3.o
	target="https://www.icann.org/public-comments/rs	rg/TR/2004/REC-xmlschema-2-20041028">
	tep-technical-bundling-2014-07-29-en">	<front>
	<front>	<title>XML Schema Part 2: Datatypes Second Edition</title>
	<title>Registry Services Technical Evaluation Panel (RSTEP) Rep	<author initials="P" surname="Biron">
	ort	<organization/>
	on Public Interest Registry's Request to Implement Technical Bu	</author>
	ndling in .NGO and .ONG</title>	<author initials="A" surname="Malhotra">
	<author initials="" surname="">	<organization/>
	<organization>ICANN</organization>	</author>
	</author>	<date month="October" year="2004"/>
	<date month="July" year="2014" />	</front>
	</front>	<refcontent>W3C Recommendation REC-xmlschema-2-20041028</refcontent>
	</reference> -->	</reference>
		</references>
		<references>
		<name>Informative References</name>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.4290.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.3915.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.3743.xml"/>

	</references>	</references>

		</references>
		<section anchor="Acknowledgements" numbered="false" toc="default">
		<name>Acknowledgements</name>
		<t>
		The authors especially thank the authors of <xref target="RFC5730" format="de
		fault"/> and
		<xref target="RFC5731" format="default"/> and the following members of 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 <contact fullnam
		e="Adrian Farrel"/>.
		</t>
		</section>
	</back>	</back>
	</rfc>	</rfc>

End of changes. 124 change blocks.
	919 lines changed or deleted	718 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/