[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 draft-iab-rfc-nonascii

Network Working Group                                        H. Flanagan
Internet-Draft                                                RFC Editor
Intended status: Informational                         February 14, 2014
Expires: August 18, 2014


                The Use of Non-ASCII Characters in RFCs
                       draft-flanagan-nonascii-00

Abstract

   This document lays out the requirements regarding the use of non-
   ASCII characters in RFCs.  It includes examples for the different
   sections of an RFC.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 18, 2014.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.





Flanagan                 Expires August 18, 2014                [Page 1]


Internet-Draft               Non-ASCII RFCs                February 2014


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Basic requirements  . . . . . . . . . . . . . . . . . . . . .   2
   3.  Rules for the use of non-ASCII characters . . . . . . . . . .   3
     3.1.  General usage throughout a document . . . . . . . . . . .   3
     3.2.  Author Names  . . . . . . . . . . . . . . . . . . . . . .   3
     3.3.  Body of the document  . . . . . . . . . . . . . . . . . .   4
     3.4.  Tables  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.5.  Code components . . . . . . . . . . . . . . . . . . . . .   5
     3.6.  Bibliographic text  . . . . . . . . . . . . . . . . . . .   5
     3.7.  Keywords  . . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Normalization Forms . . . . . . . . . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   6.  Internationalization Considerations . . . . . . . . . . . . .   6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
   10. Informative References  . . . . . . . . . . . . . . . . . . .   7
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   For much of the history of the RFC Series, the character encoding
   used has been US-ASCII [ASCII].  This was a sensible choice at the
   time: the language of the Series is English, a language which only
   uses US-ASCII-encoded characters (ignoring for a moment words
   borrowed from more richly decorated alphabets).  US-ASCII is the
   "lowest common denominator" for character encoding, making cross-
   platform viewing trivial.

   There are limits to US-ASCII, however, which hinder its continued use
   as the exclusive character encoding for the Series.  The increasing
   need for easily readable, internationalized content suggests it is
   time to allow non-ASCII characters in RFCs where necessary.  Given
   the continuing goal of maximum readability across platforms, the use
   of non-ASCII should not be gratuitous in a document.  This RFC
   describes the rules under which non-ASCII characters may be used in
   an RFC.  These rules will be applied as the necessary changes are
   made to submission checking and editorial tools.

2.  Basic requirements

   Three fundamental requirements inform the guidance and examples
   provided in this document.  They are:





Flanagan                 Expires August 18, 2014                [Page 2]


Internet-Draft               Non-ASCII RFCs                February 2014


   o  Searches of an index need to be able to find multiple ways of
      writing an author's name;

   o  People whose system does not have the fonts needed to display a
      particular RFC need to be able to read the non-canonical HTML,
      text, or PDF RFC correctly.

3.  Rules for the use of non-ASCII characters

3.1.  General usage throughout a document

   The mention, as opposed to the use, of non-ASCII characters requires
   the use of Unicode identifiers.  Including non-ASCII characters in
   the text is encouraged to make the mention clearer to readers with
   devices that can render the non-ASCII text.  Including Unicode
   character names is allowed.

   The distinction is between an occasion in which a word appears in a
   sentence in order to convey the meaning of that word (use), and an
   occasion in which a word appears in order to make some point about
   that word itself (mention).

   Spelling for words commonly used in the English language will follow
   the guidance in the Mirriam-Webster dictionary.  Other uses,
   including archaic or untraditional spellings, are not allowed.

   Example:

   Use:

    SIP/2.0 200 = 2**3 * 5**2 но сто девяносто девять - простое
    Via: SIP/2.0/UDP 192.0.2.198;branch=z9hG4bK1324923
    Call-ID: unreason.1234ksdfak3j2erwedfsASdf
    CSeq: 35 INVITE
    From: sip:user@example.com;tag=11141343
    To: sip:user@example.edu;tag=2229
    Content-Length: 154
    Content-Type: application/sdp

   Mention:

    For example, the characters "ᏚᎢᎵᎬᎢᎬᏒ" (U+13DA U+13A2 U+13B5
    U+13AC U+13A2 U+13AC U+13D2) from the Cherokee block look
    similar to the ASCII characters "STPETER" as they might look
    when presented using a "creative" font family.

3.2.  Author Names




Flanagan                 Expires August 18, 2014                [Page 3]


Internet-Draft               Non-ASCII RFCs                February 2014


   Valid Unicode is required, and for non-ASCII names, an ASCII-only
   identifier is required.

   Example for the header:

   Network Working Group L. Daigle Request for Comments: 2611 Thinking
   Cat Enterprises BCP: 33 D. van Gulik Category: Best Current Practice
   ISIS/CEO, JRC Ispra R. Iannella DSTC Pty Ltd P. Faeltstroem (P.
   Faltstrom) Tele2/Swipnet June 1999

   Example for the Acknowledgements: OLD: The following people
   contributed significant text to early versions of this draft: Patrik
   Faltstrom, William Chan, and Fred Baker.

    PROPOSED/NEW:
    The following people contributed significant text to early
    versions of this draft: Patrik Faeltstroem (Patrik Faltstrom),
    陈智昌 (William Chan), and Fred Baker.

3.3.  Body of the document

   Non-ASCII characters may be used only where necessary to clearly
   express the intended meaning of the text.  When such characters are
   mentioned in the text, the following rules apply:

   o  Non-ASCII characters will require identifying the codepoint (e.g.
      U+0394)

   o  Use of the actual UTF-8 character (e.g., Δ) is encouraged so
      that a reader can more easily see what the character is, if their
      device can render the text.

   o  If preferred by the author(s), the use of the official character
      names like "Greek Capital Letter Delta" is allowed.

   Examples:

       OLD (draft-ietf-precis-framework):
       However, the problem is made more serious by introducing the
       full range of Unicode code points into protocol strings. For
       example, the characters U+13DA U+13A2 U+13B5 U+13AC U+13A2
       U+13AC U+13D2 from the Cherokee block look similar to the
       ASCII characters "STPETER" as they might look when presented
       using a "creative" font family.

       NEW/ALLOWED:
       However, the problem is made more serious by introducing the
       full range of Unicode code points into protocol strings. For



Flanagan                 Expires August 18, 2014                [Page 4]


Internet-Draft               Non-ASCII RFCs                February 2014


       example, the characters U+13DA U+13A2 U+13B5 U+13AC U+13A2
       U+13AC U+13D2 (ᏚᎢᎵᎬᎢᎬᏒ) from the Cherokee block look similar
       to the ASCII characters "STPETER" as they might look when
       presented using a "creative" font family.

       ALSO ACCEPTABLE:
       However, the problem is made more serious by introducing the
       full range of Unicode code points into protocol strings. For
       example, the characters "ᏚᎢᎵᎬᎢᎬᏒ" (U+13DA U+13A2 U+13B5 U+13AC
       U+13A2 U+13AC U+13D2) from the Cherokee block look similar to
       the ASCII characters "STPETER" as they might look when
       presented using a "creative" font family.

3.4.  Tables

   Tables follow the same rules for identifiers and characters as the
   body.  If it is sensible (i.e., more understandable for a reader) for
   a given document to have two tables, one including the identifiers
   and characters, one with just the characters, that will be allowed on
   a case by case basis.

   Example: TBD

3.5.  Code components

   Use the U+ notation except within a code component where you must
   follow the rules of the programming language in which you are writing
   the code

   Example:

   TBD

3.6.  Bibliographic text

   The reference entry must be in English; whatever subfields are
   present must be available in ASCII.  As long as good sense is used,
   they may also include non-ASCII characters at author discretion.
   This applies to both normative and informative references.

   Example: [GOST3410]  "Information technology.  Cryptographic data
   security.  Signature and verification processes of [electronic]
   digital signature.", GOST R 34.10-2001, Gosudarstvennyi Standard of
   Russian Federation, Government Committee of Russia for Standards,
   2001.  (In Russian)

   Allowable addition to the above citation "Инф&#1086
   ;рмационна&#110



Flanagan                 Expires August 18, 2014                [Page 5]


Internet-Draft               Non-ASCII RFCs                February 2014


   3; технологи&#1
   103;. Криптогра
   фическая
   защита инф&#108
   6;рмации.
   Процессы ф&#108
   6;рмировани&#11
   03; и проверки
   электронн&#1086
   ;й цифровой
   подписи ", GOST R
   34.10-2001, Государс&
   #1090;венный
   стандарт Р&#108
   6;ссийской
   Федерации,
   2001.

3.7.  Keywords

   Keywords must be US-ASCII only.

4.  Normalization Forms

   If the normalization matters to the content, the authors must submit
   in a normalization-resistant form.  In other words, authors should
   not expect normalization forms to be preserved.

5.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.

6.  Internationalization Considerations

   TBD

7.  Security Considerations

8.  Acknowledgements

   With many thanks to the members of the IAB i18n program.

9.  Normative References





Flanagan                 Expires August 18, 2014                [Page 6]


Internet-Draft               Non-ASCII RFCs                February 2014


10.  Informative References

   [ASCII]  American National Standard for Information Systems - Coded
   Character Sets - 7-Bit American National Standard Code for
   Information Interchange (7-Bit ASCII), ANSI X3.4- 1986, American
   National Standards Institute, Inc., March 26, 1986.

11.  References

Author's Address

   Heather Flanagan
   RFC Editor

   Email: rse@rfc-editor.org




































Flanagan                 Expires August 18, 2014                [Page 7]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/