[lsd0001] branch master updated: more client

[gnunet]

This is an automated email from the git hooks/post-receive script.

martin-schanzenbach pushed a commit to branch master
in repository lsd0001.

The following commit(s) were added to refs/heads/master by this push:
     new 65795f8  more client
65795f8 is described below

commit 65795f84919bc5f357c725a7367d2b3a6d06b8bd
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Sun Feb 6 11:30:49 2022 +0100

    more client
---
 draft-schanzen-gns.xml | 33 ++++++++++++++++++++-------------
 1 file changed, 20 insertions(+), 13 deletions(-)

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 5f1e9f1..9139921 100644
--- 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.

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.