use cases

1 files changed, 165 insertions, 110 deletions

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 8d29003..10009a7 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -322,7 +322,7 @@
          zone key of a zone.
          Due to the statistical uniqueness of zone keys, zTLDs are also globally unique.
          A zTLD label sequence can only be distinguished from ordinary TLD label sequences
-         by attempting to decode the labels into a zone type and zone key.
+         by attempting to decode the labels into a zone type and zone key.
        </dd>
 
        <dt>Zone Type</dt>
@@ -3203,6 +3203,169 @@ Value       Symbol            Symbol
        </figure>
      </section>
      <section>
+       <name>Use Cases</name>
+       <t>
+         This section outlines a number of specific use cases which may
+         help to fill the gaps not addressed in the technical specification
+         itself.
+       </t>
+       <section anchor="day_in_zoneowner">
+         <name>Zone Dissemination</name>
+         <t>
+           In order to become a zone owner, it is sufficient to generate
+           a zone key and a corresponding secret key using a GNS implementation.
+           At this point, the zone owner can manage GNS resource records in a
+           local zone database.
+           The resource records can then be published by a GNS implementation
+           as defined in <xref target="publish"/>.
+           For other users to resolve the resource records, respective
+           zone information must be disseminated first.
+           The zone owner may decide to make the zone key and labels known
+           to a selected set of users only or to make this information available
+           to the general public.
+         </t>
+         <t>
+           Sharing zone information directly with specific users not only allows
+           to potentially preserve zone and record privacy, but also allows
+           the zone owner and the user to establish strong trust relationships.
+           For example, a bank may send a customer letter with a QR code which
+           contains the GNS zone of the bank.
+           This allows the user to scan the QR code and establish a strong
+           link to the zone of the bank and with it, for example, the IP address
+           of the online banking web site.
+         </t>
+         <t>
+           Most Internet services likely want to make their zones available
+           to the general public as efficiently as possible.
+           First, it is reasonable to assume that zones which are commanding
+           high levels of reputation and trust are likely included in the
+           default suffix-to-zone mappings of implementations.
+           Hence dissemination of a zone through delegation under such zones
+           can be a viable path in order to disseminate a zone publicly.
+           For example, it is conceivable that organizations such as ICANN
+           or country-code top-level domain registrars also manage GNS zones
+           and offer registration or delegation services.
+         </t>
+         <t>
+           Following best practices in particularly those relating to
+           security and abuse mitigation are methods which allow zone owners
+           and aspiring registrars to gain a good reputation and eventually
+           trust.
+           This includes, of course, diligent protection of private zone key
+           material.
+           Formalizing such best practices is out of scope of this
+           specification and should be addressed in a separate document and take
+           <xref target="security"/> into account.
+         </t>
+       </section>
+       <section>
+         <name>Suffix-to-zone Configuration</name>
+         <t>
+           A user is expected to install a GNS implementation if it is not already
+           provided through other means such as the operating system
+           or the browser.
+           It is likely that the implementation ships with a configurable
+           default suffix-to-name mapping.
+           This means that the user is able to resolve GNS names ending on a
+           zTLD or ending on a configured suffix-to-name mapping.
+           At this point the user may delete or otherwise modify the
+           implementation's default suffix-to-name mapping:
+          </t>
+          <t>
+            Deletion of mappings may become necessary of the
+            zone owner referenced by the mapping has lost the trust of the user.
+            For example, this could be due to lax registration policies resulting
+            in phishing activities.
+            Modification and addition of new mappings are means to heal the
+            namespace perforation which would occur in the case of a deletion
+            or to simply establish a strong direct trust relationship.
+            However, this requires the user's knowledge of the respective zone
+            keys.
+            This information must be retrieved out of band, as illustrated in
+            <xref target="day_in_zoneowner"/>:
+            A bank may send the user a letter with a QR code which contains the
+            GNS zone of the bank.
+            Other examples include scanning the QR off the device of a friend,
+            from a storefront, or an advertisement.
+            The level of trust in the respective zone is contextual and likely
+            varies from user to user.
+            Trust in a zone provided through a letter from a bank which
+            may also include a credit card is certainly different from a zone
+            found on a random advertisement in the streets.
+            However, this trust is immediately tangible to the user and can
+            be reflected in the local naming as well.
+          </t>
+          <t>
+            User clients should facilitate the suffix-to-name modification
+            process, for example by providing a QR code reader or other import
+            mechanisms.
+            Implementations are ideally implemented
+            according to best practices, particular addressing applicable points
+            from <xref target="security"/>.
+            Formalizing such best practices is out of scope of this
+            specification.
+         </t>
+       </section>
+       <section>
+         <name>Virtual Hosting</name>
+         <t>
+            HTTP virtual hosting and TLS Server Name Indication are common
+            use cases on the Web.
+            The HTTP client such as a browser supplies a DNS name in the HTTP
+            "Host"-header or the TLS handshake, respectively.
+            This allows the HTTP server to serve the indicated virtual host
+            with a matching TLS handshake.
+            Any resource record in GNS can be represented as a concatenation of
+            of a GNS label and the zTLD of the zone.
+            While not human-readable, this property of GNS names can be
+            leveraged in order to facilitate the same use cases.
+          </t>
+          <t>
+            Consider the GNS name "www.example.gns" entered in a GNS-aware
+            HTTP client.
+            At first, "www.example.gns" is resolved using GNS yielding a record
+            set.
+            Then, the HTTP client first determines the virtual host as follows:
+          </t>
+          <ol>
+            <li>If there is a LEHO record (<xref target="gnsrecords_leho"/>) in
+              the record set, then the HTTP client uses the record value in the
+              "Host"-header field of the HTTP request. Example:
+              "Host: www.example.com".</li>
+            <li>
+              If there is no LEHO record in the record set,
+              then the HTTP client tries to find the zone of the record
+              and translates the GNS name into an unabiguous
+              zTLD-representation before using it in the "Host"-header field of
+              the HTTP request. Example:
+              "Host: www.000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W".
+            </li>
+          </ol>
+          <t>
+            In order to determine a canonical representation of the record with
+            a zTLD, at most two queries are required:
+            First, it must be checked whether "www.example.com" itself points to
+            a zone delegation record which would imply that the record set which
+            was originally resolved is published under the apex label.
+            If it does, the unique GNS name is simply the zTLD representation
+            of the delegated zone: "Host: 000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W".
+            If it does not, the unique GNS name is the concatenation of the
+            label "www" and the zTLD representation of the zone as given in the
+            example above.
+            In any case, this representation is globally unique.
+            As such, it can be configured by the HTTP server administrator as a
+            virtual host name.
+          </t>
+          <t>
+            If the HTTP client is a browser, the use of a unique GNS name
+            for virtual hosting or TLS SNI does not necessarily have to be
+            shown to the user.
+            For example, the name in the URL bar may remain as "www.example.gnu"
+            even if the used unique name differs.
+          </t>
+       </section>
+     </section>
+     <section>
        <name>Example flows</name>
        <section>
          <name>AAAA Example Resolution</name>
@@ -3329,115 +3492,7 @@ Value       Symbol            Symbol
            <li>Return record set to application.</li>
          </ol>
        </section>
-       <section anchor="day_in_zoneowner">
-         <name>Use-case: Zone Owner</name>
-         <t>
-           In order to become a zone owner, it is sufficient to generate
-           a zone key and a corresponding secret key using a GNS implementation.
-           At this point, the zone owner can manage GNS resource records in a
-           local zone database.
-           The resource records can then be published by a GNS implementation
-           as defined in <xref target="publish"/>.
-         </t>
-         <t>
-           In order for other users to resolve the resource records, respective
-           zone information must be disseminated first.
-           The zone owner may decide to make the zone key and labels known
-           to a selected set of users only or to make this information available
-           to the general public.
-         </t>
-         <t>
-           Sharing zone information directly with specific users not only allows
-           to potentially preserve zone and record privacy, but also allows
-           the zone owner and the user to establish strong trust relationships.
-           For example, a bank may send a customer letter with a QR code which
-           contains the GNS zone of the bank.
-           This allows the user to scan the QR code and establish a strong
-           link to the zone of the bank and with it, for example, the IP address
-           of the online banking web site.
-         </t>
-         <t>
-           Most Internet services likely want to make their zones available
-           to the general public as efficiently as possible.
-           First, it is reasonable to assume that zones which are commanding
-           high levels of reputation and trust are likely included in the
-           default suffix-to-zone mappings of implementations.
-           Hence dissemination of a zone through delegation under such zones
-           can be a viable path in order to disseminate a zone publicly.
-           For example, it is conceivable that organizations such as ICANN
-           or country-code top-level domain registrars also manage GNS zones
-           and offer registration or delegation services.
-         </t>
-         <t>
-           Following best practices in particularly those relating to
-           security and abuse mitigation are methods which allow zone owners
-           and aspiring registrars to gain a good reputation and eventually
-           trust.
-           This includes, of course, diligent protection of private zone key
-           material.
-           Formalizing such best practices is out of scope of this
-           specification and should be addressed in a separate document addressing
-           <xref target="security"/>.
-         </t>
-       </section>
-       <section>
-         <name>Use-case: End-user</name>
-         <t>
-           A user is expected to install a GNS implementation if it is not already
-           provided through other means such as the operating system
-           or the browser.
-         </t>
-         <t>
-           It is expected that in any case, the implementation likely ships
-           with a configurable default suffix-to-name mapping.
-           This means that the user is able to resolve GNS names ending on a
-           zTLD or ending on a configured suffix-to-name mapping.
-         </t>
-         <t>
-           At this point the user may modify the implementation's default
-           suffix-to-name mapping.
-           This includes:
-          </t>
-          <ul>
-            <li>Deletion of mappings.</li>
-            <li>Modification of a mapping</li>
-            <li>Addition of a new mapping</li>
-          </ul>
-          <t>
-            The user may delete mappings. This may become necessary of the
-            zone owner referenced by the mapping has lost the trust of the user.
-            For example, this could be due to lax registration policies resulting
-            in phishing activities.
-          </t>
-          <t>
-            Modification and addition of new mappings are means to heal the
-            namespace perforation which would occur in the case of a deletion
-            or to simply establish a strong direct trust relationship.
-            However, this requires the user's knowledge of respective zone
-            information.
-            This information must be retrieved out of band, as illustrated in
-            <xref target="day_in_zoneowner"/>:
-            A bank may send the user a letter with a QR code which contains the
-            GNS zone of the bank.
-            Other examples include scanning the QR off the device of a friend,
-            from a storefront, or an advertisement.
-            The level of trust in the respective zone is contextual and likely
-            varies from user to user.
-            Trust in a zone provided through a letter from a bank which
-            may also include a credit card is certainly different from a zone
-            found on a random advertisement in the streets.
-            However, this trust is immediately tangible to the user and can
-            be reflected in the local naming as well.
-          </t>
-          <t>
-            User clients should facilitate the suffix-to-name modification
-            process and are ideally implemented
-            according to best practices, particular addressing applicable points
-            from <xref target="security"/>.
-            Formalizing such best practices is out of scope of this
-            specification.
-         </t>
-       </section>
+
      </section>
      <section>
        <name>Test Vectors</name>