<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!--
    <!ENTITY bibxml2rfc-informative SYSTEM "draft-sullivan-rfc2277-bis-00.xml-informative">
    <!ENTITY bibxml2rfc-normative SYSTEM "draft-sullivan-rfc2277-bis-00.xml-normative">
   -->
    <!ENTITY iso10646 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml2/reference.ISO.10646-1.1993.xml'>
    <!ENTITY rfc1033 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1033.xml'>
    <!ENTITY rfc1034 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml'>
    <!ENTITY rfc2026 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2026.xml'>
    <!ENTITY rfc2119 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
    <!ENTITY rfc2130 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2130.xml'>
    <!ENTITY rfc2181 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2181.xml'>
    <!ENTITY rfc2277 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2277.xml'>
    <!ENTITY rfc3629 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml'>
    <!ENTITY rfc5646 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5646.xml'>
    <!ENTITY rfc5198 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5198.xml'>
    <!ENTITY rfc5321 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5321.xml'>
    <!ENTITY rfc5890 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5890.xml'>
    <!ENTITY rfc5891 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5891.xml'>
    <!ENTITY rfc5892 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5892.xml'>
    <!ENTITY rfc5893 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5893.xml'>
    <!ENTITY rfc5894 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5894.xml'>
    <!ENTITY rfc5895 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5895.xml'>
    <!ENTITY rfc6055 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6055.xml'>
    <!ENTITY rfc6365 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6365.xml'>
    <!ENTITY rfc6943 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6943.xml'>
    <!ENTITY rfc6762 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6762.xml'>
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<!-- NOTE: you need ekr's bibxml2rfc to use this XML file. -->


<!-- processing instructions (for a complete list and description,
     see file http://xml.resource.org/authoring/README.html -->

    <!-- try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict="yes" ?>

    <!-- items used when reviewing the document -->
<?rfc comments="yes" ?>  <!-- controls display of <cref> elements -->
<?rfc inline="yes" ?>    <!-- when no, put comments at end in comments section,
                                otherwise, put inline -->
<?rfc editing="no" ?>   <!-- when yes, insert editing marks -->

    <!-- create table of contents (set it options).  
         Note the table of contents may be omitted
         for very short documents --> 
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>

    <!-- choose the options for the references. Some like
         symbolic tags in the references (and citations)
         and others prefer numbers. --> 
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>

    <!-- these two save paper: start new paragraphs from the same page etc. -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- end of list of processing instructions -->

    <!-- Information about the document.
         categories values: std, bcp, info, exp, and historic
         For Internet-Drafts, specify attribute "ipr".
         (ipr values are: full3667, noModification3667, noDerivatives3667),
         Also for Internet-Drafts, can specify values for
         attributes "iprExtract", and "docName".  Note
         that the value for iprExtract is the anchor attribute
         value of a section that can be extracted, and is only
         useful when the value of "ipr" is not "full3667". -->
    <!-- TODO: verify which attributes are specified only
            by the RFC editor.  It appears that attributes
            "number", "obsoletes", "updates", and "seriesNo"
            are specified by the RFC editor (and not by
            the document author). -->
<rfc
    category="bcp"
    ipr="trust200902"
    docName="draft-sullivan-rfc2277-bis-00" >


<front>
    <title abbrev="Charset Policy">IETF Policy on Character Sets and Languages</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->
    <author
        fullname="Andrew Sullivan" 
        initials="A. J." 
        surname="Sullivan">

    <!-- abbrev not needed but can be used for the header
         if the full organization name is too long -->
        <organization abbrev="Dyn">Dyn</organization>
        <address>
            <postal>
                <street>150 Dow St.</street>
                <city>Manchester</city>
                <region>NH</region>
                <code>03101</code>
                <country>U.S.A.</country>
            </postal>
        <email>asullivan@dyn.com</email>
        </address>
    </author>

    <author fullname="Dave Thaler" initials="D." surname="Thaler">
      <organization abbrev="Microsoft">Microsoft
      Corporation</organization>
      <address>
	<postal>
	  <street>One Microsoft Way</street>
	  <city>Redmonad</city> <region>WA</region>
	  <code>98052</code>
	  <country>USA</country>
	</postal>
	<phone>+1 425 703 8835</phone>
	<email>dthaler@microsoft.com</email>
      </address>
    </author>

    <author fullname="John C Klensin" initials="J.C."
surname="Klensin">
      <organization/>
      <address>
        <postal>
          <street>1770 Massachusetts Ave, Ste 322</street>
          <city>Cambridge</city> <region>MA</region>
          <code>02140</code>
          <country>USA</country>
        </postal>       <phone>+1 617 245 1457</phone>
        <email>john-ietf@jck.com</email>
      </address>
    </author>


    <date /> <!-- month="May" is no longer necessary
                                          note also, day="30" is optional -->

<!--    <area>Internet</area> -->

    <!-- WG name at the upperleft corner of the doc,
         IETF fine for individual submissions -->
    <workgroup>IETF</workgroup>
    <abstract>
    <t>This is a proposed new policy for the IETF on Character Sets and Languages.
    </t>
    </abstract>


</front>

<middle>
  <section title="Introduction" anchor="sec_introduction">
    <t>The Internet is international.</t>

    <t>With the international Internet follows an absolute requirement
    to interchange data in a multiplicity of languages, which in turn
    utilize a bewildering number of characters.</t>

    <t>The document is very much based upon RFC 2277 <xref
    target="RFC2277" /> which is the current policy being applied by the
    Internet Engineering Steering Group (IESG) towards the
    standardization efforts in the Internet Engineering Task Force
    (IETF) in order to help Internet protocols fulfill these
    requirements.</t>

    <t>RFC 2277 in turn was based on the recommendations
    of the IAB Character Set Workshop of February 29-March 1, 1996,
    which is documented in RFC 2130 <xref target="RFC2130" />.  This
    document is a proposed replacement for RFC 2277 and 
    attempts to be explicit and clear, and as concise as
    possible without leaving out necessary detail.<cref
    source="ajs@anvilwalrusden.com">What other references do we want
    to add?</cref></t>

    <section title="Terminology" anchor="sec_term">
      <t>This document uses the terms "character", "charset", "coded
      character set", "language", "locale", and "protocol elements" as
      defined in RFC 6365 <xref target="RFC6365" />.  IDNA terminology
      is defined in RFC 5890 <xref target="RFC5890" />.  Any of those
      definitions may be used below, and the reader is expected to be
      familiar with them.  <cref source="dthaler@microsoft.com">That
      last sentence makes this document much less accessible.  I think
      at a minimum we need to list which terms used in this document
      are defined in each other RFC.  I've now added a list above for
      6365, but it may be missing some and the list of terms used from
      5890 is needed.</cref><cref source="ajs@anvilwalrusden.com">This
      is fair.  I suggest we leave this as is and do an exhaustive
      pass for terminology later and updates these lists.</cref></t>

      <t>This document uses the terms 'MUST', 'SHOULD' and 'MAY', and
      their negatives, in the way described in RFC 2119 <xref
      target="RFC2119" />.  In this case, 'the specification' as used
      by RFC 2119 refers to the processing of protocols being
      submitted to the IETF standards process.</t>
    </section>

  </section>

  <section title="Where to do internationalization" anchor="sec_where">
    <t>Internationalization is necessary because of the way natural
    language is written.  It enables localization, which is for
    humans. This means that protocols are not subject to
    internationalization; text strings are.  Where protocol elements
    look like text tokens, such as in many IETF application layer
    protocols, protocols MUST specify which parts are protocol and
    which are text (see Section 2.2.1.1 of <xref target="RFC2130"
    />).</t>

    <t>It is helpful to distinguish among four different types of
    strings for these purposes: domain names whether in the DNS or not,
    other protocol elements that are not normally visible to users,
    other protocol elements that are (even sometimes) normally visible
    to users, and data (in most cases, the protocol payload).</t>

    <section title="Domain names" anchor="sec_dns">
      <t>Domain names (or strings of domain-name-like things) are used
      in a number of protocols, and not all of those names are
      intended to be looked up in the DNS.  This raises a number of
      issues explored at length in <xref target="RFC6055" />.</t>

      <t>Given this state of affairs, it is possible to recommend the
      following.  These recommendations are consistent with RFC 6055:</t>
      <t><list style="symbols">
      <t>At resolution time, names that are to be looked up in the
      global DNS SHOULD be transmitted as A-labels.</t>
      <t>At resolution time, names that are not to be looked up in the
      global DNS ought to be transmitted in the form appropriate to
      the name resolution protocol.  This is often UTF-8.</t>
      <t>Storage of internationalized domain names ought generally
         to be in the form of U-labels.</t>
      <t>Any protocol that needs to use domain names ought to use
         U-labels or A-labels consistently, and ought to prefer U-labels.</t>
      <t>Storage of U-labels (or putative U-labels) should be in the
         encoding form appropriate to the context.  For instance, on a
         system that normally encodes UTF-8 using NFD, that is how the
         strings should be stored; similarly, a system that uses UTF-16
         should store the strings in that form.</t>
      </list>
      <cref source="ajs@anvilwalrusden.com">This in the end
      will need to be checked carefully for its consistency with 6055.</cref></t>
    </section>

    <section title='Non-DNS, "invisible" protocol elements'
         anchor='sec_non_dns_inviz'>
      <t>Many protocols include elements that are either words or
      word-like in some natural language (usually English), but that are
      never exposed to users under normal circumstances.  Users might
      encounter these protocol elements in log messages and so on, and
      system administrators might regularly encounter them as part of
      the ordinary support burden.  But these elements are no more
      candidates for internationalization than are hexadecimal protocol
      parameters.  Because they are not intended for user consumption,
      they should not be treated as any part of a user interface.
      Internationalization considerations do not apply to them.</t>
      
      <t>It is important to recognize that some of this class of
      protocol element sometimes appears to be exposed to users -- for
      instance, many user agents for mail display headers.  In these
      cases, it is important to distinguish between the protocol
      element itself, and the user cues it may provide.  The protocol
      element does not need to be internationalized.  The user
      interface might.  In general, it is best to internationalize (or
      localize) strings that are encountered by the user and to keep
      those that are passed between computer systems and interpreted
      by them as simple and unambiguous as possible.  Even for names or
      strings that provide the underpinnings for the strings that
      users type or with which they interact, it is important to keep
      their forms as simple as possible.  Examples of such strings
      include the results of a search or material that must be
      translated into several different languages.
     </t>
    </section>

    <section title='Non-DNS, "visible" protocol elements'
         anchor='sec_non_dns_viz'> 
      <t>Sometimes, protocol elements are expected to be visible or,
      as likely, manipulable by users.  <cref
      source="ajs@anvilwalrusden.com">Sorry, the following bit needs
      some more references, which I've failed to get right in the
      interests of expediency.  This is here to remind me.</cref> For
      instance, many values of SMTP <xref target="RFC5321" /> commands
      are parts of mail addresses that users are expected to type.  In
      the presence of EAI, those addresses may well be
      internationalized.</t>

      <t>In general, there are two ways to handle these sorts of
      strings.  One is to use an ASCII-compatible encoding in the way
      that IDNA does.  Another is to internationalize the protocol.
      If an internationalized protocol is to be undertaken, agility
      among coded character sets appears to cause more problems than
      it solves.  Therefore, for the purposes of transmission, it is
      best to transmit protocol elements as UTF-8 strings in
      "Net-Unicode" <xref target="RFC5198" /> form, with an
      appropriate profile.  All ASCII-only strings meet this
      criterion.  <cref source="ajs@anvilwalrusden">Maybe the profile
      stuff needs to refer to PRECIS anyway.</cref></t>

      <t>Merely requiring Net-Unicode is not enough.  The PRECIS
      working group documents outline a number of considerations for
      how protocol elements and data need to be handled in the face of
      internationalization concerns.  These kinds of considerations
      are especially important for protocol elements that may be
      influenced by user action.  For instance, if comparisons are to
      be used, good PRECIS profiles for those elements are
      critical.</t>

      <t>In the design of protocols for use on the Internet (or in
      other communications systems) that use textual keywords, there
      is a tradeoff between strings that have high mnemonic value
      (i.e., the identifiers are easily remembered by those who will
      use them) in local environments and those that are easily
      recognized and used internationally. Most cases are (and should
      be) resolved in favor of the latter, because these are strings
      used in protocols, a single set can easily be translated, and
      because it is possible to choose a single well-known script with
      good properties for those strings. But there are cases when
      other considerations are more important and each case and
      protocol should be carefully and separately considered.  <cref
      source="ajs@anvilwalrusden.com">I think I'd remove the last of
      those sentences unless we want to say when.</cref></t>
      

    </section>

    <section title="Protocol data" anchor="sec_proto_data">
      <t>Protocol data is very frequently user visible, and to the
      extent there are highly variable internationalization
      principles, they appear more commonly here.</t>

      <t>In general, protocol data needs to carry an indicator of its
      coded character set.  A protocol MUST identify, for all
      character data, which coded character set is in use.  Protocols
      MUST be able to use UTF-8.  New protocols SHOULD use UTF-8, and
      UTF-8 only, unless strong motivation is given for exceptions.
      The identification methods discussed in this section are for use
      with legacy protocols and situations.</t>
    
      <t>NOTE: In the protocol stack for any given application, there is
      usually one or a few layers that need to address these problems.</t>

      <t>It would, for instance, not be appropriate to define language
      tags for Ethernet frames. It is the responsibility of protocol
      designers to ensure that whenever responsibility for
      internationalization is left to "another layer", those responsible
      for that layer are in fact aware that they have that
      responsibility.  The precis framework provides more
      guidance. <cref source="ajs">Surely this is too hand-wavy?  Should
      we refer to particular bits?</cref></t>
    </section>
  </section>

  <section title="General charset policy"
       anchor="sec_charser_pol">
    <t>The general policy of the IETF is that all data should be
    transmitted on the wire as UTF-8.  Any protocol that does not
    conform to this policy but that is intended for the IETF standards
    track MUST justify it to the IETF.</t>

    <t>When the protocol allows a choice of multiple charsets,
    someone must make a decision on which charset to use.</t>
    
    <t>In some cases, like HTTP, there is direct or semi-direct
    communication between the producer and the consumer of data
    containing text. In such cases, it may make sense to negotiate a
    charset before sending data.</t>
    
    <t>In other cases, like E-mail or stored data, there is no such
    communication, and the best one can do is to make sure the
    charset is clearly identified with the stored data, and choosing
    a charset that is as widely known as possible.</t>
    
    <t>Note that a charset is an absolute; text that is encoded in a
    charset cannot be rendered comprehensibly without supporting
    that charset.  This also applies to English texts; charsets like
    EBCDIC do NOT have ASCII as a proper subset.</t>
    
    <t>Negotiating a charset may be regarded as an interim mechanism
    that is to be supported until support for interchange of UTF-8
    is prevalent.  Despite the wide adoption of Unicode and UTF-8,
    the timeframe of "interim" may remain long, though perhaps not permanent.</t>
  </section>

  <section title="Languages" anchor="sec_lang">
    <section title="The need for language information"
         anchor="sec_need_lang">
<!--original section 4.1-->
      <t>All human-readable text has a language.</t>

      <t>Many operations, including high quality formatting,
      text-to-speech synthesis, searching, hyphenation, spellchecking
      and so on benefit greatly from, or are all but impossible
      without, access to information about the language of a piece of
      text (Section 3.1.1.4 of <xref target="RFC2130" />).</t>

      <t>Humans have some tolerance for foreign languages, but are
      generally very unhappy with being presented text in a language
      they do not understand; this is why negotiation, or at least
      negotiation, of language is needed.</t>

      <t>In most cases, machines will not be able to deduce the
      language of a transmitted text by themselves; the protocol must
      specify how to transfer the language information if it is to be
      available at all.  It is sometimes possible to guess the langage
      of a block of text, but such guessing is usually unreliable and
      becomes dramatically less reliable the shorter the block of
      text.</t>

<!-- Going to remove this.  It is in 2277 but I do not understand it
and others do not either.
      <t>The interaction between language and processing is complex;
      for instance, if I compare "name-of-thing(lang=en)" to "name-of-
      thing(lang=no)" for equality, I will generally expect a match,
      while the word "ask(no)" is a kind of tree, and is hardly useful
      as a command verb.</t>-->
    </section>

    <section title="Requirement for language tagging"
         anchor="sec_req_langtag">
      <t>Protocols that transfer text MUST provide for carrying
      information about the language of that text.</t>

      <t>Protocols SHOULD also provide for carrying language
      information about visible protocol elements (especially if they
      are names), where appropriate.</t>

      <t>Note that this does not mean that such information must
      always be present; the requirement is that if the sender of
      information wishes to send information about the language of a
      text, the protocol provides a well-defined way to carry this
      information.  Nevertheless, if the data originator does not
      supply that information, it is generally impossible to make it
      up later.</t>
    </section>

    <section title="How to identify a language" anchor="sec_id_lang">
      <t>The language tag <xref target="RFC5646" /> is at the moment
      the most flexible tool available for identifying a language;
      protocols SHOULD use this, or provide clear and solid
      justification for doing otherwise in the document.  Language
      tags are in general not useful without profiling appropriate to
      the case, and there is significant danger of over-specification
      with tags.  See Section 4.1 of RFC 5646.</t>

      <t>Note also that a language is distinct from a POSIX locale
      (see <xref target="sec_locale" />); a POSIX locale identifies a
      set of cultural conventions, which may imply a language (the
      "POSIX" and "C" locales of course do not), while a language tag
      identifies only a language.</t>
    </section>

    <section title="Considerations for language negotiation" anchor="sec_lang_neg">

      <t>Protocols where users have text presented to them in response
      to user actions MUST provide for support of multiple languages.</t>
      
      <t>How this is done will vary between protocols; for instance,
      in some cases, a negotiation where the client proposes a set of
      languages and the server replies with one is appropriate; in
      other cases, a server may choose to send multiple variants of a
      text and let the client pick which one to display.</t>

      <t>Negotiation is useful in the case where one side of the
      protocol exchange is able to present text in multiple languages
      to the other side, and the other side has a preference for one
      of these; the most common example is the text part of error
      responses, or Web pages that are available in multiple
      languages.</t>

      <t>Users do not, of course, actually use protocols, but instead
      user interfaces that in turn use the protocols.  Therefore, what
      is necessary to support is not the full internationalization of
      everything in the protocol, but enough that the user-visible
      components can be localized appropriately.  See <xref
      target="sec_non_dns_viz" />.</t>

      <t>Negotiating a language should be regarded as a permanent
      requirement of the protocol that will not go away at any time in
      the future.</t>

      <t>In many cases, it should be possible to include it as part of
      the connection establishment, together with authentication and
      other preferences negotiation.</t>
    </section>

    <section title="Default language" anchor="sec_default">
      <t>For the purposes of display, it may be necessary to pick a
      default language to use when it is not possible to determine the
      language.  It is evident that picking a default may lead to user
      dissatisfaction or confusion, but when language cannot be
      determined such fallbacks may be necessary.</t>

      <t>Section 4.1 of <xref target="RFC5646" />, numbers 5 and 7,
      outline the considerations for language identification when the
      language cannot be determined.</t>

    </section>
  </section>
  
  <section title="Locale" anchor="sec_locale">
    <t>The POSIX standard <xref target="ISO.9945-2.1993"/> defines a concept
    called a "locale", which includes a lot of information about
    collating order for sorting, date format, currency format and so
    on.</t>

    <t>In some cases, and especially with text where the user is
    expected to do processing on the text, locale information may be
    usefully attached to the text; this would identify the sender's
    opinion about appropriate rules to follow when processing the
    document, which the recipient may choose to agree with or ignore.</t>

    <t>This document does not require the communication of locale
    information on all text, but encourages its inclusion when
    appropriate.</t>

    <t>Note that language and character set information will often be
    present as parts of a locale tag (such as no_NO.iso-8859-1; the
    language is before the underscore and the character set is after
    the dot); care must be taken to define precisely which
    specification of character set and language applies to any one
    text item.</t>
    
    <t>The default locale is the "POSIX" locale.</t>
  </section>

  <section title="Documenting Internationalization Decisions" anchor="sec_documenting">

    <t>In documents that deal with internationalization issues at all,
    a synopsis of the approaches chosen for internationalization
    SHOULD be collected into a section called "Internationalization
    considerations".  This practice has historically not been followed
    regularly, but it remains a good idea.  The goal is to provide an
    easy reference for those who are looking for advice on these
    issues when implementing the protocol.</t>
  </section>

  <section title="Security Considerations" anchor="sec_security">
    <t>Security warnings in a foreign language may cause inappropriate
       behaviour (such as ignoring the warning entirely) from the user.
    In addition, the issues raised in <xref target="RFC6943" />, especially in
    its section 4.2 and section 5, are of particular relevance to
    internationalization.</t>
  </section>

<section anchor="Acknowledgements" title="Acknowledgements">

  <t>Much of the text comes from <xref target="RFC2277" />.  Harald Alvestrand was the primary author of that RFC.</t>

  <t>Most of the discussion above was initiated as part of the IAB's internationalization program.  At the time of writing, the program members were (in alphabetical order) Marc Blanchet, Stuart Cheshire, Leslie Daigle, Patrik Faltstrom, Heather Flanagan, John Klensin, Olaf Kolkman, Barry Leiba, Xing Li, Pete Resnick, Peter Saint-Andre, Andrew Sullivan, and Dave Thaler.</t>

       <t>Significant text in <xref target="sec_non_dns_inviz" /> and
       <xref target="sec_non_dns_viz" /> was derived from a
       forthcoming Internet Society education module for
       next-generation Internet leaders and future influencers and
       used with permission.  The contributions and support for that
       work of Toral Cowleson and Niel Harper of the Internet Society
       are gratefully acknowledged.</t>

</section>

<section anchor="IANA" title="IANA Considerations">
  <t>This document makes no requests of IANA.</t>
</section>

</middle>
<back>
<!--references split to informative and normative-->
<!--
<references title="Normative References">
    &bibxml2rfc-normative;
</references>
-->
<references title="Informative References">
    <!-- &bibxml2rfc-informative; -->
      <reference anchor="ISO.9945-2.1993">
        <front>
          <title>ISO/IEC 9945-2:1993 Information Technology -- 
                 Portable Operating System Interface (POSIX) -- 
                 Part 2: Shell and Utilities
              </title>
          <author>
            <organization>International Organization for Standardization
            </organization>
          </author>
          <date year="1993"/>
        </front>
        <seriesInfo value="Standard 9945-2" name="ISO"/>
      </reference>

    &iso10646;
    &rfc1033;
    &rfc1034;
    &rfc2026;
    &rfc2119;
    &rfc2130;
    &rfc2181;
    &rfc2277;
    &rfc3629;
    &rfc5646;
    &rfc5198;
    &rfc5321;
    &rfc5890;
    &rfc5891;
    &rfc5892;
    &rfc5893;
    &rfc5894;
    &rfc5895;
    &rfc6055;
    &rfc6365;
    &rfc6943;
    &rfc6762;
</references>

<section title="Version History" anchor="sec_versions">
  <section title="00" anchor="sec_00">
    <t>Initial version.  Contains a number of xml2rfc warnings.</t>
  </section>
</section>

</back>

</rfc>

