Definition of content type #49

Github issue #49
network-quality · Jul 6, 2022 · 70a7eeb · 70a7eeb
1 parent 0fbaeb7
commit 70a7eeb
Show file tree

Hide file tree

Showing 6 changed files with 248 additions and 241 deletions.
diff --git a/draft-ietf-ippm-responsiveness.html b/draft-ietf-ippm-responsiveness.html
@@ -692,6 +692,14 @@ <h1 id="rfc.section.6">
 <p id="rfc.section.6.p.1">The RPM measurement uses standard protocols: no new protocol is defined.</p>
 <p id="rfc.section.6.p.2">Both the client and the server MUST support HTTP/2 over TLS 1.3.  The client MUST be able to send a GET request and a POST.  The server MUST be able to respond to both of these HTTP commands.  The server MUST have the ability to provide content upon a GET request.  Both client and server SHOULD use loss-based congestion controls like Cubic.  The server MUST use a packet scheduling algorithm that minimizes internal queueing to avoid affecting the client&#8217;s measurement.</p>
 <p id="rfc.section.6.p.3">The server MUST respond to 4 URLs:</p>
+<p></p>
+
+<ol>
+<li>A &#8220;small&#8221; URL/response: The server must respond with a status code of 200 and 1 byte in the body.  The actual body content is irrelevant.  The server SHOULD specify the content-type as application/octet-stream.</li>
+<li>A &#8220;large&#8221; URL/response: The server must respond with a status code of 200 and a body size of at least 8GB.  The server SHOULD specify the content-type as application/octet-stream.  The body can be bigger, and may need to grow as network speeds increases over time.  The actual body content is irrelevant.  The client will probably never completely download the object, but will instead close the connection after reaching working condition and making its measurements.</li>
+<li>An &#8220;upload&#8221; URL/response: The server must handle a POST request with an arbitrary body size.  The server should discard the payload.</li>
+<li>A configuration URL that returns a JSON <a href="#RFC8259" class="xref">[RFC8259]</a> object with the information the client uses to run the test (sample below). The server SHOULD specify the content-type as application/json.  Sample JSON:</li>
+</ol>
 <pre>
 {
   "version": 1,
@@ -702,14 +710,6 @@ <h1 id="rfc.section.6">
   }
 }
 </pre>
-<p></p>
-
-<ol>
-<li>A &#8220;small&#8221; URL/response: The server must respond with a status code of 200 and 1 byte in the body.  The actual body content is irrelevant.</li>
-<li>A &#8220;large&#8221; URL/response: The server must respond with a status code of 200 and a body size of at least 8GB.  The body can be bigger, and may need to grow as network speeds increases over time.  The actual body content is irrelevant.  The client will probably never completely download the object, but will instead close the connection after reaching working condition and making its measurements.</li>
-<li>An &#8220;upload&#8221; URL/response: The server must handle a POST request with an arbitrary body size.  The server should discard the payload.</li>
-<li>A configuration URL that returns a JSON <a href="#RFC8259" class="xref">[RFC8259]</a> object with the information the client uses to run the test (sample below).  Sample JSON:  <br><br> </li>
-</ol>
 <p id="rfc.section.6.p.5">The client begins the responsiveness measurement by querying for the JSON configuration.  This supplies the URLs for creating the load-generating connections in the upstream and downstream direction as well as the small object for the latency measurements.</p>
 <h1 id="rfc.section.7">
 <a href="#rfc.section.7">7.</a> <a href="#security-considerations" id="security-considerations">Security Considerations</a>

diff --git a/draft-ietf-ippm-responsiveness.md b/draft-ietf-ippm-responsiveness.md
@@ -530,9 +530,11 @@ The server MUST respond to 4 URLs:
 1. A "small" URL/response:
 The server must respond with a status code of 200 and 1 byte in the body.
 The actual body content is irrelevant.
+The server SHOULD specify the content-type as application/octet-stream.
 
 2. A "large" URL/response:
 The server must respond with a status code of 200 and a body size of at least 8GB.
+The server SHOULD specify the content-type as application/octet-stream.
 The body can be bigger, and may need to grow as network speeds increases over time.
 The actual body content is irrelevant.
 The client will probably never completely download the object,
@@ -544,19 +546,20 @@ The server must handle a POST request with an arbitrary body size.
 The server should discard the payload.
 
 4. A configuration URL that returns a JSON {{RFC8259}} object with the information
-the client uses to run the test (sample below).
+the client uses to run the test (sample below). The server SHOULD specify the
+content-type as application/json.
 Sample JSON:
 
-   ~~~
-   {
-     "version": 1,
-     "urls": {
-       "small_https_download_url": "https://networkquality.example.com/api/v1/small",
-       "large_https_download_url": "https://networkquality.example.com/api/v1/large",
-       "https_upload_url": "https://networkquality.example.com/api/v1/upload"
-     }
-   }
-   ~~~
+~~~
+{
+  "version": 1,
+  "urls": {
+    "small_https_download_url": "https://networkquality.example.com/api/v1/small",
+    "large_https_download_url": "https://networkquality.example.com/api/v1/large",
+    "https_upload_url": "https://networkquality.example.com/api/v1/upload"
+  }
+}
+~~~
 
 The client begins the responsiveness measurement by querying for the JSON configuration.
 This supplies the URLs for creating the load-generating connections in

diff --git a/draft-ietf-ippm-responsiveness.pdf b/draft-ietf-ippm-responsiveness.pdf
diff --git a/draft-ietf-ippm-responsiveness.ps b/draft-ietf-ippm-responsiveness.ps
diff --git a/draft-ietf-ippm-responsiveness.txt b/draft-ietf-ippm-responsiveness.txt
@@ -640,22 +640,25 @@ Internet-Draft   Responsiveness under Working Conditions       July 2022
 
    1.  A "small" URL/response: The server must respond with a status
        code of 200 and 1 byte in the body.  The actual body content is
-       irrelevant.
+       irrelevant.  The server SHOULD specify the content-type as
+       application/octet-stream.
 
    2.  A "large" URL/response: The server must respond with a status
-       code of 200 and a body size of at least 8GB.  The body can be
-       bigger, and may need to grow as network speeds increases over
-       time.  The actual body content is irrelevant.  The client will
-       probably never completely download the object, but will instead
-       close the connection after reaching working condition and making
-       its measurements.
+       code of 200 and a body size of at least 8GB.  The server SHOULD
+       specify the content-type as application/octet-stream.  The body
+       can be bigger, and may need to grow as network speeds increases
+       over time.  The actual body content is irrelevant.  The client
+       will probably never completely download the object, but will
+       instead close the connection after reaching working condition and
+       making its measurements.
 
    3.  An "upload" URL/response: The server must handle a POST request
        with an arbitrary body size.  The server should discard the
        payload.
 
    4.  A configuration URL that returns a JSON [RFC8259] object with the
-       information the client uses to run the test (sample below).
+       information the client uses to run the test (sample below).  The
+       server SHOULD specify the content-type as application/json.
        Sample JSON:
 
 
@@ -666,9 +669,6 @@ Internet-Draft   Responsiveness under Working Conditions       July 2022
 
 
 
-
-
-
 Paasch, et al.           Expires January 7, 2023               [Page 12]
 
 Internet-Draft   Responsiveness under Working Conditions       July 2022