[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0001] branch master updated: Client and Applications
From: |
gnunet |
Subject: |
[lsd0001] branch master updated: Client and Applications |
Date: |
Sun, 06 Feb 2022 15:17:34 +0100 |
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.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [lsd0001] branch master updated: Client and Applications,
gnunet <=