Changeset 2593

Timestamp:

28/01/14 00:44:14 (8 years ago)

Author:

fielding@…

Message:

(editorial) correctly word requirements on generating lists and recipient parsing of lists; see #531

Location:

draft-ietf-httpbis/latest

Files:

• p1-messaging.html (modified) (3 diffs)
• p1-messaging.xml (modified) (5 diffs)

draft-ietf-httpbis/latest/p1-messaging.html

@@ -2353 +2353 @@
          </p>
          <div id="rfc.figure.u.61"></div>
-         <p>Thus, a sender <em class="bcp14">MUST</em> expand the list construct as follows:
+         <p>In any production that uses the list construct, a sender <em class="bcp14">MUST NOT</em> generate empty list elements. In other words, a sender <em class="bcp14">MUST</em> generate lists that satisfy the following syntax:
          </p><pre class="text">  1#element =&gt; element *( OWS "," OWS element )
 </pre><div id="rfc.figure.u.62"></div>
@@ -2360 +2360 @@
          <p>and for n &gt;= 1 and m &gt; 1:</p><pre class="text">  &lt;n&gt;#&lt;m&gt;element =&gt; element &lt;n-1&gt;*&lt;m-1&gt;( OWS "," OWS element )
 </pre><p id="rfc.section.7.p.6">For compatibility with legacy list rules, a recipient <em class="bcp14">MUST</em> parse and ignore a reasonable number of empty list elements: enough to handle common mistakes by senders that merge values,
-            but not so much that they could be used as a denial of service mechanism. In other words, a recipient <em class="bcp14">MUST</em> expand the list construct as follows:
+            but not so much that they could be used as a denial of service mechanism. In other words, a recipient <em class="bcp14">MUST</em> accept lists that satisfy the following syntax:
          </p>
          <div id="rfc.figure.u.64"></div><pre class="text">  #element =&gt; [ ( "," / element ) *( OWS "," [ OWS element ] ) ]
@@ -2378 +2378 @@
   ","
   ",   ,"
-</pre><p id="rfc.section.7.p.14"><a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;B</a> shows the collected ABNF after the list constructs have been expanded, as described above, for recipients.
+</pre><p id="rfc.section.7.p.14"><a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;B</a> shows the collected ABNF for recipients after the list constructs have been expanded.
          </p>
       </div>

draft-ietf-httpbis/latest/p1-messaging.xml

@@ -3313 +3313 @@
 <section title="ABNF list extension: #rule" anchor="abnf.extension">
 <t>
-  A #rule extension to the ABNF rules of <xref target="RFC5234"/> is used to
-  improve readability in the definitions of some header field values.
-</t>
-<t>
-  A construct "#" is defined, similar to "*", for defining comma-delimited
-  lists of elements. The full form is "&lt;n&gt;#&lt;m&gt;element" indicating
-  at least &lt;n&gt; and at most &lt;m&gt; elements, each separated by a single
-  comma (",") and optional whitespace (OWS).   
+   A #rule extension to the ABNF rules of <xref target="RFC5234"/> is used to
+   improve readability in the definitions of some header field values.
+</t>
+<t>
+   A construct "#" is defined, similar to "*", for defining comma-delimited
+   lists of elements. The full form is "&lt;n&gt;#&lt;m&gt;element" indicating
+   at least &lt;n&gt; and at most &lt;m&gt; elements, each separated by a single
+   comma (",") and optional whitespace (OWS).   
 </t>
 <figure><preamble>
-  Thus, a sender &MUST; expand the list construct as follows:
+   In any production that uses the list construct, a sender &MUST-NOT;
+   generate empty list elements. In other words, a sender &MUST; generate
+   lists that satisfy the following syntax:
 </preamble><artwork type="example">
   1#element =&gt; element *( OWS "," OWS element )
 </artwork></figure>
 <figure><preamble>
-  and:
+   and:
 </preamble><artwork type="example">
   #element =&gt; [ 1#element ]
 </artwork></figure>
 <figure><preamble>
-  and for n &gt;= 1 and m &gt; 1:
+   and for n &gt;= 1 and m &gt; 1:
 </preamble><artwork type="example">
   &lt;n&gt;#&lt;m&gt;element =&gt; element &lt;n-1&gt;*&lt;m-1&gt;( OWS "," OWS element )
 </artwork></figure>
 <t>
-  For compatibility with legacy list rules, a recipient &MUST; parse and ignore
-  a reasonable number of empty list elements: enough to handle common mistakes
-  by senders that merge values, but not so much that they could be used as a
-  denial of service mechanism. In other words, a recipient &MUST; expand the
-  list construct as follows:
+   For compatibility with legacy list rules, a recipient &MUST; parse and ignore
+   a reasonable number of empty list elements: enough to handle common mistakes
+   by senders that merge values, but not so much that they could be used as a
+   denial of service mechanism. In other words, a recipient &MUST; accept lists
+   that satisfy the following syntax:
 </t>
 <figure><artwork type="example">
@@ -3350 +3352 @@
 </artwork></figure>
 <t>
-  Empty elements do not contribute to the count of elements present.
-  For example, given these ABNF productions: 
+   Empty elements do not contribute to the count of elements present.
+   For example, given these ABNF productions: 
 </t>
 <figure><artwork type="example">
@@ -3358 +3360 @@
 </artwork></figure>
 <t>
-  Then the following are valid values for example-list (not including the
-  double quotes, which are present for delimitation only):
+   Then the following are valid values for example-list (not including the
+   double quotes, which are present for delimitation only):
 </t>
 <figure><artwork type="example">
@@ -3367 +3369 @@
 </artwork></figure>
 <t>
-  In contrast, the following values would be invalid, since at least one
-  non-empty element is required by the example-list production:
+   In contrast, the following values would be invalid, since at least one
+   non-empty element is required by the example-list production:
 </t>
 <figure><artwork type="example">
@@ -3376 +3378 @@
 </artwork></figure>
 <t>
-  <xref target="collected.abnf"/> shows the collected ABNF after the list
-  constructs have been expanded, as described above, for recipients.
+   <xref target="collected.abnf"/> shows the collected ABNF for recipients
+   after the list constructs have been expanded.
 </t>
 </section>