home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc2130 < prev    next >
Text File  |  1997-04-21  |  63KB  |  1,740 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        C. Weider
  8. Request for Comments: 2130                                   Microsoft
  9. Category: Informational                                     C. Preston
  10.                                                        Preston & Lynch
  11.                                                            K. Simonsen
  12.                                                                  DKUUG
  13.                                                          H. Alvestrand
  14.                                                                UNINETT
  15.                                                            R. Atkinson
  16.                                                          Cisco Systems
  17.                                                             M. Crispin
  18.                                               University of Washington
  19.                                                            P. Svanberg
  20.                                                                    KTH
  21.                                                             April 1997
  22.  
  23.               The Report of the IAB Character Set Workshop
  24.                     held 29 February - 1 March, 1996
  25.  
  26. Status of this Memo
  27.  
  28.    This memo provides information for the Internet community.  This memo
  29.    does not specify an Internet standard of any kind.  Distribution of
  30.    this memo is unlimited.
  31.  
  32. Acknowledgments
  33.  
  34.    The authors would like to sincerely thank Information Sciences
  35.    Institute (ISI), and in particular Joyce K. Reynolds for graciously
  36.    hosting this event; Joe Kemp and Jeanine Yamazaki of ISI made sure
  37.    the facilities met our needs.  We also wish to thank the Internet
  38.    Society, which underwrote travel for participants who might not
  39.    otherwise have been able to attend.  Of course, we also wish to thank
  40.    the many experts who participated in the workshop and on the mailing
  41.    list; a complete list of these people can be found in Appendix D.
  42.    Bunyip Information Systems was kind enough to provide mailing list
  43.    facilities for this work.
  44.  
  45. Table of Contents
  46.  
  47.    Abstract
  48.    0:    Executive summary..........................................   2
  49.    1:    Introduction...............................................   3
  50.    2:    Character sets on the Internet -- the problem..............   3
  51.    2.1:  Character set handling in existing protocols...............   4
  52.    3:    Architectural model........................................   6
  53.    3.1:  Segments defined...........................................   7
  54.    3.2:  On the wire................................................   8
  55.  
  56.  
  57.  
  58. Weider, et. al.              Informational                      [Page 1]
  59.  
  60. RFC 2130             Character Set Workshop Report            April 1997
  61.  
  62.  
  63.    3.3:  Determining which values of CCS, CES, and TES are used.....   9
  64.    3.4:  Recommended Defaults.......................................  10
  65.    3.5:  Guidelines for conversions between coded character sets....  13
  66.    4:    Presentation issues........................................  14
  67.    5:    Open issues................................................  14
  68.    5.1:  Language tags..............................................  15
  69.    5.2:  Public identifiers.........................................  16
  70.    5.3:  Bi-directionality..........................................  16
  71.    6:    Security Considerations....................................  16
  72.    7:    Conclusions................................................  16
  73.    8:    Recommendations............................................  17
  74.    8.1:  To the IAB.................................................  17
  75.    8.2:  For new Internet protocols.................................  18
  76.    8.3:  For registration of new character sets.....................  18
  77.    Appendix A: List of protocols affected by character set issues...  20
  78.    Appendix B: Acronyms.............................................  23
  79.    Appendix C: Glossary.............................................  24
  80.    Appendix D: References...........................................  25
  81.    Appendix E: Recommended reading..................................  27
  82.    Appendix F: Workshop attendee list...............................  29
  83.    Appendix G: Authors' Addresses...................................  30
  84.  
  85. Abstract
  86.  
  87.    This report details the conclusions of an IAB-sponsored invitational
  88.    workshop held 29 February  - 1 March, 1996, to discuss the use of
  89.    character sets on the Internet.  It motivates the need to have
  90.    character set handling in Internet protocols which transmit text,
  91.    provides a conceptual framework for specifying character sets,
  92.    recommends the use of MIME tagging for transmitted text, recommends a
  93.    default character set *without* stating that there is no need for
  94.    other character sets, and makes a series of recommendations to the
  95.    IAB, IANA, and the IESG for furthering the integration of the
  96.    character set framework into text transmission protocols.
  97.  
  98. 0: Executive summary
  99.  
  100.    The term 'Character Set' means many things to many people. Even the
  101.    MIME registry of character sets registers items that have great
  102.    differences in semantics and applicability. This workshop provides
  103.    guidance to the IAB and IETF about the use of character sets on the
  104.    Internet and provides a common framework for interoperability between
  105.    the many characters in use there.
  106.  
  107.    The framework consists of four components: an architecture model,
  108.    which specifies components necessary for on-the-wire transmission of
  109.    text; recommendations for tagging transmitted (and stored) text;
  110.    recommended defaults for each level of the model; and a set of
  111.  
  112.  
  113.  
  114. Weider, et. al.              Informational                      [Page 2]
  115.  
  116. RFC 2130             Character Set Workshop Report            April 1997
  117.  
  118.  
  119.    recommendations to the IAB, IANA, and the IESG for furthering the
  120.    integration of  this framework into text transmission protocols.
  121.  
  122.    The architectural model specifies 7 layers, of which only three are
  123.    required for on-the-wire transmission. The Coded Character Set is a
  124.    mapping from a set of abstract characters to a set of integers. The
  125.    Character Encoding Scheme is a mapping from a Coded Character Set (or
  126.    several) to a set of octets. The Transfer Encoding Syntax is a
  127.    transformation applied to data which has been encoded using a
  128.    Character Encoding Scheme to allow it to be transmitted. These layers
  129.    should be specified in a transmitted text stream by using the MIME
  130.    encoding mechanisms.
  131.  
  132.    This report recommends the use of ISO 10646 as the default Coded
  133.    Character Set, and UTF-8 as the default Character Encoding Scheme in
  134.    the creation of new protocols or new version of old protocols which
  135.    transmit text. These defaults do not deprecate the use of other
  136.    character sets when and where they are needed; they are simply
  137.    intended to provide guidance and a specification for
  138.    interoperability.
  139.  
  140. 1:  Introduction
  141.  
  142.    This is the report of an IAB-sponsored invitational workshop on the
  143.    use of Character Sets on the Internet, held 29 February - 1 March
  144.    1996 at Information Sciences Institute (ISI) in Marina del Rey,
  145.    California.  In addition, this report covers the discussion on the
  146.    mailing list up to and slightly beyond the workshop itself.  The
  147.    goals of this workshop were to provide guidance to the IAB and the
  148.    IETF about the use of character sets on the Internet, and if possible
  149.    a common framework for interoperability between the many character
  150.    sets in use there.  Both goals were achieved.
  151.  
  152. 2:  Character sets on the Internet - the problem
  153.  
  154.    The term 'character set' is typically applied to the contents of a
  155.    wide variety of text transmission and display protocols used on the
  156.    Internet.  Because the term is used to mean different things,
  157.    confusion has arisen.  For example, the MIME registry of character
  158.    sets [MIME] contains items that may differ greatly in their
  159.    applicability and semantics in various Internet protocols.
  160.  
  161.    In addition, there is a vast profusion of different text encoding
  162.    schemes in use on the Internet.  This per se is not a problem; each
  163.    scheme has evolved to meet real needs.  However, information
  164.    applications such as mail, directories, and the World Wide Web have
  165.    each developed different techniques for dealing with the growing
  166.    number of schemes.  A robust information architecture for the
  167.  
  168.  
  169.  
  170. Weider, et. al.              Informational                      [Page 3]
  171.  
  172. RFC 2130             Character Set Workshop Report            April 1997
  173.  
  174.  
  175.    Internet requires as much interoperability between these techniques
  176.    as possible.
  177.  
  178. 2.1:  Related topics deemed out of scope for this workshop
  179.  
  180.    Successful display of plain text transmitted over the Internet
  181.    requires a lot of information about the text itself, such as the
  182.    underlying character set, language, and so forth.  An additional set
  183.    of formatting information is needed if the receiving application
  184.    wishes to use local (cultural) conventions when it presents the data
  185.    to the user.  This formatting includes information, that provides the
  186.    data necessary to format certain  types of textual data (dates,
  187.    times, numbers and monetary notation) into a form which is familiar
  188.    to the user.  The POSIX [POSIX] notation of locale encompasses
  189.    language, coded character set and cultural conventions.
  190.  
  191.    To avoid unfruitful discussion, and to make the best use of the time
  192.    available for the workshop, we declared the following  issues out of
  193.    scope for the purposes of this workshop:
  194.  
  195.    -  glyphs
  196.    -  sorting
  197.    -  culture (e.g. do we present the American or British spelling?)
  198.    -  user interface issues
  199.    -  internal representation of textual data
  200.    -  included characters (why aren't certain characters available in
  201.           any character set?)
  202.    -  locale (in the POSIX sense)
  203.    -  font registration
  204.    -  semantics
  205.    -  user input/output issues
  206.    -  Han unification issues
  207.  
  208.    There are some related issues which were included for discussion,
  209.    most importantly the 'locale' components necessary for transport and
  210.    identification of multilingual texts.
  211.  
  212. 2.2:  Character Set handling in existing protocols
  213.  
  214.    One of the group's overriding concerns was that the framework
  215.    developed for character set handling not break existing protocols.
  216.    With that in mind, the way character sets are being used in existing
  217.    protocols was examined.  See Appendix A for a list of those protocols
  218.    and some recommendations for change.
  219.  
  220. 2.2.1:  General comments
  221.  
  222.    The problem areas here fall into three main categories: protocols,
  223.  
  224.  
  225.  
  226. Weider, et. al.              Informational                      [Page 4]
  227.  
  228. RFC 2130             Character Set Workshop Report            April 1997
  229.  
  230.  
  231.    identifiers, and data.
  232.  
  233. 2.2.1.1:  Protocols
  234.  
  235.    The protocol machinery SHOULD NOT be changed; allowing, for instance,
  236.    SMTP [SMTP] to use both MAIL FROM and POST FRA is dangerous to the
  237.    protocols' stability.  However, many protocols carry error messages
  238.    and other information that is intended for human consumption; it
  239.    MIGHT be an advantage to allow these to be localized into a specific
  240.    language and character set, rather than staying in English and US-
  241.    ASCII [ASCII].  If this is done, new extensions should follow the
  242.    framework outlined below.
  243.  
  244. 2.2.1.2:  Identifiers.
  245.  
  246.    There is a strong statement of direction from the IAB, RFC 1958 [RFC
  247.    1958],  which states:
  248.  
  249.         4.3 Public (i.e. widely visible) names should be in case
  250.             independent ASCII.  Specifically, this refers to DNS names,
  251.             and to protocol elements that are transmitted in text format.
  252.             ...
  253.         5.4 Designs should be fully international, with support for
  254.             localization (adaptation to local character sets). In
  255.             particular, there should be a uniform approach to character
  256.             set tagging for information content.
  257.  
  258.    In protocols that up to now have used US-ASCII only, UTF-8 [UTF-8]
  259.    forms a simple upgrade path; however, its use should be negotiated
  260.    either by negotiating a protocol version or by negotiating charset
  261.    usage, and a fallback to a US-ASCII compatible representation such as
  262.    UTF-7 [UTF-7] MUST be available.
  263.  
  264.    The need for passing application data such as language on individual
  265.    identifiers varies between applications; protocols SHOULD attempt to
  266.    evaluate this need when designing mechanisms.  Applying the ASCII
  267.    requirement for identifiers that are only used in a local context
  268.    (such as private mailbox folder names) is both unrealistic and
  269.    unreasonable; in such cases, methods for consistency in the handling
  270.    of character set should be considered.
  271.  
  272. 2.2.1.3:  Data
  273.  
  274.    Data that require character set handling includes text, databases,
  275.    and HTML [HTML] pages, for example.  In these the support for
  276.    multiple character sets and proper application information is
  277.    absolutely vital, and MUST be supported.
  278.  
  279.  
  280.  
  281.  
  282. Weider, et. al.              Informational                      [Page 5]
  283.  
  284. RFC 2130             Character Set Workshop Report            April 1997
  285.  
  286.  
  287. 2.3:  Architectural requirements
  288.  
  289.    To address the issues enumerated for this work, first an
  290.    architectural model was created which establishes the components that
  291.    are required to fully specify the transmission of textual data. Many
  292.    of these components are already familiar to the users of encoding
  293.    protocols such as MIME.  Not all of these are discussed in detail in
  294.    this report; we restrict ourselves primarily to those components
  295.    which are required to specify the 'on-the-wire' phase of text
  296.    transmission.
  297.  
  298.    Mandating a single, all-encompassing character set would not fit well
  299.    with the IETF philosophy of planning for architectural diversity.
  300.    So, the best that can be done is to provide a common *framework* for
  301.    identifying and using the multitude of character sets available on
  302.    the Internet.  It would be an advantage if the total number of Coded
  303.    Character Sets could be kept to a minimum.  This framework should
  304.    meet the following requirements:
  305.  
  306.    -  it should not break existing protocols (because then the likelihood
  307.         of deployment is very small),
  308.    -  it should allow the use of character sets currently used on the
  309.         Internet, and
  310.    -  it should be relatively easy to build into new protocols.
  311.  
  312. 3:  Architectural model
  313.  
  314.    The basic architectural model which guided our discussions is shown
  315.    in below.  A distinction was made between those segments which were
  316.    necessary to successfully transmit character set data on-the-wire and
  317.    those needed to present that data to a user in a comprehensible
  318.    manner.  The discussions were primarily restricted to those segments
  319.    of the model which specify the 'on-the-wire' transmission of textual
  320.    data.
  321.  
  322.    User interface issues: these are briefly discussed in Section 3.1.1.
  323.         Layout
  324.         Culture
  325.         Locale
  326.         Language
  327.    On-the-wire: see section 3.2 for detailed discussion.
  328.         Transfer Syntax
  329.         Character Encoding Scheme
  330.         Coded Character Set
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Weider, et. al.              Informational                      [Page 6]
  339.  
  340. RFC 2130             Character Set Workshop Report            April 1997
  341.  
  342.  
  343. 3.1:  Segments defined
  344.  
  345. 3.1:1:  User interface
  346.  
  347. 3.1.1.1:  Layout
  348.  
  349.    Layout includes the elements needed for displaying text to the user,
  350.    such as font selection, word-wrapping, etc.  It is similar to the
  351.    'presentation' layer in the 7-layer ISO telecommunications model
  352.    [ISO-7498].
  353.  
  354. 3.1.1.2:  Culture
  355.  
  356.    Culture includes information about cultural preferences, which affect
  357.    spelling, word choice, and so forth.
  358.  
  359. 3.1.1.3:  Locale
  360.  
  361.    The locale component includes the information necessary to make
  362.    choices about text manipulation which will present the text to the
  363.    user in an expected format.  This information may include the display
  364.    of date, time and monetary symbol preferences.  Notice that locale
  365.    modifications are typically applied to a text stream before it is
  366.    presented to the user, although they also are used to specify input
  367.    formats.
  368.  
  369. 3.1.1.4:  Language
  370.  
  371.    This component specifies the language of the transmitted text.  At
  372.    times and in specific cases, language information may be required to
  373.    achieve a particular level of quality for the purpose of displaying a
  374.    text stream.  For example, UTF-8 encoded Han may require transmission
  375.    of a language tag to select the specific glyphs to be displayed at a
  376.    particular level of quality.
  377.  
  378.    Note that information other than language may be used to achieve the
  379.    required level of quality in a display process.  In particular, a
  380.    font tag is sufficient to produce identical results.  However, the
  381.    association of a language with a specific block of text has
  382.    usefulness far beyond its use in display.  In particular, as the
  383.    amount of information available in multiple languages on the World
  384.    Wide Web grows, it becomes critical to specify which language is in
  385.    use in particular documents, to assist automatic indexing and
  386.    retrieval of relevant documents.
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Weider, et. al.              Informational                      [Page 7]
  395.  
  396. RFC 2130             Character Set Workshop Report            April 1997
  397.  
  398.  
  399.    The term 'language tag' should be reserved for the short identifier
  400.    of RFC 1766 [RFC-1766] that only serves to identify the language.
  401.    While there may be other text attributes intimately associated with
  402.    the language of the document, such as desired font or text direction,
  403.    these should be specified with other identifiers rather than
  404.    overloading the language tag.
  405.  
  406. 3.2:  On the wire
  407.  
  408.    There are three segments of the model which are required for
  409.    completely specifying the content of a transmitted text stream (with
  410.    the occasional exception of the Language component, mentioned above).
  411.    These components are:
  412.  
  413.    1)  Coded Character Set,
  414.    2)  Character Encoding Scheme, and
  415.    3)  Transfer Encoding Syntax.
  416.  
  417.    Each of these abstract components must be explicitly specified by the
  418.    transmitter when the data is sent.  There may be instances of an
  419.    implicit specification due to the protocol/standard being used (i.e.
  420.    ANSI/NISO Z39.50).  Also, in MIME, the Coded Character Set and
  421.    Character Encoding Scheme are specified by the Charset parameter to
  422.    the Content-Type header field, and Transfer Encoding Syntax is
  423.    specified by the Content-Transfer-Encoding header field.
  424.  
  425. 3.2.1:  Coded Character Set
  426.  
  427.    A Coded Character Set (CCS) is a mapping from a set of abstract
  428.    characters to a set of integers.  Examples of coded character sets
  429.    are ISO 10646 [ISO-10646], US-ASCII [ASCII], and ISO-8859 series
  430.    [ISO-8859].
  431.  
  432. 3.2.2:  Character Encoding Scheme
  433.  
  434.    A Character Encoding Scheme (CES) is a mapping from a Coded Character
  435.    Set or several coded character sets to a set of octets. Examples of
  436.    Character Encoding Schemes are ISO 2022 [ISO-2022] and UTF-8 [UTF-8].
  437.    A given CES is typically associated with a single CCS; for example,
  438.    UTF-8 applies only to ISO 10646.
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Weider, et. al.              Informational                      [Page 8]
  451.  
  452. RFC 2130             Character Set Workshop Report            April 1997
  453.  
  454.  
  455. 3.2.3:  Transfer Encoding Syntax
  456.  
  457.    It is frequently necessary to transform encoded text into a format
  458.    which is transmissible by specific protocols.  The Transfer Encoding
  459.    Syntax (TES) is a transformation applied to character data encoded
  460.    using a CCS and possibly a CES to allow it to be transmitted.
  461.    Examples of Transfer Encoding Syntaxes are Base64 Encoding [Base64],
  462.    gzip encoding, and so forth.
  463.  
  464. 3.3:  Determining which values of CCS, CES, and TES are used
  465.  
  466.    To completely specify which CCS, CES, and TES are used in a specific
  467.    text transmission, there needs to be a consistent set of labels for
  468.    specifying which CCS, CES, and TES are used.  Once the appropriate
  469.    mechanisms have been selected, there are six techniques for attaching
  470.    these labels to the data.
  471.  
  472.    The labels themselves are named and registered, either with IANA
  473.    [IANA] or with some other registry.  Ideally, their definitions are
  474.    retrievable from some registration authority.
  475.  
  476.    Labels may be determined in one of the following ways:
  477.  
  478.    -  Determined by guessing, where the receiver of the text has to
  479.       guess the values of the CCS, CES, and TES. For example: "I got
  480.       this from Sweden so it's probably  ISO-8859-1."  This is
  481.       obviously not a very foolproof way to decode text.
  482.    -  Determined by the standard, where the protocol used to transmit
  483.       the data has made documented choices of CCS, CES, and TES in the
  484.       standard. Thus, the encodings used are known through the
  485.       access protocol, for example HTTP [HTTP] uses (but is not
  486.       limited to) ISO-8859-1, SMTP uses US-ASCII.
  487.    -  Attached to the transfer envelope, where the descriptive labels are
  488.       attached to the wrapper placed around the text for transport.
  489.       MIME headers are a good example of this technique.
  490.    -  Included in the data stream, where the data stream itself has
  491.       been encoded in such a way as to signal the character set used.
  492.       For example, ISO-2022 encodes the data with escape sequences to
  493.       provide information on the character subset currently being used.
  494.    -  Agreed by prior bilateral agreement, where some out-of-band
  495.       negotiation has allowed the text transmitter and receiver to
  496.       determine the CCS, CES, and  TES for the transmitted text.
  497.    -  Agreed to by negotiation during some phase, typically
  498.       initialization of the protocol.
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Weider, et. al.              Informational                      [Page 9]
  507.  
  508. RFC 2130             Character Set Workshop Report            April 1997
  509.  
  510.  
  511. 3.3.1:  Recommendations for value specification mechanisms
  512.  
  513.    While each of these techniques (with the  exception of guessing) is
  514.    useful in particular situations, interoperability requires a more
  515.    consistent set of techniques.  Thus, we recommend that MIME
  516.    registered values be used for all tagging of character sets and
  517.    languages UNLESS there is an existing mechanism for determining the
  518.    required information using one of the other techniques (except
  519.    guessing).  This recommendation will require a fair bit of work on
  520.    the part of protocol designers, implementors, the IETF, the IESG, and
  521.    the IAB.
  522.  
  523.    However, it is important to point out that the MIME concept of
  524.    'charset' in some cases cuts across several layers of components in
  525.    our model.  While this can be accepted in existing registrations, we
  526.    also recommend that the MIME registration procedure for character
  527.    sets be modified to show how a proposed character set deals with the
  528.    CCS and the CES. Most 'charsets' have a well defined CCS and CES,
  529.    they should merely be teased apart for the registration.
  530.  
  531.    There are a number of other recommendations, but these will be
  532.    covered in the next sections.
  533.  
  534. 3.4:  Recommended Defaults
  535.  
  536.    For a number of reasons, one cannot define a mandatory set of
  537.    defaults for all Internet protocols.  There is a mass of current
  538.    practice, future protocols are likely to have different purposes,
  539.    which may determine their handling of text, and protocols may need
  540.    specific variation support.  For example, in mail, text is a
  541.    predominant data type and coded character sets then become a major
  542.    issue for the protocol.  Also, since e-mail is ubiquitous and users
  543.    expect to be able to send it to everyone, the mail protocols need to
  544.    be quite adept at handling different character set encodings.  On the
  545.    other hand, if strings are seldom used in a given protocol, there is
  546.    no need to weigh the protocol down with a sophisticated apparatus for
  547.    handling multiple character sets, assuming that the predicated
  548.    character set can handle all the protocol's needs. This observation
  549.    also applies to the specification techniques for character set
  550.    parameters.  If only one character set encoding is needed, it can be
  551.    made explicit in the protocol specification.  Protocols with a
  552.    greater need for character set support will need a more elaborate
  553.    specification technique.
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Weider, et. al.              Informational                     [Page 10]
  563.  
  564. RFC 2130             Character Set Workshop Report            April 1997
  565.  
  566.  
  567. 3.4.1:  Clarity of specification
  568.  
  569.    We recommend that each protocol clearly specify what it is using for
  570.    each of the layers of the transmission model.  Users (or clients)
  571.    should never have to guess what the parameter is for a given layer.
  572.  
  573. 3.4.2:  Default Coded Character Set:
  574.  
  575.    The default Coded Character Set is the repertoire of ISO-10646.
  576.  
  577. 3.4.3:   Default Character Encoding Scheme
  578.  
  579.    For text-oriented protocols, new protocols should use UTF-8, and
  580.    protocols that have a backwards compatibility requirement should use
  581.    the default of the existing protocol, e.g. US-ASCII for mail, and
  582.    ISO-8859-1 for HTTP.  The recommended specification scheme is the
  583.    MIME "charset" specification, using the IANA "charset"
  584.    specifications.  The MIME specifications will need to be clarified to
  585.    meet this model in the future.
  586.  
  587.    For other protocols, the default should be UTF-8 as this initially
  588.    allows US-ASCII to be entered as-is, and enables the full repertoire
  589.    of ISO 10646.
  590.  
  591.    Some protocols, such as those descended from SGML [SGML], have other
  592.    natural notations for characters outside their "natural" repertoire;
  593.    for instance, HTML [HTML] allows the use of &#nnnn to refer to any
  594.    ISO 10646 character.  Note that this, like all other encodings that
  595.    depend on "escape characters", redefines at least one character from
  596.    the base character set for use as an indicator of "foreign"
  597.    characters.  Use of this approach must be weighed very carefully.
  598.  
  599. 3.4.4:   Default Transport Encoding Scheme
  600.  
  601.    There is no recommended default for this level.  For plain text
  602.    oriented protocols, the bytestream transport format should be 8-bit
  603.    clean, possibly with normalization of end-of-line indicators.  Some
  604.    special cases could be made for protocols that are not 8-bit clean,
  605.    such as encoding it for transport over 7-bit connections.  For binary
  606.    the same recommendation holds as above.  The specification technique
  607.    should either be defined in the  protocol, if only one way is
  608.    permitted, or by use of MIME content-transfer-encoding (CTE)
  609.    techniques, using IANA registered values.
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Weider, et. al.              Informational                     [Page 11]
  619.  
  620. RFC 2130             Character Set Workshop Report            April 1997
  621.  
  622.  
  623. 3.4.5:  Default Language
  624.  
  625.    There is no recommended default for the language level.  For human
  626.    readable text, there should always be a way to specify the natural
  627.    language. The specification technique should be a MIME identifier
  628.    with IANA  registered values for languages.  If headers are used, the
  629.    header should be 'Content-Language'.
  630.  
  631. 3.4.6:  Default Locale
  632.  
  633.    The default should be the POSIX locale.  The specification technique
  634.    should use the Cultural register of CEN ENV 12005 [CEN] for the
  635.    values.  If headers are used, the header should be 'Content-Locale'.
  636.  
  637. 3.4.7:  Default Culture
  638.  
  639.    There is no recommended default for the Culture level.  The
  640.    specification  technique should be a MIME or MIME-like identifier
  641.    (e.g. Content-Culture) and should use the Cultural register of CEN
  642.    ENV 12005 for its values.
  643.  
  644. 3.4.8:  Default Presentation
  645.  
  646.    There is no recommended default for the Presentation level.  The
  647.    specification technique should be a MIME or MIME-like identifier
  648.    (e.g.  Content-Layout) and use the glyph register of ISO 10036 and
  649.    other registers for its values.
  650.  
  651. 3.4.9:  Multiplexing
  652.  
  653.    In some cases, text transmission may require the use of a number of
  654.    different values for a given parameter; for example, English
  655.    annotation of Japanese text might well require shifting the Content-
  656.    Language parameter.  The way to switch the value of parameters within
  657.    a single body of text depends on the application.  For instance, the
  658.    HTML I18N [I18N] work defines a language attribute on most of its
  659.    elements, including <SPAN>, <HTML>, and <BODY>, for the purpose of
  660.    switching between different languages.  When only one value is
  661.    needed, this value should be as general as possible, and specified in
  662.    the protocol standard with reference to the IANA or other registry
  663.    value.  All levels should be specified explicitly.
  664.  
  665. 3.4.10:  Storage
  666.  
  667.    Because stored text may very well be stored without any of the
  668.    additional information necessary for decoding, stored text SHOULD be
  669.    tagged in a MIME compliant fashion.  This alleviates the problem of
  670.    being unable to interpret text which has been stored for a long time,
  671.  
  672.  
  673.  
  674. Weider, et. al.              Informational                     [Page 12]
  675.  
  676. RFC 2130             Character Set Workshop Report            April 1997
  677.  
  678.  
  679.    or text whose provenance is not available.
  680.  
  681. 3.5:  Guidelines for conversions between coded character sets
  682.  
  683.    This section covers various algorithms to convert a source text S,
  684.    encoded in the coded character set CCS(S), to a target text T,
  685.    encoded in the coded character set CCS(T).
  686.  
  687.    Rep(X) is the character repertoire of coded character set X, i.e. the
  688.    set of characters which can be represented with X.
  689.  
  690. 3.5.1:  Exact conversion
  691.  
  692.    When Rep(CCS(S)) and Rep(CCS(T)) are equal or Rep(CCS(S)) is a subset
  693.    of Rep(CCS(T)), exact conversion is possible; i.e. T is equal to S.
  694.    The octets just need to be remapped.  The algorithm for performing
  695.    this remapping is simple, if the IANA-registered definition tables
  696.    for CCS(S) and CCS(T) are available.
  697.  
  698. 3.5.2:  Approximate conversion
  699.  
  700.    In all other cases, any conversion creates a text T which differs
  701.    from S.  There are different principles for how this inevitable
  702.    difference should be handled.  A choice between them should be made,
  703.    depending on the purpose and requirements of the conversion.  Where
  704.    possible, the client application should be given mechanisms to
  705.    determine what has been done to the text.
  706.  
  707.    3.5.2.1:  Length-modifying conversion for human display
  708.  
  709.    When the length of the target text T is allowed to differ from the
  710.    length of the source text S, one should use a conversion method in
  711.    which each source character is converted to one or several target
  712.    character(s), using a best resemblance criteria in the choice of that
  713.    target character(s).
  714.  
  715.    Examples:
  716.       LATIN CAPITAL LETTER [*] ->  AE
  717.       COPYRIGHT SIGN       [*] -> (c)
  718.  
  719. 3.5.2.2:  Length-preserving conversion for human display
  720.  
  721.    Where the text T must be presented and the length of T cannot differ
  722.    from the length of S, one should use a conversion method where each
  723.    source character is converted to one target character, using some
  724.    kind of best  resemblance criteria in the choice of target character.
  725.  
  726.  
  727.  
  728.  
  729.  
  730. Weider, et. al.              Informational                     [Page 13]
  731.  
  732. RFC 2130             Character Set Workshop Report            April 1997
  733.  
  734.  
  735.    Examples:
  736.      LATIN CAPITAL LETTER  [*] -> A
  737.      COPYRIGHT SIGN        [*] -> C
  738.  
  739. 3.5.2.3:  Conversion without data loss
  740.  
  741.    Where the conversion of the text S into T must be completely
  742.    reversible, apply a Character Encoding Syntax or other reversible
  743.    transformation method.  This case is most frequently met in data
  744.    storage requirements.
  745.  
  746.    Examples:
  747.      LATIN CAPITAL LETTER [*] -> &AE
  748.      COPYRIGHT SIGN       [*] -> &(C
  749.  
  750.    An alternate method, which can be used if the size of Rep(CCS(T)) >=
  751.    Rep(CCS(S)), then for each character in Rep(CCS(S)) which is not
  752.    present in Rep(CCS(T)), define a mapping into a character in
  753.    Rep(CCS(T)) which is not present in Rep(CCS(S)).
  754.  
  755.    Examples:
  756.      LATIN CAPITAL LETTER  [*] -> CYRILLIC CAPITAL LETTER [*]
  757.      COPYRIGHT SIGN  [*] -> PARTIAL DIFFERENTIAL SIGN [*]
  758.  
  759.    Note that conversion without data loss requires redefining some
  760.    member of T to indicate "the introduction of character data outside
  761.    T".  This effectively adds another level of CES on top of CES(T).
  762.  
  763. 4: Presentation issues
  764.  
  765.    There are a number of considerations to make in selecting the base
  766.    character set.  One such consideration is the protocol's convenience
  767.    to users with limited equipment (for example only ISO 8859-1 or a
  768.    keyboard without the ability to enter all the characters in ISO
  769.    10646).  Alternative representation should be considered for these
  770.    users, both for input and output.  Possible options for the
  771.    representation of characters that can not be displayed include
  772.    transliteration (a la CEN/TC304 or ISO TC46/SC2 ), RFC 1345 [RFC-
  773.    1345] representative icons, or the WG2 short name (u+xxxx).
  774.  
  775. 5: Open issues
  776.  
  777.    In addition to the issues declared out of scope and enumerated in
  778.    section 2.1, the following issues are still open and will need to be
  779.    addressed in other forums.  These issues: language tags, public
  780.    identifiers such as URL names, and bi-directionality are briefly
  781.    discussed below as they repeatedly encroached the discussion.
  782.  
  783.  
  784.  
  785.  
  786. Weider, et. al.              Informational                     [Page 14]
  787.  
  788. RFC 2130             Character Set Workshop Report            April 1997
  789.  
  790.  
  791. 5.1: Language tags
  792.  
  793.    Although the workshop decided not to explicitly address the so-called
  794.    "CJK issue", a few members felt it was necessary to have some
  795.    mechanism to address the problem of correct Han character display in
  796.    the ISO-10646 issue, and that saying that it was a "font issue" would
  797.    not suffice.
  798.  
  799.    The "CJK issue" refers to the extended discussion about "Han
  800.    unification", the use of a single ISO-10646 codepoint to represent
  801.    multiple national variants of a Chinese (Han) character.  ISO-10646
  802.    can map uniquely to any single CJK national character set, but in the
  803.    absence of additional  information an application can not display an
  804.    ISO-10646 text using the proper national variants for that text.
  805.  
  806.    It was agreed that language tags would be sufficient to disambiguate
  807.    unified characters. There was not, in our opinion, a significant
  808.    technical difference between the use of different coded character
  809.    sets with overlapping codepoints, and a single coded character set
  810.    with language tags.  Either way, the application has sufficient
  811.    information to display the text properly.
  812.  
  813.    It was observed that in contemporary usage of MIME charsets, the
  814.    language is implied as well as the coded character set and the
  815.    character encoding syntax.  We agreed that this is excessive
  816.    overloading of MIME charsets.
  817.  
  818.    To specify the language used in a particular block of text, we
  819.    recommend that the MIME tag "Content-Language" be used.  There are a
  820.    number of questions about this approach that need to be worked out,
  821.    however:
  822.  
  823.    -  Is Content-Language: actually suitable?
  824.    -  Is there an overload between this function and the other
  825.         intended functions of Content-Language: as described in RFC
  826.         1766?
  827.    -  What, precisely, does "Content-Language: zh-tw, ja, ko, zh-cn"
  828.         mean in this context? We believe it means that, in drawing a
  829.         Han character, the Taiwanese variant (presumably traditional
  830.         Han) is preferred, followed by the Japanese, Korean, and
  831.         mainland Chinese (presumably simplified Han) variants. It does
  832.         *NOT* mean "mixed text containing Taiwanese, Japanese, Korean,
  833.         and mainland Chinese text with all the national variants in
  834.         each of these".
  835.  
  836.    Mixed CJK text, that simultaneously displays different variants
  837.    occupying the same codepoint, requires language tags embedded in the
  838.    data.  Ohta and Handa propose in RFC 1554 [RFC-1554] a MIME charset
  839.  
  840.  
  841.  
  842. Weider, et. al.              Informational                     [Page 15]
  843.  
  844. RFC 2130             Character Set Workshop Report            April 1997
  845.  
  846.  
  847.    using ISO-2022 shifts between multiple coded character sets; in
  848.    effect this is an encoding that uses coded character sets for
  849.    displaying the appropriate glyphs.
  850.  
  851.    There is some speculation that states that mixed CJK text is
  852.    relatively infrequent, and that therefore it is acceptable to require
  853.    that such text be represented using a rich text format that can
  854.    support language tags.  In other words, that a simplifying assumption
  855.    can be made for TEXT/PLAIN in  email using ISO-10646 that will not
  856.    require multiple display representations for the same codepoint.  A
  857.    mechanism such as RFC 1554 could address this need if it was
  858.    important; although arguably RFC 1554 should really be identified as
  859.    TEXT/ISO-2022.
  860.  
  861.    Note again that we recommend that support for language tagging SHOULD
  862.    be built into new protocols, as this will become a critical component
  863.    of the automated indexing and retrieval in information applications
  864.    of the future.
  865.  
  866. 5.2:   Public identifiers
  867.  
  868.    There is a considerable demand from the user community for the
  869.    ability to use non-ASCII characters in URL names, IMAP mailbox names,
  870.    file names, and other public identifiers. This is still an open
  871.    problem.
  872.  
  873. 5.3:   Bi-directionality
  874.  
  875.    It was realized that a consistent framework for bi-directional text
  876.    was needed but there was no attempt to work on it in this workshop.
  877.  
  878. 6:  Security Considerations
  879.  
  880.    There are no security considerations associated with character sets.
  881.  
  882. 7:  Conclusions
  883.  
  884.    This paper provides a conceptual framework and a set of
  885.    recommendations which, if adopted, should provide a solid foundation
  886.    for interoperability on the Internet. There are, however, a number of
  887.    open issues which will need to be addressed to provide ever better
  888.    use of text on the Internet.
  889.  
  890.  
  891.  
  892.  
  893.  
  894.  
  895.  
  896.  
  897.  
  898. Weider, et. al.              Informational                     [Page 16]
  899.  
  900. RFC 2130             Character Set Workshop Report            April 1997
  901.  
  902.  
  903. 8:  Recommendations
  904.  
  905. 8.1:  To the IAB
  906.  
  907.    There were a number of recommendations to the IAB about making the
  908.    standards process more aware of the need for character set
  909.    interoperability, and about the framework itself.
  910.  
  911.    A: The IAB should trigger the examination of all RFCs to determine
  912.    the way  they handle character sets, and obsolete or annotate the
  913.    RFCs where necessary.
  914.  
  915.    B: The IESG should trigger the recommendation of procedures to the
  916.    RFC editor  to encourage RFCs to specify character set handling if
  917.    they specify the  transmission of text.
  918.  
  919.    C: The IAB should trigger the production of a perspectives document
  920.    on the  character set work that has gone on in the past and relate it
  921.    to the current framework.
  922.  
  923.    D: Full ISO 10646 has a sufficiently broad repertoire, and scope for
  924.    further extension, that it is sufficient for use in Internet
  925.    Protocols (without excluding the use of existing alternatives).
  926.    There is no need for specific development of character set standards
  927.    for the Internet.
  928.  
  929.    E: The IAB should encourage the IRTF to create a research group to
  930.    explore the open issues of character sets on the Internet. This group
  931.    should set its sights much higher than this workshop did.
  932.  
  933.    F: The IANA (perhaps with the help of an IETF or IRTF group) should
  934.    develop  procedures for the registration of new character sets for
  935.    use in the Internet.
  936.  
  937.    G: Register UTF-8 as a Character Encoding Scheme for MIME.
  938.  
  939.    H: The current use of the "x-*" format for distinguishing
  940.    experimental tags should be continued for private use among
  941.    consenting parties. All other namespaces should be allocated by IANA.
  942.  
  943.    I: Application protocol RFCs SHOULD include a section on
  944.    "multilingual Considerations".
  945.  
  946.    J: Application Protocol RFCs SHOULD indicate how to transfer 'on the
  947.    wire' all characters in the character sets they use. They SHOULD also
  948.    specify how to transfer other information that applications may need
  949.    to know about the data.
  950.  
  951.  
  952.  
  953.  
  954. Weider, et. al.              Informational                     [Page 17]
  955.  
  956. RFC 2130             Character Set Workshop Report            April 1997
  957.  
  958.  
  959.    K: The IESG should trigger a set of extensions to RFC 1522 to allow
  960.    language tagging of the free text parts of message headers.
  961.  
  962. 8.2:  For new Internet protocols
  963.  
  964.    New protocols do not suffer from the need to be compatible with old
  965.    7-bit pipes.  New protocol specifications SHOULD use ISO 10646 as the
  966.    base charset unless there is an overriding need to use a different
  967.    base character set.
  968.  
  969.    New protocols SHOULD use values from the IANA registries when
  970.    referring to parameter values.  The way these values are carried in
  971.    the protocols is protocol dependent; if the protocol uses RFC-822-
  972.    like headers, the header names already in use SHOULD be used.
  973.  
  974.    For protocols with only a single choice for each component, the
  975.    protocol  should use the most general specification and should be
  976.    specified with reference to the registered value in the protocol
  977.    standard.
  978.  
  979.    Protocols SHOULD tag text streams with the language of the text.
  980.  
  981. 8.3:  For the registration of new character sets
  982.  
  983.    Ned Freed will be releasing a new MIME registration document in
  984.    conjunction with this paper.
  985.  
  986. 8.3.1:   A definition table for a coded character set
  987.  
  988.    A definition table for a coded character set A must for each
  989.    character C that is in the repertoire of A give:
  990.  
  991.    a) if C is present in ISO 10646, the code value (in hexadecimal form)
  992.         for that character.
  993.  
  994.    b) If C is not present in ISO 10646, but may be constructed using ISO
  995.         10646 combining characters, the series of code values (in
  996.         hexadecimal form) used to construct that character.
  997.  
  998.    c) if C is not present in ISO 10646, a textual description of the
  999.         character,  and a reference to its origin.
  1000.  
  1001.  
  1002.  
  1003.  
  1004.  
  1005.  
  1006.  
  1007.  
  1008.  
  1009.  
  1010. Weider, et. al.              Informational                     [Page 18]
  1011.  
  1012. RFC 2130             Character Set Workshop Report            April 1997
  1013.  
  1014.  
  1015. 8.3.2:   A definition of a character encoding scheme
  1016.  
  1017.    A definition of a character encoding scheme consists of:
  1018.  
  1019.    -  A description of an algorithm which transforms every possible
  1020.         sequence of octets to either a sequence of pairs <CCS, code
  1021.         value> or to the  error state "illegal octet sequence"
  1022.    -  Specifications, either by reference to CCS's registered by IANA or
  1023.       in text, of each CCS upon which this CES is based.
  1024.  
  1025.  
  1026.  
  1027.  
  1028.  
  1029.  
  1030.  
  1031.  
  1032.  
  1033.  
  1034.  
  1035.  
  1036.  
  1037.  
  1038.  
  1039.  
  1040.  
  1041.  
  1042.  
  1043.  
  1044.  
  1045.  
  1046.  
  1047.  
  1048.  
  1049.  
  1050.  
  1051.  
  1052.  
  1053.  
  1054.  
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060.  
  1061.  
  1062.  
  1063.  
  1064.  
  1065.  
  1066. Weider, et. al.              Informational                     [Page 19]
  1067.  
  1068. RFC 2130             Character Set Workshop Report            April 1997
  1069.  
  1070.  
  1071. Appendix A:
  1072.  
  1073. A-1:  IETF Protocols
  1074.  
  1075.    The following list describes how various existing protocols handle
  1076.    multiple character set information.
  1077.  
  1078.    Email
  1079.  
  1080.       SMTP
  1081.         See 8.2. ESMTP makes it easy to negotiate the use of alternate
  1082.         language and encoding if it is needed.
  1083.       Headers
  1084.         RFC 1522 forms an adequate framework for supporting text; UTF-8
  1085.         alone is not a possible solution, because the mail pathways are
  1086.         assumed to be 7-bit 'forever'. However, RFC 1522 should be
  1087.         extended to allow language tagging of the free text parts of
  1088.         message headers.
  1089.       Bodies
  1090.         Selection of charset parameters for Email text bodies is
  1091.         reasonably well covered by the charset= parameter on Text/* MIME
  1092.         types.  Language is defined by the Content-language header of
  1093.         RFC 1766.  Other information will have to be added using body
  1094.         part headers; due to the way MIME differentiates between body
  1095.         part headers and message headers, these will all have to have
  1096.         names starting with Content- .
  1097.  
  1098.    NetNews
  1099.  
  1100.       NNTP
  1101.         See 8.2. No strong tradition for negotiation of encoding in NNTP
  1102.         exists.
  1103.       NetNews Messages
  1104.         These should be able to leverage off the mechanisms defined for
  1105.         Email.  One difference is that nearly all NNTP channels are 8-
  1106.         bit clean; some NNTP newsgroups have a tradition of using 8-bit
  1107.         charsets in both headers and bodies. Defining character set
  1108.         default on a per newsgroup basis might be a suitable approach.
  1109.  
  1110.    RTCP
  1111.         The identifiers carried as information about parties are already
  1112.         defined to be in UTF-8.
  1113.  
  1114.  
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122. Weider, et. al.              Informational                     [Page 20]
  1123.  
  1124. RFC 2130             Character Set Workshop Report            April 1997
  1125.  
  1126.  
  1127.    FTP
  1128.       Protocol
  1129.         See 8.2. The common use of welcome banners in the login response
  1130.         means that there might be strong reason here to allow client and
  1131.         server to negotiate a language different from the default for
  1132.         greetings and error messages. This should be a simple protocol
  1133.         extension.
  1134.       Filenames
  1135.         Many fileservers now how have the capability of using non-ASCII
  1136.         characters in filenames, while the "dir" and "get" commands of
  1137.         are defined in terms of US-ASCII only. One possible solution
  1138.         would be to define a "UTF-8" mode for the transfer of filenames
  1139.         and directory information; this would need to be a negotiated
  1140.         facility, with fallback to US-ASCII if not negotiated. The
  1141.         important point here is consistency between all implementations;
  1142.         a single charset is better here than the ability to handle
  1143.         multiple charsets.
  1144.  
  1145.    World Wide Web
  1146.       HTTP
  1147.         See 8.2. The single-shot stype of HTTP makes negotiation more
  1148.         complex than it would otherwise be.
  1149.       HTML
  1150.         Internationalization of HTML [I18N] seems fairly well covered in
  1151.         the current "I18N" document. It needs review to see if it needs
  1152.         more specific details in order to carry application information
  1153.         apart from the language.
  1154.  
  1155.    URLs
  1156.         URLs are "input identifiers", and powerful arguments should be
  1157.         made if they are ever to be anything but US-ASCII.
  1158.  
  1159.    IMAP
  1160.         IMAP's information objects are MIME Email objects, and therefore
  1161.         are able to use that standard's methods. However, IMAP folder
  1162.         names are local identifiers; there is strong reason to allow
  1163.         non-ASCII characters in these. A UTF-8 negotiation might be the
  1164.         most appropriate thing, however, UTF-8 is awkward to use.
  1165.         Unfortunately, UTF-7 isn't suitable because it conflicts with
  1166.         popular hierarchy delimiters. The most recent IMAP work in
  1167.         progress specification describes a modified UTF-7 which avoids
  1168.         this problem.
  1169.  
  1170.  
  1171.  
  1172.  
  1173.  
  1174.  
  1175.  
  1176.  
  1177.  
  1178. Weider, et. al.              Informational                     [Page 21]
  1179.  
  1180. RFC 2130             Character Set Workshop Report            April 1997
  1181.  
  1182.  
  1183.    DNS
  1184.         DNS names are the prime example of identifiers that need to stay
  1185.         in US-ASCII for global interoperability. However, some DNS
  1186.         information, in particular TXT records, may represent
  1187.         information (such as names) that is outside the ASCII range. A
  1188.         single solution is the best; problems resulting from UTF-8
  1189.         should be investigated.
  1190.  
  1191.    WHOIS++
  1192.         WHOIS++ version 1 is defined to use ISO 8859-1. The next version
  1193.         will use UTF-8. The currently designed changes will also allow
  1194.         the specification of individual attributes on attribute names;
  1195.         these will make the passing of application information about the
  1196.         values (such as language) easier. No immediate action seems
  1197.         necessary.
  1198.  
  1199.    WHOIS
  1200.         This has been a stable protocol for so many years now that it
  1201.         seems unwise to suggest that it be modified. Furthermore,
  1202.         compatible extensions exist in RWHOIS and WHOIS++; modification
  1203.         should rather be made to these protocols than to the WHOIS
  1204.         protocol itself.
  1205.  
  1206.    Telnet
  1207.         This is a prime example of protocol where character set support
  1208.         is necessary and nonexistent. The current work in progress on
  1209.         character set negotiation in Telnet seems adequate to the task;
  1210.         the question of passing other application data that might be
  1211.         useful is still open.
  1212.  
  1213. A-2: Non-IETF protocols
  1214.  
  1215.    For these protocols, the IETF does not have any power to change them.
  1216.    However, the guidelines developed by the workshop may still be useful
  1217.    as input to the further development of the protocols.
  1218.  
  1219.    Gopher: Gopher, Gopher+
  1220.  
  1221.    Prospero (Archie)
  1222.  
  1223.    NFS:  Filesystem
  1224.  
  1225.    CORBA, Finger, GEDI, IRC, ISO 10160/1, Kerberos, LPR, RSTAT, RWhois,
  1226.    SGML, TFTP, X11, X.500, Z39.50
  1227.  
  1228.  
  1229.  
  1230.  
  1231.  
  1232.  
  1233.  
  1234. Weider, et. al.              Informational                     [Page 22]
  1235.  
  1236. RFC 2130             Character Set Workshop Report            April 1997
  1237.  
  1238.  
  1239. Appendix B: Acronyms
  1240.  
  1241.    ASCII       American National Standard Code for Information Character
  1242.                  Sets
  1243.    CCS         Coded Character Sets
  1244.    CEN ENV     European Committee for Standardisation (CEN) European
  1245.                  pre-standard (ENV)
  1246.    CES         Character Encoding Scheme
  1247.    CJK         Chinese Japanese Korean
  1248.    CORBA       Common Object Request Broker Architecture
  1249.    CTE         Content Transfer Encoding
  1250.    DNS         Domain Name Service
  1251.    ESMTP       Extended SMTP
  1252.    FTP         File Transfer Protocol
  1253.    HTML        Hypertext Transfer Protocol
  1254.    I18N        Internationalization (or 18 characters between the first
  1255.                  (I) and last (n)character)
  1256.    IAB         Internet Activities Board
  1257.    IANA        Internet Assigned Numbers Authority
  1258.    IESG        Internet Engineering Steering Group
  1259.    IETF        Internet Engineering Task Force
  1260.    IMAP        Internet Message Access Protocol
  1261.    IRC         Internet Relay Chat
  1262.    IRTF        Internet Research Task Force
  1263.    ISI         Information Sciences Institute
  1264.    ISO         International Standards Organization
  1265.    MIME        Multipurpose Internet Mail Extensions
  1266.    NFS         Networked File Server
  1267.    NNTP        Net News Transfer Protocol
  1268.    POSIX       Portable Operating System Interface
  1269.    RFC         Request for Comments (Internet standards documents)
  1270.    RPC         Remote Procedure Call
  1271.    RSTAT       Remote Statistics
  1272.    RTCP        Real-Time Transport Control Protocol
  1273.    Rwhois      Referral Whois
  1274.    SGML        Standard Generalized Mark-up Language
  1275.    SMTP        Simple Mail Transfer Protocol
  1276.    TES         Transfer Encoding Syntax
  1277.    TFTP        Trivial File Transfer Protocol
  1278.    URL         Uniform Resource Locator
  1279.    UTF         Universal Text/Translation Format
  1280.  
  1281.  
  1282.  
  1283.  
  1284.  
  1285.  
  1286.  
  1287.  
  1288.  
  1289.  
  1290. Weider, et. al.              Informational                     [Page 23]
  1291.  
  1292. RFC 2130             Character Set Workshop Report            April 1997
  1293.  
  1294.  
  1295. Appendix C:  Glossary
  1296.  
  1297.    Bi-directionality -  A property of some text where text written right-
  1298.          to- left (Arabic or Hebrew) and text written left-to-right
  1299.          (e.g. Latin) are intermixed in one and the same line.
  1300.  
  1301.    Character - A single graphic symbol represented by sequence of one or
  1302.         more bytes.
  1303.  
  1304.    Character Encoding Scheme - The mapping from a coded character set to
  1305.         an encoding which may be more suitable for specific purpose. For
  1306.         example, UTF-8 is a character encoding scheme for ISO 10646.
  1307.  
  1308.    Character Set - An enumerated group of symbols (e.g., letters, numbers
  1309.         or glyphs)
  1310.  
  1311.    Coded Character Set - The mapping from a set of integers to the
  1312.         characters of a character set.
  1313.  
  1314.    Culture - Preferences in the display of text based on cultural norms,
  1315.         such as spelling and word choice.
  1316.  
  1317.    Language - The words and combinations of words the constitute a system
  1318.         of expression and communication among people with a shared
  1319.         history or set of traditions.
  1320.  
  1321.    Layout - Information needed to display text to the user, similar to
  1322.         the presentation layer in the ISO telecommunications model.
  1323.  
  1324.    Locale - The attributes of communication, such as language, character
  1325.         set and cultural conventions.
  1326.  
  1327.    On-the-wire -  The data that actually gets put into packets for
  1328.         transmission to other computers.
  1329.  
  1330.    Transfer Encoding Syntax -  The mapping from a coded character set
  1331.         which has been encoded in a Character Encoding Scheme to an
  1332.         encoding which may be more suitable for transmission using
  1333.         specific protocols. For example, Base64 is a transfer encoding
  1334.         syntax.
  1335.  
  1336.  
  1337.  
  1338.  
  1339.  
  1340.  
  1341.  
  1342.  
  1343.  
  1344.  
  1345.  
  1346. Weider, et. al.              Informational                     [Page 24]
  1347.  
  1348. RFC 2130             Character Set Workshop Report            April 1997
  1349.  
  1350.  
  1351. Appendix D:  References
  1352.  
  1353. [*]  Non-ASCII character
  1354.  
  1355. [ASCII]  ANSI X3.4:1986  "Coded  Character Sets - 7 Bit American
  1356.      National Standard Code for Information Interchange (7-bit ASCII)"
  1357.  
  1358. [Base64]  Freed, N., and N. Borenstein, "Multipurpose Internet
  1359.      Mail Extensions (MIME) Part One: Format of Internet Message
  1360.      Bodies", RFC 2045, November 1996.
  1361.  
  1362. [CEN]  see http://tobbi.iti.is/TC304/welcome.html for current status.
  1363.  
  1364. [HTML]  Berners-Lee, T., and D. Connolly, "Hypertext Markup Language -
  1365.      2.0", RFC 1866, November 1995.
  1366.  
  1367. [HTTP]  Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
  1368.      Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
  1369.  
  1370. [I18N]  Yergeau, F., et.al.,  "Internationalization of the Hypertext
  1371.      Markup Language", RFC 2070, January 1997.
  1372.  
  1373. [IANA] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
  1374.      1700, ISI, October 1994.
  1375.  
  1376. [ISO-2022]  ISO/IEC 2022:1994,  "Information technology -- Character
  1377.      Code Structure and Extension Techniques",  JTC1/SC2.
  1378.  
  1379. [ISO-7498]  ISO/IEC 7498-1:1994,  "Information technology - Open Systems
  1380.      Interconnection - Basic Reference Model:  The Basic Model".
  1381.  
  1382. [ISO-8859]  Information Processing -- 8-bit Single-Byte Coded Graphic
  1383.      Character Sets -- Part 1: Latin Alphabet no. 1,
  1384.      ISO 8859-1:1987(E). Part 2: Latin Alphabet no. 2, ISO 8859-2
  1385.      1987(E). Part 3: Latin Alphabet no. 3, ISO 8859-3:1988(E).
  1386.      Part 4: Latin Alphabet no. 4, ISO 8859-4, 1988(E). Part 5:
  1387.      Latin/Cyrillic Alphabet ISO 8859-5, 1988(E). Part 6:
  1388.      Latin/Arabic Alphabet, ISO 8859-6, 1987(E). Part 7: Latin/Greek
  1389.      Alphabet, ISO 8859-7, 1987(E). Part 8: Latin/Hebrew Alphabet, ISO
  1390.      8859-8-1988(E).Part 9: Latin Alphabet no. 5, ISO 8859-9, 1990(E).
  1391.      Part 10: Latin Alphabet no. 6, ISO 8859-10:1992(E).
  1392.  
  1393. [ISO-10646]  ISO/IEC 10646-1:1993(E ),  "Information technology --
  1394.      Universal Multiple-Octet Coded Character Set (UCS) -- Part 1:
  1395.      Architecture and Basic Multilingual Plane".  JTC1/SC2, 1993
  1396.  
  1397.  
  1398.  
  1399.  
  1400.  
  1401.  
  1402. Weider, et. al.              Informational                     [Page 25]
  1403.  
  1404. RFC 2130             Character Set Workshop Report            April 1997
  1405.  
  1406.  
  1407. [MIME]  See [Base64]
  1408.  
  1409. [POSIX]  Institute of Electrical and Electronics Engineers.  "IEEE
  1410.      standard interpretations for IEEE standard portable operating
  1411.      systems interface for computer environments". IEEE Std 1003.1
  1412.      -1988/Int, 1992 edition.  Sponsor, Technical Committee on Operating
  1413.      Systems of the IEEE Computer Society.  New York, NY: Institute of
  1414.      Electrical and Electronic Engineers, 1992.
  1415.  
  1416. RFC 1340  See [IANA]
  1417.  
  1418. [RFC-1345]  Simonsen, K., "Character Mnemonics & Character Sets",
  1419.      RFC 1345, Rationel Alim Planlaegning, June 1992.
  1420.  
  1421. [RFC-1554]  Ohta, M., and K. Handa,  "ISO-2022-JP-2: Multilingual
  1422.      Extension of ISO-2022-JP",  Tokyo Institute of Technology, ETL,
  1423.      December 1993.
  1424.  
  1425. RFC 1642  See [UTF-7]
  1426.  
  1427. [RFC-1766]  Alvestrad, H., "Tags for the Identification of Languages",
  1428.      RFC 1766, UNINETT, March 1995.
  1429.  
  1430. [RFC 1958]  Carpenter, B. (ed.) "Architectural Principles of the
  1431.      Internet", RFC 1958, IAB, June 1996.
  1432.  
  1433. [SGML] ISO 8879:1986 "Information Processing - Text and Office Systems
  1434.      - Standard Generalized Markup Language (SGML)"
  1435.  
  1436. [SMTP]   Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
  1437.      August, 1982.
  1438.  
  1439. [Unicode]  "The Unicode standard, version 2.0.  Unicode Consortium.
  1440.      Reading, Mass.: Addison-Wesley Developers Press, 1996
  1441.  
  1442. [UTF-7]  Goldsmith, D., and M. Davis, "UTF-7: A Mail Safe
  1443.      Transformation Format of Unicode", RFC 1642, Taligent, Inc., July
  1444.      1994.
  1445.  
  1446. [UTF-8]  International Standards Organization, Joint Technical
  1447.      Committee 1 (ISO/JTC1), "Amendment 2:1993, UCS Transformation
  1448.      Format 8 (UTF-8)", in ISO/IEC 10646-1:1993 Information technology
  1449.      - Universal Multiple-Octet Coded Character Set (UCS) -- Part 1:
  1450.      Architecture and Basic Multilingual Plane.  JTC1/SC2, 1993.
  1451.  
  1452.  
  1453.  
  1454.  
  1455.  
  1456.  
  1457.  
  1458. Weider, et. al.              Informational                     [Page 26]
  1459.  
  1460. RFC 2130             Character Set Workshop Report            April 1997
  1461.  
  1462.  
  1463. Appendix E:  Recommended reading
  1464.  
  1465. Alvestrand, H., "Tags for the Identification of Languages", RFC 1766,
  1466.      UNINETT, March 1995.
  1467.  
  1468. Alvestrand, H., "X.400 Use of Extended Character Sets", RFC 1502,
  1469.      SINTEF DELAB, August 1993.
  1470.  
  1471. Borenstein, N.,  "Implications of MIME for Internet Mail Gateways",
  1472.      RFC 1344, Bellcore, June 1992.
  1473.  
  1474. Freed, N., and N. Borenstein, "Multipurpose Internet
  1475.      Mail Extensions (MIME) Part One: Format of Internet Message
  1476.      Bodies", RFC 2045, November 1996.
  1477.  
  1478. Chernov, A., "Registration of a Cyrillic Character Set", RFC 1489,
  1479.      RELCOM Development Team, July 1993.
  1480.  
  1481. Choi, U., and K. Chan, "Korean Character Encoding for Internet
  1482.      Messages", RFC 1557, KAIST, December 1993.
  1483.  
  1484. Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions
  1485.      (MIME) Part Two: Media Types", RFC 2046, November 1996.
  1486.  
  1487. Goldsmith, D., and M. Davis, "Transformation Format for Unicode",
  1488.      RFC 1642, Taligent, Inc., July 1994.
  1489.  
  1490. Goldsmith, D., and M. Davis, "Using Unicode with MIME", RFC 1641,
  1491.      Taligent, Inc., July 1994.
  1492.  
  1493. Jerman-Blazic, B. "Character handling in computer communication" in
  1494.      "user needs in information technology standards", Computer Weekly
  1495.      Professional service, eds. C.D. Evans, B.L. Meed & R.S. Walker,
  1496.      P.C. Butterworth Heineman, 1993, Oxford, Boston, p. 102-129.
  1497.  
  1498. Jerman-Blazic, B. "Tool supporting the internationalization of the
  1499.      generic network services", Computer Networks and ISDN Systems,
  1500.      No. 27 (1994), p. 429-435.
  1501.  
  1502. Jerman-Blazic, B., A. Gogala and D. Gabrijelcic, "Transparent language
  1503.      processing: A solution for internationalization of Internet
  1504.      services", The LISA Forum Newsletter, 5 (1996) p. 12-21
  1505.  
  1506. Lee, F., "HZ - A Data Format for Exchanging Files of Arbitrarily Mixed
  1507.      Chinese and ASCII Characters", RFC 1843, Stanford University,
  1508.      August 1995.
  1509.  
  1510.  
  1511.  
  1512.  
  1513.  
  1514. Weider, et. al.              Informational                     [Page 27]
  1515.  
  1516. RFC 2130             Character Set Workshop Report            April 1997
  1517.  
  1518.  
  1519. McCarthy, J., "Arbitrary Character Sets", RFC 373, Stanford
  1520.      University, July 1972.
  1521.  
  1522. Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Two:
  1523.      Message Header Extensions for Non-ASCII Text", RFC 1522,
  1524.      September 1993.  (Obsoleted by RFC 2047.)
  1525.  
  1526. Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three:
  1527.      Message Header Extensions for Non-ASCII Text", RFC 2047,
  1528.      University of Tennessee, November 1996.
  1529.  
  1530. Murai, J., Crispin, M., and E. von der Poel. "Japanese Character
  1531.      Encoding for Internet Messages", RFC 1468, Keio University &
  1532.      Panda Programming, June 1993.
  1533.  
  1534. Nussbacher, H., "Handling of Bi-directional Texts in MIME", Israeli
  1535.      Inter-University, December 1993.
  1536.  
  1537. Nussbacher, H., and Y. Bourvine, "Hebrew Character Encoding for
  1538.      Internet Messages", RFC 1555, Israeli Inter-University and
  1539.      Hebrew University, December 1993.
  1540.  
  1541. Ohta, M., "Character Sets ISO-10646 and ISO-10646-J-1", RFC 1815,
  1542.      Tokyo Institute of Technology, July 1995.
  1543.  
  1544. Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)", STD 9,
  1545.      RFC 959, ISI, October 1985.
  1546.  
  1547. Postel, J., and J. Reynolds, "Telnet Protocol Specification", STD 8,
  1548.      RFC 854, ISI, May 1983.
  1549.  
  1550. Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
  1551.      ISI, October 1994. p.100-117.
  1552.  
  1553. Rose, M., "The Internet Message", Prentice Hall, 1992.
  1554.  
  1555. Simonsen, K., "Character Mnemonics & Character Sets", RFC 1345,
  1556.      Rationel Almen Planlaegning, June 1992.
  1557.  
  1558. Unicode Consortium.  "The Unicode standard, version 2.0.  Reading,
  1559.      Mass.: Addison-Wesley Developers Press, 1996
  1560.  
  1561. Wei, U., et.al.  "ASCII Printable Characters-Based Chinese Character
  1562.      Encoding for Internet Messages", RFC 1842, AsiInfo Services,
  1563.      Inc., et.al.  August 1995.
  1564.  
  1565. Yergeau, F. "UTF-8, a transformation format of Unicode and ISO 10646",
  1566.      RFC 2044, ALIS Technologies, October 1996.
  1567.  
  1568.  
  1569.  
  1570. Weider, et. al.              Informational                     [Page 28]
  1571.  
  1572. RFC 2130             Character Set Workshop Report            April 1997
  1573.  
  1574.  
  1575. Zhu, H., et.al., "Chinese Character Encoding for Internet Messages",
  1576.      RFC 1922, Tsinghua University, et.al., March 1996.
  1577.  
  1578. Appendix F: Workshop attendee list
  1579.  
  1580.    These people were participants on the workshop mailing list.
  1581.    An * indicates that the person attended the workshop in person.
  1582.  
  1583.      Glenn Adams <glenn@spyglass.com>
  1584.    * Joan Aliprand <joan@unicode.org>
  1585.    * Harald Alvestrand <Harald.T.Alvestrand@uninett.no>
  1586.    * Ran Atkinson <ran@cisco.com>
  1587.    * Bert Bos <bert@w3.org>
  1588.    * Brian Carpenter <brian@dxcoms.cern.ch>
  1589.    * Mark Crispin <mrc@panda.com>
  1590.      Makx Dekkers <dekkers@pica.nl>
  1591.      Robert Elz <kre@munnari.oz.au>
  1592.      Patrik Faltstrom <paf@paf.se>
  1593.    * Zhu Haifeng <zhf@net.tsinghua.edu.cn>
  1594.      Keniichi Handa<handa@etl.go.jp>
  1595.      Olle Jarnefors <ojarnef@admin.kth.se>
  1596.      Borka Jerman-Blazic <borka@e5.ijs.si>
  1597.      John Klensin <klensin@mail1.reston.mci.net>
  1598.    * Larry Masinter <masinter@parc.xerox.com>
  1599.    * Rick McGowan <Rick_McGowan@next.com>
  1600.    * Keith Moore <moore+charsets@cs.utk.edu>
  1601.    * Lisa Moore <lisam@vnet.ibm.com>
  1602.      Ruth Moulton <ruth@muswell.demon.co.uk>
  1603.    * Cecilia Preston <cecilia@well.com>
  1604.    * Joyce K. Reynolds <jkrey@isi.edu>
  1605.    * Keld Simonsen <keld@dkuug.dk>
  1606.    * Gary Smith <Gary_Smith@oclc.org>
  1607.    * Peter Svanberg <psv@nada.kth.se>
  1608.    * Chris Weider <cweider@microsoft.com >
  1609.  
  1610.  
  1611.  
  1612.  
  1613.  
  1614.  
  1615.  
  1616.  
  1617.  
  1618.  
  1619.  
  1620.  
  1621.  
  1622.  
  1623.  
  1624.  
  1625.  
  1626. Weider, et. al.              Informational                     [Page 29]
  1627.  
  1628. RFC 2130             Character Set Workshop Report            April 1997
  1629.  
  1630.  
  1631. Appendix G: Authors' Addresses
  1632.  
  1633.    Chris Weider
  1634.    Microsoft Corp.
  1635.    1 Microsoft Way
  1636.    Redmond, WA 98052
  1637.    USA
  1638.  
  1639.    EMail: cweider@microsoft.com
  1640.  
  1641.  
  1642.    Cecilia Preston
  1643.    Preston & Lynch
  1644.    PO Box 8310
  1645.    Emeryville, CA 94662
  1646.    USA
  1647.  
  1648.    EMail: cecilia@well.com
  1649.  
  1650.  
  1651.    Keld Simonsen
  1652.    DKUUG
  1653.    Freubjergvey 3
  1654.    DK-2100 Kxbenhavn X
  1655.    Danmark
  1656.  
  1657.    EMail: Keld@dkuug.dk
  1658.  
  1659.  
  1660.    Harald T. Alvestrand
  1661.    UNINETT
  1662.    P.O.Box 6883 Elgeseter
  1663.    N-7002 TRONDHEIM
  1664.    NORWAY
  1665.  
  1666.    EMail: Harald.T.Alvestrand@uninett.no
  1667.  
  1668.  
  1669.    Randall Atkinson
  1670.    cisco Systems
  1671.    170 West Tasman Drive
  1672.    San Jose, CA 95134-1706
  1673.    USA
  1674.  
  1675.    EMail: rja@cisco.com
  1676.  
  1677.  
  1678.  
  1679.  
  1680.  
  1681.  
  1682. Weider, et. al.              Informational                     [Page 30]
  1683.  
  1684. RFC 2130             Character Set Workshop Report            April 1997
  1685.  
  1686.  
  1687.    Mark Crispin
  1688.    Networks & Distributed Computing
  1689.    University of Washington
  1690.    4545 15th Avenue NE
  1691.    Seattle, WA  98105-4527
  1692.    USA
  1693.  
  1694.    EMail: mrc@cac.washington.edu
  1695.  
  1696.  
  1697.    Peter Svanberg
  1698.    Dept. of Numberical Analysis and Computing Science (Nada)
  1699.    Royal Institute of Technology
  1700.    SE-100 44 STOCKHOLM
  1701.    SWEDEN
  1702.  
  1703.    EMail: psv@nada.kth.se
  1704.  
  1705.  
  1706.  
  1707.  
  1708.  
  1709.  
  1710.  
  1711.  
  1712.  
  1713.  
  1714.  
  1715.  
  1716.  
  1717.  
  1718.  
  1719.  
  1720.  
  1721.  
  1722.  
  1723.  
  1724.  
  1725.  
  1726.  
  1727.  
  1728.  
  1729.  
  1730.  
  1731.  
  1732.  
  1733.  
  1734.  
  1735.  
  1736.  
  1737.  
  1738. Weider, et. al.              Informational                     [Page 31]
  1739.  
  1740.