Ignore:
Timestamp:
01/09/12 06:20:46 (10 years ago)
Author:
fielding@…
Message:

(editorial) section moves only -- registries belong in IANA considerations

File:
1 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p2-semantics.xml

    r1842 r1843  
    12401240</section>
    12411241
    1242 <section title="Status Code Registry" anchor="status.code.registry">
    1243 <t>
    1244   The HTTP Status Code Registry defines the name space for the status-code
    1245   token in the status-line of an HTTP response.
    1246 </t>
    1247 <t>
    1248   Values to be added to this name space require IETF Review
    1249   (see <xref target="RFC5226" x:fmt="," x:sec="4.1"/>).
    1250 </t>
    1251 <t>
    1252   The registry itself is maintained at <eref target="http://www.iana.org/assignments/http-status-codes"/>.
    1253 </t>
    1254 
    1255 <section title="Considerations for New Status Codes" anchor="considerations.for.new.status.codes">
    1256 <t>
    1257    When it is necessary to express new semantics for a HTTP response that
    1258    aren't specific to a single application or media type, and currently defined
    1259    status codes are inadequate, a new status code can be registered.
    1260 </t>
    1261 <t>
    1262    HTTP status codes are generic; that is, they are potentially applicable to
    1263    any resource, not just one particular media type, "type" of resource, or
    1264    application. As such, it is preferred that new HTTP status codes be
    1265    registered in a document that isn't specific to a single application, so
    1266    that this is clear.
    1267 </t>
    1268 <t>
    1269    Definitions of new HTTP status codes typically explain the request
    1270    conditions that produce a response containing the status code (e.g.,
    1271    combinations of request header fields and/or method(s)), along with any
    1272    interactions with response header fields (e.g., those that are required,
    1273    those that modify the semantics of the response).
    1274 </t>
    1275 <t>
    1276    New HTTP status codes are required to fall under one of the categories
    1277    defined in <xref target="status.codes"/>. To allow existing parsers to
    1278    properly handle them, new status codes cannot disallow a response body,
    1279    although they can mandate a zero-length response body. They can require the
    1280    presence of one or more particular HTTP response header field(s).
    1281 </t>
    1282 <t>
    1283    Likewise, their definitions can specify that caches are allowed to use
    1284    heuristics to determine their freshness (see &caching;; by default, it is
    1285    not allowed), and can define how to determine the resource which they
    1286    carry a representation for (see <xref
    1287    target="identifying.response.associated.with.representation"/>; by default,
    1288    it is anonymous).
    1289 </t>
    1290 </section>
    1291 
    1292 </section>
    1293 
    12941242<section title="Informational 1xx" anchor="status.1xx">
    12951243  <x:anchor-alias value="1xx"/>
    … …  
    24362384  </list>
    24372385</t>
    2438 
    2439 <section title="Content Coding Registry" anchor="content.coding.registry">
    2440 <t>
    2441    The HTTP Content Coding Registry defines the name space for the content
    2442    coding names.
    2443 </t>
    2444 <t>
    2445    Registrations &MUST; include the following fields:
    2446    <list style="symbols">
    2447      <t>Name</t>
    2448      <t>Description</t>
    2449      <t>Pointer to specification text</t>
    2450    </list>
    2451 </t>
    2452 <t>
    2453    Names of content codings &MUST-NOT; overlap with names of transfer codings
    2454    (&transfer-codings;), unless the encoding transformation is identical (as
    2455    is the case for the compression codings defined in
    2456    &compression-codings;).
    2457 </t>
    2458 <t>
    2459    Values to be added to this name space require IETF Review
    2460    (see <xref target="RFC5226" x:fmt="of" x:sec="4.1"/>), and &MUST;
    2461    conform to the purpose of content coding defined in this section.
    2462 </t>
    2463 <t>
    2464    The registry itself is maintained at
    2465    <eref target="http://www.iana.org/assignments/http-parameters"/>.
    2466 </t>
    2467 </section>
    2468 
    24692386</section>
    24702387
    … …  
    40303947  Request line of an HTTP request.
    40313948</t>
     3949<section title="Procedure" anchor="method.procedure">
    40323950<t>
    40333951  Registrations &MUST; include the following fields:
    … …  
    40463964  The registry itself is maintained at <eref target="http://www.iana.org/assignments/http-methods"/>.
    40473965</t>
     3966</section>
    40483967
    40493968<section title="Considerations for New Methods" anchor="considerations.for.new.methods">
    … …  
    41414060</section>
    41424061
    4143 <section title="Status Code Registry" anchor="status.code.registration">
     4062<section title="Status Code Registry" anchor="status.code.registry">
     4063<t>
     4064  The HTTP Status Code Registry defines the name space for the status-code
     4065  token in the status-line of an HTTP response (<xref target="status.codes"/>).
     4066</t>
     4067
     4068<section title="Procedure" anchor="status.code.procedure">
     4069<t>
     4070  Values to be added to this name space require IETF Review
     4071  (see <xref target="RFC5226" x:fmt="," x:sec="4.1"/>).
     4072</t>
     4073<t>
     4074  The registry itself is maintained at <eref target="http://www.iana.org/assignments/http-status-codes"/>.
     4075</t>
     4076</section>
     4077
     4078<section title="Considerations for New Status Codes" anchor="considerations.for.new.status.codes">
     4079<t>
     4080   When it is necessary to express new semantics for a HTTP response that
     4081   aren't specific to a single application or media type, and currently defined
     4082   status codes are inadequate, a new status code can be registered.
     4083</t>
     4084<t>
     4085   HTTP status codes are generic; that is, they are potentially applicable to
     4086   any resource, not just one particular media type, "type" of resource, or
     4087   application. As such, it is preferred that new HTTP status codes be
     4088   registered in a document that isn't specific to a single application, so
     4089   that this is clear.
     4090</t>
     4091<t>
     4092   Definitions of new HTTP status codes typically explain the request
     4093   conditions that produce a response containing the status code (e.g.,
     4094   combinations of request header fields and/or method(s)), along with any
     4095   interactions with response header fields (e.g., those that are required,
     4096   those that modify the semantics of the response).
     4097</t>
     4098<t>
     4099   New HTTP status codes are required to fall under one of the categories
     4100   defined in <xref target="status.codes"/>. To allow existing parsers to
     4101   properly handle them, new status codes cannot disallow a response body,
     4102   although they can mandate a zero-length response body. They can require the
     4103   presence of one or more particular HTTP response header field(s).
     4104</t>
     4105<t>
     4106   Likewise, their definitions can specify that caches are allowed to use
     4107   heuristics to determine their freshness (see &caching;; by default, it is
     4108   not allowed), and can define how to determine the resource which they
     4109   carry a representation for (see <xref
     4110   target="identifying.response.associated.with.representation"/>; by default,
     4111   it is anonymous).
     4112</t>
     4113</section>
     4114
     4115<section title="Registrations" anchor="status.code.registration">
    41444116<t>
    41454117   The registration procedure for HTTP Status Codes &mdash; previously defined
    … …  
    43414313<?ENDINC p2-semantics.iana-status-codes ?>
    43424314</section>
     4315</section>
     4316
    43434317<section title="Header Field Registration" anchor="header.field.registration">
    43444318<t>
    … …  
    44764450</section>
    44774451
    4478 <section title="Content Coding Registry" anchor="content.coding.registration">
     4452<section title="Content Coding Registry" anchor="content.coding.registry">
     4453<t>
     4454   The HTTP Content Coding Registry defines the name space for the content
     4455   coding names.
     4456</t>
     4457
     4458<section title="Procedure" anchor="content.coding.procedure">
     4459<t>
     4460   Registrations &MUST; include the following fields:
     4461   <list style="symbols">
     4462     <t>Name</t>
     4463     <t>Description</t>
     4464     <t>Pointer to specification text</t>
     4465   </list>
     4466</t>
     4467<t>
     4468   Names of content codings &MUST-NOT; overlap with names of transfer codings
     4469   (&transfer-codings;), unless the encoding transformation is identical (as
     4470   is the case for the compression codings defined in
     4471   &compression-codings;).
     4472</t>
     4473<t>
     4474   Values to be added to this name space require IETF Review
     4475   (see <xref target="RFC5226" x:fmt="of" x:sec="4.1"/>), and &MUST;
     4476   conform to the purpose of content coding defined in this section.
     4477</t>
     4478<t>
     4479   The registry itself is maintained at
     4480   <eref target="http://www.iana.org/assignments/http-parameters"/>.
     4481</t>
     4482</section>
     4483
     4484<section title="Registrations" anchor="content.coding.registration">
    44794485<t>
    44804486   The registration procedure for HTTP Content Codings is now defined
    … …  
    45144520</texttable>
    45154521</section>
    4516 
     4522</section>
    45174523</section>
    45184524
Note: See TracChangeset for help on using the changeset viewer.