Commit 9f92a3d7 authored by Stéphane Bortzmeyer's avatar Stéphane Bortzmeyer

Version -00 published

parent 292517e9
......@@ -43,7 +43,7 @@
<!-- <?rfc strict="yes"?> -->
<rfc category="std" ipr="trust200902" docName="draft-bortzmeyer-regext-epp-dname">
<rfc category="std" ipr="trust200902" docName="draft-bortzmeyer-regext-epp-dname-00">
<front>
<title abbrev="EPP Mapping for DNAME delegation">
EPP&nbsp;Mapping&nbsp;for&nbsp;DNAME&nbsp;delegation&nbsp;of&nbsp;domain&nbsp;names</title>
......@@ -54,7 +54,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="2010" month="May" day="4"/>
<date year="2018" month="January" day="5"/>
<area>General</area>
<keyword>EPP</keyword>
<keyword>Extensible Provisioning Protocol</keyword>
......@@ -129,21 +129,11 @@
<t>This extension adds additional elements to the EPP domain name
mapping <xref target="RFC5731"/>. Only those new elements are
described here.</t>
<section title="DNAME Information" anchor="dnameInfo">
<t>DNAME information is published by a DNS server to indicate
<t>DNAME information is published by a DNS server to indicate
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 title="Booleans" anchor="booleans">
<t>Boolean values MUST be represented in the XML Schema
format described in Part 2 of the W3C XML Schema recommendation
<xref target="W3C.REC-xmlschema-2-20041028"/>.</t>
</section>
</section>
<section title="Presentation">
......@@ -168,12 +158,11 @@
<section title="Examples">
<t>Example use of the dnameDeleg:dnameTarget, for instance for
an EPP create:<vspace blankLines="0"/></t>
an EPP &lt;create&gt;:<vspace blankLines="0"/></t>
<figure><artwork>
&lt;dnameDeleg:dnameTarget&gt;foo.bar.example&lt;/dnameDeleg:dnameTarget&gt;
</artwork></figure>
</section>
</section>
<section title="EPP Command Mapping" anchor="commands">
<t>A detailed description of the EPP syntax and semantics can be found in
......@@ -193,7 +182,7 @@
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.</t>
delegation for this domain. TODO see issue #3 to discuss it.</t>
</section>
<section title="EPP &lt;info&gt; Command" anchor="info">
......@@ -243,7 +232,9 @@ S: </domain:authInfo>
S: </domain:infData>
S: </resData>
S: <extension>
S: <dnameDeleg:dnameTarget>foo.bar.example</dnameDeleg:dnameTarget>
S: <dnameDeleg:dnameTarget xmlns:dnameDeleg="urn:ietf:params:xml:ns:dnameDeleg-1.0">
S: foo.bar.example
S: </dnameDeleg:dnameTarget>
S: </extension>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
......@@ -289,7 +280,8 @@ S:</epp>
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
&lt;dnameDeleg:dnameTarget&gt; and &lt;domain:ns&gt; elements.</t>
&lt;dnameDeleg:dnameTarget&gt; and &lt;domain:ns&gt;
elements. TODO See issue #4 for the error code.</t>
<t>
<figure>
<artwork>Example &lt;create&gt; Command:
......@@ -312,7 +304,7 @@ C: </domain:authInfo>
C: </domain:create>
C: </create>
C: <extension>
C: <dnameDeleg:dnameTarget>foo.bar.example</dnameDeleg:dnameTarget>
C: <dnameDeleg:dnameTarget xmlns:dnameDeleg="urn:ietf:params:xml:ns:dnameDeleg-1.0">foo.bar.example</dnameDeleg:dnameTarget>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
......@@ -358,7 +350,7 @@ C:</epp>
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,
or it switches the domain to a DNAME delegation, of it was
or it switches the domain to a DNAME delegation, if it was
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
......@@ -380,10 +372,8 @@ C: <domain:name>example.com</domain:name>
C: </domain:update>
C: </update>
C: <extension>
C: <dnameDeleg:dnameTarget>foo.bar.example
C: <dnameDeleg:dnameTarget xmlns:dnameDeleg="urn:ietf:params:xml:ns:dnameDeleg-1.0">foo.bar.example
C: </dnameDeleg:dnameTarget>
C: </dnameDeleg:add>
C: </dnameDeleg:update>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
......@@ -440,7 +430,7 @@ END
<t>Registration request for the extension namespace:</t>
<t>URI: urn:ietf:params:xml:ns:dnameDeleg-1.1</t>
<t>URI: urn:ietf:params:xml:ns:dnameDeleg-1.0</t>
<t>Registrant Contact: IESG</t>
......@@ -448,7 +438,7 @@ END
<t>Registration request for the extension XML schema:</t>
<t>URI: urn:ietf:params:xml:schema:dnameDeleg-1.1</t>
<t>URI: urn:ietf:params:xml:schema:dnameDeleg-1.0</t>
<t>Registrant Contact: IESG</t>
......@@ -499,7 +489,6 @@ END
&rfc3688;
&rfc5730;
&rfc5731;
&rfc5910;
&rfc6672;
&W3C.xml;
&W3C.xmlschema-1;
......@@ -511,6 +500,7 @@ END
&rfc1035;
&rfc2781;
&rfc3629;
&rfc5910;
&rfc7535;
</references>
<?rfc rfcedstyle="yes"?>
......
......@@ -43,7 +43,7 @@
<!-- <?rfc strict="yes"?> -->
<rfc category="std" ipr="trust200902" docName="draft-bortzmeyer-regext-epp-dname">
<rfc category="std" ipr="trust200902" docName="draft-bortzmeyer-regext-epp-dname-00">
<front>
<title abbrev="EPP Mapping for DNAME delegation">
EPP&nbsp;Mapping&nbsp;for&nbsp;DNAME&nbsp;delegation&nbsp;of&nbsp;domain&nbsp;names</title>
......@@ -54,7 +54,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="2010" month="May" day="4"/>
<date year="2018" month="January" day="5"/>
<area>General</area>
<keyword>EPP</keyword>
<keyword>Extensible Provisioning Protocol</keyword>
......@@ -129,21 +129,11 @@
<t>This extension adds additional elements to the EPP domain name
mapping <xref target="RFC5731"/>. Only those new elements are
described here.</t>
<section title="DNAME Information" anchor="dnameInfo">
<t>DNAME information is published by a DNS server to indicate
<t>DNAME information is published by a DNS server to indicate
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 title="Booleans" anchor="booleans">
<t>Boolean values MUST be represented in the XML Schema
format described in Part 2 of the W3C XML Schema recommendation
<xref target="W3C.REC-xmlschema-2-20041028"/>.</t>
</section>
</section>
<section title="Presentation">
......@@ -168,12 +158,11 @@
<section title="Examples">
<t>Example use of the dnameDeleg:dnameTarget, for instance for
an EPP create:<vspace blankLines="0"/></t>
an EPP &lt;create&gt;:<vspace blankLines="0"/></t>
<figure><artwork>
&lt;dnameDeleg:dnameTarget&gt;foo.bar.example&lt;/dnameDeleg:dnameTarget&gt;
</artwork></figure>
</section>
</section>
<section title="EPP Command Mapping" anchor="commands">
<t>A detailed description of the EPP syntax and semantics can be found in
......@@ -193,7 +182,7 @@
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.</t>
delegation for this domain. TODO see issue #3 to discuss it.</t>
</section>
<section title="EPP &lt;info&gt; Command" anchor="info">
......@@ -243,7 +232,9 @@ S: </domain:authInfo>
S: </domain:infData>
S: </resData>
S: <extension>
S: <dnameDeleg:dnameTarget>foo.bar.example</dnameDeleg:dnameTarget>
S: <dnameDeleg:dnameTarget xmlns:dnameDeleg="urn:ietf:params:xml:ns:dnameDeleg-1.0">
S: foo.bar.example
S: </dnameDeleg:dnameTarget>
S: </extension>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
......@@ -289,7 +280,8 @@ S:</epp>
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
&lt;dnameDeleg:dnameTarget&gt; and &lt;domain:ns&gt; elements.</t>
&lt;dnameDeleg:dnameTarget&gt; and &lt;domain:ns&gt;
elements. TODO See issue #4 for the error code.</t>
<t>
<figure>
<artwork>Example &lt;create&gt; Command:
......@@ -312,7 +304,7 @@ C: </domain:authInfo>
C: </domain:create>
C: </create>
C: <extension>
C: <dnameDeleg:dnameTarget>foo.bar.example</dnameDeleg:dnameTarget>
C: <dnameDeleg:dnameTarget xmlns:dnameDeleg="urn:ietf:params:xml:ns:dnameDeleg-1.0">foo.bar.example</dnameDeleg:dnameTarget>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
......@@ -358,7 +350,7 @@ C:</epp>
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,
or it switches the domain to a DNAME delegation, of it was
or it switches the domain to a DNAME delegation, if it was
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
......@@ -380,10 +372,8 @@ C: <domain:name>example.com</domain:name>
C: </domain:update>
C: </update>
C: <extension>
C: <dnameDeleg:dnameTarget>foo.bar.example
C: <dnameDeleg:dnameTarget xmlns:dnameDeleg="urn:ietf:params:xml:ns:dnameDeleg-1.0">foo.bar.example
C: </dnameDeleg:dnameTarget>
C: </dnameDeleg:add>
C: </dnameDeleg:update>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
......@@ -461,7 +451,7 @@ END
<t>Registration request for the extension namespace:</t>
<t>URI: urn:ietf:params:xml:ns:dnameDeleg-1.1</t>
<t>URI: urn:ietf:params:xml:ns:dnameDeleg-1.0</t>
<t>Registrant Contact: IESG</t>
......@@ -469,7 +459,7 @@ END
<t>Registration request for the extension XML schema:</t>
<t>URI: urn:ietf:params:xml:schema:dnameDeleg-1.1</t>
<t>URI: urn:ietf:params:xml:schema:dnameDeleg-1.0</t>
<t>Registrant Contact: IESG</t>
......@@ -520,7 +510,6 @@ END
&rfc3688;
&rfc5730;
&rfc5731;
&rfc5910;
&rfc6672;
&W3C.xml;
&W3C.xmlschema-1;
......@@ -532,6 +521,7 @@ END
&rfc1035;
&rfc2781;
&rfc3629;
&rfc5910;
&rfc7535;
</references>
<?rfc rfcedstyle="yes"?>
......
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