[lsd0001] branch master updated: Client and Applications

[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 31079b6  Client and Applications
31079b6 is described below

commit 31079b67a01923a1c0b247db18ca762d25b1e555
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Sun Feb 6 15:17:29 2022 +0100

    Client and Applications
---
 draft-schanzen-gns.xml | 30 ++++++++++++++++++++----------
 1 file changed, 20 insertions(+), 10 deletions(-)

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 9139921..52e9fd4 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -276,6 +276,11 @@
          It enables the user to manage zones (<xref target="publish"/>) and
          resolve names (<xref target="resolution"/>).
        </dd>
+       <dt>Application</dt>
+       <dd>
+         An application refers to a component which uses a GNS implementation
+         to resolve records from the network and (usually) processes its 
contents.
+       </dd>
      </dl>
    </section>
    <section anchor="overview" numbered="true" toc="default">
@@ -344,18 +349,21 @@
        In the remainder of this document, the "implementer" refers to the 
developer building
        a GNS implementation including, for example, zone management tools and
        name resolution components.
-       An "application" refers to a component which uses a GNS implementation
-       to resolve records from the network and (usually) processes its 
contents.
      </t>
    </section>
    <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.
        Each zone can be represented by a Zone Top-Level Domain (zTLD) string.
      </t>
+     <t>
+       <!-- FIXME: MUST or SHOULD? Was must reformulated SHOULD -->
+       A client implementation SHOULD enable the user to create and manage 
zones.
+       If this functionality is not implemented, names can still be resolved
+       if zone keys for the initial step in the name resolution are available
+       (see <xref target="resolution"/>).
+     </t>
      <t>
        Each zone type (ztype) is assigned a unique 32-bit number when it is 
registered
        in the GNUnet Assigned Numbers Authority <xref target="GANA" />.
@@ -1847,6 +1855,7 @@ q := SHA-512 (ZKDF-Public(zk, label))
        <xref target="governance" />.
      </t>
      <t>
+       <!-- FIXME removed client everywhere. We only have an implementation -->
        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.
@@ -1857,9 +1866,10 @@ q := SHA-512 (ZKDF-Public(zk, label))
        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. -->
-       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.
+       The resolver implementation MUST NOT filter results according to the 
desired
+       record type.
+       Filtering of record sets MAY still be done by the client which
+       could be a stub resolver.
      </t>
      <section anchor="governance" numbered="true" toc="default">
        <name>Start Zones</name>
@@ -1884,13 +1894,13 @@ q := SHA-512 (ZKDF-Public(zk, label))
          management of root servers in DNS (see <xref target="RFC8324"/>, 
Section 3.10 and 3.12).
        </t>
         <t>
-         In the following, we give examples how a local client resolver SHOULD
+         In the following, we give examples how a local client SHOULD
          discover the start zone.  The process given is not exhaustive and
          clients MAY supplement it with other mechanisms or ignore it if the
          particular application requires a different process.
        </t>
        <t>
-         GNS clients MUST first try to interpret the top-level domain of
+         GNS implementations MUST first try to interpret the top-level domain 
of
          a GNS name as a zone key representation (i.e. a zTLD).
          If the top-level domain can be converted to a valid ztype and zone
          key value, the resulting zone key is used as the start zone:
@@ -2360,7 +2370,7 @@ NICK: john (Supplemental)
            ensure that their local start zone information is not compromised or
            outdated.
            It can be expected that the processing of zone revocations and an
-           initial start zone is provided with a GNS client implementation
+           initial start zone is provided with a GNS implementation
            ("drop shipping").  Shipping an initial start zone with an entry for
            the root (".") effectively establishes a root zone.
            Extension and customization of the zone is at the full discretion of

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