Changeset 1452 for draft-ietf-httpbis/latest/p7-auth.xml
- Timestamp:
- 23/10/11 20:20:31 (11 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p7-auth.xml
r1443 r1452 16 16 <!ENTITY ID-YEAR "2011"> 17 17 <!ENTITY mdash "—"> 18 <!ENTITY architecture "<xref target='Part1' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 18 19 <!ENTITY notation "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 19 20 <!ENTITY notation-abnf "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 230 231 </t> 231 232 232 <section title=" Requirements" anchor="intro.requirements">233 <section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling"> 233 234 <t> 234 235 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", … … 237 238 </t> 238 239 <t> 239 An implementation is not compliant if it fails to satisfy one or more 240 of the "MUST" or "REQUIRED" level requirements for the protocols it 241 implements. An implementation that satisfies all the "MUST" or "REQUIRED" 242 level and all the "SHOULD" level requirements for its protocols is said 243 to be "unconditionally compliant"; one that satisfies all the "MUST" 244 level requirements but not all the "SHOULD" level requirements for its 245 protocols is said to be "conditionally compliant". 240 This document defines conformance criteria for several roles in HTTP 241 communication, including Senders, Recipients, Clients, Servers, User-Agents, 242 Origin Servers, Intermediaries, Proxies and Gateways. See &architecture; 243 for definitions of these terms. 244 </t> 245 <t> 246 An implementation is considered conformant if it complies with all of the 247 requirements associated with its role(s). Note that SHOULD-level requirements 248 are relevant here, unless one of the documented exceptions is applicable. 249 </t> 250 <t> 251 This document also uses ABNF to define valid protocol elements 252 (<xref target="notation"/>). In addition to the prose requirements placed 253 upon them, Senders &MUST-NOT; generate protocol elements that are invalid. 254 </t> 255 <t> 256 Unless noted otherwise, Recipients &MAY; take steps to recover a usable 257 protocol element from an invalid construct. However, HTTP does not define 258 specific error handling mechanisms, except in cases where it has direct 259 impact on security. This is because different uses of the protocol require 260 different error handling strategies; for example, a Web browser may wish to 261 transparently recover from a response where the Location header field 262 doesn't parse according to the ABNF, whereby in a systems control protocol 263 using HTTP, this type of error recovery could lead to dangerous consequences. 246 264 </t> 247 265 </section> … … 1389 1407 <section title="Since draft-ietf-httpbis-p7-auth-16" anchor="changes.since.16"> 1390 1408 <t> 1391 None yet. 1409 Closed issues: 1410 <list style="symbols"> 1411 <t> 1412 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/186"/>: 1413 "Document HTTP's error-handling philosophy" 1414 </t> 1415 </list> 1392 1416 </t> 1393 1417 </section>
Note: See TracChangeset
for help on using the changeset viewer.