standards/rfc3282.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                      H. Alvestrand
   8 Request for Comments: 3282                                 Cisco Systems
   9 Obsoletes: 1766                                                 May 2002
  10 Category: Standards Track
  11
  12
  13                        Content Language Headers
  14
  15 Status of this Memo
  16
  17    This document specifies an Internet standards track protocol for the
  18    Internet community, and requests discussion and suggestions for
  19    improvements.  Please refer to the current edition of the "Internet
  20    Official Protocol Standards" (STD 1) for the standardization state
  21    and status of this protocol.  Distribution of this memo is unlimited.
  22
  23 Copyright Notice
  24
  25    Copyright (C) The Internet Society (2002).  All Rights Reserved.
  26
  27 Abstract
  28
  29    This document defines a "Content-language:" header, for use in cases
  30    where one desires to indicate the language of something that has RFC
  31    822-like headers, like MIME body parts or Web documents, and an
  32    "Accept-Language:" header for use in cases where one wishes to
  33    indicate one's preferences with regard to language.
  34
  35 1. Introduction
  36
  37    There are a number of languages presently or previously used by human
  38    beings in this world.
  39
  40    A great number of these people would prefer to have information
  41    presented in a language which they understand.
  42
  43    In some contexts, it is possible to have information available in
  44    more than one language, or it might be possible to provide tools
  45    (such as dictionaries) to assist in the understanding of a language.
  46
  47    In other cases, it may be desirable to use a computer program to
  48    convert information from one format (such as plaintext) into another
  49    (such as computer-synthesized speech, or Braille, or high-quality
  50    print renderings).
  51
  52
  53
  54
  55
  56
  57
  58 Alvestrand                  Standards Track                     [Page 1]
  59 \f
  60 RFC 3282                Content Language Headers                May 2002
  61
  62
  63    A prerequisite for any such function is a means of labelling the
  64    information content with an identifier for the language that is used
  65    in this information content, such as is defined by [TAGS].  This
  66    document specifies a protocol element for use with protocols that use
  67    RFC 822-like headers for carrying language tags as defined in [TAGS].
  68
  69    The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  70    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  71    document are to be interpreted as described in [RFC 2119].
  72
  73 2. The Content-language header
  74
  75    The "Content-Language" header is intended for use in the case where
  76    one desires to indicate the language(s) of something that has RFC
  77    822-like headers, such as MIME body parts or Web documents.
  78
  79    The RFC 822 EBNF of the Content-Language header is:
  80
  81       Content-Language = "Content-Language" ":" 1#Language-tag
  82
  83    In the more strict RFC 2234 ABNF:
  84
  85       Content-Language = "Content-Language" ":" [CFWS] Language-List
  86       Language-List = Language-Tag [CFWS]
  87                          *("," [CFWS] Language-Tag [CFWS])
  88
  89    The Content-Language header may list several languages in a comma-
  90    separated list.
  91
  92    The CFWS construct is intended to function like the whitespace
  93    convention in RFC 822, which means also that one can place
  94    parenthesized comments anywhere in the language sequence, or use
  95    continuation lines.  A formal definition is given in RFC 2822
  96    [RFC2822].
  97
  98    In keeping with the tradition of RFC 2822, a more liberal "obsolete"
  99    grammar is also given:
 100
 101       obs-content-language = "Content-Language" *WSP ":"
 102                               [CFWS] Language-List
 103
 104    Like RFC 2822, this specification says that conforming
 105    implementations MUST accept the obs-content-language syntax, but MUST
 106    NOT generate it; all generated headers MUST conform to the Content-
 107    Language syntax.
 108
 109
 110
 111
 112
 113
 114 Alvestrand                  Standards Track                     [Page 2]
 115 \f
 116 RFC 3282                Content Language Headers                May 2002
 117
 118
 119 2.1 Examples of Content-language values
 120
 121    Voice recording from Liverpool downtown
 122
 123       Content-type: audio/basic
 124       Content-Language: en-scouse
 125
 126    Document in Mingo, an American Indian language which does not have an
 127    ISO 639 code:
 128
 129       Content-type: text/plain
 130       Content-Language: i-mingo
 131
 132    A English-French dictionary
 133
 134       Content-type: application/dictionary
 135       Content-Language: en, fr (This is a dictionary)
 136
 137    An official European Commission document (in a few of its official
 138    languages):
 139
 140       Content-type: multipart/alternative
 141       Content-Language: da, de, el, en, fr, it
 142
 143    An excerpt from Star Trek
 144
 145       Content-type: video/mpeg
 146       Content-Language: i-klingon
 147
 148 3. The Accept-Language header
 149
 150    The "Accept-Language" header is intended for use in cases where a
 151    user or a process desires to identify the preferred language(s) when
 152    RFC 822-like headers, such as MIME body parts or Web documents, are
 153    used.
 154
 155    The RFC 822 EBNF of the Accept-Language header is:
 156
 157       Accept-Language = "Accept-Language" ":"
 158                              1#( language-range [ ";" "q" "=" qvalue ] )
 159
 160    A slightly more restrictive RFC 2234 ABNF definition is:
 161
 162       Accept-Language = "Accept-Language:" [CFWS] language-q
 163                         *( "," [CFWS] language-q )
 164       language-q = language-range [";" [CFWS] "q=" qvalue ] [CFWS]
 165       qvalue         = ( "0" [ "." 0*3DIGIT ] )
 166                      / ( "1" [ "." 0*3("0") ] )
 167
 168
 169
 170 Alvestrand                  Standards Track                     [Page 3]
 171 \f
 172 RFC 3282                Content Language Headers                May 2002
 173
 174
 175
 176    A more liberal RFC 2234 ABNF definition is:
 177
 178       Obs-accept-language = "Accept-Language" *WSP ":" [CFWS]
 179            obs-language-q *( "," [CFWS] obs-language-q ) [CFWS]
 180       obs-language-q = language-range
 181             [ [CFWS] ";" [CFWS] "q" [CFWS] "=" qvalue ]
 182
 183    Like RFC 2822, this specification says that conforming
 184    implementations MUST accept the obs-accept-language syntax, but MUST
 185    NOT generate it; all generated messages MUST conform to the Accept-
 186    Language syntax.
 187
 188    The syntax and semantics of language-range is defined in [TAGS].  The
 189    Accept-Language header may list several language-ranges in a comma-
 190    separated list, and each may include a quality value Q.  If no Q
 191    values are given, the language-ranges are given in priority order,
 192    with the leftmost language-range being the most preferred language;
 193    this is an extension to the HTTP/1.1 rules, but matches current
 194    practice.
 195
 196    If Q values are given, refer to HTTP/1.1 [RFC 2616] for the details
 197    on how to evaluate it.
 198
 199 4. Security Considerations
 200
 201    The only security issue that has been raised with language tags since
 202    the publication of RFC 1766, which stated that "Security issues are
 203    believed to be irrelevant to this memo", is a concern with language
 204    ranges used in content negotiation - that they may be used to infer
 205    the nationality of the sender, and thus identify potential targets
 206    for surveillance.
 207
 208    This is a special case of the general problem that anything you send
 209    is visible to the receiving party; it is useful to be aware that such
 210    concerns can exist in some cases.
 211
 212    The exact magnitude of the threat, and any possible countermeasures,
 213    is left to each application protocol.
 214
 215 5. Character set considerations
 216
 217    This document adds no new considerations beyond what is mentioned in
 218    [TAGS].
 219
 220
 221
 222
 223
 224
 225
 226 Alvestrand                  Standards Track                     [Page 4]
 227 \f
 228 RFC 3282                Content Language Headers                May 2002
 229
 230
 231 6. Acknowledgements
 232
 233    This document has benefited from many rounds of review and comments
 234    in various fora of the IETF and the Internet working groups.
 235
 236    Any list of contributors is bound to be incomplete; please regard the
 237    following as only a selection from the group of people who have
 238    contributed to make this document what it is today.
 239
 240    In alphabetical order:
 241
 242    Tim Berners-Lee, Nathaniel Borenstein, Sean M. Burke, John Clews, Jim
 243    Conklin, John Cowan, Dave Crocker, Martin Duerst, Michael Everson,
 244    Ned Freed, Tim Goodwin, Dirk-Willem van Gulik, Marion Gunn, Paul
 245    Hoffman, Olle Jarnefors, John Klensin, Bruce Lilly, Keith Moore,
 246    Chris Newman, Masataka Ohta, Keld Jorn Simonsen, Rhys Weatherley,
 247    Misha Wolf, Francois Yergeau and many, many others.
 248
 249    Special thanks must go to Michael Everson, who has served as language
 250    tag reviewer for almost the entire period, since the publication of
 251    RFC 1766, and has provided a great deal of input to this revision.
 252    Bruce Lilly did a special job of reading and commenting on my ABNF
 253    definitions.
 254
 255 7. References
 256
 257    [TAGS]      Alvestrand, H., "Tags for the Identification of
 258                Languages", BCP 47, RFC 3066
 259
 260    [ISO 639]   ISO 639:1988 (E/F) - Code for the representation of names
 261                of languages - The International Organization for
 262                Standardization, 1st edition, 1988-04-01 Prepared by
 263                ISO/TC 37 - Terminology (principles and coordination).
 264                Note that a new version (ISO 639-1:2000) is in
 265                preparation at the time of this writing.
 266
 267    [ISO 639-2] ISO 639-2:1998 - Codes for the representation of names of
 268                languages -- Part 2: Alpha-3 code  - edition 1, 1998-11-
 269                01, 66 pages, prepared by ISO/TC 37/SC 2
 270
 271    [ISO 3166]  ISO 3166:1988 (E/F) - Codes for the representation of
 272                names of countries - The International Organization for
 273                Standardization, 3rd edition, 1988-08-15.
 274
 275    [ISO 15924] ISO/DIS 15924 - Codes for the representation of names of
 276                scripts (under development by ISO TC46/SC2)
 277
 278
 279
 280
 281
 282 Alvestrand                  Standards Track                     [Page 5]
 283 \f
 284 RFC 3282                Content Language Headers                May 2002
 285
 286
 287    [RFC 2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
 288                Extensions (MIME) Part One: Format of Internet Message
 289                Bodies", RFC 2045, November 1996.
 290
 291    [RFC 2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
 292                Extensions (MIME) Part Two: Media Types", RFC 2046,
 293                November 1996.
 294
 295    [RFC 2047]  Moore, K., "MIME (Multipurpose Internet Mail Extensions)
 296                Part Three: Message Header Extensions for Non-ASCII
 297                Text", RFC 2047, November 1996.
 298
 299    [RFC 2048]  Freed, N., Klensin, J. and J. Postel, "Multipurpose
 300                Internet Mail Extensions (MIME) Part Four: Registration
 301                Procedures", RFC 2048, November 1996.
 302
 303    [RFC 2049]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
 304                Extensions (MIME) Part Five: Conformance Criteria and
 305                Examples", RFC 2049, November 1996.
 306
 307    [RFC 2119]  Bradner, S., "Key words for use in RFCs to Indicate
 308                Requirement Levels", BCP 14, RFC 2119, March 1997.
 309
 310    [RFC 2234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
 311                Specifications: ABNF", RFC 2234, November 1997.
 312
 313    [RFC 2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
 314                Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
 315                Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
 316
 317    [RFC 2822]  Resnick, P., "Internet Message Format", RFC 2822, April
 318                2001.
 319
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338 Alvestrand                  Standards Track                     [Page 6]
 339 \f
 340 RFC 3282                Content Language Headers                May 2002
 341
 342
 343 Appendix A: Changes from RFC 1766
 344
 345    The definition of the language tags has been split, and is now RFC
 346    3066.  The differences parameter to multipart/alternative is no
 347    longer part of this standard, because no implementations of the
 348    function were ever found.  Consult RFC 1766 if you need the
 349    information.
 350
 351    The ABNF for content-language has been updated to use the RFC 2234
 352    ABNF.
 353
 354 Author's Address
 355
 356    Harald Tveit Alvestrand
 357    Cisco Systems
 358    Weidemanns vei 27
 359    7043 Trondheim
 360    NORWAY
 361
 362    EMail: Harald@Alvestrand.no
 363    Phone: +47 73 50 33 52
 364
 365
 366
 367
 368
 369
 370
 371
 372
 373
 374
 375
 376
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394 Alvestrand                  Standards Track                     [Page 7]
 395 \f
 396 RFC 3282                Content Language Headers                May 2002
 397
 398
 399 Full Copyright Statement
 400
 401    Copyright (C) The Internet Society (2002).  All Rights Reserved.
 402
 403    This document and translations of it may be copied and furnished to
 404    others, and derivative works that comment on or otherwise explain it
 405    or assist in its implementation may be prepared, copied, published
 406    and distributed, in whole or in part, without restriction of any
 407    kind, provided that the above copyright notice and this paragraph are
 408    included on all such copies and derivative works.  However, this
 409    document itself may not be modified in any way, such as by removing
 410    the copyright notice or references to the Internet Society or other
 411    Internet organizations, except as needed for the purpose of
 412    developing Internet standards in which case the procedures for
 413    copyrights defined in the Internet Standards process must be
 414    followed, or as required to translate it into languages other than
 415    English.
 416
 417    The limited permissions granted above are perpetual and will not be
 418    revoked by the Internet Society or its successors or assigns.
 419
 420    This document and the information contained herein is provided on an
 421    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 422    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 423    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 424    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 425    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 426
 427 Acknowledgement
 428
 429    Funding for the RFC Editor function is currently provided by the
 430    Internet Society.
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447
 448
 449
 450 Alvestrand                  Standards Track                     [Page 8]
 451 \f