Ignore:
Timestamp:
10/02/11 18:58:41 (9 years ago)
Author:
julian.reschke@…
Message:

rephrase some conformance requirements, add new section about conformance in general

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis-content-disp/latest/draft-ietf-httpbis-content-disp.xml

    r1104 r1115  
    105105</section> 
    106106
    107 <section title="Notational Conventions">
     107<section title="Notational Conventions" anchor="notational.conventions">
    108108<t>
    109109  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     
    116116  implied linear whitespace (LWS).
    117117</t>
    118 </section> 
     118</section>
     119
     120<section title="Conformance and Error Handling" anchor="conformance.and.error.handling">
     121<t>
     122  This specification defines conformance criteria for both senders (usually,
     123  HTTP origin servers) and recipients (usually, HTTP user agents) of the
     124  Content-Location header field. An implementation is considered conformant if
     125  it complies with all of the requirements associated with its role.
     126</t>
     127<t>
     128  This specification also defines certain forms of the header field-value to be
     129  invalid, using both ABNF and prose requirements, but it does not define
     130  special handling these invalid field-values.
     131</t>
     132<t>
     133  Sending implementations &MUST-NOT; generate Content-Location header fields
     134  that are invalid.
     135</t>
     136<t>
     137  Consuming implementations &MAY; take steps to recover a usable field-value
     138  from an invalid header field, but &SHOULD-NOT; reject the message outright,
     139  unless this is explicitly desirable behaviour (e.g., the implementation is a
     140  validator). As such, the default handling of invalid fields is to ignore them.
     141</t>
     142</section>
    119143
    120144<section title="Header Field Definition" anchor="header.field.definition">
     
    161185  ext-value   = &lt;ext-value, defined in <xref target="RFC5987" x:sec="3.2"/>&gt;
    162186</artwork></figure>
    163 
    164 <t>
    165   Senders &MUST-NOT; generate header field values with multiple instances of
    166   the same parameter name. Recipients &SHOULD; treat these values
    167   as invalid.
     187<t>
     188  Header field values with multiple instances of the same parameter name are
     189  invalid.
    168190</t>
    169191<t>
     
    190212</t>
    191213<t>
    192   Unknown or unhandled disposition types &SHOULD; be handled the same way as
    193   "attachment" (see also <xref target="RFC2183" x:fmt="," x:sec="2.8"/>).
     214  Unknown or unhandled disposition types &SHOULD; be handled by recipients the
     215  same way as "attachment" (see also <xref target="RFC2183" x:fmt="," x:sec="2.8"/>).
    194216</t>
    195217</section>
     
    926948  Updated implementation information (Chrome 9 implements RFC 5987).
    927949</t>
     950<t>
     951  Clarify who requirements are on, add a section discussing conformance
     952  and handling of invalid field values in general.
     953</t>
    928954</section>
    929955
Note: See TracChangeset for help on using the changeset viewer.