commit a4e6f255fde09f5baabed088b886d475125ad3e3
parent 8d54b11c81eaa81e66bbea6ebcf9ea80982f0c41
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Wed, 13 Dec 2023 11:01:29 +0100
consolidate cases
Diffstat:
1 file changed, 7 insertions(+), 39 deletions(-)
diff --git a/draft-nadler-sbox.xml b/draft-nadler-sbox.xml
@@ -60,10 +60,6 @@
interoperability among implementations (for example, pre-existing
GNUnet implementations).
</t>
- <!--<t>
- Additionally, this is the continued-maintenance version of RFC 9498 which
- is being updated as the work progresses: The Living Standards Document 0010 (LSD0010).
- </t>-->
</abstract>
</front>
<middle>
@@ -82,32 +78,9 @@
A new record type is defined to extend the GNS to support a wider range of underscore labels.
The new record type is called SBOX and is intended to handle all variations of underscore labels the BOX record type is not able to.
</t>
- <!--<t>
- Per Domain Name System (DNS) terminology <xref target="RFC1035"/>, GNS roughly follows the idea of
- a local
- root zone deployment (see <xref target="RFC8806"/>), with the
- difference that the design encourages alternative roots and
- does not expect all deployments to use the same or any specific
- root zone. In the GNS reference implementation, users can
- autonomously and freely delegate control of names to zones
- through their local configurations.
- GNS expects each user to be in control of their setup.
- By following the guidelines in <xref target="namespace_ambiguity"/>,
- users should manage to avoid any confusion as to how names are
- resolved.
- </t>
- <t>
- Name resolution and zone dissemination are based on the
- principle of a petname system where users can assign local
- names to zones. The GNS has its roots in ideas from the Simple
- Distributed Security Infrastructure <xref target="SDSI"/>,
- enabling the decentralized mapping of secure identifiers to
- memorable names. One of the first academic descriptions of the
- cryptographic ideas behind GNS can be found in <xref target="GNS"/>.
- </t>-->
<t>
- This document defines the normative wire format of resource
- records and resolution processes for use by implementers.
+ This document defines the normative wire format of the SBOX resource
+ record and resolution processes for use by implementers.
</t>
<section>
<name>Requirements Notation</name>
@@ -217,16 +190,11 @@
<dd>If the remainder of the name to be resolved is of the format "_SERVICE._PROTO" and the
record set contains one or more matching BOX records, the records in the BOX records are
part of the final result and the recursion is processed as described in <xref
- target="box_processing" />. An additional check for "Case 6" <bcp14>MUST</bcp14> be
- made if the record set contains SBOX records.</dd>
- </dl>
- <dl newline="false">
- <dt>Case 6:</dt>
- <dd>If the remainder of the name to be resolved is starting with "_" and the record set
+ target="box_processing" />.
+ If the remainder of the name to be resolved is starting with "_" and the record set
contains one or more matching SBOX records, the records in the SBOX records are part of
the final result and the recursion is processed as described in <xref
- target="sbox_processing" />. An additional check for "Case 3" <bcp14>MUST</bcp14> be
- made if the record set contains BOX records.</dd>
+ target="sbox_processing" />.
</dl>
<section anchor="box_processing">
<name>BOX</name>
@@ -273,8 +241,8 @@
<td>65547</td>
<td>SBOX</td>
<td>(*)</td>
- <td>LSD 0010</td>
- <td>SBox records</td>
+ <td>LSD 0008</td>
+ <td>SBOX records</td>
</tr>
</tbody>
<tfoot>
