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

Versions: 00

Network Working Group                                         J. Klensin
Internet-Draft                                         November 24, 2011
Updates: 2047, 2231 (if approved)
Expires: May 27, 2012


              The "U" Encoding for Encoded-Words in Email
                 draft-klensin-encoded-word-type-u-00

Abstract

   The "Encoded Word" conventions have been used extensively in email
   headers and elsewhere to permit the encoding of non-ASCII characters
   where only ASCII ones are normally permitted.  The existing
   specification defines only two kinds of encoding, one of which cannot
   be understood easily by people and the other of which has been widely
   discredited.  This document specifies a third encoding that is easily
   accessible by users and much more closely tied to contemporary
   practices.

   The current version of the proposal is intended for possible
   discussion in the EAI, IRI, and PRECIS WGs to see if it sheds light
   on other issues being discussed in those WGs.  It is not, at this
   point, proposed for adoption.

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 May 27, 2012.

Copyright Notice

   Copyright (c) 2011 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



Klensin                   Expires May 27, 2012                  [Page 1]


Internet-Draft          Encoded-Words: U Encoding          November 2011


   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.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Updated Specifications  . . . . . . . . . . . . . . . . . . 3
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
     1.3.  Scope and Discussion List . . . . . . . . . . . . . . . . . 4
   2.  Specification . . . . . . . . . . . . . . . . . . . . . . . . . 4
   3.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     5.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
     5.2.  Informative References  . . . . . . . . . . . . . . . . . . 5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 6




























Klensin                   Expires May 27, 2012                  [Page 2]


Internet-Draft          Encoded-Words: U Encoding          November 2011


1.  Introduction

   The "Encoded Word" conventions [RFC2047] have been used extensively
   in email headers and elsewhere to permit the encoding of non-ASCII
   characters where only ASCII ones are normally permitted.  That
   existing encoded-word specification defines only two kinds of
   encoding, one of which cannot be understood easily by people ("B",
   the MIME "Base64" encoding) and the other of which ("Q", so-called
   Quoted Printable) has been widely discredited.  This document
   specifies a third encoding, based on the "\u'NNNN'" convention, that
   is easily accessible by users and much more closely tied to
   contemporary practices.

   Unlike the "B" and "Q" encodings, which were specified at a time when
   many coded character sets were in common use, it is now appropriate
   [RFC5198] to tie a new encoding specifically to Unicode [Unicode] and
   the corresponding ISO Standard [ISO10646], viewing conversion to
   local character sets, if necessary at all, to be a local matter.
   Consequently, this specification permits only the combination "=?iso-
   10646-UCS-4?u?".

   [[anchor2: Note in Draft: If we were really going to do this, it
   would make sense to define a charset that would actually reflect
   Unicode code points, not some encoding of them.  Neither of the
   currently-registered "iso-10646-UCS-4" nor "UTF-32" and its
   variations are quite right for that purpose.  Cf.
   http://www.iana.org/assignments/character-sets]]

   If adopted, it is intended not only as an alternative to "Q" and "B",
   but also as an alternative to the %-encoding of Section 2.1 of the
   URI Specification [RFC3986] of UTF-8 [RFC3629] (and other) strings.
   %-encoding was more than adequate for its original purpose of
   encoding eight-bit character sets, notably ISO 8859-1 [ISO8859-1],
   but is problematic for email (especially addresses and fields related
   to them) because "%" has an important historic (and still
   occasionally used) meaning in those contexts and because its use to
   encode already-encoded forms of multi-octet character sets, such as
   UTF-8 and Unicode, creates strings that are at least as difficult for
   end users to interpret as Base64.

1.1.  Updated Specifications

   This document, if approved, updates the Encoded-Word specification
   [RFC2047] and the specification for the use encoded-words with
   language information [RFC2231] to permit use of an additional
   encoding type, type "U".





Klensin                   Expires May 27, 2012                  [Page 3]


Internet-Draft          Encoded-Words: U Encoding          November 2011


1.2.  Terminology

   Some reasonable understanding of Encoded-Words and the Quoted-
   Printable, Base64, and %-encoding conventions are required to
   understand this introductory material but not the proposal itself.

   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
   in this document are to be interpreted as defined in RFC 2119
   [RFC2119].

1.3.  Scope and Discussion List

   RFC Editor: In the unlikely event that you see this subsection, it
   should be removed before publication.

   The current version of the proposal is intended for possible
   discussion in the EAI, IRI, and PRECIS WGs to see if it sheds light
   on other issues being discussed in those WGs.  If discussions are of
   interest, they should occur on the mailing lists associated with
   those groups.

   This Internet Draft is, at this point, intended only to promote
   discussion of a possibly-useful building block for other work.  It is
   not proposed for adoption by the IETF for any purpose.


2.  Specification

   A new encoding form for encoded words is defined with code "u".  The
   associated encoded-text string is consistent with the rules in
   Section 4 of RFC 2047, i.e., it consists of ASCII characters with
   space, tab, and "?" characters excluded.  Non-ASCII characters are
   encoded using the \u'NNNN' form, where "NNNN" consists of four to six
   hexadecimal digits designating a Unicode (ISO 10646) code point.
   That encoding convention is defined in RFC 5137 [RFC5137] together
   with an explanation of why the quotes should be required.

   As an example, the German equivalent of the string "This is nuts",
   would appear in the extended form of RFC 2231 (updated by verified
   Erratum 478 [RFC2231-Err478]) as
   =?iso-10646-UCS-4+de?u?Das ist verr\u'00FC'ckt?=


3.  Security Considerations

   This specification does not raise any security issues that are not
   already present in RFC 2047 and its various updates.  Because the
   coding is more transparent to the end user than any of Base64, Quoted



Klensin                   Expires May 27, 2012                  [Page 4]


Internet-Draft          Encoded-Words: U Encoding          November 2011


   Printable for non-ASCII text, or %-encoding of UTF-8, it may
   eliminate or reduce one possible attack vector that is present with
   those other approaches.


4.  IANA Considerations

   [[anchor9: RFC Editor: Please remove this section.]]
   Because there does not appear to be a registry for either encoded-
   word encodings or the content-transfer-encodings on which they are
   based, this document requires no actions by the IANA.


5.  References

5.1.  Normative References

   [RFC2047]  Moore, K., "MIME (Multipurpose Internet Mail Extensions)
              Part Three: Message Header Extensions for Non-ASCII Text",
              RFC 2047, November 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2231]  Freed, N. and K. Moore, "MIME Parameter Value and Encoded
              Word Extensions:
              Character Sets, Languages, and Continuations", RFC 2231,
              November 1997.

   [RFC2231-Err478]
              Stedfast, J., "MIME Parameter Value and Encoded Word
              Extensions: Character Sets, Languages, and Continuations,
              Erratum 478", November 2001,
              <http://www.rfc-editor.org./errata_search.php?eid=478>.

   [Unicode]  The Unicode Consortium.  The Unicode Standard, Version
              6.0.0, defined by:, "The Unicode Standard, Version 6.0.0",
              Mountain View, CA: The Unicode Consortium, 2011. ISBN 978-
              1-936213-01-6, 2011,
              <http://www.unicode.org/versions/Unicode6.0.0/>.

5.2.  Informative References

   [ISO10646]
              International Organization for Standardization,
              "Information Technology - Universal Multiple-octet coded
              Character Set (UCS)", ISO Standard 10646:2011, March 2011.




Klensin                   Expires May 27, 2012                  [Page 5]


Internet-Draft          Encoded-Words: U Encoding          November 2011


   [ISO8859-1]
              International Organization for Standardization,
              "Information technology - 8-bit single byte coded graphic
              - character sets - Part 1: Latin alphabet No. 1",
              ISO Standard 8859-1:1998, 1998.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, November 2003.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

   [RFC5137]  Klensin, J., "ASCII Escaping of Unicode Characters",
              BCP 137, RFC 5137, February 2008.

   [RFC5198]  Klensin, J. and M. Padlipsky, "Unicode Format for Network
              Interchange", RFC 5198, March 2008.


Author's Address

   John C Klensin
   1770 Massachusetts Ave, #322
   Cambridge, MA  02140
   USA

   Phone: +1 617 491 5735
   Email: john-ietf@jck.com






















Klensin                   Expires May 27, 2012                  [Page 6]


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