Updates from RFC Editor questions.

Author: PSUdaemon

rfc9246.xml

@@ -53,7 +53,7 @@
 <!-- [rfced] Please insert any keywords (beyond those that appear in the
 title) for use on https://www.rfc-editor.org/search. -->
 
-<keyword>example</keyword>
+<keyword>jwt,json,token,cdn,url,http,hls,dash</keyword>
 
     <abstract>
       <t>This document describes how the concept of URI Signing supports the
@@ -181,7 +181,7 @@ title) for use on https://www.rfc-editor.org/search. -->
         to a CDN, creating a Target CDN URI (2) (alternatively, the Target
         CDN URI itself is embedded in the HTML). The Target CDN URI is the
         Signed URI, which may include the IP address of the UA and/or a time
-        window. The signed URI always contains a signed JWT generated by the
+        window. The Signed URI always contains a signed JWT generated by the
         CSP using a shared secret or private key. Once the UA receives the
         response with the Signed URI, it sends a new HTTP request using the
         Signed URI to the CDN (3). Upon receiving the request, the CDN
@@ -362,11 +362,14 @@ title) for use on https://www.rfc-editor.org/search. -->
       <t>The following is an example where the URI Signing Package Attribute name is "token" and the signed JWT is "SIGNEDJWT":</t>
 
 
-      <sourcecode type=""><![CDATA[http://example.com/media/path?come=data&token=SIGNEDJWT&other=data]]></sourcecode>
+      <sourcecode><![CDATA[http://example.com/media/path?come=data&token=SIGNEDJWT&other=data]]></sourcecode>
 <!-- [rfced] Please let us know if a "type" attribute may be added to the
 sourcecode elements in this document. The allowed types can be found
 here: https://www.rfc-editor.org/materials/sourcecode-types.txt
 Note that it is acceptable to leave the type attribute empty.
+
+Updated.
+
 -->
 
 
@@ -390,7 +393,7 @@ Note that it is acceptable to leave the type attribute empty.
         "mandatory" identifiers in square brackets refer to whether or
         not a given claim <bcp14>MUST</bcp14> be present in a URI Signing JWT.)</t>
         <t>Note: The time on the entities that generate and
-        verify the signed URI <bcp14>MUST</bcp14> be in sync. In the CDNI case, this
+        verify the Signed URI <bcp14>MUST</bcp14> be in sync. In the CDNI case, this
         means that CSP, uCDN, and dCDN servers need to be
         time synchronized. It is <bcp14>RECOMMENDED</bcp14> to use
         <xref target="RFC5905" format="default">NTP</xref> for time synchronization.</t>
@@ -405,8 +408,8 @@ Note that it is acceptable to leave the type attribute empty.
 	  <t>Issuer (iss) [optional] - The semantics in
             <xref target="RFC7519" sectionFormat="of" section="4.1.1" format="default"/> <bcp14>MUST</bcp14> be followed.
             If this claim is used, it <bcp14>MUST</bcp14> be used to identify the
-            issuer (signer) of the JWT.  In particular, the recipient will have already
-            received, in trusted configuration, a mapping of issuer name to one or more
+            Issuer (signer) of the JWT.  In particular, the recipient will have already
+            received, in trusted configuration, a mapping of Issuer name to one or more
             keys used to sign JWTs and must verify that the JWT was signed by one of
             those keys. If this claim is used and the CDN verifying the
             signed JWT does not support Issuer verification, or if the
@@ -620,7 +623,7 @@ sectionFormat="of" section="4.1.7"  format="default"/> <bcp14>MUST</bcp14> be fo
           client <bcp14>SHOULD</bcp14> be directed to return the token with requests for any path. If the CDNI Signed
           Token Depth is greater than zero, then the CDN <bcp14>SHOULD</bcp14> send the client a token to return for
           future requests wherein the first CDNI Signed Token Depth segments of the path match the first
-          CDNI Signed Token Depth segments of the signed URI path. This matching <bcp14>MUST</bcp14> use the URI with the
+          CDNI Signed Token Depth segments of the Signed URI path. This matching <bcp14>MUST</bcp14> use the URI with the
           token removed, as specified in <xref target="uri_container_forms" format="default"/>.</t>
           <t>If the URI path to match contains fewer segments than the CDNI Signed Token Depth claim, a signed JWT
           <bcp14>MUST NOT</bcp14> be generated for the purposes of Signed Token Renewal. If the CDNI Signed Token Depth
@@ -676,9 +679,12 @@ purposes only):"
 
 Original:
 [^:]*\\://[^/]*/folder/content/quality_[^/]*/segment.{3}\\.mp4(\\?.*)?
+
+Changed below.
+
 -->
             <sourcecode><![CDATA[
-[^:]*\\://[^/]*/folder/content/quality_[^/]*/segment.{3}\\.mp4(\\?.*)?
+[^:]*\\://[^/]*/dir/content/quality_[^/]*/segment.{3}\\.mp4(\\?.*)?
                   ]]></sourcecode>
             <t>Note: Due to computational complexity of executing arbitrary regular expressions, it is <bcp14>RECOMMENDED</bcp14> to only execute after verifying the JWT to ensure its authenticity.</t>
           </section>
@@ -761,7 +767,7 @@ Original:
         </section>
       </section>
       <section anchor="communicating_token" numbered="true" toc="default">
-        <name>Communicating a Signed JWTs in Signed Token Renewal</name>
+        <name>Communicating a Signed JWT in Signed Token Renewal</name>
 <!--[rfced] Should the 's' be removed in this section title?
 In other words, was singular or plural intended?
 
@@ -773,6 +779,9 @@ Perhaps (singular):
 
 Or (plural):
  3.3.  Communicating Signed JWTs in Signed Token Renewal
+
+Fixed.
+
 -->
         <t>This section assumes the value of the CDNI Signed Token Transport (cdnistt) claim
         has been set to 1.</t>
@@ -949,14 +958,14 @@ in the JWT token.
           </li>
         </ul>
         <t>The following is an example of a URI Signing metadata payload with all default values:</t>
-        <sourcecode><![CDATA[
+        <sourcecode type="json"><![CDATA[
 {
   "generic-metadata-type": "MI.UriSigning"
   "generic-metadata-value": {}
 }
           ]]></sourcecode>
         <t>The following is an example of a URI Signing metadata payload with explicit values:</t>
-        <sourcecode><![CDATA[
+        <sourcecode type="json"><![CDATA[
 {
   "generic-metadata-type": "MI.UriSigning"
   "generic-metadata-value":
@@ -1082,19 +1091,19 @@ in the JWT token.
      |5.Request is denied |                    |      <Negative>    |
      |<-------------------------------------------------------------|
      |                    |                    |                    |
-     |6.CSP provides signed URI                |      <Positive>    |
+     |6.CSP provides Signed URI                |      <Positive>    |
      |<-------------------------------------------------------------|
      |                    |                    |                    |
      |7.Content request   |                    |                    |
-     |---------------------------------------->| [Verify URI       |
+     |---------------------------------------->| [Verify URI        |
      |                    |                    |  signature]        |
      |                    |                    |                    |
      |                    |    (ALT: Verification result)           |
      |8.Request is denied |          <Negative>|                    |
      |<----------------------------------------|                    |
      |                    |                    |                    |
      |9.Re-sign URI and redirect to  <Positive>|                    |
-     |  dCDN (newly signed URI)                |                    |
+     |  dCDN (newly Signed URI)                |                    |
      |<----------------------------------------|                    |
      |                    |                    |                    |
      |10.Content request  |                    |                    |
@@ -1116,11 +1125,11 @@ in the JWT token.
             interface, the dCDN advertises its capabilities
             including URI Signing support to the uCDN.</li>
           <li>CSP provides to the uCDN the information needed to
-            verify signed URIs from that CSP. For example, this
+            verify Signed URIs from that CSP. For example, this
             information will include one or more keys used for validation.</li>
           <li>Using the CDNI Metadata interface, the uCDN
             communicates to a dCDN the information needed to
-            verify signed URIs from the uCDN for the given
+            verify Signed URIs from the uCDN for the given
             CSP. For example, this information may include the URI query
             string parameter name for the URI Signing Package Attribute
             in addition to keys used for validation.</li>
@@ -1146,7 +1155,7 @@ in the JWT token.
             provides it to the end user as the URI to use to further request the
             content from the dCDN.</li>
           <li>On receipt of the corresponding content request, the
-            dCDN verifies the Signed JWT in the signed URI using the
+            dCDN verifies the Signed JWT in the Signed URI using the
             information provided by the uCDN in the CDNI
             Metadata.</li>
           <li>If the verification result is negative, the dCDN rejects the
@@ -1185,13 +1194,18 @@ in the JWT token.
 <!-- [rfced] The acronym FCI is not expanded prior to its first use in Figure 3.
 May we add its definition to the terminolgy section?
 
+Yes.
+
 Perhaps:
    FCI: the Footprint & Capabilities Advertisement interface
 -->
 
 <!-- [rfced] This document uses "FCI interface" despite "interface" being
 represented in the acronym itself. May we remove "interface" after both
 intstances of FCI?
+
+Yes.
+
 -->
         <figure anchor="fig_dns_routing">
           <name>DNS-based Request Routing with URI Signing</name>
@@ -1218,7 +1232,7 @@ intstances of FCI?
      |5.Request is denied |                    |      <Negative>    |
      |<-------------------------------------------------------------|
      |                    |                    |                    |
-     |6.Provides signed URI                    |      <Positive>    |
+     |6.Provides Signed URI                    |      <Positive>    |
      |<-------------------------------------------------------------|
      |                    |                    |                    |
      |7.DNS request       |                    |                    |
@@ -1787,13 +1801,18 @@ of RFC 9246
 <!-- [rfced] In the following sentence, what is the intended expansion for
 "LRU"? Is "Least Recently Used (LRU) value" correct?
 
+Yes.
+
 Original:
    If no exp claim is present then a simple LRU could be
    used, however this would allow values to eventually be reused.
 
 Perhaps:
    If no exp claim is present, then a simple Least Recently Used (LRU)
    value could be used; however, this would allow values to eventually be reused.
+
+This is fine.
+
 -->
 	  </dd>
 
@@ -1908,6 +1927,8 @@ Perhaps:
 this be used instead of the current 2014 version (which has been
 withdrawn)?
 
+Yes.
+
 Current:
    [MPEG-DASH]
               ISO, "Information technology - Dynamic adaptive streaming        
@@ -1935,10 +1956,10 @@ Current:
       <t>This section contains three examples of token usage: a simple example with only the
       required claim present, a complex example that demonstrates the full JWT claims set,
       including an encrypted Client IP Address (cdniip), and one that uses a Signed Token Renewal.</t>
-      <t>Note: All of the examples have whitespace added to improve formatting and readability,
+      <t>Note: All of the examples have empty space added to improve formatting and readability,
       but are not present in the generated content.</t>
       <t>All examples use the following JWK Set <xref target="RFC7517" format="default"/>:</t>
-      <sourcecode><![CDATA[
+      <sourcecode type="json"><![CDATA[
 { "keys": [
   {
     "kty": "EC",
@@ -1992,13 +2013,18 @@ place a line break in this line?
 
 Current:
 "cdniuc": "hash:sha-256;2tderfWPa86Ku7YnzW51YUp7dGUjBS_3SW3ELx4hmWY" 
+
+Changed:
+"cdniuc":
+  "hash:sha-256;2tderfWPa86Ku7YnzW51YUp7dGUjBS_3SW3ELx4hmWY" 
 -->
 
-	<sourcecode><![CDATA[
+	<sourcecode type="json"><![CDATA[
 {
   "exp": 1646867369,
   "iss": "uCDN Inc",
-  "cdniuc": "hash:sha-256;2tderfWPa86Ku7YnzW51YUp7dGUjBS_3SW3ELx4hmWY"
+  "cdniuc":
+    "hash:sha-256;2tderfWPa86Ku7YnzW51YUp7dGUjBS_3SW3ELx4hmWY"
 }
 ]]></sourcecode>
         <t>
@@ -2039,7 +2065,7 @@ F6ip2Dv.CohdtLLpgBnTvRJQCFuz-g
         <t>
           The JWT Claim Set before signing:
         </t>
-        <sourcecode><![CDATA[
+        <sourcecode type="json"><![CDATA[
 {
   "aud": "dCDN LLC",
   "sub": "eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XYmp4
@@ -2085,7 +2111,7 @@ jcX8xYD0z3LzQclMG65i1kT2sRbZ7isUw8w
         <t>
           The JWT Claim Set before signing:
         </t>
-        <sourcecode><![CDATA[
+        <sourcecode type="json"><![CDATA[
 {
   "cdniets": 30,
   "cdnistt": 1,
@@ -2114,7 +2140,7 @@ HYw
         <t>
           The JWT Claim Set before signing:
         </t>
-        <sourcecode><![CDATA[
+        <sourcecode type="json"><![CDATA[
 {
   "cdniets": 30,
   "cdnistt": 1,
@@ -2160,9 +2186,16 @@ document. Please let us know which form, if any, is preferred.
 
 signed URI vs. Signed URI
 
+Signed URI
+
 issuer vs. Issuer
 
+It should be Issuer
+
 JSON object vs. JSON Web Encryption Object
+
+I think the two different uses are correct.
+
 -->
 
 <!-- [rfced] Please review the "Inclusive Language" portion of the online 
@@ -2171,6 +2204,9 @@ and let us know if any changes are needed.
 
 For example, please consider whether the following should be updated: 
 "whitespace"
+
+Changed to "empty space"
+
 -->