From ima-bounces@ietf.org Fri Sep 01 04:00:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ3wj-00042m-1s; Fri, 01 Sep 2006 04:00:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ3wi-00042h-Bs for ima@ietf.org; Fri, 01 Sep 2006 04:00:12 -0400 Received: from proof.pobox.com ([207.106.133.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJ3wh-0003Sl-5o for ima@ietf.org; Fri, 01 Sep 2006 04:00:12 -0400 Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id E74D828D87; Fri, 1 Sep 2006 04:00:32 -0400 (EDT) Received: from MCQWP2 (ip72-197-112-82.sd.sd.cox.net [72.197.112.82]) by proof.sasl.smtp.pobox.com (Postfix) with ESMTP id 8B1C86AFCC; Fri, 1 Sep 2006 04:00:31 -0400 (EDT) Date: Fri, 1 Sep 2006 01:00:01 -0700 From: Bill McQuillan X-Priority: 3 (Normal) Message-ID: <19510733522.20060901010001@pobox.com> To: IMA Discussion Subject: Re: [EAI] Comments on draft-ietf-eai-utf8headers-01.txt In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 1.2 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 2006-08-31, Charles Lindsey wrote: > 3. Terminology > In this document, header fields are "UTF-8 header" if the bodies of > s/"UTF-8 header"/"UTF-8 headers"/ Please let's not spread the "header fields" = "headers" pollution of the standard email terminology! A message/rfc822 contains a single "header" made up of "header fields". The fact that we might extend this to "UTF-8 header" shouldn't change the usage. [Note that a MIME multipart message MAY have multiple (MIME) "headers" in the body, each made up of (MIME) "header fields."] -- Bill McQuillan _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Sep 04 15:22:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKK12-00005l-Mh; Mon, 04 Sep 2006 15:21:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKK11-0008UB-Cp for ima@ietf.org; Mon, 04 Sep 2006 15:21:51 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKK0x-0004DH-HQ for ima@ietf.org; Mon, 04 Sep 2006 15:21:51 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster#pop3&clerew$man^ac^uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.231) id 44fc7cc5.152cc.8ea for ima@ietf.org; Mon, 4 Sep 2006 20:21:41 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id k84JLcUH009182 for ; Mon, 4 Sep 2006 20:21:39 +0100 (BST) Date: Mon, 04 Sep 2006 20:21:38 +0100 To: ima@ietf.org From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 83867a50fd8f547996ccdaf89af24437 Subject: [EAI] Comments on draft-ietf-eai-downgrade-02 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org s/EAI/UTF8SMTP/ throughout the document, including in the title. 1. Introduction Traditional mail systems which are defined by [RFC2821] and [RFC2822] allow US-ASCII characters in SMTP envelope and mail headers in body part. The EAI proposal [I-D.ietf-eai-framework], [I-D.ietf-eai-utf8headers] and [I-D.ietf-eai-smtpext] allows UTF-8 characters in SMTP envelope and mail headers in body part. s/mail headers in body part/mail header field bodies/ (twice) otherwise, people will think you are talking about headers inside the s of mail messages. "field body" is the term RFC 2822 uses for a header field without its header name. ... Not only SMTP envelope, but also UTF-8 characters in mail headers MUST be converted to US-ASCII. s/mail headers/mail header fields/ here and in lots of other places, to accord with the terminology of RFC 2822. And then s/mail header fields/mail header fields and in the headers fields of MIME multipart and message types/. Otherwise, an already downgraded message will get munged if it then encounters a non-8BITMIME server. In this document, requirements for downgrading is described in section Section 3, SMTP Downgrading is described in Section 4, and SMTP DATA/Header Downgrading is described in Section 5. s/is described/are described/ I don't like the use of the term "SMTP DATA/header" to describe the mail messages that are transported. We are speaking of objects that conform to RFC 2822 as modified by our utf8headers document, but these objects are going to turn up in all sorts of places apart from within SMTP, such as within other transports (e.g. UUCP), in gateways from other media (e.g. News), within mailing list expanders, and within POP3, IMAP and other storage agents, and they are likely to have to be downgraded (or upgraded) according to your rules in Section 5 in all sorts of situations (e.g. various gateways). Of course, your Section 4 is SMTP-specific, but not your Section 5. So a better term would be "Email header downgrading". 3. Downgrade Requirements 3.1. Timing and conditions of downgrading Note: If the UTF8SMTP header exists, downgrading will be performed. If UTF-8 characters exist in mail headers without the UTF8SMTP header, this is a protocol error, ... No, only if that header exists with the parameter "UTF8", not when its parameter is "downgraded" or "ASCII". Note also that I have suggested renaming this header as something like "Header-Content", and using "UTF8SMTP" as the parameter. 3.2. Requirements Followings are requirements of downgrading. I think that is more a list of hoped-for properties rather than a list of requirements. I doubt we are going to succeed in realizing them all (e.g. an upgrade may not always be an exact inverse of the original downgrade). 4. SMTP Downgrading Downgrading in SMTP envelope uses ALT-ADDRESS parameter proposed in [I-D.ietf-eai-smtpext]. An address is downgradable if the address is all-ASCII address or the address has all-ASCII address specified by ALT-ADDRESS parameter. But what about punycode downgraded (possibly under the control of an "atomic" or "downgradable" keyword)? It is clear that such a downgrade is achievable, given the offficial definition or punycode. We discussed that, but we never agreed to remove it from the draft AKAIR. One SMTP session may contain multiple recipients. Downgrading SHOULD be performed for each SMTP recipient address. ... s/for each SMTP recipient address/for each SMTP recipient address individually/ EAI-Downgraded-From: EAI-Downgraded-To: You need to give a syntax for these new header fields. Also, they should be regarded as Trace fields, so that they come in the middle of the sequence of Received headers, to indicate whereabouts in the sequence of MTAs the downgrading was done. Also, we need a name not involving "EAI-", and I would suggest something involving "Envelope-". So we would get something like: trace = [return] 1*( received / envelope-down ) envelope-down = "Envelope-Downgraded-From:" downchange CRLF / "Envelope-Downgraded-To:" downchange CRLF downchange = [CFWS] "<" utf8-addr-spec [alt-address] ">" [CFWS] "<" [CFWS] addr-spec [CFWS ">" [CFWS] ESMTP ORCPT parameter is used for Delivery Status Notifications (DSNs) [RFC3461]. ... ORCPT parameter downgrading should be defined here. Then please let us have a specific proposal for the next draft. 5. SMTP DATA/Header Downgrading As I said earlier, this needs a title that does not confine it to things that appear in an SMTP DATA command. Originator address(es): ... Destination address(es): ... IDs: IDs such as Message-ID:, Date:, In-Reply-To: and References: ... Trace headers: ... You need to add Content-Type, Content-Disposition, etc. to your list, and also List-*. Headers (Content-*) containing s will be downgraded according to RFC 2231, and headers containing IRIs (List-*) according to RFC 3987. 5.1. Header conversion To preserve all header information, define generic encapsulation header: "Downgraded: HeaderName: HeaderValue". The header value is encoded by [RFC2047] with UTF-8 tag. Again, some syntax is needed. I would suggest: fields =/ downgraded downgraded = "Downgraded:" [CFWS] field-name ":" unstructured CRLF field-name = 1*ftext ftext = %d33-57 / %d59-126 ; printable ASCII except ":" Downgrading: * Check if the mail has 'UTF8SMTP' header and its value is "UTF8". Otherwise, downgrading is not required. * Check each header whether it contains UTF-8 characters or not. You need to deal with the RFC 2047 stuff here: | If the header contains any , or any s | or es | + encode them according to RFC 2047 | If the header contains UTF-8 characters, | ^ | still + If the header is an address header which is described in Section 5.1.1, - Preserve the header in 'Downgraded' header. No, that comes a little later - Downgrade the header defined in Section 5.1.1. | + If the header field contains any ... Section 5.1.2 ... | + If the header contains any IRI ... Section 5.1.3 ... + Preserve the header in 'Downgraded' header. + The other header case, encode the header by [RFC2047] with UTF-8 tag. But NO!!! You cannot just apply RFC 2047 to any other header which just happens to contain UTF-8. So far, nobody has defined any UTF-8 headers not already covered above, but for sure they will appear in the future. The only thing you can do with them (though maybe the guy who invented such a header also invented a downgrade for it) is to create a Dowwgraded header for it (which of course can then contain RFC 2047). * Change 'UTF8SMTP' header value to "Downgraded". And point out that you don't need to create a Downgraded header field if the only thing you did was to apply RFC 2047 to s, s and s. Upgrading: + If the header is address header described in Section 5.1.1, - Apply address header downgrading to the decoded header. Add "using the Downgraded header field" - Remove the header line which is the same with the downgraded line. What do you mean by "same"? Suppose the folding if different. Suppose extra whitespace has appeared/disappeared? Suppose some RFC 2047 encoding has been done differently, or with a different character set? And what if there isn't any matdhing header? Surely that is a protocol error? Do we want to define what happens in that case (e.g. leave the header in place, in which case you may have two From (or To) headers, which is a breach of RFC 2822)? + Remove the 'Downgraded' header. + Add decoded header to mail header. * If each mail header has [RFC2047] encoded part and which encoding is "UTF-8", it is a downgraded header, so decode it. And of course that is one possible cause why the upgraded header may not be identical to the pre-downgraded header. * Change 'UTF8SMTP' header value to "UTF8". Pros: * EAI incompliant MUA displays the downgraded mail body except s/mail body/header field bodies/ Cons: ... Also, restoration order of the downgraded headers is not guaranteed. ... I think you ought to define exactly where the Downgraded headers and modified headers are to be put (e.g. at the same place in the message as the old version). This should be a "SHOULD". 5.1.1. Downgrading address headers The header value is composed of single or multiple mailbox/angle-addr fields defined in [I-D.ietf-eai-utf8headers]. s/header value/header field body/ The next bit would need to be adapted to the changes I have suggested for 5.1 above. 2. By mailbox/angle-addr downgrading, if the field became empty, the field should be removed. 3. If all header field is removed, remove the header. But suppose the header was From: "Joe Doe" You will get From: "Joe Doe" which makes it Non-RFC 2822-compliant, but you cannot remove it because it is not empty. 4. If From header is removed, generate new From: header from envelope-from address. Ugh! Though I cannot think of anything better. 2. Non-ASCII mail address without ALT-ADDRESS parameter case, remove this angle-addr. No, that is not right. If the is then you should be able to translate the utf8-domain with punycode and carry on. And, as I have already said, I would still like to be able to translate the using punycode, possible restricted by an atomic/downgradable parameter. 8. IANA Considerations IANA is requested to add the "EAI-Downgraded-From:", "EAI-Downgraded-To:" and "Downgraded:" new headers to the registry with the entries pointing to this specification for its definition. No, you have to provide templates for all your new headers, as I explained when commenting on the utf8headers draft. Appendix A. Examples Some nice esamples here, but it would be better to show them as a continuous series in one Appendix. As it is, each Appendix starts by repeating where the previous Appendix left off, which is wasteful as well as confusing. Message-Id: MESSAGE_ID s/MESSAGE_ID// in all the examples. From: To: CC: Please can we include some s and some cases of multiple s in the same header in the examples? -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      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 IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima