Changeset 2392


Ignore:
Timestamp:
14/09/13 06:54:34 (7 years ago)
Author:
fielding@…
Message:

clarify that recipients MUST parse for empty list elements; addresses #475

Location:
draft-ietf-httpbis/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.html

    r2391 r2392  
    22162216      </p>
    22172217      <div id="rfc.figure.u.61"></div>
    2218       <p>Thus,</p><pre class="text">  1#element =&gt; element *( OWS "," OWS element )
     2218      <p>Thus, a sender <em class="bcp14">MUST</em> expand the list construct as follows:
     2219      </p><pre class="text">  1#element =&gt; element *( OWS "," OWS element )
    22192220</pre><div id="rfc.figure.u.62"></div>
    22202221      <p>and:</p><pre class="text">  #element =&gt; [ 1#element ]
    22212222</pre><div id="rfc.figure.u.63"></div>
    22222223      <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 )
    2223 </pre><p id="rfc.section.7.p.6">For compatibility with legacy list rules, recipients <em class="bcp14">SHOULD</em> accept empty list elements. In other words, consumers would follow the list productions:
     2224</pre><p id="rfc.section.7.p.6">For compatibility with legacy list rules, recipients <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,
     2225         but not so much that they could be used as a denial of service mechanism. In other words, recipients <em class="bcp14">MUST</em> expand the list construct as follows:
    22242226      </p>
    22252227      <div id="rfc.figure.u.64"></div><pre class="text">  #element =&gt; [ ( "," / element ) *( OWS "," [ OWS element ] ) ]
    22262228 
    22272229  1#element =&gt; *( "," OWS ) element *( OWS "," [ OWS element ] )
    2228 </pre><p id="rfc.section.7.p.8">Note that empty elements do not contribute to the count of elements present, though.</p>
    2229       <p id="rfc.section.7.p.9">For example, given these ABNF productions:</p>
     2230</pre><p id="rfc.section.7.p.8">Empty elements do not contribute to the count of elements present. For example, given these ABNF productions:</p>
    22302231      <div id="rfc.figure.u.65"></div><pre class="text">  example-list      = 1#example-list-elmt
    22312232  example-list-elmt = token ; see <a href="#field.components" title="Field value components">Section&nbsp;3.2.6</a>
    2232 </pre><p id="rfc.section.7.p.11">Then these are valid values for example-list (not including the double quotes, which are present for delimitation only):</p>
     2233</pre><p id="rfc.section.7.p.10">Then the following are valid values for example-list (not including the double quotes, which are present for delimitation
     2234         only):
     2235      </p>
    22332236      <div id="rfc.figure.u.66"></div><pre class="text">  "foo,bar"
    22342237  "foo ,bar,"
    22352238  "foo , ,bar,charlie   "
    2236 </pre><p id="rfc.section.7.p.13">But these values would be invalid, as at least one non-empty element is required:</p>
     2239</pre><p id="rfc.section.7.p.12">In contrast, the following values would be invalid, since at least one non-empty element is required by the example-list production:</p>
    22372240      <div id="rfc.figure.u.67"></div><pre class="text">  ""
    22382241  ","
    22392242  ",   ,"
    2240 </pre><p id="rfc.section.7.p.15"><a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;B</a> shows the collected ABNF, with the list rules expanded as explained above.
     2243</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.
    22412244      </p>
    22422245      <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r2391 r2392  
    32913291</t>
    32923292<figure><preamble>
    3293   Thus,
     3293  Thus, a sender &MUST; expand the list construct as follows:
    32943294</preamble><artwork type="example">
    32953295  1#element =&gt; element *( OWS "," OWS element )
     
    33063306</artwork></figure>
    33073307<t>
    3308   For compatibility with legacy list rules, recipients &SHOULD; accept empty
    3309   list elements. In other words, consumers would follow the list productions:
     3308  For compatibility with legacy list rules, recipients &MUST; parse and ignore
     3309  a reasonable number of empty list elements: enough to handle common mistakes
     3310  by senders that merge values, but not so much that they could be used as a
     3311  denial of service mechanism. In other words, recipients &MUST; expand the
     3312  list construct as follows:
    33103313</t>
    33113314<figure><artwork type="example">
     
    33153318</artwork></figure>
    33163319<t>
    3317   Note that empty elements do not contribute to the count of elements present,
    3318   though.
    3319 </t>
    3320 <t>
     3320  Empty elements do not contribute to the count of elements present.
    33213321  For example, given these ABNF productions:
    33223322</t>
     
    33263326</artwork></figure>
    33273327<t>
    3328   Then these are valid values for example-list (not including the double
    3329   quotes, which are present for delimitation only):
     3328  Then the following are valid values for example-list (not including the
     3329  double quotes, which are present for delimitation only):
    33303330</t>
    33313331<figure><artwork type="example">
     
    33353335</artwork></figure>
    33363336<t>
    3337   But these values would be invalid, as at least one non-empty element is
    3338   required:
     3337  In contrast, the following values would be invalid, since at least one
     3338  non-empty element is required by the example-list production:
    33393339</t>
    33403340<figure><artwork type="example">
     
    33443344</artwork></figure>
    33453345<t>
    3346   <xref target="collected.abnf"/> shows the collected ABNF, with the list rules
    3347   expanded as explained above.
     3346  <xref target="collected.abnf"/> shows the collected ABNF after the list
     3347  constructs have been expanded, as described above, for recipients.
    33483348</t>
    33493349</section>
Note: See TracChangeset for help on using the changeset viewer.