draft-bortzmeyer-regext-epp-dname-noschema.xml 27.6 KB
Newer Older
Stephane Bortzmeyer's avatar
Stephane Bortzmeyer committed
1
<?xml version="1.0" encoding="utf-8"?>
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[
  <!ENTITY rfc1034 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml'>
  <!ENTITY rfc1035 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml'>
  <!ENTITY rfc2119 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
  <!ENTITY rfc2781 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2781.xml'>
  <!ENTITY rfc3629 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml'>
  <!ENTITY rfc3688 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3688.xml'>
  <!ENTITY rfc5730 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5730.xml'>
  <!ENTITY rfc5731 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5731.xml'>
19 20
  <!ENTITY rfc5734 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5734.xml'>
21 22 23 24 25 26
  <!ENTITY rfc5910 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5910.xml'>
  <!ENTITY rfc6672 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6672.xml'>
  <!ENTITY rfc7535 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7535.xml'>
27 28
  <!ENTITY rfc7942 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7942.xml'>
29 30
  <!ENTITY I-D.bortzmeyer-dname-root SYSTEM
   'http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.bortzmeyer-dname-root'>
31 32
  <!ENTITY I-D.hildebrand-deth SYSTEM
   'http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.hildebrand-deth'>
33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53
  <!ENTITY W3C.xml PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml4/reference.W3C.REC-xml-20001006.xml'>
  <!ENTITY W3C.xmlschema-1 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml4/reference.W3C.REC-xmlschema-1-20041028.xml'>
  <!ENTITY W3C.xmlschema-2 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml4/reference.W3C.REC-xmlschema-2-20041028.xml'>
]>

<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>

<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc iprnotified="no"?>

<!-- <?rfc strict="yes"?> -->

Stephane Bortzmeyer's avatar
Stephane Bortzmeyer committed
54
<rfc category="std" ipr="trust200902" docName="draft-bortzmeyer-regext-epp-dname-02">
55 56 57
  <front>
    <title abbrev="EPP Mapping for DNAME delegation">
      EPP&nbsp;Mapping&nbsp;for&nbsp;DNAME&nbsp;delegation&nbsp;of&nbsp;domain&nbsp;names</title>
Stephane Bortzmeyer's avatar
Stephane Bortzmeyer committed
58
    <author fullname="Stéphane Bortzmeyer" initials="S." surname="Bortzmeyer">
59 60 61 62 63 64
      <organization>AFNIC</organization>
      <address><postal><street>1, rue
      Stephenson</street><code>78180</code><city>Montigny-le-Bretonneux</city><country>France</country></postal>
      <phone>+33 1 39 30 83 46</phone>
      <email>bortzmeyer+ietf@nic.fr</email><uri>http://www.afnic.fr/</uri></address>
    </author>
Stephane Bortzmeyer's avatar
Stephane Bortzmeyer committed
65
    <date year="2018" month="March" day="19"/>
66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81
    <area>General</area>
    <keyword>EPP</keyword>
    <keyword>Extensible Provisioning Protocol</keyword>
    <keyword>DNAME</keyword>
    <keyword>AS112</keyword>
    <keyword>XML</keyword>
    <keyword>DNS</keyword>

    <abstract>
      <t>This document describes an Extensible Provisioning Protocol
      (EPP) extension mapping for the provisioning and management of
      Domain Name System for domain names stored in a shared central
      repository.  Specified in XML, this mapping extends the EPP
      domain name mapping to provide the ability to delegate a domain
      names through DNAME resource records, thus making the new domain
      an alias of a previous domain.</t>
82 83 84 85 86 87 88
      <t>REMOVE BEFORE PUBLICATION This document should be discussed
      on the Registration Protocols Extensions (regext) mailing
      list. The source of this document is kept on a Gitlab <eref
      target="https://framagit.org/bortzmeyer/ietf-epp-dname">at
      Framagit</eref>. A list of open issues <eref
      target="https://framagit.org/bortzmeyer/ietf-epp-dname/issues">is
      there as well</eref>.</t>
89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109
    </abstract>
  </front>

  <middle>
    <section title="Introduction" anchor="intro">
      <t>This document describes an extension mapping for version 1.0 of the
      Extensible Provisioning Protocol (EPP) described in RFC 5730
      <xref target="RFC5730"/>.  This mapping, an extension of the domain name
      mapping described in RFC 5731 <xref target="RFC5731"/>, is specified using
      the Extensible Markup Language (XML) 1.0 <xref target="W3C.REC-xml-20001006"/>
      and XML Schema notation (<xref target="W3C.REC-xmlschema-1-20041028"/>
      <xref target="W3C.REC-xmlschema-2-20041028"/>).</t>

      <t>The EPP core protocol specification <xref target="RFC5730"/>
      provides a complete description of EPP command and response
      structures.  A thorough understanding of the base protocol
      specification is necessary to understand the mapping described
      in this document.  Familiarity with the Domain Name System (DNS)
      described in RFC 1034 <xref target="RFC1034"/> and RFC&nbsp;1035
      <xref target="RFC1035"/> and with the DNS DNAME Resource Record
      type described in RFC 6672 <xref target="RFC6672"/> is required
110 111 112 113
      to understand the DNS concepts described in this
      document. (DNAME have properties that may be surprising at
      first; for instance, it aliases only the subdomains, not the
      owner name of the DNAME record itself.)</t>
114 115 116 117 118 119 120

      <t>The EPP mapping described in this document specifies a mechanism
      for the provisioning and management of domain names in a
      shared central repository. Today, most registries allow only
      delegation of domain names to name servers specified in NS
      resource records. DNAME <xref target="RFC6672"/> allow another
      type of delegation, which can be useful for instance for the new
121 122
      AS 112 <xref target="RFC7535"/>, as proposed in <xref
target="I-D.bortzmeyer-dname-root"/>. Information exchanged via this mapping
123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150
      can be extracted from the repository and used to publish DNAME
      resource records.</t>

      <section title="Conventions Used in This Document" anchor="conventions">
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
        document are to be interpreted as described in BCP 14, RFC 2119
        <xref target="RFC2119"/>.</t>

        <t>In examples, "C:" represents lines sent by a protocol client, and "S:"
        represents lines returned by a protocol server.  "////" is used to note
        element values that have been shortened to better fit page boundaries.
        Indentation and white space in examples is provided only to illustrate
        element relationships and is not a mandatory feature of this protocol.</t>

        <t>XML is case sensitive.  Unless stated otherwise, XML specifications
        and examples provided in this document MUST be interpreted in the
        character case presented in order to develop a conforming implementation.</t>
        
        <t>dnameDeleg-1.0 is used as an abbreviation for urn:ietf:params:xml:ns:dnameDeleg-1.0.</t>
        
      </section>
    </section>

    <section title="Object Attributes" anchor="attrs">
      <t>This extension adds additional elements to the EPP domain name
      mapping <xref target="RFC5731"/>.  Only those new elements are
      described here.</t>
151
      <t>DNAME information is published by a DNS server to indicate
152 153 154 155 156 157 158 159 160 161 162 163 164 165
        that a child zone is actually an alias of another zone.  A
        DNAME resource record (RR) contains a single field named
        target. See RFC 6672 <xref target="RFC6672"/> for the specific
        field format.</t>
    </section>
     
    <section title="Presentation">
      <t>It is the server policy to allow DNAME delegations or not. It
      is also the server policy to allow (or not) a domain to switch between
      these two types of delegation with a EPP &lt;update&gt;.</t>
      
     <t>The interface relies on the use of the
     &lt;dnameDeleg:dnameTarget&gt; element for creates, adds,
     removes, and &lt;domain:info&gt; responses.  The data is provided
166 167 168 169 170
     by the client. If the DNAME target is in a zone managed by the
     server, the server operator MAY checks its existence in its
     database and the fact that it is not itself a DNAME. Otherwise,
     the server operator MAY issue out-of-band DNS queries to check if
     the target really exists.</t>
171 172 173 174 175
     
     <t>The &lt;dnameDeleg:dnameTarget&gt; element contains a domain
     name, as described in Section 2.1 of RFC 6672 <xref
     target="RFC6672"/>.  The value of the
     &lt;dnameDeleg:dnameTarget&gt; element is represented as a
176 177
     eppcom:labelType (<xref target="RFC5730"/>, section 4.4, and
     <xref target="W3C.REC-xmlschema-2-20041028"/>).</t>
178 179 180 181 182
    </section>
      
      <section title="Examples">
        
      <t>Example use of the dnameDeleg:dnameTarget, for instance for
183
      an EPP &lt;create&gt;:<vspace blankLines="0"/></t>
184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202
<figure><artwork>
&lt;dnameDeleg:dnameTarget&gt;foo.bar.example&lt;/dnameDeleg:dnameTarget&gt;
      </artwork></figure>
      </section>
 
    <section title="EPP Command Mapping" anchor="commands">
      <t>A detailed description of the EPP syntax and semantics can be found in
      the EPP core protocol specification <xref target="RFC5730"/>.
      The command mappings described here are specifically for use in
      provisioning and managing DNAME delegations via EPP.</t>

      <section title="EPP Query Commands" anchor="queries">
        <t>EPP provides three commands to retrieve object information:
        &lt;check&gt; to determine if an object is known to the server,
        &lt;info&gt; to retrieve detailed information associated with an
        object, and &lt;transfer&gt; to retrieve object transfer status
        information.</t>

        <section title="EPP &lt;check&gt; Command" anchor="check">
203 204 205 206 207 208 209
          <t>This extension does not add any elements to the EPP
          &lt;check&gt; command or &lt;check&gt; response described in
          the EPP domain mapping <xref target="RFC5731"/>. Note that
          an EPP client cannot use &lt;check&gt; to find out if a
          server authorizes DNAME delegation for this specific domain
          (EPP login information is not sufficient because the fact
          that the server supports the extension does not mean it is
210 211
          authorized for all names.) [REMOVE BEFORE PUBLICATION: issue
	  #3 discussed the case.]</t>
212 213 214
        </section>

        <section title="EPP &lt;info&gt; Command" anchor="info">
215 216
          <t>This extension does not add any elements to the EPP
          &lt;info&gt; command described in the EPP domain mapping
217 218
          <xref target="RFC5731"/>. [REMOVE BEFORE PUBLICATION: issue
	  #6 discussed whether or not it would be a good idea.] However,
219 220
          additional elements are defined for the &lt;info&gt;
          response.</t>
221 222 223 224 225

          <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"/>.
          In addition, the EPP &lt;extension&gt; element SHOULD contain a child
226 227 228 229 230
          &lt;dnameDeleg:dnameTarget&gt; element that identifies the
	  extension namespace if the domain object has data associated
	  with this extension, based on server policy and depending on
	  support of the client for dnameDeleg, based on the EPP login
	  services it provided. The &lt;dnameDeleg:dnameTarget&gt;
231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267
          element contains a domain name as its value. A server MUST
	  NOT return both a &lt;dnameDeleg:dnameTarget&gt; and a
	  &lt;domain:ns&gt; (<xref target="RFC5731"/>, section 3.1.2).</t>

           <t>
          <figure>
              <artwork>Example &lt;info&gt; Response 
<![CDATA[
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
S:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
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>example.com</domain:name>
S:        <domain:roid>EXAMPLE1-REP</domain:roid>
S:        <domain:status s="ok"/>
S:        <domain:registrant>jd1234</domain:registrant>
S:        <domain:contact type="admin">sh8013</domain:contact>
S:        <domain:contact type="tech">sh8013</domain:contact>
S:        <domain:clID>ClientX</domain:clID>
S:        <domain:crID>ClientY</domain:crID>
S:        <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate>
S:        <domain:upID>ClientX</domain:upID>
S:        <domain:upDate>1999-12-03T09:00:00.0Z</domain:upDate>
S:        <domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate>
S:        <domain:trDate>2000-04-08T09:00:00.0Z</domain:trDate>
S:        <domain:authInfo>
S:          <domain:pw>2fooBAR</domain:pw>
S:        </domain:authInfo>
S:      </domain:infData>
S:    </resData>
S:    <extension>
268 269 270
S:      <dnameDeleg:dnameTarget xmlns:dnameDeleg="urn:ietf:params:xml:ns:dnameDeleg-1.0">
S:           foo.bar.example
S:      </dnameDeleg:dnameTarget>
271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291
S:    </extension>
S:    <trID>
S:      <clTRID>ABC-12345</clTRID>
S:      <svTRID>54322-XYZ</svTRID>
S:    </trID>
S:  </response>
S:</epp>
]]>
	      </artwork>
          </figure>
          </t>

          <t>An EPP error response MUST be returned if an &lt;info&gt; command
          cannot be processed for any reason.</t>
        </section>
      </section>

        <section title="EPP &lt;transfer&gt; Command" anchor="transferQ">
          <t>This extension does not add any elements to the EPP &lt;transfer&gt;
          command or &lt;transfer&gt; response described in the EPP domain mapping
          <xref target="RFC5731"/>. A domain cannot be switched from
292 293 294 295
	  NS delegation to DNAME delegation (or vice-versa) through a
	  transfer.</t>
	  <t> Note that this may be one additional reason for a
	transfer to fail: if the gaining registrar does not support
296
	  DNAME delegation. The server MUST return error code 2106.</t>
297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319
        </section>
      </section>

      <section title="EPP Transform Commands" anchor="transforms">
        <t>EPP provides five commands to transform objects: &lt;create&gt; to create
        an instance of an object, &lt;delete&gt; to delete an instance of an object,
        &lt;renew&gt; to extend the validity period of an object, &lt;transfer&gt; to
        manage object sponsorship changes, and &lt;update&gt; to change information
        associated with an object.</t>

        <section title="EPP &lt;create&gt; Command" anchor="create">
          <t>This extension defines an additional element for the EPP &lt;create&gt;
          command described in the EPP domain mapping <xref target="RFC5731"/>.
          No additional elements are defined for the EPP &lt;create&gt; response.</t>

          <t>The EPP &lt;create&gt; command provides a transform operation that allows
          a client to create a domain object.  In addition to the EPP
          command elements described in the EPP domain mapping <xref target="RFC5731"/>,
          the command MUST contain an &lt;extension&gt; element, and the &lt;extension&gt; element
          MUST contain a child &lt;dnameDeleg:dnameTarget&gt; element that identifies
          the extension namespace if the client wants to associate data defined in this extension to the domain object.  
          The &lt;dnameDeleg:dnameTarget&gt; has a domain name as
	  value. A client MUST NOT send both a
320
	  &lt;dnameDeleg:dnameTarget&gt; and &lt;domain:ns&gt;
321 322
	  elements. TODO See issue #4 for the choice of the error
	  code(s).</t>
323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344
           <t>
            <figure>
              <artwork>Example &lt;create&gt; Command:
<![CDATA[
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
C:  <command>
C:    <create>
C:      <domain:create
C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:        <domain:name>example.com</domain:name>
C:        <domain:period unit="y">2</domain:period>
C:        <domain:registrant>jd1234</domain:registrant>
C:        <domain:contact type="admin">sh8013</domain:contact>
C:        <domain:contact type="tech">sh8013</domain:contact>
C:        <domain:authInfo>
C:          <domain:pw>2fooBAR</domain:pw>
C:        </domain:authInfo>
C:      </domain:create>
C:    </create>
C:    <extension>
345
C:      <dnameDeleg:dnameTarget xmlns:dnameDeleg="urn:ietf:params:xml:ns:dnameDeleg-1.0">foo.bar.example</dnameDeleg:dnameTarget>
346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390
C:    </extension>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>
]]>
</artwork>
            </figure>
          </t>

          <t>When a &lt;create&gt; command has been processed successfully, the EPP
          response is as described in the EPP domain mapping <xref target="RFC5731"/>.</t>
        </section>

        <section title="EPP &lt;delete&gt; Command" anchor="delete">
          <t>This extension does not add any elements to the EPP &lt;delete&gt;
          command or &lt;delete&gt; response described in the EPP domain mapping
          <xref target="RFC5731"/>.</t>
        </section>

        <section title="EPP &lt;renew&gt; Command" anchor="renew">
          <t>This extension does not add any elements to the EPP &lt;renew&gt;
          command or &lt;renew&gt; response described in the EPP domain mapping
          <xref target="RFC5731"/>.</t>
        </section>

        <section title="EPP &lt;transfer&gt; Command" anchor="transferT">
          <t>This extension does not add any elements to the EPP &lt;transfer&gt;
          command or &lt;transfer&gt; response described in the EPP domain mapping
          <xref target="RFC5731"/>.</t>
        </section>

        <section title="EPP &lt;update&gt; Command" anchor="update">
          <t>This extension defines additional elements for the EPP &lt;update&gt;
          command described in the EPP domain mapping <xref target="RFC5731"/>.
          No additional elements are defined for the EPP &lt;update&gt; response.</t>

          <t>The EPP &lt;update&gt; command provides a transform operation that
          allows a client to modify the attributes of a domain object.  In
          addition to the EPP command elements described in the EPP domain
          mapping, the command MUST contain an &lt;extension&gt; element, and the &lt;extension&gt; element
          MUST contain a child &lt;dnameDeleg:dnameTarget&gt; element that identifies
          the extension namespace if the client wants to update the domain object with data defined in this extension.  
          The &lt;dnameDeleg:dnameTarget&gt; element has a domain name
	  as its value. If present, it updates the DNAME delegation to
	  the new target, if the domain was already DNAME-delegated,
391
	  or it switches the domain to a DNAME delegation, if it was
392 393 394 395
	  previously a NS delegation. A server MAY refuse such a
	  switch, per its policy. In the same way, a RFC 5731 <xref
	  target="RFC5731"/> update with NS information, without the
	  extension decribed here, switches to NS
396 397 398 399
	  delegation if the domain was previously DNAME-delegated.</t>
	  <t>TODO there is an issue with the switch from NS to DNAME
	  delegation if the domain had in-bailiwick name servers. See
	  issue #7.</t>
400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415

          <t>
            <figure>
              <artwork>Example &lt;update&gt; Command, Adding and Removing: 
<![CDATA[
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
C:  <command>
C:    <update>
C:      <domain:update
C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:        <domain:name>example.com</domain:name>
C:      </domain:update>
C:    </update>
C:    <extension>
416
C:          <dnameDeleg:dnameTarget xmlns:dnameDeleg="urn:ietf:params:xml:ns:dnameDeleg-1.0">foo.bar.example
417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473
C:          </dnameDeleg:dnameTarget>
C:    </extension>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>
]]>
	      </artwork>
            </figure>
          </t>

          <t>When an extended &lt;update&gt; command has been processed
          successfully, the EPP response is as described in the EPP domain
          mapping <xref target="RFC5731"/>.</t>
	</section>
      </section>

    <section title="Formal Syntax" anchor="syntax">
      <t>An EPP object mapping 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
END
]]>
	  </artwork>
        </figure>
<!-- 		</t> -->
    </section>

    <section title="Internationalization Considerations" anchor="i18n">
      <t>EPP is represented in XML, which provides native support for encoding
      information using the Unicode character set and its more compact
      representations including UTF-8 <xref target="RFC3629"/>.  Conformant XML
      processors recognize both UTF-8 and UTF-16 <xref target="RFC2781"/>.  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 in environments where parser encoding support
      incompatibility exists.</t>

      <t>As an extension of the EPP domain mapping <xref target="RFC5731"/>, 
      the internationalization requirements in the EPP domain mapping <xref target="RFC5731"/> are followed 
      by this extension. This extension does not override any of the EPP domain mapping <xref target="RFC5731"/> 
      internationalization features.</t>  
    </section>

    <section title="IANA Considerations" anchor="iana">
      <t>This document uses URNs to describe XML namespaces and XML schemas
      conforming to a registry mechanism described in RFC 3688 <xref target="RFC3688"/>.
      Two URI assignments have been completed by the IANA.</t>

      <t>Registration request for the extension namespace:</t>

474
      <t>URI: urn:ietf:params:xml:ns:dnameDeleg-1.0</t>
475 476 477 478 479 480 481

      <t>Registrant Contact: IESG</t>

      <t>XML: None.  Namespace URIs do not represent an XML specification.</t>

      <t>Registration request for the extension XML schema:</t>

482
      <t>URI: urn:ietf:params:xml:schema:dnameDeleg-1.0</t>
483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503

      <t>Registrant Contact: IESG</t>

      <t>XML: See the "Formal Syntax" section of this document.</t>
    </section>

    <section title="Security Considerations" anchor="security">
      <t>The mapping extensions described in this document do not provide any
      security services beyond those described by EPP <xref target="RFC5730"/>,
      the EPP domain name mapping <xref target="RFC5731"/>,
      and protocol layers used by EPP.  The security considerations described in
      these other specifications apply to this specification as well.</t>

      <t>As with other domain object transforms, the EPP transform operations
      described in this document MUST be restricted to the sponsoring client
      as authenticated using the mechanisms described in Sections&nbsp;2.9.1.1 and
      7 of RFC 5730 <xref target="RFC5730"/>.  Any attempt to perform a
      transform operation on a domain object by any client other than the
      sponsoring client MUST be rejected with an appropriate EPP authorization
      error.</t>

504 505 506 507 508 509 510
      <t>The provisioning service described in this document involves
      the exchange of information that can have an operational impact
      on the DNS.  A trust relationship MUST exist between the EPP
      client and server, and provisioning of DNAME delegation MUST
      only be done after the identities of both parties have been
      confirmed using a strong authentication mechanism. This is just
      a repeat of <xref target="RFC5734"/>, section 8.</t>
511 512 513 514 515 516 517 518 519 520 521

      <t>An EPP client might be acting as an agent for a zone administrator who
      wants to send DNAME delegation information to be published by the server
      operator.  Man-in-the-middle attacks are thus possible as a result of
      direct client activity or inadvertent client data manipulation.</t>

    </section>

    <section title="Acknowledgements" anchor="acks">    
      <t>Most of the text has been copied from <xref
      target="RFC5910"/>, so thanks to its authors.</t>
522
      <t>Thanks to James Gould for a detailed review and for
523 524
      John Levine and Patrick Mevzek for good remarks. Thanks to
      Patrick Mevzek for the first implementation.</t>
525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546
    </section>
  </middle>

  <back>

<?rfc rfcedstyle="no"?>
    <references title="Normative References">
      &rfc2119;
      &rfc3688;
      &rfc5730;
      &rfc5731;
      &rfc6672;
      &W3C.xml;
      &W3C.xmlschema-1;
      &W3C.xmlschema-2;
    </references>

    <references title="Informative References">
      &rfc1034;
      &rfc1035;
      &rfc2781;
      &rfc3629;
547
      &rfc5734;
548
      &rfc5910;
549
      &rfc7535;
550
      &rfc7942;
551
      &I-D.bortzmeyer-dname-root;
552
      &I-D.hildebrand-deth;
553
    </references>
554 555 556 557 558 559

    <section title="Generic Resource Records type">
      <t>The goal of this document is not to allow arbitrary DNS
      Resource record types (such as TXT or LOC). Such a mapping would
      require the ability to add, update and remove individual
      records, but it would allow the EPP server to implement a
560 561 562 563
      "delegation-less" registry. An example of such attempt to define
      a standard protocol for provisioning a lot of resource record
      types is <xref target="I-D.hildebrand-deth"/>. But we don't
      follow that path. Instead, we keep the idea that the
564 565 566
      EPP server registers only delegations, either through NS records
      or, as here, a DNAME record. This keeps the mapping much
      simpler.</t>
567 568 569
      <t>For this reason, the possibility to add other resource
      records together with the DNAME (<xref target="RFC6672"/>,
      section 2.4) is out-of-scope here.</t>
570 571
    </section>
    
572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601
    <section title="Implementation status">
      <t>RFC-EDITOR: REMOVE BEFORE PUBLICATION</t>
      <t>This section records the status of known implementations of
      the protocol defined by this specification at the time of
      posting of this Internet-Draft, and is based on a proposal
      described in <xref target="RFC7942"/>.  The description of implementations in
      this section is intended to assist the IETF in its decision
      processes in progressing drafts to RFCs.  Please note that the
      listing of any individual implementation here does not imply
      endorsement by the IETF.  Furthermore, no effort has been spent
      to verify the information presented here that was supplied by
      IETF contributors.  This is not intended as, and must not be
      construed to be, a catalog of available implementations or their
      features.  Readers are advised to note that other
      implementations may exist.</t>
     <t>
     According to <xref target="RFC7942"/>, "this will allow reviewers and working
     groups to assign due consideration to documents that have the
     benefit of running code, which may serve as evidence of valuable
     experimentation and feedback that have made the implemented
     protocols more mature.  It is up to the individual working groups
     to use this information as they see fit".
     </t>
     <t>This EPP extension is implemented in the <eref
     target="https://metacpan.org/pod/Net::DRI">Net::DRI EPP
     client</eref>, written in Perl. The specific part of Net::DRI is
     <eref
     target="https://metacpan.org/source/PMEVZEK/Net-DRI-0.96_10/lib/Net/DRI/Protocol/EPP/Extensions/DNAME.pm">DNAME.pm</eref>.</t>
    </section>
      
602 603 604 605
<?rfc rfcedstyle="yes"?>
    
  </back>
</rfc>