Commit ffa01ca5 authored by Stéphane Bortzmeyer's avatar Stéphane Bortzmeyer

Merge branch 'master' of framagit.org:bortzmeyer/ietf-epp-dname

parents a482c22e 4be31629
......@@ -45,7 +45,7 @@
<!-- <?rfc strict="yes"?> -->
<rfc category="std" ipr="trust200902" docName="draft-bortzmeyer-regext-epp-dname-00">
<rfc category="std" ipr="trust200902" docName="draft-bortzmeyer-regext-epp-dname-01">
<front>
<title abbrev="EPP Mapping for DNAME delegation">
EPP&nbsp;Mapping&nbsp;for&nbsp;DNAME&nbsp;delegation&nbsp;of&nbsp;domain&nbsp;names</title>
......@@ -56,7 +56,7 @@
<phone>+33 1 39 30 83 46</phone>
<email>bortzmeyer+ietf@nic.fr</email><uri>http://www.afnic.fr/</uri></address>
</author>
<date year="2018" month="January" day="5"/>
<date year="2018" month="TODO" day="TODO"/>
<area>General</area>
<keyword>EPP</keyword>
<keyword>Extensible Provisioning Protocol</keyword>
......@@ -161,8 +161,8 @@ target="I-D.bortzmeyer-dname-root"/>. Information exchanged via this mapping
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
string<!-- https://www.w3.org/TR/xmlschema-2/#string -->
<xref target="W3C.REC-xmlschema-2-20041028"/>.</t>
eppcom:labelType (<xref target="RFC5730"/>, section 4.4, and
<xref target="W3C.REC-xmlschema-2-20041028"/>).</t>
</section>
<section title="Examples">
......@@ -188,23 +188,33 @@ target="I-D.bortzmeyer-dname-root"/>. Information exchanged via this mapping
information.</t>
<section title="EPP &lt;check&gt; Command" anchor="check">
<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 domain. TODO see issue #3 to discuss it.</t>
<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
authorized for all names. TODO see issue #3 to discuss
it.</t>
</section>
<section title="EPP &lt;info&gt; Command" anchor="info">
<t>This extension does not add any elements to the EPP &lt;info&gt;
command described in the EPP domain mapping <xref target="RFC5731"/>.
However, additional elements are defined for the &lt;info&gt; response.</t>
<t>This extension does not add any elements to the EPP
&lt;info&gt; command described in the EPP domain mapping
<xref target="RFC5731"/>. TODO see issue #6. However,
additional elements are defined for the &lt;info&gt;
response.</t>
<t>When an &lt;info&gt; command has been processed successfully, the
EPP &lt;resData&gt; element MUST contain child elements as described
in the EPP domain mapping <xref target="RFC5731"/>.
In addition, the EPP &lt;extension&gt; element SHOULD contain a child
&lt;dnameDeleg:dnameTarget&gt; element that identifies the extension namespace if the domain object has data associated with this extension and based on server policy. The &lt;dnameDeleg:dnameTarget&gt;
&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;
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>
......@@ -266,7 +276,11 @@ S:</epp>
<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
NS delegation to DNAME delegation (or vice-versa) through a transfer.</t>
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
DNAME delegation.</t>
</section>
</section>
......@@ -487,7 +501,7 @@ END
<section title="Acknowledgements" anchor="acks">
<t>Most of the text has been copied from <xref
target="RFC5910"/>, so thanks to its authors.</t>
<t>Thanks to James Gould for a detailed review.</t>
</section>
</middle>
......@@ -514,6 +528,18 @@ END
&rfc7535;
&I-D.bortzmeyer-dname-root;
</references>
<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
"delegation-less" registry. Instead, we keep the idea that the
EPP server registers only delegations, either through NS records
or, as here, a DNAME record. This keeps the mapping much
simpler.</t>
</section>
<?rfc rfcedstyle="yes"?>
</back>
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment