Ignore:
Timestamp:
30/03/12 15:28:57 (11 years ago)
Author:
julian.reschke@…
Message:

Step 6 of p2/p3-merge (see #351)

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r1643 r1644  
    21642164
    21652165
    2166 <section title="Common Protocol Parameters" anchor="common.protocol.parameters">
     2166<section title="Protocol Parameters" anchor="protocol.parameters">
    21672167<section title="Date/Time Formats" anchor="http.date">
    21682168  <x:anchor-alias value="HTTP-date"/>
    … …  
    23402340   the same product &SHOULD; only differ in the product-version portion of
    23412341   the product value).
     2342</t>
     2343</section>
     2344
     2345<section title="Character Encodings (charset)" anchor="character.sets">
     2346<t>
     2347   HTTP uses charset names to indicate the character encoding of a
     2348   textual representation.
     2349</t>
     2350<t anchor="rule.charset">
     2351  <x:anchor-alias value="charset"/>
     2352   A character encoding is identified by a case-insensitive token. The
     2353   complete set of tokens is defined by the IANA Character Set registry
     2354   (<eref target="http://www.iana.org/assignments/character-sets"/>).
     2355</t>
     2356<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="charset"/>
     2357  <x:ref>charset</x:ref> = <x:ref>token</x:ref>
     2358</artwork></figure>
     2359<t>
     2360   Although HTTP allows an arbitrary token to be used as a charset
     2361   value, any token that has a predefined value within the IANA
     2362   Character Set registry &MUST; represent the character encoding defined
     2363   by that registry. Applications &SHOULD; limit their use of character
     2364   encodings to those defined within the IANA registry.
     2365</t>
     2366<t>
     2367   HTTP uses charset in two contexts: within an Accept-Charset request
     2368   header field (in which the charset value is an unquoted token) and as the
     2369   value of a parameter in a Content-Type header field (within a request or
     2370   response), in which case the parameter value of the charset parameter
     2371   can be quoted.
     2372</t>
     2373<t>
     2374   Implementors need to be aware of IETF character set requirements <xref target="RFC3629"/>
     2375   <xref target="RFC2277"/>.
     2376</t>
     2377</section>
     2378
     2379<section title="Content Codings" anchor="content.codings">
     2380  <x:anchor-alias value="content-coding"/>
     2381<t>
     2382   Content coding values indicate an encoding transformation that has
     2383   been or can be applied to a representation. Content codings are primarily
     2384   used to allow a representation to be compressed or otherwise usefully
     2385   transformed without losing the identity of its underlying media type
     2386   and without loss of information. Frequently, the representation is stored in
     2387   coded form, transmitted directly, and only decoded by the recipient.
     2388</t>
     2389<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="content-coding"/>
     2390  <x:ref>content-coding</x:ref>   = <x:ref>token</x:ref>
     2391</artwork></figure>
     2392<t>
     2393   All content-coding values are case-insensitive. HTTP/1.1 uses
     2394   content-coding values in the Accept-Encoding (<xref target="header.accept-encoding"/>) and
     2395   Content-Encoding (<xref target="header.content-encoding"/>) header fields. Although the value
     2396   describes the content-coding, what is more important is that it
     2397   indicates what decoding mechanism will be required to remove the
     2398   encoding.
     2399</t>
     2400<t>
     2401   compress<iref item="compress (Coding Format)"/><iref item="Coding Format" subitem="compress"/>
     2402  <list>
     2403    <t>
     2404      See &compress-coding;.
     2405    </t>
     2406  </list>
     2407</t>
     2408<t>
     2409   deflate<iref item="deflate (Coding Format)"/><iref item="Coding Format" subitem="deflate"/>
     2410  <list>
     2411    <t>
     2412      See &deflate-coding;.
     2413    </t>
     2414  </list>
     2415</t>
     2416<t>
     2417   gzip<iref item="gzip (Coding Format)"/><iref item="Coding Format" subitem="gzip"/>
     2418  <list>
     2419    <t>
     2420      See &gzip-coding;.
     2421    </t>
     2422  </list>
     2423</t>
     2424
     2425<section title="Content Coding Registry" anchor="content.coding.registry">
     2426<t>
     2427   The HTTP Content Coding Registry defines the name space for the content
     2428   coding names.
     2429</t>
     2430<t>
     2431   Registrations &MUST; include the following fields:
     2432   <list style="symbols">
     2433     <t>Name</t>
     2434     <t>Description</t>
     2435     <t>Pointer to specification text</t>
     2436   </list>
     2437</t>
     2438<t>
     2439   Names of content codings &MUST-NOT; overlap with names of transfer codings
     2440   (&transfer-codings;), unless the encoding transformation is identical (as
     2441   is the case for the compression codings defined in
     2442   &compression-codings;).
     2443</t>
     2444<t>
     2445   Values to be added to this name space require IETF Review
     2446   (see <xref target="RFC5226" x:fmt="of" x:sec="4.1"/>), and &MUST;
     2447   conform to the purpose of content coding defined in this section.
     2448</t>
     2449<t>
     2450   The registry itself is maintained at
     2451   <eref target="http://www.iana.org/assignments/http-parameters"/>.
     2452</t>
     2453</section>
     2454
     2455</section>
     2456
     2457<section title="Media Types" anchor="media.types">
     2458  <x:anchor-alias value="media-type"/>
     2459  <x:anchor-alias value="type"/>
     2460  <x:anchor-alias value="subtype"/>
     2461<t>
     2462   HTTP uses Internet Media Types <xref target="RFC2046"/> in the Content-Type (<xref target="header.content-type"/>)
     2463   and Accept (<xref target="header.accept"/>) header fields in order to provide
     2464   open and extensible data typing and type negotiation.
     2465</t>
     2466<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="media-type"/><iref primary="true" item="Grammar" subitem="type"/><iref primary="true" item="Grammar" subitem="subtype"/>
     2467  <x:ref>media-type</x:ref> = <x:ref>type</x:ref> "/" <x:ref>subtype</x:ref> *( <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> <x:ref>parameter</x:ref> )
     2468  <x:ref>type</x:ref>       = <x:ref>token</x:ref>
     2469  <x:ref>subtype</x:ref>    = <x:ref>token</x:ref>
     2470</artwork></figure>
     2471<t anchor="rule.parameter">
     2472  <x:anchor-alias value="attribute"/>
     2473  <x:anchor-alias value="parameter"/>
     2474  <x:anchor-alias value="value"/>
     2475   The type/subtype &MAY; be followed by parameters in the form of
     2476   attribute/value pairs.
     2477</t>
     2478<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="parameter"/><iref primary="true" item="Grammar" subitem="attribute"/><iref primary="true" item="Grammar" subitem="value"/>
     2479  <x:ref>parameter</x:ref>      = <x:ref>attribute</x:ref> "=" <x:ref>value</x:ref>
     2480  <x:ref>attribute</x:ref>      = <x:ref>token</x:ref>
     2481  <x:ref>value</x:ref>          = <x:ref>word</x:ref>
     2482</artwork></figure>
     2483<t>
     2484   The type, subtype, and parameter attribute names are case-insensitive.
     2485   Parameter values might or might not be case-sensitive, depending on the
     2486   semantics of the parameter name.  The presence or absence of a parameter might
     2487   be significant to the processing of a media-type, depending on its
     2488   definition within the media type registry.
     2489</t>
     2490<t>
     2491   A parameter value that matches the <x:ref>token</x:ref> production can be
     2492   transmitted as either a token or within a quoted-string. The quoted and
     2493   unquoted values are equivalent.
     2494</t>
     2495<t>
     2496   Note that some older HTTP applications do not recognize media type
     2497   parameters. When sending data to older HTTP applications,
     2498   implementations &SHOULD; only use media type parameters when they are
     2499   required by that type/subtype definition.
     2500</t>
     2501<t>
     2502   Media-type values are registered with the Internet Assigned Number
     2503   Authority (IANA). The media type registration process is
     2504   outlined in <xref target="RFC4288"/>. Use of non-registered media types is
     2505   discouraged.
     2506</t>
     2507
     2508<section title="Canonicalization and Text Defaults" anchor="canonicalization.and.text.defaults">
     2509<t>
     2510   Internet media types are registered with a canonical form. A
     2511   representation transferred via HTTP messages &MUST; be in the
     2512   appropriate canonical form prior to its transmission except for
     2513   "text" types, as defined in the next paragraph.
     2514</t>
     2515<t>
     2516   When in canonical form, media subtypes of the "text" type use CRLF as
     2517   the text line break. HTTP relaxes this requirement and allows the
     2518   transport of text media with plain CR or LF alone representing a line
     2519   break when it is done consistently for an entire representation. HTTP
     2520   applications &MUST; accept CRLF, bare CR, and bare LF as indicating
     2521   a line break in text media received via HTTP. In
     2522   addition, if the text is in a character encoding that does not
     2523   use octets 13 and 10 for CR and LF respectively, as is the case for
     2524   some multi-byte character encodings, HTTP allows the use of whatever octet
     2525   sequences are defined by that character encoding to represent the
     2526   equivalent of CR and LF for line breaks. This flexibility regarding
     2527   line breaks applies only to text media in the payload body; a bare CR
     2528   or LF &MUST-NOT; be substituted for CRLF within any of the HTTP control
     2529   structures (such as header fields and multipart boundaries).
     2530</t>
     2531<t>
     2532   If a representation is encoded with a content-coding, the underlying
     2533   data &MUST; be in a form defined above prior to being encoded.
     2534</t>
     2535</section>
     2536
     2537<section title="Multipart Types" anchor="multipart.types">
     2538<t>
     2539   MIME provides for a number of "multipart" types &mdash; encapsulations of
     2540   one or more representations within a single message body. All multipart
     2541   types share a common syntax, as defined in <xref target="RFC2046" x:sec="5.1.1" x:fmt="of"/>,
     2542   and &MUST; include a boundary parameter as part of the media type
     2543   value. The message body is itself a protocol element and &MUST;
     2544   therefore use only CRLF to represent line breaks between body-parts.
     2545</t>
     2546<t>
     2547   In general, HTTP treats a multipart message body no differently than
     2548   any other media type: strictly as payload.  HTTP does not use the
     2549   multipart boundary as an indicator of message body length.
     2550   <!-- jre: re-insert removed text pointing to caching? -->
     2551   In all other respects, an HTTP user agent &SHOULD; follow the same or similar
     2552   behavior as a MIME user agent would upon receipt of a multipart type.
     2553   The MIME header fields within each body-part of a multipart message body
     2554   do not have any significance to HTTP beyond that defined by
     2555   their MIME semantics.
     2556</t>
     2557<t>
     2558   If an application receives an unrecognized multipart subtype, the
     2559   application &MUST; treat it as being equivalent to "multipart/mixed".
     2560</t>
     2561<x:note>
     2562  <t>
     2563    <x:h>Note:</x:h> The "multipart/form-data" type has been specifically defined
     2564    for carrying form data suitable for processing via the POST
     2565    request method, as described in <xref target="RFC2388"/>.
     2566  </t>
     2567</x:note>
     2568</section>
     2569</section>
     2570
     2571<section title="Language Tags" anchor="language.tags">
     2572  <x:anchor-alias value="language-tag"/>
     2573<t>
     2574   A language tag, as defined in <xref target="RFC5646"/>, identifies a
     2575   natural language spoken, written, or otherwise conveyed by human beings for
     2576   communication of information to other human beings. Computer languages are
     2577   explicitly excluded. HTTP uses language tags within the Accept-Language and
     2578   Content-Language fields.
     2579</t>
     2580<t>
     2581   In summary, a language tag is composed of one or more parts: A primary
     2582   language subtag followed by a possibly empty series of subtags:
     2583</t>
     2584<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="language-tag"/>
     2585  <x:ref>language-tag</x:ref> = &lt;Language-Tag, defined in <xref target="RFC5646" x:sec="2.1"/>&gt;
     2586</artwork></figure>
     2587<t>
     2588   White space is not allowed within the tag and all tags are case-insensitive.
     2589   The name space of language subtags is administered by the IANA (see
     2590   <eref target="http://www.iana.org/assignments/language-subtag-registry"/>).
     2591</t>
     2592<figure>
     2593  <preamble>Example tags include:</preamble>
     2594<artwork type="example">
     2595  en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN
     2596</artwork>
     2597</figure>
     2598<t>
     2599   See <xref target="RFC5646"/> for further information.
    23422600</t>
    23432601</section>
    … …  
    49315189
    49325190<section title="THE TEXT FORMERLY KNOWN AS PART3">
    4933 <section title="Protocol Parameters" anchor="protocol.parameters">
    4934 
    4935 <section title="Character Encodings (charset)" anchor="character.sets">
    4936 <t>
    4937    HTTP uses charset names to indicate the character encoding of a
    4938    textual representation.
    4939 </t>
    4940 <t anchor="rule.charset">
    4941   <x:anchor-alias value="charset"/>
    4942    A character encoding is identified by a case-insensitive token. The
    4943    complete set of tokens is defined by the IANA Character Set registry
    4944    (<eref target="http://www.iana.org/assignments/character-sets"/>).
    4945 </t>
    4946 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="charset"/>
    4947   <x:ref>charset</x:ref> = <x:ref>token</x:ref>
    4948 </artwork></figure>
    4949 <t>
    4950    Although HTTP allows an arbitrary token to be used as a charset
    4951    value, any token that has a predefined value within the IANA
    4952    Character Set registry &MUST; represent the character encoding defined
    4953    by that registry. Applications &SHOULD; limit their use of character
    4954    encodings to those defined within the IANA registry.
    4955 </t>
    4956 <t>
    4957    HTTP uses charset in two contexts: within an Accept-Charset request
    4958    header field (in which the charset value is an unquoted token) and as the
    4959    value of a parameter in a Content-Type header field (within a request or
    4960    response), in which case the parameter value of the charset parameter
    4961    can be quoted.
    4962 </t>
    4963 <t>
    4964    Implementors need to be aware of IETF character set requirements <xref target="RFC3629"/>
    4965    <xref target="RFC2277"/>.
    4966 </t>
    4967 </section>
    4968 
    4969 <section title="Content Codings" anchor="content.codings">
    4970   <x:anchor-alias value="content-coding"/>
    4971 <t>
    4972    Content coding values indicate an encoding transformation that has
    4973    been or can be applied to a representation. Content codings are primarily
    4974    used to allow a representation to be compressed or otherwise usefully
    4975    transformed without losing the identity of its underlying media type
    4976    and without loss of information. Frequently, the representation is stored in
    4977    coded form, transmitted directly, and only decoded by the recipient.
    4978 </t>
    4979 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="content-coding"/>
    4980   <x:ref>content-coding</x:ref>   = <x:ref>token</x:ref>
    4981 </artwork></figure>
    4982 <t>
    4983    All content-coding values are case-insensitive. HTTP/1.1 uses
    4984    content-coding values in the Accept-Encoding (<xref target="header.accept-encoding"/>) and
    4985    Content-Encoding (<xref target="header.content-encoding"/>) header fields. Although the value
    4986    describes the content-coding, what is more important is that it
    4987    indicates what decoding mechanism will be required to remove the
    4988    encoding.
    4989 </t>
    4990 <t>
    4991    compress<iref item="compress (Coding Format)"/><iref item="Coding Format" subitem="compress"/>
    4992   <list>
    4993     <t>
    4994       See &compress-coding;.
    4995     </t>
    4996   </list>
    4997 </t>
    4998 <t>
    4999    deflate<iref item="deflate (Coding Format)"/><iref item="Coding Format" subitem="deflate"/>
    5000   <list>
    5001     <t>
    5002       See &deflate-coding;.
    5003     </t>
    5004   </list>
    5005 </t>
    5006 <t>
    5007    gzip<iref item="gzip (Coding Format)"/><iref item="Coding Format" subitem="gzip"/>
    5008   <list>
    5009     <t>
    5010       See &gzip-coding;.
    5011     </t>
    5012   </list>
    5013 </t>
    5014 
    5015 <section title="Content Coding Registry" anchor="content.coding.registry">
    5016 <t>
    5017    The HTTP Content Coding Registry defines the name space for the content
    5018    coding names.
    5019 </t>
    5020 <t>
    5021    Registrations &MUST; include the following fields:
    5022    <list style="symbols">
    5023      <t>Name</t>
    5024      <t>Description</t>
    5025      <t>Pointer to specification text</t>
    5026    </list>
    5027 </t>
    5028 <t>
    5029    Names of content codings &MUST-NOT; overlap with names of transfer codings
    5030    (&transfer-codings;), unless the encoding transformation is identical (as
    5031    is the case for the compression codings defined in
    5032    &compression-codings;).
    5033 </t>
    5034 <t>
    5035    Values to be added to this name space require IETF Review
    5036    (see <xref target="RFC5226" x:fmt="of" x:sec="4.1"/>), and &MUST;
    5037    conform to the purpose of content coding defined in this section.
    5038 </t>
    5039 <t>
    5040    The registry itself is maintained at
    5041    <eref target="http://www.iana.org/assignments/http-parameters"/>.
    5042 </t>
    5043 </section>
    5044 
    5045 </section>
    5046 
    5047 <section title="Media Types" anchor="media.types">
    5048   <x:anchor-alias value="media-type"/>
    5049   <x:anchor-alias value="type"/>
    5050   <x:anchor-alias value="subtype"/>
    5051 <t>
    5052    HTTP uses Internet Media Types <xref target="RFC2046"/> in the Content-Type (<xref target="header.content-type"/>)
    5053    and Accept (<xref target="header.accept"/>) header fields in order to provide
    5054    open and extensible data typing and type negotiation.
    5055 </t>
    5056 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="media-type"/><iref primary="true" item="Grammar" subitem="type"/><iref primary="true" item="Grammar" subitem="subtype"/>
    5057   <x:ref>media-type</x:ref> = <x:ref>type</x:ref> "/" <x:ref>subtype</x:ref> *( <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> <x:ref>parameter</x:ref> )
    5058   <x:ref>type</x:ref>       = <x:ref>token</x:ref>
    5059   <x:ref>subtype</x:ref>    = <x:ref>token</x:ref>
    5060 </artwork></figure>
    5061 <t anchor="rule.parameter">
    5062   <x:anchor-alias value="attribute"/>
    5063   <x:anchor-alias value="parameter"/>
    5064   <x:anchor-alias value="value"/>
    5065    The type/subtype &MAY; be followed by parameters in the form of
    5066    attribute/value pairs.
    5067 </t>
    5068 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="parameter"/><iref primary="true" item="Grammar" subitem="attribute"/><iref primary="true" item="Grammar" subitem="value"/>
    5069   <x:ref>parameter</x:ref>      = <x:ref>attribute</x:ref> "=" <x:ref>value</x:ref>
    5070   <x:ref>attribute</x:ref>      = <x:ref>token</x:ref>
    5071   <x:ref>value</x:ref>          = <x:ref>word</x:ref>
    5072 </artwork></figure>
    5073 <t>
    5074    The type, subtype, and parameter attribute names are case-insensitive.
    5075    Parameter values might or might not be case-sensitive, depending on the
    5076    semantics of the parameter name.  The presence or absence of a parameter might
    5077    be significant to the processing of a media-type, depending on its
    5078    definition within the media type registry.
    5079 </t>
    5080 <t>
    5081    A parameter value that matches the <x:ref>token</x:ref> production can be
    5082    transmitted as either a token or within a quoted-string. The quoted and
    5083    unquoted values are equivalent.
    5084 </t>
    5085 <t>
    5086    Note that some older HTTP applications do not recognize media type
    5087    parameters. When sending data to older HTTP applications,
    5088    implementations &SHOULD; only use media type parameters when they are
    5089    required by that type/subtype definition.
    5090 </t>
    5091 <t>
    5092    Media-type values are registered with the Internet Assigned Number
    5093    Authority (IANA). The media type registration process is
    5094    outlined in <xref target="RFC4288"/>. Use of non-registered media types is
    5095    discouraged.
    5096 </t>
    5097 
    5098 <section title="Canonicalization and Text Defaults" anchor="canonicalization.and.text.defaults">
    5099 <t>
    5100    Internet media types are registered with a canonical form. A
    5101    representation transferred via HTTP messages &MUST; be in the
    5102    appropriate canonical form prior to its transmission except for
    5103    "text" types, as defined in the next paragraph.
    5104 </t>
    5105 <t>
    5106    When in canonical form, media subtypes of the "text" type use CRLF as
    5107    the text line break. HTTP relaxes this requirement and allows the
    5108    transport of text media with plain CR or LF alone representing a line
    5109    break when it is done consistently for an entire representation. HTTP
    5110    applications &MUST; accept CRLF, bare CR, and bare LF as indicating
    5111    a line break in text media received via HTTP. In
    5112    addition, if the text is in a character encoding that does not
    5113    use octets 13 and 10 for CR and LF respectively, as is the case for
    5114    some multi-byte character encodings, HTTP allows the use of whatever octet
    5115    sequences are defined by that character encoding to represent the
    5116    equivalent of CR and LF for line breaks. This flexibility regarding
    5117    line breaks applies only to text media in the payload body; a bare CR
    5118    or LF &MUST-NOT; be substituted for CRLF within any of the HTTP control
    5119    structures (such as header fields and multipart boundaries).
    5120 </t>
    5121 <t>
    5122    If a representation is encoded with a content-coding, the underlying
    5123    data &MUST; be in a form defined above prior to being encoded.
    5124 </t>
    5125 </section>
    5126 
    5127 <section title="Multipart Types" anchor="multipart.types">
    5128 <t>
    5129    MIME provides for a number of "multipart" types &mdash; encapsulations of
    5130    one or more representations within a single message body. All multipart
    5131    types share a common syntax, as defined in <xref target="RFC2046" x:sec="5.1.1" x:fmt="of"/>,
    5132    and &MUST; include a boundary parameter as part of the media type
    5133    value. The message body is itself a protocol element and &MUST;
    5134    therefore use only CRLF to represent line breaks between body-parts.
    5135 </t>
    5136 <t>
    5137    In general, HTTP treats a multipart message body no differently than
    5138    any other media type: strictly as payload.  HTTP does not use the
    5139    multipart boundary as an indicator of message body length.
    5140    <!-- jre: re-insert removed text pointing to caching? -->
    5141    In all other respects, an HTTP user agent &SHOULD; follow the same or similar
    5142    behavior as a MIME user agent would upon receipt of a multipart type.
    5143    The MIME header fields within each body-part of a multipart message body
    5144    do not have any significance to HTTP beyond that defined by
    5145    their MIME semantics.
    5146 </t>
    5147 <t>
    5148    If an application receives an unrecognized multipart subtype, the
    5149    application &MUST; treat it as being equivalent to "multipart/mixed".
    5150 </t>
    5151 <x:note>
    5152   <t>
    5153     <x:h>Note:</x:h> The "multipart/form-data" type has been specifically defined
    5154     for carrying form data suitable for processing via the POST
    5155     request method, as described in <xref target="RFC2388"/>.
    5156   </t>
    5157 </x:note>
    5158 </section>
    5159 </section>
    5160 
    5161 <section title="Language Tags" anchor="language.tags">
    5162   <x:anchor-alias value="language-tag"/>
    5163 <t>
    5164    A language tag, as defined in <xref target="RFC5646"/>, identifies a
    5165    natural language spoken, written, or otherwise conveyed by human beings for
    5166    communication of information to other human beings. Computer languages are
    5167    explicitly excluded. HTTP uses language tags within the Accept-Language and
    5168    Content-Language fields.
    5169 </t>
    5170 <t>
    5171    In summary, a language tag is composed of one or more parts: A primary
    5172    language subtag followed by a possibly empty series of subtags:
    5173 </t>
    5174 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="language-tag"/>
    5175   <x:ref>language-tag</x:ref> = &lt;Language-Tag, defined in <xref target="RFC5646" x:sec="2.1"/>&gt;
    5176 </artwork></figure>
    5177 <t>
    5178    White space is not allowed within the tag and all tags are case-insensitive.
    5179    The name space of language subtags is administered by the IANA (see
    5180    <eref target="http://www.iana.org/assignments/language-subtag-registry"/>).
    5181 </t>
    5182 <figure>
    5183   <preamble>Example tags include:</preamble>
    5184 <artwork type="example">
    5185   en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN
    5186 </artwork>
    5187 </figure>
    5188 <t>
    5189    See <xref target="RFC5646"/> for further information.
    5190 </t>
    5191 </section>
    5192 </section>
    51935191
    51945192<section title="Payload" anchor="payload">
Note: See TracChangeset for help on using the changeset viewer.