From ima-bounces@ietf.org Fri Feb 8 11:30:03 2008 Return-Path: X-Original-To: ietfarch-ima-archive@core3.amsl.com Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE0CA28C4CF; Fri, 8 Feb 2008 11:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWpAdLt65owu; Fri, 8 Feb 2008 11:30:02 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBDEA28C424; Fri, 8 Feb 2008 11:30:02 -0800 (PST) X-Original-To: ima@ietf.org Delivered-To: ima@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8B21128C41D; Fri, 8 Feb 2008 11:30:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080208193001.8B21128C41D@core3.amsl.com> Date: Fri, 8 Feb 2008 11:30:01 -0800 (PST) Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-utf8headers-09.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : Internationalized Email Headers Author(s) : J. Yeh Filename : draft-ietf-eai-utf8headers-09.txt Pages : 16 Date : 2008-2-8 Full internationalization of electronic mail requires not only the capability to transmit non-ASCII content, to encode selected information in specific header fields, and to use non-ASCII characters in envelope addresses. It also requires being able to express those addresses and information based on them in mail header fields. This document specifies an experimental variant of Internet mail that permits the use of Unicode encoded in UTF-8, rather than ASCII, as the base form for Internet email header field bodies. This form is permitted in transmission only if authorized by an SMTP extension, as specified in an associated specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-utf8headers-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eai-utf8headers-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eai-utf8headers-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-2-8112532.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-utf8headers-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-utf8headers-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-2-8112532.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org http://www.ietf.org/mailman/listinfo/ima --NextPart-- From ima-bounces@ietf.org Sun Feb 10 10:14:51 2008 Return-Path: X-Original-To: ietfarch-ima-archive@core3.amsl.com Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82BFF3A6871; Sun, 10 Feb 2008 10:14:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgzpHWlkZZgK; Sun, 10 Feb 2008 10:14:50 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B977F3A67E1; Sun, 10 Feb 2008 10:14:50 -0800 (PST) X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BD363A6805 for ; Sun, 10 Feb 2008 10:14:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9GIHT9LQkc5 for ; Sun, 10 Feb 2008 10:14:48 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id 828183A67B4 for ; Sun, 10 Feb 2008 10:14:48 -0800 (PST) Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D14342596BC for ; Sun, 10 Feb 2008 04:41:33 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31059-04 for ; Sun, 10 Feb 2008 04:41:26 +0100 (CET) Received: from [192.168.1.119] (unknown [202.54.25.100]) by eikenes.alvestrand.no (Postfix) with ESMTP id BA1ED2596BA for ; Sun, 10 Feb 2008 04:41:24 +0100 (CET) Date: Sun, 10 Feb 2008 09:02:42 +0530 From: Harald Tveit Alvestrand To: EAI WG Message-ID: X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no Subject: [EAI] EAI - Requested session has been scheduled for IETF 71 (fwd) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org For your information. ------------ Forwarded Message ------------ Date: 9. februar 2008 01:27 -0800 From: IETF Secretariat To: harald@alvestrand.no Cc: lee@cnnic.cn, chris.newman@sun.com, lisa@osafoundation.org, session-request@ietf.org Subject: EAI - Requested session has been scheduled for IETF 71 Dear Harald Alvestrand, The sessions that you have requested have been scheduled. Below is the scheduled session information followed by the information of sessions that you have requested. EAI Session 1 (2 hours) Thursday, Afternoon Session I 1300-1500 Room Name: Breakout Room ---------------------------------------------- Requested Information: --------------------------------------------------------- Working Group Name: eai Area Name: Applications Area Session Requester: Harald Alvestrand Number of Sessions: 1 Length of Session(s): 2 hours Number of Attendees: 60 Conflicts to Avoid: First Priority: imapext lemonade apparea ipr lemonade ltru dkim sieve sasl dnsop ipr smime krb-wg enum usefor tls httpbis Second Priority: dnsext crisp BOF or IRTF Session: please avoid conflict with BOFs of APP area, Special Requests: --------------------------------------------------------- ---------- End Forwarded Message ---------- _______________________________________________ IMA mailing list IMA@ietf.org http://www.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Feb 12 20:12:02 2008 Return-Path: X-Original-To: ietfarch-ima-archive@core3.amsl.com Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9953C28C6BF; Tue, 12 Feb 2008 20:12:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.163 X-Spam-Level: *** X-Spam-Status: No, score=3.163 tagged_above=-999 required=5 tests=[AWL=-2.659, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MANGLED_LIST=2.3, MIME_HEADER_CTYPE_ONLY=0.56, MSGID_FROM_MTA_HEADER=0.803, RDNS_NONE=0.1, X_PRIORITY_CC=2.596] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sytxp97usV8J; Tue, 12 Feb 2008 20:12:01 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 696AF3A6972; Tue, 12 Feb 2008 20:12:01 -0800 (PST) X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0B8A3A6CEB for ; Tue, 12 Feb 2008 20:12:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2EvWvDbAEtiW for ; Tue, 12 Feb 2008 20:11:59 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id 814143A68A5 for ; Tue, 12 Feb 2008 20:11:58 -0800 (PST) Received: (eyou send program); Wed, 13 Feb 2008 12:13:15 +0800 Message-ID: <402875995.11414@cnnic.cn> Received: from 59.172.134.224 by mail.cnnic.cn with HTTP; Wed, 13 Feb 2008 12:13:15 +0800 X-WebMAIL-MUA: [59.172.134.224] From: "Yao Jiankang" To: ah@tr-sys.de Date: Wed, 13 Feb 2008 12:13:15 +0800 X-Priority: 3 Cc: ima@ietf.org Subject: Re: [EAI] draft-ietf-eai-smtpext-11 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Yao Jiankang List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1679133344==" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --===============1679133344== Content-Type: text/plain thanks a lot for your detail comments for refining this document. I will try to update it in the next version. YAO Jiankang >From: Alfred HÎnes >Reply-To: >To: yaojk@cnnic.cn, maowei_ietf@cnnic.cn >Subject: draft-ietf-eai-smtpext-11 >Date:Tue, 12 Feb 2008 10:56:48 +0100 (MEZ) > >Hello, > after studying the Internet-Draft authored/edited by you, > draft-ietf-eai-smtpext-11, > I'd like to submit a few comments, mostly addressing textual > flaws I found in that memo, and suggesting further improvements. > > The items below are presented in textual order. > To give more context, sometimes I quote larger blocks of text > literally and show the replacement proposed using the shorthand > notation: > > > --- > > > I use change bars ('|' in column 1) and occasionally > up/down pointing marker lines ('^^^'/'vvv') to emphasize > the location of textual issues and/or proposed corrections. > Modified text has been re-adjusted to match RFC formatting > rules, where appropriate. I also try to accomodate published > RFC-Ed policy on style and punctuation etc. in my proposals. > > > (1) General > > Please consider basing the document on the updated (work in progress) > versions for RFC 2821 (and RFC 2822), to achieve a consistent > document set and avoid referencing soon obsolete versions. > > Most details won't need to be changed, but please check again. > > > (2) Section 2.6 > > The current draft text confusingly used three different spellings > for the BODY parameter, within the span of a few lines: > BODY , 'Body' , and "Body" . > I suggest to always use BODY (without quotes -- capitalization > suffices as a kind of textual emphasis). > Furthermore, some wording is a bit confusing. > > Altogether, I recommend performing the following changes: > > (2a) 2nd paragraph > [...]. The UTF8SMTP > extension MAY be used with the BODY=8BITMIME parameter if that is > | appropriate given the body content or, if the server advertises > | BINARYMIME [RFC3030] and the BODY=BINARYMIME is appropriate, with the > | BODY=BINARYMIME parameter. > --- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > [...]. The UTF8SMTP > extension MAY be used with the BODY=8BITMIME parameter if that is > | appropriate given the body content or, with the BODY=BINARYMIME > | parameter, if the server advertises BINARYMIME [RFC3030] and that is > | appropriate. > > (2b) 3rd paragraph > > Assuming that the server advertises UTF8SMTP and 8BITMIME, and > receives at least one non-ASCII address, with or without ALT-ADDRESS, > the precise interpretation of "No 'Body' parameter", "BODY=8BITMIME", > and "BODY=BINARYMIME" in the MAIL command is: > --- > Assuming that the server advertises UTF8SMTP and 8BITMIME, and > receives at least one non-ASCII address, with or without ALT-ADDRESS, > | the precise interpretation of 'No BODY parameter', "BODY=8BITMIME", > and "BODY=BINARYMIME" in the MAIL command is: > > Note the use of single quotes to distinguish pure emphasis of a term > from literal quotations (enclosed in double quotes). > > (2c) bullet #1 > vvvvvvvv > 1. If there is no "Body" parameter, the header contains UTF-8 > characters but all the body parts are in ASCII (possibly as the > result of a Content-transfer-encoding). > --- vvvvvv > | 1. If there is no BODY parameter, the header contains UTF-8 > | characters, but all the body parts are in ASCII (possibly as the > result of a Content-transfer-encoding). > > > (3) Section 2.7 > > I suggest the following clarification: > > The information carried in the mail transport process involves > | addresses ("mailboxes") and domain names in contexts in addition to > the MAIL and RCPT commands and extended alternatives to them. In > general, the rule is that, when RFC 2821 specifies a mailbox, this > specification expects UTF-8 to be used for the entire string; when > RFC 2821 specifies a domain name, the name SHOULD be in the form of > ACE labels if its raw form is non-ASCII. > --- > The information carried in the mail transport process involves > | addresses ("mailboxes") and domain names in various contexts, in > ^^^^^^^^ ^ > addition to the MAIL and RCPT commands and extended alternatives to > them. In general, the rule is that, when RFC 2821 specifies a > mailbox, this specification expects UTF-8 to be used for the entire > string; when RFC 2821 specifies a domain name, the name SHOULD be in > the form of ACE labels if its raw form is non-ASCII. > > > (4) Section 2.7.2 > > I suggest the following clarification: > > [...]. Otherwise, surprising downgrades can happen > during temporary failures, which is not a good thing. > --- > [...]. Otherwise, surprising downgrades can happen > | during temporary failures, which users might perceive as a serious > | reliability issue. > > > (5) Section 2.7.3 -- ABNF and anchor 11 > > This comes to big surprise. > > For efficiency, SMTP supports "delayed branching", i.e. delivering > to a mail exchanger a single copy of a message for multiple recipients; > the MTA has to add its timestamp header field and then dispatch > copies of the message to the next hop, unbundled (one per recipient) > or bundled (multiple recipients with same next hop) as it fits to the > implementation and the available resources of the MTA. > > As clearly stated in RFC 2821, Section 4.4, third bullet (2nd one > on page 50), the FOR clause should contain the entries > corresponding to all RCPT commands that have been given and are > in effect for the data transfer. > > If the FOR clause would be forced to only contain a single > entry, which one should be selected ??? > > The latest revision of the 2821bis draft I had reviewed, > draft-klensin-rfc2821bis-06, stiil contains in Section 4.4: > > o The FOR clause MAY contain a list of entries when multiple > RCPT commands have been given. This may raise some security > issues and is usually not desirable; see Section 7.2. > > (Section 7.2 contains special considerations for "Bcc" recipients.) > > The ABNF in that draft version does not match this text and is wrong, > IMHO. > > I therefore suggest to change back to allow a list of recipients > in the FOR clause, in your draft. > > > (6) Section 2.7.3, last paragraph > > I suggest the following improved text for clarification: > > | Except in the 'uFor' and 'uReverse-path' line where non-ASCII domain > | names may be used, internationalized domain names in Received fields > MUST be transmitted in the form of ACE labels. [...] > --- vvvvvvv vvvv vvvvv > | Except in the 'uFor' clause and the 'uReverse-path' value where non- > ASCII domain names may be used, internationalized domain names in > | trace fields MUST be transmitted in the form of ACE labels. [...] > ^^^^^ > > (7) Section 2.7.4.1, 1st line > > s/the/a/ > > Rationale: > There may be multiple RCPT commands for a single mail transfer. > > > (8) Section 2.7.4.2, 1st paragraph below the ABNF fragments > > Please change: > > The "UTF8REPLY" parameter does not use a value. If the reply to a > VERIFY (VRFY) or EXPAND (EXPN) command requires UTF-8, but the SMTP > | client does not use the "UTF8REPLY" parameter, then either reply code > 252 or reply code 550 is used. [...] > --- > The "UTF8REPLY" parameter does not use a value. If the reply to a > VERIFY (VRFY) or EXPAND (EXPN) command requires UTF-8, but the SMTP > | client did not use the "UTF8REPLY" parameter, then either reply code > ^^^ > 252 or reply code 550 is used. [...] > > > (9) Section 7.1 > > (9a) > Please change the ref. tag "[EAI-framework]" to "[RFC4952]" and > place the entry according to ascending RFC# order. > > (9b) > Please add the missing "STD 63, " tag to the [RFC3629] entry. > > (9c) > [RFC4234] now has been obsoleted by STD 68, RFC 5234. > Please update the ref. > > > (10) Apendix A > > (10a) A.1, 1st bullet > > To avoid ambiguity in the grammar, I suggest adding "which is" in: > > o A conventional message is one that does not use any extension > defined in this document or in the UTF8header specification > | [EAI-utf8header], and which is strictly conformant to RFC 2822 > [RFC2822]. > ^^^^^^^^^ > > (10b) A.3, 2nd line > > Add a space character to make the ref. parseable for the IEFT web tools: > s/(DSNs)[RFC3461]/(DSNs) [RFC3461]/ > > (10c) A.5 > > RFC 974 has been obsoleted and incorporated into RFC 2821 > -- and you have not provided a ref. entry for it as well! > > > Best regards, > Alfred HÎnes. > > -- > > +------------------------+--------------------------------------------+ > | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | > | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | > | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | > +------------------------+--------------------------------------------+ > --===============1679133344== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org http://www.ietf.org/mailman/listinfo/ima --===============1679133344==-- From ima-bounces@ietf.org Thu Feb 14 05:00:07 2008 Return-Path: X-Original-To: ietfarch-ima-archive@core3.amsl.com Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F19DB28CF0B; Thu, 14 Feb 2008 05:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLfQuyOJzp4r; Thu, 14 Feb 2008 05:00:06 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BAE828CE44; Thu, 14 Feb 2008 05:00:04 -0800 (PST) X-Original-To: ima@ietf.org Delivered-To: ima@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 871B428CCFE; Thu, 14 Feb 2008 05:00:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080214130001.871B428CCFE@core3.amsl.com> Date: Thu, 14 Feb 2008 05:00:01 -0800 (PST) Cc: ima@ietf.org Subject: [EAI] I-D Action:draft-ietf-eai-downgrade-06.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : Downgrading mechanism for Email Address Internationalization Author(s) : Y. Yoneya, K. Fujiwara Filename : draft-ietf-eai-downgrade-06.txt Pages : 24 Date : 2008-02-14 Traditional mail systems handle only ASCII characters in SMTP envelope and mail header fields. The Email Address Internationalization (UTF8SMTP) extension allows UTF-8 characters in SMTP envelope and mail header fields. To avoid bouncing internationalized Email messages when a server in the delivery path does not support the UTF8SMTP extension, some sort of converting mechanism is required. This document describes a downgrading mechanism for Email Address Internationalization. Note that this is a way to downgrade, not tunnel. There is no associated up-conversion mechanism, although internationalized email clients might use original internationalized addresses or other data when displaying or replying to downgraded messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-downgrade-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eai-downgrade-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eai-downgrade-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-14044559.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-downgrade-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-downgrade-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-14044559.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org http://www.ietf.org/mailman/listinfo/ima --NextPart-- From ima-bounces@ietf.org Fri Feb 15 00:44:51 2008 Return-Path: X-Original-To: ietfarch-ima-archive@core3.amsl.com Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAB073A6A53; Fri, 15 Feb 2008 00:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.264 X-Spam-Level: X-Spam-Status: No, score=-0.264 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKZkTn5zYwgp; Fri, 15 Feb 2008 00:44:50 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7A5E28CDDF; Fri, 15 Feb 2008 00:44:50 -0800 (PST) X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 803943A68AC for ; Fri, 15 Feb 2008 00:44:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzww8-3Y4sVr for ; Fri, 15 Feb 2008 00:44:48 -0800 (PST) Received: from send01.jprs.co.jp (send01.jprs.co.jp [202.11.17.113]) by core3.amsl.com (Postfix) with ESMTP id 4766528CE9A for ; Fri, 15 Feb 2008 00:44:35 -0800 (PST) Received: from send01.jprs.co.jp (localhost [127.0.0.1]) by send01.jprs.co.jp (8.12.10+Sun/8.12.11) with SMTP id m1F8jsaA018433 for ; Fri, 15 Feb 2008 17:45:54 +0900 (JST) Received: (from localhost [172.18.4.61]) by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id M2008021517455328303 for ; Fri, 15 Feb 2008 17:45:53 +0900 Date: Fri, 15 Feb 2008 17:45:54 +0900 (JST) Message-Id: <20080215.174554.179924293.fujiwara@jprs.co.jp> To: ima@ietf.org From: fujiwara@jprs.co.jp X-Mailer: Mew version 5.2.53 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Subject: [EAI] downgrade-06 and downgraded-display-00 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org I submitted two documents, draft-ietf-eai-downgrade-06 and draft-fujiwara-eai-downgraded-display-00. Appendix A of downgrade-05 document is moved to new document draft-fujiwara-eai-downgraded-display-00. Please comment them. A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Displaying Downgraded Messages for Email Address Internationalization Author(s) : K. Fujiwara Filename : draft-fujiwara-eai-downgraded-display-00.txt Pages : 14 Date : 2008-02-14 This document describes how to display downgraded messages which originally contain internationalized E-mail addresses or internationalized header fields. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-fujiwara-eai-downgraded-display-00.txt -- Kazunori Fujiwara, JPRS _______________________________________________ IMA mailing list IMA@ietf.org http://www.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Feb 17 15:12:17 2008 Return-Path: X-Original-To: ietfarch-ima-archive@core3.amsl.com Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 955763A6BE9; Sun, 17 Feb 2008 15:12:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.513 X-Spam-Level: X-Spam-Status: No, score=-0.513 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJXIDrxUSdMq; Sun, 17 Feb 2008 15:12:16 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 988583A6BD1; Sun, 17 Feb 2008 15:12:16 -0800 (PST) X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AE063A6B50 for ; Sun, 17 Feb 2008 15:12:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3uR3p9aSShgH for ; Sun, 17 Feb 2008 15:12:13 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id 3E2773A6C2D for ; Sun, 17 Feb 2008 15:11:49 -0800 (PST) Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 03BD0259712 for ; Sun, 17 Feb 2008 07:51:31 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11720-09 for ; Sun, 17 Feb 2008 07:51:22 +0100 (CET) Received: from [192.168.100.209] (dynip226st155.kpn-cc.nl [77.241.226.155]) by eikenes.alvestrand.no (Postfix) with ESMTP id 35CDE259710 for ; Sun, 17 Feb 2008 07:51:21 +0100 (CET) Date: Sun, 17 Feb 2008 10:42:26 +0530 From: Harald Tveit Alvestrand To: EAI WG Message-ID: <2F8AA49F5B3F6F44B0FD13CE@B50854F0A9192E8EC6CDA126> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no Subject: [EAI] Call for interop proposals (fwd) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org this was mentioned in the Vancouver meeting as something EAI might want to participate in. It may be too early still; while interoperability results are traditionally "we don't talk about other people's problems", I don't think it is realistic to keep secret who participates in such an event. Harald ------------ Forwarded Message ------------ Date: 9. januar 2008 17:13 -0800 From: Lisa Dusseault To: Apps Discuss Cc: Lisa Dusseault's Chairs , chris-newman-chairs@tools.ietf.org Subject: Call for interop proposals At the Apps area open meeting in Vancouver, Chris & I mentioned the possibility of doing a day of interoperability events at the next IETF meeting. This would replace a day of Apps area meetings during the normal meeting hours and in the normal meeting location. Ideally it would allow people to come to the IETF for more than just "their" meeting (although we have always hoped they can attend other WG meetings as well) and participants may get more benefit and better justification for attending. If we're going to do this, we need proposals: what topic ( IDs, RFCs, suites or functionality) will be tested. I don't think interops will need a lot of management but volunteer coordinators would be ideal. Proposals will need to be followed quickly by some indications of who will participate. WG scheduling is already open and we need to tell the Secretariat immediately if they need to reserve a day for interops. Proposals should probably be posted on some relevant subject mailing list to quickly generate discussion among potential participants -- not everybody reads Apps Discuss. Thanks, Lisa ---------- End Forwarded Message ---------- _______________________________________________ IMA mailing list IMA@ietf.org http://www.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Feb 18 05:00:11 2008 Return-Path: X-Original-To: ietfarch-ima-archive@core3.amsl.com Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6085328C488; Mon, 18 Feb 2008 05:00:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqJ7BDxm-fQM; Mon, 18 Feb 2008 05:00:10 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DB4328C3CA; Mon, 18 Feb 2008 05:00:05 -0800 (PST) X-Original-To: ima@ietf.org Delivered-To: ima@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 05B9128C29A; Mon, 18 Feb 2008 05:00:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080218130002.05B9128C29A@core3.amsl.com> Date: Mon, 18 Feb 2008 05:00:02 -0800 (PST) Cc: ima@ietf.org Subject: [EAI] I-D Action:draft-ietf-eai-mailto-00.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : An update to the mailto URI scheme for Email Address Internationalization Author(s) : M. Duerst Filename : draft-ietf-eai-mailto-00.txt Pages : 7 Date : 2008-02-18 This document updates the definition of the mailto: URI Scheme for use with internationalized email addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-mailto-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eai-mailto-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eai-mailto-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-18045610.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-mailto-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-mailto-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-18045610.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org http://www.ietf.org/mailman/listinfo/ima --NextPart-- From ima-bounces@ietf.org Mon Feb 18 16:49:05 2008 Return-Path: X-Original-To: ietfarch-ima-archive@core3.amsl.com Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 901EF3A6C71; Mon, 18 Feb 2008 16:49:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.065 X-Spam-Level: X-Spam-Status: No, score=-1.065 tagged_above=-999 required=5 tests=[AWL=-0.762, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTTP_ESCAPED_HOST=0.134, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1ser4iPP89I; Mon, 18 Feb 2008 16:49:04 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE8AD3A6915; Mon, 18 Feb 2008 16:49:04 -0800 (PST) X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0F553A68FF for ; Mon, 18 Feb 2008 16:49:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcpCwETuDA9s for ; Mon, 18 Feb 2008 16:49:03 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id D625B3A63D3 for ; Mon, 18 Feb 2008 16:49:02 -0800 (PST) Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1JRGfL-0000eo-5H for ima@ietf.org; Mon, 18 Feb 2008 19:48:59 -0500 Date: Mon, 18 Feb 2008 19:48:58 -0500 From: John C Klensin To: ima@ietf.org Message-ID: <51C5A170845393A167646F34@p3.JCK.COM> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Disposition: inline Subject: [EAI] Quick comments on draft-ietf-eai-mailto-00 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org Martin, Some quick reactions... (1) This is really ugly. Perhaps nothing can be done about it, but I think that is worth noting, especially since we have gone out of our way to make non-ASCII-string@non-ASCII-string.whatever.tld a value email address. (2) It might be a bit less ugly if you used only envelope addresses (RFC2821-derived) rather than header (RFC2822-derived) ones. In particular, I really see little need to incorporate name phrases in these strings and much less need to incorporate comments. See also (6) below. (3) It is perhaps worth a comment that "?" is a valid character in a local-part. More %-encoding, I assume. The first Note 1 in Section 2 doesn't go quite far enough in that regard, even though the requirement for surrounding "<" and ">" might eliminate the parsing problem for i18n addresses. (4) In Section 2's final set of notes (below "Non-ASCII characters can be encoded in "hvalue"...), your first bullet says "SHOULD". If the sending system ignores that recommendation, what do you think will happen? Think someone might apply the UTF-8 encoding algorithm to ISO 8859-6 characters? (5) While I sympathize with the reasons for Section 3, it is handwaving, since the typical context in which a mailto URI might be used would have absolutely no way to tell at the time the URI is written. (6) Your examples should include one in which the phrase and comments, including characters in the former that require quoting, are used if you really want to require support for them. (7) If a relatively simple mailto URI will look like mailto:%3Ccaf%C3%A9@%E7%B4%8D%E8%B1%86.example.org%20%3Ccafe@ natto.example.org%3E%3E then I contend there is a security threat associated with this system that is not present in the listed RFCs. The problem is that one of our more important security aids is the user's ability to inspect a string and determine that it is nonsense or a threat. I suggest that, for a typical user, the effect of a string similar to the above is "the eyes glaze over" rather than, e.g., the implied warning of seeing the domain name (at least) as an ACE. Put differently, this sort of string makes it extremely easy for an attacker to hide hostile information in the string, since no user will be able to render that string into anything familiar. best, john _______________________________________________ IMA mailing list IMA@ietf.org http://www.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Feb 18 19:44:14 2008 Return-Path: X-Original-To: ietfarch-ima-archive@core3.amsl.com Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F20B3A6DBB; Mon, 18 Feb 2008 19:44:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.249 X-Spam-Level: X-Spam-Status: No, score=-1.249 tagged_above=-999 required=5 tests=[AWL=-0.812, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iyh4y6Zfnm-C; Mon, 18 Feb 2008 19:44:13 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F22C3A6BBC; Mon, 18 Feb 2008 19:44:13 -0800 (PST) X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AEC63A6BD1 for ; Mon, 18 Feb 2008 19:44:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhdncDnfcDGP for ; Mon, 18 Feb 2008 19:44:11 -0800 (PST) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by core3.amsl.com (Postfix) with ESMTP id E05413A67B4 for ; Mon, 18 Feb 2008 19:44:10 -0800 (PST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JRJOj-0000Rk-1W for ima@ietf.org; Tue, 19 Feb 2008 03:44:01 +0000 Received: from 1cust162.tnt2.hbg2.deu.da.uu.net ([149.225.12.162]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Feb 2008 03:44:01 +0000 Received: from nobody by 1cust162.tnt2.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Feb 2008 03:44:01 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Tue, 19 Feb 2008 04:45:34 +0100 Organization: Lines: 87 Message-ID: References: <20080218130002.05B9128C29A@core3.amsl.com> Mime-Version: 1.0 X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 1cust162.tnt2.hbg2.deu.da.uu.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 Subject: Re: [EAI] I-D Action:draft-ietf-eai-mailto-00.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Frank Ellermann List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org > An update to the mailto URI scheme for Email Address Internationalization Oops, I thought the idea was to finish mailto-bis *before* tackling mailto-eai. Maybe putting this all on hold until 2822upd is no moving target, which could be really soon. The draft says that mailto-eai is based on RFCXXXX, that's mailto-bis. Apparently RFCYYYY is the utf8headers draft. Where RFCXXXX mailto-bis uses mailto-eai needs RFCYYYY , not the like RFC 2368: Replacing the x822 by the x821 , or in other words x822 , is one the mailto-bis points, no comments (etc.) in mailto-eai or mailto-bis, as already noted by John. | to = [ mailbox *("%2C" mailbox ) ] Compare I'm not sure about the necessity of "%2C" instead of "," here. Plus a few other issues like reserving "?" in the query part, or reserving ";" before the query part (or at all, see the original mailto-bis review at the given link). mailto-bis got rid of because it's not more defined in STD 66. Apparently mailto-eai is based on an obsolete mailto-bis-00 or mailto-bis-01. was fixed (eliminated) in mailto-bis-02, the current version is mailto-bis-04. | Please note that if the left-hand side of the mail address | contains non-ASCII characters, the less-than and | greater-than sign (anglebrackets, escaped as %3C and %3E) | are mandatory. That is a consequence of using RFCYYYY , or maybe RFCYYYY BTW, there is an ABNF bug in RFCYYYY: | angle-addr =/ [CFWS] "<" utf8-addr-spec [ alt-address ] ">" [CFWS] / | obs-angle-addr Please strike the "/" in "=/" (found in eai-utf8headers-09). For the purpose of mailto-eai I think we can get rid of the angle brackets at this level. RFC 2368 and mailto-bis also don't don't have angle brackets. mailto-eai only needs the stuff *within* the angle brackets, that is utf8-addr-spec [ alt-address ] Maybe using its own name for this construct: utf8-addr = utf-8-addr-spec [ alt-address ] Importing utf8-addr-spec and alt-address "as is" from RFCYYYY. Note that there still are angle brackets at the level of the alt-address. And there's another bug in RFCYYYY, 1*FWS is incorrect, how often did I aready report this trivial bug ? THERE IS NO SUCH THING AS 1*FWS, JUST FWS DOES WHAT YOU WANT. Back to mailto-eai: | Please note that at least a space is needed before the | "alt-address", and that such a space also has to be | percent-encoded. Yes. I wonder if mailto-eai could simplify it into "one and only one percent-encode space". The FWS business is about folding long header fields (once, not 1*FWS multiple times). mailto-eai only needs a separator, nothing more elaborated, and soon net-utf8 will start to finish off HTAB everywhere. One %20 is IMO bad enough for mailto-eai, no percent-encoded FWS please. Maybe mailto-eai should get an IRI example, using hex. NCRs to emulate UTF-8 in an US-ASCII draft. Ideally it should also have an IRI example for a legacy charset like KOI8-R, but I fear that's too confusing in an US-ASCII draft or RFC. Frank _______________________________________________ IMA mailing list IMA@ietf.org http://www.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Feb 19 02:07:47 2008 Return-Path: X-Original-To: ietfarch-ima-archive@core3.amsl.com Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D563D3A6DED; Tue, 19 Feb 2008 02:07:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.008 X-Spam-Level: *** X-Spam-Status: No, score=3.008 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTTP_ESCAPED_HOST=0.134, J_CHICKENPOX_23=0.6, RCVD_IN_NJABL_RELAY=2.696, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywLd7d8O4SnN; Tue, 19 Feb 2008 02:07:46 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 952623A6A5F; Tue, 19 Feb 2008 02:07:46 -0800 (PST) X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3E133A6D7C for ; Tue, 19 Feb 2008 02:07:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mj-UAs-HyLv8 for ; Tue, 19 Feb 2008 02:07:43 -0800 (PST) Received: from scmailgw1.scop.aoyama.ac.jp (scmailgw1.scop.aoyama.ac.jp [133.2.251.194]) by core3.amsl.com (Postfix) with ESMTP id B7B8E3A6C58 for ; Tue, 19 Feb 2008 02:07:11 -0800 (PST) Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id m1JA777q003223 for ; Tue, 19 Feb 2008 19:07:07 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 10b5_6d7aadc6_ded2_11dc_8c6e_0014221fa3c9; Tue, 19 Feb 2008 19:07:07 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:58967) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 19 Feb 2008 19:02:44 +0900 Message-Id: <6.0.0.20.2.20080219182319.09676e30@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 19 Feb 2008 18:26:07 +0900 To: John C Klensin , ima@ietf.org From: Martin Duerst In-Reply-To: <51C5A170845393A167646F34@p3.JCK.COM> References: <51C5A170845393A167646F34@p3.JCK.COM> Mime-Version: 1.0 Subject: Re: [EAI] Quick comments on draft-ietf-eai-mailto-00 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org Hello John, Many thanks (also to Frank) for your very quick feedback. At 09:48 08/02/19, John C Klensin wrote: >Martin, > >Some quick reactions... > >(1) This is really ugly. Perhaps nothing can be done about it, >but I think that is worth noting, especially since we have gone >out of our way to make >non-ASCII-string@non-ASCII-string.whatever.tld a value email >address. What are you referring to by "This"? If it's all the %-escaping, then I fully agree with you. That's why we have IRIs :-). I can guarantee that the draft would contain quite a few IRI examples if the ID/RFC format allowed non-ASCII. But we can't change the fact that we have to escape '<' and '>' and so on. More later. Regards, Martin. >(2) It might be a bit less ugly if you used only envelope >addresses (RFC2821-derived) rather than header (RFC2822-derived) >ones. In particular, I really see little need to incorporate >name phrases in these strings and much less need to incorporate >comments. See also (6) below. > >(3) It is perhaps worth a comment that "?" is a valid character >in a local-part. More %-encoding, I assume. The first Note 1 >in Section 2 doesn't go quite far enough in that regard, even >though the requirement for surrounding "<" and ">" might >eliminate the parsing problem for i18n addresses. > >(4) In Section 2's final set of notes (below "Non-ASCII >characters can be encoded in "hvalue"...), your first bullet >says "SHOULD". If the sending system ignores that >recommendation, what do you think will happen? Think someone >might apply the UTF-8 encoding algorithm to ISO 8859-6 >characters? > >(5) While I sympathize with the reasons for Section 3, it is >handwaving, since the typical context in which a mailto URI >might be used would have absolutely no way to tell at the time >the URI is written. > >(6) Your examples should include one in which the phrase and >comments, including characters in the former that require >quoting, are used if you really want to require support for them. > >(7) If a relatively simple mailto URI will look like > >mailto:%3Ccaf%C3%A9@%E7%B4%8D%E8%B1%86.example.org%20%3Ccafe@ > natto.example.org%3E%3E > >then I contend there is a security threat associated with this >system that is not present in the listed RFCs. The problem is >that one of our more important security aids is the user's >ability to inspect a string and determine that it is nonsense or >a threat. I suggest that, for a typical user, the effect of a >string similar to the above is "the eyes glaze over" rather >than, e.g., the implied warning of seeing the domain name (at >least) as an ACE. Put differently, this sort of string makes >it extremely easy for an attacker to hide hostile information in >the string, since no user will be able to render that string >into anything familiar. > > best, > john > > >_______________________________________________ >IMA mailing list >IMA@ietf.org >http://www.ietf.org/mailman/listinfo/ima #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org http://www.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Feb 19 10:56:12 2008 Return-Path: X-Original-To: ietfarch-ima-archive@core3.amsl.com Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F6053A6B4A; Tue, 19 Feb 2008 10:56:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.798 X-Spam-Level: X-Spam-Status: No, score=-0.798 tagged_above=-999 required=5 tests=[AWL=-0.361, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T+QAWWxdA1u7; Tue, 19 Feb 2008 10:56:08 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A1C63A6B00; Tue, 19 Feb 2008 10:56:08 -0800 (PST) X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00AD93A6B1E for ; Tue, 19 Feb 2008 10:56:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfRI-Q1DxvhB for ; Tue, 19 Feb 2008 10:56:04 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id ABFF93A6B00 for ; Tue, 19 Feb 2008 10:56:04 -0800 (PST) Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1JRXdI-000AvD-Fx; Tue, 19 Feb 2008 13:56:00 -0500 Date: Tue, 19 Feb 2008 13:55:59 -0500 From: John C Klensin To: Martin Duerst , ima@ietf.org Message-ID: <0A3A4A19787C7DDAEAEE9B80@p3.JCK.COM> In-Reply-To: <6.0.0.20.2.20080219182319.09676e30@localhost> References: <51C5A170845393A167646F34@p3.JCK.COM> <6.0.0.20.2.20080219182319.09676e30@localhost> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [EAI] Quick comments on draft-ietf-eai-mailto-00 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --On Tuesday, 19 February, 2008 18:26 +0900 Martin Duerst wrote: >> (1) This is really ugly. Perhaps nothing can be done about >> it, but I think that is worth noting, especially since we >> have gone out of our way to make >> non-ASCII-string@non-ASCII-string.whatever.tld a value email >> address. > > What are you referring to by "This"? If it's all the > %-escaping, then I fully agree with you. That's why we have > IRIs :-). I can guarantee that the draft would contain quite a > few IRI examples if the ID/RFC format allowed non-ASCII. > > But we can't change the fact that we have to escape '<' and '>' > and so on. Understood. And that was, in fact, what I was referring to. john _______________________________________________ IMA mailing list IMA@ietf.org http://www.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Feb 22 00:30:47 2008 Return-Path: X-Original-To: ietfarch-ima-archive@core3.amsl.com Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3189F3A6B95; Fri, 22 Feb 2008 00:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.102 X-Spam-Level: X-Spam-Status: No, score=-1.102 tagged_above=-999 required=5 tests=[AWL=-0.665, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-cozPFbhb17; Fri, 22 Feb 2008 00:30:46 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 202A128C11B; Fri, 22 Feb 2008 00:30:46 -0800 (PST) X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57E7B28C11B for ; Fri, 22 Feb 2008 00:30:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebJ6Tzx7kIwn for ; Fri, 22 Feb 2008 00:30:44 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id E656C3A69AC for ; Fri, 22 Feb 2008 00:30:43 -0800 (PST) Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AF302259707; Fri, 22 Feb 2008 09:30:39 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13219-09; Fri, 22 Feb 2008 09:30:29 +0100 (CET) Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9EC8E259700; Fri, 22 Feb 2008 09:30:29 +0100 (CET) Message-ID: <47BE87F9.4080901@alvestrand.no> Date: Fri, 22 Feb 2008 09:29:45 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.14pre (X11/20071023) MIME-Version: 1.0 To: Chris Newman , Lisa Dusseault X-Enigmail-Version: 0.94.2.0 Content-Type: multipart/mixed; boundary="------------030102040007060001090807" X-Virus-Scanned: by amavisd-new at alvestrand.no Cc: EAI WG Subject: [EAI] Request for publication of draft-ietf-eai-dsn-06 as Experimental X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org This is a multi-part message in MIME format. --------------030102040007060001090807 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Greetings, the EAI WG hereby requests that draft-ietf-eai-dsn-06 be published as Experimental. This forms part of a package with draft-ietf-eai-smtpext and draft-ietf-eai-utf8headers, but due to its history of authorship, it should be processed differently from the others. The detailed writeup is enclosed. A request for the other 2 will be forthcoming shortly. Harald Alvestrand, WG chair --------------030102040007060001090807 Content-Type: text/plain; name="dsn-writeup.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dsn-writeup.txt" Document writeup for draft-ietf-eai-dsn-05, destined for Experimental status (February 1, 2007 template) (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Harald Alvestrand. Yes. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Yes. No. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Solid. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (Concerns with -smtp / -utf8headers also touch this document) (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes. The only unstable normative references are to -smtp and -utf8headers. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? Yes. MIME type review was asked for on January 21, 2008. One comment, positive, has been recieved. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Yes. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document specifies a format for handling delivery status notifications when those notifications concern messages that are extended according to the EAI UTF8SMTP extension. Working Group Summary The WG came to consensus on this document. Document Quality The document has been reviewed in the WG. (end) --------------030102040007060001090807 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org http://www.ietf.org/mailman/listinfo/ima --------------030102040007060001090807-- From ima-bounces@ietf.org Fri Feb 22 00:55:12 2008 Return-Path: X-Original-To: ietfarch-ima-archive@core3.amsl.com Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1233928C112; Fri, 22 Feb 2008 00:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.011 X-Spam-Level: X-Spam-Status: No, score=-1.011 tagged_above=-999 required=5 tests=[AWL=-0.574, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d57XRtnCiUbd; Fri, 22 Feb 2008 00:55:11 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02DA73A6C3A; Fri, 22 Feb 2008 00:55:11 -0800 (PST) X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D82933A6C3A for ; Fri, 22 Feb 2008 00:55:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjXuPGsuGALo for ; Fri, 22 Feb 2008 00:55:08 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id 256833A6C24 for ; Fri, 22 Feb 2008 00:55:08 -0800 (PST) Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DDCA0259702; Fri, 22 Feb 2008 09:55:03 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13788-09; Fri, 22 Feb 2008 09:54:53 +0100 (CET) Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id F1E78259700; Fri, 22 Feb 2008 09:54:52 +0100 (CET) Message-ID: <47BE8DB1.1000307@alvestrand.no> Date: Fri, 22 Feb 2008 09:54:09 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.14pre (X11/20071023) MIME-Version: 1.0 To: Chris Newman , Lisa Dusseault X-Enigmail-Version: 0.94.2.0 Content-Type: multipart/mixed; boundary="------------050900020709020900020505" X-Virus-Scanned: by amavisd-new at alvestrand.no Cc: EAI WG Subject: [EAI] Request for advancement of draft-ietf-eai-{utf8headers, smtpext} to Experimental X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org This is a multi-part message in MIME format. --------------050900020709020900020505 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Enclosed is the writeup for the request to advance the two documents draft-ietf-eai-utf8headers-09 draft-ietf-eai-smtpext-11 to Experimental status. Please process appropriately; we believe an IETF Last Call is a Good Thing. Harald Alvestrand, WG chair. --------------050900020709020900020505 Content-Type: text/plain; name="core-writeup.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="core-writeup.txt" (February 1, 2007 template) Writeup for the documents: draft-ietf-eai-smtpext-11 draft-ietf-eai-utf8heders-09 destined for Experimental status. (the writeup for the linked draft-ietf-eai-dsn-05 is sent separately) (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Harald Alvestrand. Yes. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Yes. No. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? I believe the WG as a whole understands and agrees that the documents are a solid description of the chosen approach. See below for the "possible conflict". (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) Charles Lindsey and Frank Ellermann have argued strongly against a specific point in the specification: The transmission of EAI messages in a subtype of "message". Charles has indicated that he will re-raise this issue at Last Call time. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes. MIME type review was asked for on January 21, 2008; one positive comment has been recieved as of February 22. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes. SMTP: There are normative references to -dsn and -utf8hdr, which are part of this package, as well as mailesc-registry, which should go forward ahead of it. UTF8: There are normative references to -smtpext, which is part of this package. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? Yes. No new registries, -SMTP has some new values to register. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Yes. One minor ABNF error has been identified, and will be corrected with other Last Call comments. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary These two documents form the core specification for an extension to SMTP and RFC 2822 that allow the free use of UTF-8 in message headers without encoding. This includes the use of non-ASCII characters in email addresses, both on the left and right hand sides of the @ character. Working Group Summary The WG was chartered to explore one particular approach to email internationalization, and succeeded in keeping to that charter. There was extensive discussion of one particular design choice - on which MIME type to use. Document Quality The documents have been extensively reviewed by people with mail expertise. There have been reports of implementations, but no interoperability tests have been reported to date. (end) --------------050900020709020900020505 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org http://www.ietf.org/mailman/listinfo/ima --------------050900020709020900020505-- From ima-bounces@ietf.org Fri Feb 22 02:23:00 2008 Return-Path: X-Original-To: ietfarch-ima-archive@core3.amsl.com Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0059428C272; Fri, 22 Feb 2008 02:22:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.741 X-Spam-Level: X-Spam-Status: No, score=-0.741 tagged_above=-999 required=5 tests=[AWL=-0.304, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijAFVsYDUITK; Fri, 22 Feb 2008 02:22:59 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15B933A6BD5; Fri, 22 Feb 2008 02:22:59 -0800 (PST) X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF8A13A6BD5 for ; Fri, 22 Feb 2008 02:22:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CW1G-oC8dJgV for ; Fri, 22 Feb 2008 02:22:56 -0800 (PST) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by core3.amsl.com (Postfix) with ESMTP id C22CE3A6BC0 for ; Fri, 22 Feb 2008 02:22:56 -0800 (PST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JSV3H-0008Kr-PF for ima@ietf.org; Fri, 22 Feb 2008 10:22:47 +0000 Received: from 1cust46.tnt3.hbg2.deu.da.uu.net ([149.225.14.46]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Feb 2008 10:22:47 +0000 Received: from nobody by 1cust46.tnt3.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Feb 2008 10:22:47 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Fri, 22 Feb 2008 11:24:12 +0100 Organization: Lines: 32 Message-ID: References: <47BE8DB1.1000307@alvestrand.no> Mime-Version: 1.0 X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 1cust46.tnt3.hbg2.deu.da.uu.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 Subject: Re: [EAI] Request for advancement of draft-ietf-eai-{utf8headers, smtpext} to Experimental X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Frank Ellermann List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org [mailed separately] Harald Alvestrand wrote: > Charles Lindsey and Frank Ellermann have argued strongly > against a specific point in the specification: The > transmission of EAI messages in a subtype of "message". Just in case if it is unclear: These objections are to some degree orthogonal. Charles argues that EAI cannot overrule an "EXPRESSLY FORBIDDEN" in MIME, while I came to the conclusion that this is actually an error in MIME, compare . I argue that EAI has no business to update MIME at all, EAI could solve Charles' issue with an erratum. I like message/global, but think its definition is flawed, if there is no UTF-8 in the header (singular) the message is implicitly a message/rfc822, not a message/global. The EAI definition uses a convoluted MIME part parsing checking headers (plural) of the message and MIME parts, for the purpose of updating MIME allowing UTF-8 also in MIME part headers. IMO it's incompatible with MIME 1.0 and also no "KISS" solution. > One minor ABNF error has been identified, and will be > corrected with other Last Call comments. I hope that covers the erroneous 1*FWS instead of FWS. Frank _______________________________________________ IMA mailing list IMA@ietf.org http://www.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Feb 24 16:15:03 2008 Return-Path: X-Original-To: ietfarch-ima-archive@core3.amsl.com Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FA6F28C287; Sun, 24 Feb 2008 16:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9BoRyrEKo7M; Sun, 24 Feb 2008 16:15:02 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31E3C28C1FE; Sun, 24 Feb 2008 16:15:02 -0800 (PST) X-Original-To: ima@ietf.org Delivered-To: ima@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C79D628C1A9; Sun, 24 Feb 2008 16:15:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080225001501.C79D628C1A9@core3.amsl.com> Date: Sun, 24 Feb 2008 16:15:01 -0800 (PST) Cc: ima@ietf.org Subject: [EAI] I-D Action:draft-ietf-eai-mailinglist-03.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : Mailing Lists and Internationalized Email Addresses Author(s) : R. Gellens, E. Chung Filename : draft-ietf-eai-mailinglist-03.txt Pages : 10 Date : 2008-02-22 This document describes considerations for mailing lists with the introduction of internationalized email addresses. This document makes some specific recommendations on how mailing lists should act in various situations. Gellens & Chung [page 1] Expires August 2008 Internet Draft Mailing Lists and i18mail Addresses February 2008 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-mailinglist-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eai-mailinglist-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eai-mailinglist-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-24161012.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-mailinglist-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-mailinglist-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-24161012.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org http://www.ietf.org/mailman/listinfo/ima --NextPart-- From ima-bounces@ietf.org Sun Feb 24 17:00:05 2008 Return-Path: X-Original-To: ietfarch-ima-archive@core3.amsl.com Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC95D28C43F; Sun, 24 Feb 2008 17:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9Bnz4+Eqyeq; Sun, 24 Feb 2008 17:00:04 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EE0A28C269; Sun, 24 Feb 2008 17:00:03 -0800 (PST) X-Original-To: ima@ietf.org Delivered-To: ima@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 394253A6A8A; Sun, 24 Feb 2008 17:00:00 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080225010001.394253A6A8A@core3.amsl.com> Date: Sun, 24 Feb 2008 17:00:01 -0800 (PST) Cc: ima@ietf.org Subject: [EAI] I-D Action:draft-ietf-eai-pop-03.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : POP3 Support for UTF-8 Author(s) : C. Newman, R. Gellens Filename : draft-ietf-eai-pop-03.txt Pages : 13 Date : 2008-02-24 This specification extends the Post Office Protocol version 3 (POP3) to support un-encoded international characters in user names, passwords, mail addresses, message headers, and protocol-level textual error strings. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-pop-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eai-pop-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eai-pop-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-24164613.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-pop-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-pop-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-24164613.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org http://www.ietf.org/mailman/listinfo/ima --NextPart-- From ima-bounces@ietf.org Sun Feb 24 23:44:26 2008 Return-Path: X-Original-To: ietfarch-ima-archive@core3.amsl.com Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D68B3A6A16; Sun, 24 Feb 2008 23:44:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.923 X-Spam-Level: ** X-Spam-Status: No, score=2.923 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_23=0.6, RCVD_IN_NJABL_RELAY=2.696, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8VEKLvSRvNL; Sun, 24 Feb 2008 23:44:25 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09D8E28C15F; Sun, 24 Feb 2008 23:44:25 -0800 (PST) X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A81CC3A6A16 for ; Sun, 24 Feb 2008 23:44:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9l0ihYfLrXNg for ; Sun, 24 Feb 2008 23:44:21 -0800 (PST) Received: from scmailgw2.scop.aoyama.ac.jp (scmailgw2.scop.aoyama.ac.jp [133.2.251.195]) by core3.amsl.com (Postfix) with ESMTP id 491FE3A68F9 for ; Sun, 24 Feb 2008 23:44:20 -0800 (PST) Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id m1P7iBFw000880 for ; Mon, 25 Feb 2008 16:44:11 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 3f36_742bbcb2_e375_11dc_8c33_0014221fa3c9; Mon, 25 Feb 2008 16:44:10 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:43931) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 25 Feb 2008 16:39:44 +0900 Message-Id: <6.0.0.20.2.20080225143454.0bd91ec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 25 Feb 2008 16:43:21 +0900 To: Frank Ellermann , ima@ietf.org From: Martin Duerst In-Reply-To: References: <20080218130002.05B9128C29A@core3.amsl.com> Mime-Version: 1.0 Cc: jwz@jwz.org, Larry Masinter Subject: Re: [EAI] I-D Action:draft-ietf-eai-mailto-00.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org At 12:45 08/02/19, Frank Ellermann wrote: >> An update to the mailto URI scheme for Email Address Internationalization > >Oops, I thought the idea was to finish mailto-bis *before* >tackling mailto-eai. Well, yes in theory, but in practice, it makes quite a bit of sense to have these activities overlap. See below for an example. >Maybe putting this all on hold until >2822upd is no moving target, which could be really soon. We don't need to put it on hold. We may want to wait with finalization to make sure we are in sync with 2822upd, but we still can use the time to move ahead and tease out issues. >The draft says that mailto-eai is based on RFCXXXX, that's >mailto-bis. Apparently RFCYYYY is the utf8headers draft. Correct. >Where RFCXXXX mailto-bis uses mailto-eai needs >RFCYYYY , not the like RFC 2368: > >Replacing the x822 by the x821 , or in >other words x822 , is one the mailto-bis points, >no comments (etc.) in mailto-eai or mailto-bis, as already >noted by John. I just submitted another version of draft-duerst-mailto-bis, and while working on the edits, had the chance to do some "archaeology". The change from to happened in draft-duerst-mailto-bis-01.txt, after a not- necessarily conclusive discussion involving (among others) Bruce Lilly, Paul Hofmann, John Cowan, Larry, and Frank. It may be Larry who made the actual edit, but it may have been me. When drafting mailto-eai, I was looking at the utf8headers draft and decided that in order to get a syntax definition for the > construct, the best thing to pick was . Obviously, while in email header fields, the syntax > isn't a big issue, in mailto URIs, it doesn't look pretty at all. The first alternative might be to use internationalized or some such, but that might not fly because it would just be interpreted as display_name by most current mailto: implementations who may, either by design or more probably by accident, still implement mailto: according to RFC 2368. Of course, we could define things so that foo gets parsed as display_name (backwards compatible behavior for RFC 2396) if foo is ASCII-only, and internationalized if foo (the LHS side of foo?) contains non-ASCII characters, but we should carefully think about the consequences this has for implementations. Any further comments, in particular on this major point, greatly appreciated. Regards, Martin. >| to = [ mailbox *("%2C" mailbox ) ] > >Compare > >I'm not sure about the necessity of "%2C" instead of "," >here. Plus a few other issues like reserving "?" in the >query part, or reserving ";" before the query part (or at >all, see the original mailto-bis review at the given link). > >mailto-bis got rid of because it's not more defined >in STD 66. Apparently mailto-eai is based on an obsolete >mailto-bis-00 or mailto-bis-01. > > was fixed (eliminated) in mailto-bis-02, the current >version is mailto-bis-04. > >| Please note that if the left-hand side of the mail address >| contains non-ASCII characters, the less-than and >| greater-than sign (anglebrackets, escaped as %3C and %3E) >| are mandatory. > >That is a consequence of using RFCYYYY , or maybe >RFCYYYY BTW, there is an ABNF bug in RFCYYYY: > >| angle-addr =/ [CFWS] "<" utf8-addr-spec [ alt-address ] ">" [CFWS] / >| obs-angle-addr > >Please strike the "/" in "=/" (found in eai-utf8headers-09). > >For the purpose of mailto-eai I think we can get rid of the >angle brackets at this level. RFC 2368 and mailto-bis also >don't don't have angle brackets. > >mailto-eai only needs the stuff *within* the angle brackets, >that is utf8-addr-spec [ alt-address ] Maybe using its own >name for this construct: > > utf8-addr = utf-8-addr-spec [ alt-address ] > >Importing utf8-addr-spec and alt-address "as is" from RFCYYYY. > >Note that there still are angle brackets at the level of the >alt-address. And there's another bug in RFCYYYY, 1*FWS is >incorrect, how often did I aready report this trivial bug ? > >THERE IS NO SUCH THING AS 1*FWS, JUST FWS DOES WHAT YOU WANT. > >Back to mailto-eai: > >| Please note that at least a space is needed before the >| "alt-address", and that such a space also has to be >| percent-encoded. > >Yes. I wonder if mailto-eai could simplify it into "one and >only one percent-encode space". The FWS business is about >folding long header fields (once, not 1*FWS multiple times). > >mailto-eai only needs a separator, nothing more elaborated, >and soon net-utf8 will start to finish off HTAB everywhere. > >One %20 is IMO bad enough for mailto-eai, no percent-encoded >FWS please. > >Maybe mailto-eai should get an IRI example, using hex. NCRs >to emulate UTF-8 in an US-ASCII draft. Ideally it should >also have an IRI example for a legacy charset like KOI8-R, >but I fear that's too confusing in an US-ASCII draft or RFC. > > Frank > >_______________________________________________ >IMA mailing list >IMA@ietf.org >http://www.ietf.org/mailman/listinfo/ima #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org http://www.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Feb 26 05:32:59 2008 Return-Path: X-Original-To: ietfarch-ima-archive@core3.amsl.com Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BC4B3A690C; Tue, 26 Feb 2008 05:32:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.98 X-Spam-Level: X-Spam-Status: No, score=-0.98 tagged_above=-999 required=5 tests=[AWL=-0.543, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZUntHrMYrLE; Tue, 26 Feb 2008 05:32:58 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5014D28C2A6; Tue, 26 Feb 2008 05:32:58 -0800 (PST) X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8EC628C2A6 for ; Tue, 26 Feb 2008 05:32:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52gBfwhhTLxm for ; Tue, 26 Feb 2008 05:32:56 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 0DA553A684C for ; Tue, 26 Feb 2008 05:32:56 -0800 (PST) Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1JTzvD-000F0Z-F2; Tue, 26 Feb 2008 08:32:39 -0500 Date: Tue, 26 Feb 2008 08:32:36 -0500 From: John C Klensin To: Martin Duerst , Frank Ellermann , ima@ietf.org Message-ID: In-Reply-To: <6.0.0.20.2.20080225143454.0bd91ec0@localhost> References: <20080218130002.05B9128C29A@core3.amsl.com> <6.0.0.20.2.20080225143454.0bd91ec0@localhost> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Disposition: inline Cc: jwz@jwz.org, Larry Masinter Subject: Re: [EAI] I-D Action:draft-ietf-eai-mailto-00.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --On Monday, 25 February, 2008 16:43 +0900 Martin Duerst wrote: >... > Of course, we could define things so that > foo > gets parsed as > display_name > (backwards compatible behavior for RFC 2396) if foo is > ASCII-only, and > internationalized > if foo (the LHS side of foo?) contains non-ASCII characters, > but we should carefully think about the consequences this has > for implementations. > Any further comments, in particular on this major point, > greatly appreciated. FWIW, I think this requires a heuristic that is just too complicated to work -- it won't be understood by users and won't be understood by systems. People will certainly try non-ASCII display names paired with ASCII mailboxes and will also try ASCII display names paired with non-ASCII mailboxes. Then you will be faced with trying to figure out just which is which, e.g., whether "foo" is a display name or an Alt-address. The fact that we have a number of mail client implementations who think they need to transform the mailbox foo@bar into the display name-mailbox pair "foo@bar" further complicates that situation. john _______________________________________________ IMA mailing list IMA@ietf.org http://www.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Feb 26 13:20:26 2008 Return-Path: X-Original-To: ietfarch-ima-archive@core3.amsl.com Delivered-To: ietfarch-ima-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E235F28C331; Tue, 26 Feb 2008 13:20:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.75 X-Spam-Level: X-Spam-Status: No, score=-0.75 tagged_above=-999 required=5 tests=[AWL=-0.313, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q46Q7hRcfre5; Tue, 26 Feb 2008 13:20:25 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C14428C4FC; Tue, 26 Feb 2008 13:20:25 -0800 (PST) X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1FD228C52E for ; Tue, 26 Feb 2008 13:20:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltpkDZUZzabl for ; Tue, 26 Feb 2008 13:20:22 -0800 (PST) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by core3.amsl.com (Postfix) with ESMTP id 3AB2C28C87F for ; Tue, 26 Feb 2008 13:20:07 -0800 (PST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JU7DS-0008SX-NX for ima@ietf.org; Tue, 26 Feb 2008 21:19:58 +0000 Received: from 1cust125.tnt1.hbg2.deu.da.uu.net ([149.225.10.125]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 26 Feb 2008 21:19:58 +0000 Received: from nobody by 1cust125.tnt1.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 26 Feb 2008 21:19:58 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Tue, 26 Feb 2008 22:21:20 +0100 Organization: Lines: 179 Message-ID: References: <20080218130002.05B9128C29A@core3.amsl.com> <6.0.0.20.2.20080225143454.0bd91ec0@localhost> Mime-Version: 1.0 X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 1cust125.tnt1.hbg2.deu.da.uu.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2800.1914 Subject: Re: [EAI] I-D Action:draft-ietf-eai-mailto-00.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Frank Ellermann List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org Martin Duerst wrote: >> Oops, I thought the idea was to finish mailto-bis *before* >> tackling mailto-eai. > Well, yes in theory, but in practice, it makes quite a bit > of sense to have these activities overlap. See below for > an example. Maybe, but then let's please pick this list to hash out the details, it is too confusing if it involves three lists (EAI, URI, RFC822). Here's how I see the mailto mess: RFC 1738 had a very simple mailto: concept based on RFC 822 given as encoded822addr = 1*xchar used to be or or . is what is today known as STD 66 . Figuring out what and was, and what it is today can be difficult. But ",", ";", "?", "&", and "=" were allowed in RFC 1738 mailto URIs. RFC 2368 introduced the concept of a query-part introduced by "?" with "&" separated name "=" value pairs. Therefore we can forget RFC 1738 noting "," and ";" as still allowed. RFC 2368 also replaced by . But that was an error, and mailto-bis will fix it. RFC 2368 used the infamous #-rule to form comma separated lists of es. For an 822-parser the #-rule is okay, comma-separated optional elements with comments and folding white space. For a 2822 parser it's a nightmare (2822upd needed a major change to emulate the #-rule as obs-cenity). For an URI-parser the #-rule with is FUBAR, and mailto-bis tries to fix it. But so far it does not, it has %2C instead of the "," (allowed since RFC 1738) to separate elements. [ISSUE #1] RFC 2368 states that "?", "&", and "=" are reserved. That is somewhat odd, as "&" and "=" only need to be reserved after the "?". And "?" only needs to be reserved before the query part (i.e. in the list of mailto addresses). Let's assume that was a simplification in RFC 2368, using the same rules on both sides of the "?". But mailto-bis claims that ";" has to be percent encoded, in addition to "&" and ";". It was always okay to use semicolon "as is", so I guess that's wrong in 2c1. [ISSUE #2] 2c2 states that and are not allowed, it should also state that is not allowed. [ISSUE #3] Using 2822upd instead of RFC 2822 would be clearer, you could then simply decree that all 2822upd obs-cenities are verboten. You won't miss a bit of these obscenities, guaranteed, the rest of mailto-bis is interesting enough without this cruft. 2c3 is fine for the part and wrt comments also in the part. IMO you can't say that white space is generally not allowed in , it only has to be percent-encoded when found in . [ISSUE #4] 2c4 should go to an I18N section about mailto IRIs. For an ordinary URI consumer a percent-encoded with UTF8-non-ascii makes no sense, and where it makes sense it belongs to mailto-eai, not mailto-bis. [ISSUE #5] URI producers MUST NOT use percent-encoded UTF8-non-ascii in a or of a mailto URI. There is no such thing as a domain with UTF8-non-ascii, domains in 2822upd e-mail are limited to A-labels separated by dots. 2c5 for the has it right, percent-encoded UTF8-non-ascii is reserved for mailto-EAI, simply shift 2c5 also to the I18N section with references to RFC 3987 and EAI for the details. As is 2c4 and 2c5 are confusing for the purpose of explaining non-EAI mailto URLs. The section about "body" doesn't mention that the charset is unclear, actually a bug in RFC 2368. Just saying that 2368 > 2277 implicitly means UTF-8 is shaky, at least it has to be explicitly spelled out, and also noted in the 2368-diff. [ISSUE #6] Besides I fear that "body" is an interoperability nightmare and poorly supported, so there should be a warning that anything with more than a single US ASCII line might fail miserably. The "to" idea (to= parameter) in RFC 2368 was always odd, it won't work for RFC 1738 clients ignoring a query part, it's redundant wrt the purpose of mailto without to=, and the example mailto:?to=... IMO violates the STD 66 syntax. [ISSUE #7] The NOT RECOMMENDED should be about using to= at all, using only to= isn't possible under STD 66 rules. I don't see why using the same header field name more than once is allowed, with tons of prose explaining why it most likely won't fly. Just say MUST NOT and be done with it. RFC 2368 didn't say that this is okay, for most plausible header fields in a mailto URL RFC 2822 allows at most one occurence. [ISSUE #8] Keywords are unlimited in 2822upd, but I've never seen an e-mail with multiple keywords, let alone a mailto URL using multiple keywords. Netnews does not allow multiple keywords. RFC 2368 says Bcc is a bad idea, mailto-bis claims that it is okay. RFC 2368 got it right, Cc is good enough in URLs. [ISSUE #9] RFC 2368 gives more examples of bad ideas, but the mailto-bis chapter about unsafe header fields gives not a single example, it also doesn't mention Reply-To as "new" known good idea (but it's explained in an example later). Chapter 6 should be renamed to I18N considerations, adding 2c4 and 2c5 wholesale with references to RFC 3987, EAI, and BCP 18 as mentioned above (issues #5 and #6). Percent encoding UTF-8 as outlined in the "non-ascii" part of chapter 2 (2nd point in the 2nd list) doesn't help, only RFC 2047 can be expected to work (outside of EAI) with who knows what legacy MUA using its very own idea of a "local" charset. RFC 2368 got this right: | 8-bit characters in mailto URLs are forbidden. MIME | encoded words (as defined in [RFC2047]) are permitted | in header values, but not for any part of a "body" hname. There is no such thing as a mail header field using UTF-8 outside of EAI (message/global). And mailto-bis prepares a message/rfc822, not a message/global. [ISSUE #10] Only for body= it's arguably possible to permit UTF-8, based on the shaky 2368 > 2277 theory, IOW assuming an RFC 2368 bug. Chapter 7.3 uses UTF-8 in header fields, that belongs into mailto-eai (message/global), not mailto-bis. The examples in 7.3 using RFC 2047 are okay for a message/rfc822 header. > we still can use the time to move ahead and tease out issues. Okay, ten issues, I hope I didn't forget anything already reported for mailto-bis-04 and before. > When drafting mailto-eai, I was looking at the utf8headers > draft and decided that in order to get a syntax definition > for the > construct, the best > thing to pick was . IMHO mailto-eai should not be completely different from the old RFC 1738 idea , reenforced in mailto-bis, and reflecting common practice, no matter what RFC 2368 says - was a mistake, Paul said this, one of the authors. > The first alternative might be to use > internationalized > or some such, but that might not fly because it would > just be interpreted as > display_name Point. After the long rant about legacy MUAs, and why they won't get UTF-8 right, I cannot suddenly assume that they would understand EAI syntax. In fact EAI addresses cannot work at all with legacy MUAs, unless the MUA is so stupid that it never notes that it is trying something "unusual", delegating all trivial error handling to the MSA But I still don't want the in utf8-headers, for nested angle brackets you need something like... "<" utf8-addr-spec [ alt-address ] ">" ...minus 2822 obs-cenities, and with a single space instead of FWS, let alone 1*FWS. Frank _______________________________________________ IMA mailing list IMA@ietf.org http://www.ietf.org/mailman/listinfo/ima