commit 6c54a724bd64d781d4395ee2f8afdbc4b2caeecf
parent 552edf5e3136e3c144805d4508ba05b387f1ecc3
Author: Christian Grothoff <christian@grothoff.org>
Date: Fri, 30 Jun 2023 23:36:54 +0200
improve English
Diffstat:
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -2077,12 +2077,12 @@ q := SHA-512 (ZKDF(zk, label))
Recursive in this context means that a resolver does not provide
intermediate results for a query to the application.
Instead, it <bcp14>MUST</bcp14> respond to a resolution request with either the
- requested resource record or an error message in case the resolution
+ requested resource record or an error message in case resolution
fails.
<xref target="figure_resolution"/> illustrates how an application
requests the lookup of a GNS name (1).
The application <bcp14>MAY</bcp14> provide a desired record type to the resolver.
- Subsequently, the Start Zone is determined (2) and the recursive
+ Subsequently, a Start Zone is determined (2) and the recursive
resolution process started.
This is where the desired record type is used to guide processing.
For example, if a zone delegation record type is requested, the
@@ -2091,8 +2091,8 @@ q := SHA-512 (ZKDF(zk, label))
Details on how the resolution process is initiated and each iterative
result (3a,3b) in the resolution is processed are provided in the sections below.
The results of the lookup are eventually returned to the application (4).
- The implementation <bcp14>MUST NOT</bcp14> filter results
- according to the desired record type.
+ The implementation <bcp14>MUST NOT</bcp14> filter the returned resource
+ record sets according to the desired record type.
Filtering of record sets is typically done by the application.
</t>
<figure anchor="figure_resolution" title="The recursive GNS resolution process.">
