commit 65795f84919bc5f357c725a7367d2b3a6d06b8bd
parent 13154ca17a1c52861a0d10935dda3840165c0486
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Sun, 6 Feb 2022 11:30:49 +0100
more client
Diffstat:
1 file changed, 20 insertions(+), 13 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -269,12 +269,12 @@
A GNS resource record contains information as defined by its
resource record type.
</dd>
- <dt>Client (Resolver)</dt>
+ <dt>Client</dt>
<dd>
- FIXME: We are using the word "client" often and it is not clearly
- defined what a client is. Sometimes it is a "client resolver".
- Is there another part of the resolver? What is it called?
- This is mostly an issue in the name resolution section.
+ The client is an implementation component which facilitates
+ zone management and name resolution.
+ It enables the user to manage zones (<xref target="publish"/>) and
+ resolve names (<xref target="resolution"/>).
</dd>
</dl>
</section>
@@ -351,8 +351,10 @@
<section anchor="zones" numbered="true" toc="default">
<name>Zones</name>
<t>
+ <!-- FIXME: MUST or SHOULD? -->
+ A client implementation MUST enable the user to manage zones.
A zone in GNS is uniquely identified by its zone type and zone key.
- It can be represented by a Zone Top-Level Domain (zTLD) string.
+ Each zone can be represented by a Zone Top-Level Domain (zTLD) string.
</t>
<t>
Each zone type (ztype) is assigned a unique 32-bit number when it is registered
@@ -1619,7 +1621,6 @@ GET(key) -> value
ensure query privacy (see <xref target="RFC8324"/>, Section 3.5).
The storage key derivation and records
block creation is specified in the following sections.
- A client implementation MUST enable the user the manage zones.
The implementation MUST use the PUT storage procedure in order to update
the zone contents accordingly.
</t>
@@ -1846,20 +1847,26 @@ q := SHA-512 (ZKDF-Public(zk, label))
<xref target="governance" />.
</t>
<t>
- When GNS name resolution is requested, a desired record type MAY be
- provided by the client to guide processing.
+ The client implementation MAY allow the user to provide a desired
+ record type for the resolver.
+ The desired record type is used to guide processing.
+ For example, if zone delegation record type is requested, the
+ resolution of the apex label in that zone may not be necessary, as
+ the desired record is already found.
<!-- FIXME: Is this still necessary? Clarify the purpose of the
provided record type and normatively define that resolver MUST NOT
filter? THe normative statement for the CLIENT does not make sense.
We need a normative statement for the implementer of GNS. -->
- However, filtering of record sets according to the required record
- types MUST still be done by the client after the resource record set
- is retrieved.
+ The resolver MUST NOT filter according to the desired record type.
+ Filtering of record sets types MAY still be done by the client after the
+ resource record set is retrieved.
</t>
<section anchor="governance" numbered="true" toc="default">
<name>Start Zones</name>
<t>
- <!-- FIXME: This is a mess -->
+ <!-- FIXME: This is a mess. Does the resolver know the configuration
+ or only the client? Because the resolver needs to know the zones for
+ redirects, for example -->
The resolution of a GNS name starts in an initial start zone.
The local resolver may have one or more local start zones configured
which point to local or remote zone keys.
