Subject: [EAI] [eai] rfc5335bis #9 (new): POLL: new text in Introduction in RFC5335bis to replace the original

From: "eai issue tracker" <[email-masked]>
Date: Fri, 18 Feb 2011 05:36:18 -0000

#9: POLL: new text in Introduction in RFC5335bis to replace the original

 POLL: Is the new text in Introduction section in RFC5335bis good to
 replace
 the original?

 new text
 --------
 1.  Introduction

    Internet mail distinguishes a message from its transport and further
    divides a message between a header and a body [RFC5598].  Internet
    mail header fields contain a variety of strings that are intended to
    be user-visible.  The range of supported characters for these strings
    was originally limited to a subset of [ASCII]; globalization of the
    Internet requires support of the much larger set contained in UTF-8
    [RFC5198].  Complex encoding alternatives to UTF-8, as an overlay to
    the existing ASCII base, would introduce inefficiencies as well as
    opportunities for processing errors.  Native support for UTF-8
    encoding [RFC3629] is widely available among systems now used over
    the Internet.  Hence supporting this encoding directly within email
    is desired.  This document specifies an enhancement to Internet mail
    that permits the use of UTF-8 encoding, rather than only ASCII, as
    the base form for header fields.

    This specification is based on a model of native, end-to-end support
    for UTF-8, which uses an "8-bit clean" environment .  Support for
    carriage across legacy, 7-bit infrastructure and for processing by
    7-bit receivers requires additional mechanisms that are not provided
    by this specification.
 --------

 original text
 --------

 1.1.  Role of This Specification

    Full internationalization of electronic mail requires several
    capabilities:

    o  The capability to transmit non-ASCII content, provided for as part
       of the basic MIME specification [RFC2045], [RFC2046].

    o  The capability to use international characters in envelope
       addresses, discussed in [I-D.ietf-eai-frmwrk-4952bis] and
       specified in [I-D.ietf-eai-rfc5336bis].

    o  The capability to express those addresses, and information related
       to them and based on them, in mail header fields, defined in this
       document.

    This document specifies a variant of Internet mail that permits the
    use of Unicode encoded in UTF-8 [RFC3629], rather than ASCII, as the
    base form for Internet email header fields.  This form is permitted
    in transmission, if authorized by the SMTP extension specified in
    [I-D.ietf-eai-rfc5336bis] or by other transport mechanisms capable of
    processing it.

 --------

-- 
----------------------------------+-----------------------------------------
 Reporter:  jyee@…                |       Owner:      
     Type:  state                 |      Status:  new 
 Priority:  major                 |   Milestone:      
Component:  rfc5335bis            |     Version:      
 Severity:  Active WG Document    |    Keywords:  poll
----------------------------------+-----------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/eai/trac/ticket/9>
eai <http://tools.ietf.org/wg/eai/>

---

From: [email-masked]
Date: Sat, 19 Feb 2011 18:09:03 -0800 (PST)

>  POLL: Is the new text in Introduction section in RFC5335bis good to

I'm sorry to have to say it, but in this case the old text is actually
considerably better. The new text has all of the sae problems as the proposed
new abstract text - in particular it fails to mention envelope address fields -
but here it's worse. It's essentialt that the introduction state exactly what
parts of the syntax of messages are being changed. The old text did that, the
new text does not.

I strongly recommend going back to the original text and if necessary tweaking
the terminology it uses.

				Ned

> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ima