Subject: [EAI] Comments on draft-ietf-eai-utf8headers-01.txt

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 31 Aug 2006 17:21:12 +0100

Only just got around to looking at this in detail.

1.  Introduction

1.1.  Role of this specification

It needs one more bullet such as:

    o  The capability to use international characters in other headers, but  
only
       as expressly permitted herein, or in future extensions.

    ...  This form is permitted in transmission, if authorized
    by the SMTP extension specified in [EAI-SMTP-extension].

Add "or by other transport mechanisms capable of processing it".

[Note that it would already work just fine in UUCP, though care would be  
needed when gatewaying it into SMTP. It would also work fine in NNTP (I  
have heard suggestions that NNTP could be used for email).]

2.  Background and History

    The traditional format of email messages [RFC2822] only allows ASCII ...

s/only allows/allows only/

    that is connected to the SMTP message transport change described in

s/connected/related/

3.  Terminology

    In this document, header fields are "UTF-8 header" if the bodies of

s/"UTF-8 header"/"UTF-8 headers"/

4.  Pre-requirement

    The use of UTF-8 header fields is dependent on the use of an SMTP
    extension named "UTF8SMTP".

Add "or of similar capabilities in other transports".

s/Though there's nothing bad to use [RFC2047], but it is not
    recommended in this document.
   /Although there is nothing wrong with the continued use of [RFC2047],
    it is not recommended in this document./

5.  Identification of internationalized email

    When a SMTP client tries to send a mail to a SMTP server that does
    not support EAI, ...

s/EAI/UTF8SMTP/ here, and everywhere else in the document.

[The term "EAI" is unlikely to be widely understood (except as the name of  
this WG), or to come into widespread use.]

[I am not too happy with the term "UTF8SMTP" either (since other  
tramsports may use this format, and I would have preferred  
"UTF8-headers"). But that is the term we have agreed so far.]

    ... It is nice to have a mechanism ... to identify whether the
    message is new format ...

s/is new format/is in the new format/

    To be able to do so, sending MUA MUST insert a new header field to
    identify the presence of i18n information (particularly UTF-8
    headers) in the message.  The new header specified as "UTF8SMTP", and
    elements of the header is the version number of i18n email.  The i18n
    header field syntax specified as below:

I think the term "UTFSMTP" was intended to be the name of the new format  
(or the name of the capability agents would need in order to process it).  
So I don't think it is suitable as the name of the new header (I have  
suggested something like "Header-Type"). So I would suggest something more  
like:

    fields =/ header-type ; to anchor it into the syntax of RFC 2822

    header-type     = "Header-Type:" [FWS] content-code [FWS]
                      *( ";" parameter ) CRLF
    content-code    = "UTF8SMTP" / "ASCII" / "Downgraded"

And then you have to give semantics:
    "UTF8SMTP" indicates that the message is in the format defined by this
    document;
    "ASCII" indicates that it is in the format defined by RFC 2822 (and is  
the
    default when this header field is absent); and
    "Downgraded" indicates the same as "ASCII", but also that it was earlier
    downgraded from "UTF8SMTP".

BTW, I notice that you have forbidden comments in this header. Why was  
that?

    parameter       = "Header-Language:" [FWS] Language-List
    Language-List   = Language-Tag [FWS]
                      *("," [FWS] Language-Tag [FWS])

Here you have a choice. If you want to indicate the language by means of a  
<parameter>, then that will not work as you have shown it, because  
<parameter> is defined in RFC 2045 as ammended by RFC 2231, and has some  
[CFWS] hidden inside it (not obviously so, because it was defined in terms  
of RFC 822). So what you have written is not syntactically correct. The  
proper way to do it would be to say

    The only <parameter> defined by this document (others may be defined  
later,
    and SHOULD be ignored) is the header-language parameter, which has
       <attribute> "header-language"
       <value>     any <language-list>, where
    language-list   = Language-Tag *("," Language-Tag)

and then you have to point out that if there is more than one  
Language-Tag, the <value> has to be turned into a <quoted-string> because  
"," is a <tspecial> and cannot, therefore, appear in a <token>.

See section 3.2.8 of draft-ietf-usefor-usefor-09 for the correct way to do  
it (at least, we hope it is the correct way). But it all gets rather  
tedious :-( .

Your alternative is to define a new header field, similar to RFC 3282:

       field =/ Header-Language
       Header-Language = "Header-Language" ":" [CFWS] Language-List
       Language-List = Language-Tag [CFWS]
                          *("," [CFWS] Language-Tag [CFWS])

I think that is probably better, as it sits nicely beside the  
Content-Language header. However, you may still want to retain the  
<parameter>s in the Header-Type, just to allow some space for unforeseen  
needs, but with none defined in this document (we also did that in  
draft-ietf-usefor-usefor-09 in the case of the Archive header field).

    While we can't require ordering of headers, ...  Thus, when a i18n  
email is
    delivered.

s/delivered/generated/

    o  The "UTF8SMTP" header field MUST be inserted, along with Return-
       path, by the final delivery MTA if not presented.

s/if not presented/if not already present/

But there is a problem there. How is the final delivewry agent supposed to  
know? You cannot insist on a MUST if there is no obvious way to implement  
it. Scanning the headers looking for 8bit is not enough in the case of  
multipart and message types, which can contain further headers, possibly  
with 8bit in them, within the <body>.

If this situation arises, then there has already been a protocol error. If  
some subsequent agent knows how to recover from it, then good luck to it.  
But you cannot REQUIRE that behaviour.

    o  Whenever the email need to downgrade, the content-code of the
       "UTF8SMTP" MUST change to "Downgraded", the detail of downgrade
       process will describe in [EAI-downgrading].

s/need to downgrade/is downgraded/
s/will describe/will be described/

    o  If more than one "UTF8SMTP" header is presented, MTA SHOULD simply
       ignore any excess ones.

Again, this would be a protocol error (though possibly recoverable if they  
were the same). But RFC 2822 is careful to state which header fields are  
permitted to occur more than once (and there are only a few). Your  
document should say the same about any new header fields that it  
introduces.

6.  Changes on Message Header Fields

    SMTP client can send header fields in UTF-8 format, if the UTF8SMTP
    extension advertised by SMTP server.

Add "or as permitted by other transport mechanisms".

    For those tokens not referred in this section remains as the original
    definition in RFC 2822.

s/tokens/syntax rules/

6.1.  UTF8 Syntax

    These are taken from FRC 3629, but keep in this document for
    convenient reason.

s/keep/kept/
s/convenient reason/reasons of convenience/

6.2.  Syntax extend from RFC 2822

This section is now much improved, and sets the onus on future extensions  
to specify exactly where UTF-8 will be allowed.

6.3.  Change on addr-spec syntax

    alt-address    =  "{" [CFWS] addr-spec [CFWS] "}"

Several problems there.

It is ambiguous, because "{" and "}" are <utf8-atext>s. s/{/[/ and s/}/]/,  
and it will be OK.

I think you want a [CFWS] before the "{" (or "["). But you don't want  
those {CFWS] inside the "{...}", because the <addr-spec> already allows  
them to occur there.

What has happened to "downgradable" (aka "atomic")? I do not recall that  
we ever decided to do away with it. So I would expect to see:

    alt-address    =  [CFWS] "{" ( addr-spec / "downgradable" ) "}"

       "DISPLAY_NAME" <ASCII@ASCII>
          ; tradition mailbox format

s/tradition/traditional/

6.4.  Trace field syntax

    ... More
    generally, UTF-8 information of any sort MUST NOT appear in Received
    fields, even in comments within those fields.

Did we actually decide that? Chris Newman had a nice scheme for hiding  
"For" fields inside <comment>s.

7.1.  Mailing list header fields

    All mailing list and mail redistribution related header fields may
    need further discuss.

Yes, this needs doing. Wasn't somebody suppoed to be writing a Draft for  
mailing lists? I would have expected all those List-* headers which  
contain URIs (which is most of them) to be allowed to use IRIs instead  
(there is a well-known downgrade to URI available).

7.2.  MIME headers

    MIME header bodies (parameter <value> in [RFC2231]) need to allow
    UTF8 characters in conformance with this specification.

Yes, it is time we were getting on with this. Perhaps something like:

    The syntax of <value>, as defined in RFC 2045, is

    value = token / quoted-string

    In all those headers, such as Content-Type and Content-Dispoaition [and
    maybe our own UTF8SMTP/Header-Type, plus lots of others being defined in
    various other documents], which make use of <value>s within <parameter>s
    as defined in RFC 2045 as modified by RFC 2231, it will now be allowed
    to use <quoted-string>s containing UTF-8 characters (see the revised
    syntax of <qtext> in section 6.2 of this document).

It will then be up to our downgrade document to refer you to RFC 2231 for  
how to downgrade them.

8.  Security Considerations

    In this specification, a user could provide a ASCII alternative
    address for a non-ASCII address.  However, it is possible these two
    address going to different mailbox, or even different person.  This
    might not be the protocol problem, but user's personal choice (or
    administration policy).

s/a ASCII/an ASCII/
s/going to different mailbox, or even different person/
   go to different mailboxes, or even different persons/
s/the protocol problem/a protocol problem/
s/but user's/but the user's/

Also, you need to add something like "or it might be a deliberate attempt  
to deceive or cause confusion". You may be sure that spammers and scammers  
will exploit this loophole to the full :-( .

9.  IANA considerations

    IANA is requested to add the "UTF8SMTP" new header to the registry
    with the entry pointing to this specification for its definition.
    For those headers that modified in this document need to have their
    registrations modified, so as to refer to the specification in
    addition to their current definitions.

No, you need to provide a proper template for every header you have used  
(or even modified). See draft-ietf-usefor-usefor-09 for an example of how  
to do this.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

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