From randy@qualcomm.com Tue Oct 6 15:44:10 2009 Return-Path: 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 EEA1E28C125 for ; Tue, 6 Oct 2009 15:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.522 X-Spam-Level: X-Spam-Status: No, score=-105.522 tagged_above=-999 required=5 tests=[AWL=1.077, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 5inbI+besmNq for ; Tue, 6 Oct 2009 15:44:02 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 6BB8028C1D2 for ; Tue, 6 Oct 2009 15:44:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1254869139; x=1286405139; h=message-id:in-reply-to:references:x-mailer: x-message-note:date:to:from:subject:mime-version: content-type:x-random-sig-tag:x-ironport-av; z=Message-ID:=20 |In-Reply-To:=20<6.2.5.6.2.20090830221729.02f9d248@elandn ews.com>=0D=0A=20<6.2.5.6.2.20090830230838.02f4f830@resis tor.net>=0D=0A=20|References:=20<6.2.5.6.2.20090830221729. 02f9d248@elandnews.com>=0D=0A=20<6.2.5.6.2.20090830221729 .02f9d248@elandnews.com>=0D=0A=20=09=0D=0A=20<6.2.5.6.2.20 090830230838.02f4f830@resistor.net>=0D=0A=20<6.2.5.6.2.20 090830221729.02f9d248@elandnews.com>=0D=0A=20|X-Mailer:=20 Eudora=20for=20Mac=20OS=20X|X-message-Note:=20Warning:=20 Outlook=20in=20use.=20=20Upgrade=20to=20Eudora:=20|Date:=20Tue,=206=20Oct=202009=2015:45:03 =20-0700|To:=20SM=20,=20EAI=20WG=20,=0D=0A=20=20=20=20=20=20=20=20Philip=20Guenther =0D=0A=09|From:=20Randall=20Ge llens=20|Subject:=20Re:=20[EAI]=20Com ments=20on=20draft-ietf-eai-pop-06|MIME-Version:=201.0 |Content-Type:=20text/plain=3B=20charset=3D"us-ascii"=3B =20format=3Dflowed|X-Random-Sig-Tag:=201.0b28 |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5763"=3B=20 a=3D"24652456"; bh=6MJYweI8o5cQ6mWGkYxGrAqcwt2XaIgns8114BtoGZQ=; b=F4R9wsHnt59kLuXy1nPUILMEXTGCkPErF3hvTd959RMoobPz3RmYpkH2 KC9THkaISfFeQG171azqNiD+wqxhJbweRTUz9XA5lOSa50AH+D67SBo/a P9DNGMjIEgSXYYIciaC2uZdn6buYKXtHuVLSTGA3lKMkdxRB+/P0kvdmd w=; X-IronPort-AV: E=McAfee;i="5300,2777,5763"; a="24652456" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Oct 2009 15:45:38 -0700 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n96Mjb64021902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 6 Oct 2009 15:45:37 -0700 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n96MjPqn014100 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 6 Oct 2009 15:45:30 -0700 Received: from nasanexmsp02.na.qualcomm.com (10.45.56.203) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 6 Oct 2009 15:45:25 -0700 Received: from [192.168.1.13] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.203) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 6 Oct 2009 15:45:25 -0700 Message-ID: In-Reply-To: <6.2.5.6.2.20090830221729.02f9d248@elandnews.com> <6.2.5.6.2.20090830230838.02f4f830@resistor.net> References: <6.2.5.6.2.20090830221729.02f9d248@elandnews.com> <6.2.5.6.2.20090830221729.02f9d248@elandnews.com> <6.2.5.6.2.20090830230838.02f4f830@resistor.net> <6.2.5.6.2.20090830221729.02f9d248@elandnews.com> X-Mailer: Eudora for Mac OS X X-message-Note: Warning: Outlook in use. Upgrade to Eudora: Date: Tue, 6 Oct 2009 15:45:03 -0700 To: SM , EAI WG , Philip Guenther From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 Subject: Re: [EAI] Comments on draft-ietf-eai-pop-06 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: , X-List-Received-Date: Tue, 06 Oct 2009 22:44:11 -0000 Thanks, the typo has been fixed. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- One should always be a little improbable. --Oscar Wilde From root@core3.amsl.com Tue Oct 6 16:30:02 2009 Return-Path: X-Original-To: ima@ietf.org Delivered-To: ima@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 40AC73A677E; Tue, 6 Oct 2009 16:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091006233002.40AC73A677E@core3.amsl.com> Date: Tue, 6 Oct 2009 16:30:02 -0700 (PDT) Cc: ima@ietf.org Subject: [EAI] I-D Action:draft-ietf-eai-pop-07.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: , X-List-Received-Date: Tue, 06 Oct 2009 23:30:02 -0000 --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) : R. Gellens, C. Newman Filename : draft-ietf-eai-pop-07.txt Pages : 15 Date : 2009-10-06 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-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-eai-pop-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-06162020.I-D@ietf.org> --NextPart-- From wwwrun@core3.amsl.com Tue Oct 6 16:45:06 2009 Return-Path: X-Original-To: ima@ietf.org Delivered-To: ima@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id D8E6E3A698B; Tue, 6 Oct 2009 16:44:51 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20091006234452.D8E6E3A698B@core3.amsl.com> Date: Tue, 6 Oct 2009 16:44:51 -0700 (PDT) Cc: ima@ietf.org Subject: [EAI] Last Call: draft-ietf-eai-pop (POP3 Support for UTF-8) to Experimental RFC X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 23:45:07 -0000 The IESG has received a request from the Email Address Internationalization WG (eai) to consider the following document: - 'POP3 Support for UTF-8 ' as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-10-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-eai-pop-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14991&rfc_flag=0 From alexey.melnikov@isode.com Mon Oct 12 16:07:38 2009 Return-Path: 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 1CF513A69EF for ; Mon, 12 Oct 2009 16:07:38 -0700 (PDT) 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 XbDQ-Z0CJQz6 for ; Mon, 12 Oct 2009 16:07:37 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 20BFA3A69E8 for ; Mon, 12 Oct 2009 16:07:37 -0700 (PDT) Received: from [94.197.202.101] (94.197.202.101.threembb.co.uk [94.197.202.101]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 13 Oct 2009 00:07:37 +0100 Message-ID: <4AD3B6A5.5090507@isode.com> Date: Tue, 13 Oct 2009 00:07:17 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: ima@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [EAI] IRI BOF in Hiroshima 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: , X-List-Received-Date: Mon, 12 Oct 2009 23:07:38 -0000 Folks, Internationalized Resource Identifiers (IRI) BOF in Hiroshima is going to be talking about mailto: URIs and IRIs. This is related to the discussion on this mailing list about extending mailto: versa designing a new URI/IRI scheme. So if you are attending the Hiroshima IETF and interested in this topic, please come to the IRI BOF. More information can be found: Regards, Alexey From alexey.melnikov@isode.com Mon Oct 12 16:10:48 2009 Return-Path: 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 BCE1C3A6997 for ; Mon, 12 Oct 2009 16:10:48 -0700 (PDT) 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=[AWL=0.000, 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 Hd4g8iiWFZeh for ; Mon, 12 Oct 2009 16:10:48 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 558D73A67D9 for ; Mon, 12 Oct 2009 16:10:47 -0700 (PDT) Received: from [94.197.202.101] (94.197.202.101.threembb.co.uk [94.197.202.101]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 13 Oct 2009 00:10:44 +0100 Message-ID: <4AD3B75C.9070201@isode.com> Date: Tue, 13 Oct 2009 00:10:20 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: ima@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [EAI] Status of draft-ietf-eai-downgraded-display-02.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: , X-List-Received-Date: Mon, 12 Oct 2009 23:10:48 -0000 IESG has reviewed this document last Thursday. There is only one DISCUSS blocking publication of this document: ============= Pasi Eronen: Discuss: [2009-10-06] I have reviewed draft-ietf-eai-downgraded-display-02, and have couple of questions/concerns that I'd like to discuss before recommending approval of the document: - I found the algorithm in Section 4 extremely difficult to understand. For example, in Step 2 one could assume the generated header fields are added to the "edit space" -- but the example later suggests that's probably not the case. And it's very unclear why Step 6 applies also to "Address Header Fields' Preservation Header Fields", or what it does for them (I thought those are already processed by steps 1...5). I'd suggest some rewriting here to add clarity. - Section 5 says hiding the information from the actual header fields isn't a problem if the comparison done in step 4 succeeds. But this step applies only to address header fields, right? What about non-address header fields? ============= The document needs to be updated to clarify these issues. Thanks, Alexey From duerst@it.aoyama.ac.jp Wed Oct 14 08:41:27 2009 Return-Path: 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 F1EDF3A69AB for ; Wed, 14 Oct 2009 08:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.747 X-Spam-Level: ** X-Spam-Status: No, score=2.747 tagged_above=-999 required=5 tests=[AWL=1.469, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] 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 hucmD-2axCUr for ; Wed, 14 Oct 2009 08:41:25 -0700 (PDT) Received: from scmailgw01.scop.aoyama.ac.jp (scmailgw01.scop.aoyama.ac.jp [133.2.251.41]) by core3.amsl.com (Postfix) with ESMTP id 822923A68A6 for ; Wed, 14 Oct 2009 08:41:25 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp (scmse02.scbb.aoyama.ac.jp [133.2.253.159]) by scmailgw01.scop.aoyama.ac.jp (secret/secret) with SMTP id n9EFfREt019257 for ; Thu, 15 Oct 2009 00:41:27 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 7543_08f11390_b8d8_11de_ab24_001d096c5782; Thu, 15 Oct 2009 00:41:27 +0900 Received: from [IPv6:::1] ([133.2.210.1]:48004) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 15 Oct 2009 00:38:00 +0900 Message-ID: <4AD5558B.9060203@it.aoyama.ac.jp> Date: Wed, 14 Oct 2009 13:37:31 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: Alexey Melnikov References: <4A78218E.90608@isode.com> In-Reply-To: <4A78218E.90608@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "public-iri@w3.org" , Jamie Zawinsky , "ima@ietf.org" Subject: Re: [EAI] [Fwd: AD review of draft-duerst-mailto-bis-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: , X-List-Received-Date: Wed, 14 Oct 2009 15:41:27 -0000 Hello Alex, On 2009/08/04 20:54, Alexey Melnikov wrote: > I believe I completed the todo item assigned to me during the Stockholm > meeting. Many thanks for your review. Very helpful. > as it seems to be blocking some EAI drafts. Which? EAI seems to move forward nicely. > In Section 2: > > addr-spec = local-part "@" domain > local-part = dot-atom / quoted-string > > I don't think this change goes all the way to clarify that obsolete RFC > 5322 syntax and comments are disallowed. > RFC 5322: > domain = dot-atom / domain-literal / obs-domain > > domain-literal = [CFWS] "[" *([FWS] dtext) [FWS] "]" [CFWS] > > dot-atom-text = 1*atext *("." 1*atext) > > dot-atom = [CFWS] dot-atom-text [CFWS] > > atom = [CFWS] 1*atext [CFWS] > > obs-domain = atom *("." atom) > > I think "obs-domain" and "domain-literal" definitions are problematic > (at least). I changed 'domain' too simply be 'dot-atom'. I hope this works. (not exactly my area of expertise) > Within 'mailto' URIs, the characters "?", "=", and "&" are reserved. > > "Reserved" in URI sense? If yes, I think this can be made clearer. Changed the text to read: Within 'mailto' URIs, the characters "?", "=", and "&" are reserved, serving as delimiters. They must be escaped (as "%3F", "%3D", and "%26", respectively) when not serving as delimiters. But these are explained elsewhere in the spec, too, so that may now be too much, and may get reduced again on proofreading (after careful cross-checking). > 4. Percent-encoding can be used in the part of an spec>, in order to denote an internationalized domain name. The > considerations for in [STD66] apply. In particular, > non-ASCII characters must > > s/must/MUST ? > > first be encoded according to UTF-8 > [STD63], and then each octet of the corresponding UTF-8 sequence > must > > s/must/MUST ? > > be percent-encoded to be represented as URI characters. URI > producing applications must not > > s/must not/MUST NOT ? Fixed all of those. Sometimes adjusted wording, sometimes upper-casing and sometimes using clearly non-normative wording. > use percent-encoding in domain > names unless it is used to represent a UTF-8 character sequence. > When the internationalized domain name is used to compose a > message, the name must be transformed to the IDNA encoding where > appropriate [RFC3490]. URI producers should provide these domain > names in the IDNA encoding, rather than percent-encoded, if they > wish to maximize interoperability with legacy 'mailto' URI > interpreters. > > As per IRI bar BOF in Stockholm: this needs to be aligned with any > [potential] changes to the IRI spec. Yes. I personally don't think we need to change this (except for some more careful wording). > 5. Percent-encoding of non-ASCII octets in the of an > is reserved for the internationalization of the > . Non-ASCII characters must > > s/must/MUST ? > > first be encoded > according to UTF-8 [STD63], and then each octet of the > corresponding UTF-8 sequence must > > s/must/MUST ? > > be percent-encoded to be > represented as URI characters. Any other percent-encoding of > non-ASCII characters is prohibited. When a > containing non-ASCII characters will be used to compose a > message, the must > > s/must/MUST ? > > be transformed to conform to > whatever encoding may be defined in a future specification for > the internationalization of email addresses. > > [...] > > Non-ASCII characters can be encoded in hfvalue as follows: > [...] > > 2. Non-ASCII characters can be encoded according to UTF-8 [STD63], > and then each octet of the corresponding UTF-8 sequence is > percent-encoded to be represented as URI characters. When header > field values encoded in this way are used to compose a message, > the must > > s/must/MUST ? Done (sometimes with wording changes). > be transformed into MIME encoded words > [RFC2047], except for an of a "body" , which > has to be encoded according to [RFC2045]. Please note that for > MIME encoded words and for bodies in composed email messages, > encodings other than UTF-8 MAY be used as long as the characters > are properly transcoded. > > [...] > > MIME encoded words and UTF-8-based percent-encoding SHOULD NOT both > be used sequentially in the same , and MUST NOT be combined. > > Can you clarify what you are trying to say here? > In particular I am not clear on the meaning of "sequentially" here. Ok. Sequentially means e.g. using MIME for the first word in the subject, and UTF-8-based percent-encoding for the second word. As for the "MUST NOT be combined", that either makes MIME completely impossible ('?' and '=' used in MIME encoded words have to be reencoded, but that isn't allowed) or leaves that provision hanging in the air ('?' and '=' are US-ASCII, so UTF-8 is irrelevant when percent-encoding them) depending on the interpretation of 'UTF-8'. So that has to be fixed. First I was thinking about replacing the paragraph with something like: "In mailto: URIs, UTF-8-based percent-encoding is preferred to MIME encoded words because for the later, the '=' and '?' characters have to be percent-encoded." But then that's also slightly inappropriate because MIME encoded words may work in some old implementations where UTF-8 doesn't. Then I went ahead and deleted that paragraph (because even 'sequential' mixing may be okay assuming implementations peel off one encoding layer after the other), and just inserted a short notice about the need to percent-encode '=' and '?' in point 1. a few lines above. > In Section 3: > > In current practice, resolving URIs such as those in the 'http' URI > scheme causes an immediate interaction between client software and a > host running an interactive server. The 'mailto' URI has unusual > semantics because resolving such a URI does not cause an immediate > interaction. Instead, the client creates a message to the designated > address with the various header fields set as default. The user can > edit the message, send this message unedited, or choose not to send > the message. The operation of how any URI scheme is resolved is not > mandated by the URI specifications. > > The last sentence doesn't seem to be related to the rest of the > paragraph. Should it be deleted or moved to a separate paragraph? This sentence is giving the motivation for why the paragraph starts with "in current practice" and why there isn't a more normative definition along the lines of "to resolve a 'mailto' URI scheme, you MUST ...". So the position of this sentence seems okay to me. If you have any proposal for how to make this clearer, I'll be glad to use that. > In Section 4: > > The creator of a 'mailto' URI cannot expect the resolver of a URI to > understand more than the "subject" header field and "body". > > What about the "To" header field? I don't know too much about actual implementations, but the fact that what corresponds to 'To' is usually given befor the '?' seems to suggest to me that universal support for 'To' is neither necessary nor therefore guaranteed. > Clients > that resolve 'mailto' URIs into mail messages MUST be able to > correctly create [RFC5322]-compliant mail messages using the > "subject" header field and "body". > > In Section 8: > > A 'mailto' URI gives a template for a message that can be sent by > mail client software. The contents of that template may be opaque or > difficult to read by the user at the time of specifying the URI. > Thus, a mail client should never send a message based on a 'mailto' > > s/should/SHOULD ? > > URI without first showing the full message that will be sent to the > user (including all header fields that were specified by the 'mailto' > URI), fully decoded, and asking the user for approval to send the > message as electronic mail. The mail client should also make it > > s/should/SHOULD > > clear that the user is about to send an electronic mail message, > since the user may not be aware that this is the result of a 'mailto' > URI. > > A mail client should never send anything without complete disclosure > > s/should/SHOULD > > to the user of what will be sent; it should disclose not only the > > s/should/SHOULD Done. > message destination, but also any header fields. Unrecognized header > fields, or header fields with values inconsistent with those the mail > client would normally send should be especially suspect. MIME header > fields (MIME- Version, Content-*) are most likely inappropriate, > except when added by the MUA to correctly encode the text(s) being > sent, as are those relating to routing (From, Apparently-To, etc.) > > > 9. IANA Considerations > > This document changes the definition of the 'mailto' URI scheme; the > registry of URI schemes needs to be updated to refer to this document > rather than its predecessor, [RFC2368]. > > It doesn't look like the proper URI registration template was ever > specified in this document or its predecessor. Of course not in its predecessor, that was before we had any templates, I guess. Anyway, I added a template, please have a look at it when I post the draft. Regards, Martin. -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From alexey.melnikov@isode.com Fri Oct 16 12:49:45 2009 Return-Path: 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 89F6D28C0F5 for ; Fri, 16 Oct 2009 12:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.325 X-Spam-Level: X-Spam-Status: No, score=-2.325 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 hgu97OYywL3F for ; Fri, 16 Oct 2009 12:49:44 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 16A733A63D3 for ; Fri, 16 Oct 2009 12:49:44 -0700 (PDT) Received: from [172.16.2.200] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 16 Oct 2009 20:49:47 +0100 Message-ID: <4AD8CE34.1030800@isode.com> Date: Fri, 16 Oct 2009 20:49:08 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= References: <4A78218E.90608@isode.com> <4AD5558B.9060203@it.aoyama.ac.jp> In-Reply-To: <4AD5558B.9060203@it.aoyama.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: quoted-printable Cc: "public-iri@w3.org" , Jamie Zawinsky , "ima@ietf.org" Subject: Re: [EAI] [Fwd: AD review of draft-duerst-mailto-bis-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: , X-List-Received-Date: Fri, 16 Oct 2009 19:49:45 -0000 Martin J. D=FCrst wrote: > Hello Alex, Hi Martin, > On 2009/08/04 20:54, Alexey Melnikov wrote: > >> I believe I completed the todo item assigned to me during the Stockholm >> meeting. > > Many thanks for your review. Very helpful. > > > as it seems to be blocking some EAI drafts. > > Which? EAI seems to move forward nicely. I think it was either the "mailing lists" or the "downgrade" document. > > In Section 2: > > > > addr-spec =3D local-part "@" domain > > local-part =3D dot-atom / quoted-string > > > > I don't think this change goes all the way to clarify that obsolete RFC > > 5322 syntax and comments are disallowed. > > RFC 5322: > > domain =3D dot-atom / domain-literal / obs-domain > > > > domain-literal =3D [CFWS] "[" *([FWS] dtext) [FWS] "]" [CFWS] > > > > dot-atom-text =3D 1*atext *("." 1*atext) > > > > dot-atom =3D [CFWS] dot-atom-text [CFWS] > > > > atom =3D [CFWS] 1*atext [CFWS] > > > > obs-domain =3D atom *("." atom) > > > > I think "obs-domain" and "domain-literal" definitions are problematic > > (at least). > > I changed 'domain' too simply be 'dot-atom'. I hope this works. > (not exactly my area of expertise) I think a version of "domain-literal" which doesn't allow CFWS/FWS is=20 also needed. E.g. to allow IPv6. Ok, this might be obscure. But I think earlier versions allowed for that. > > Within 'mailto' URIs, the characters "?", "=3D", and "&" are reserved. > > > > "Reserved" in URI sense? If yes, I think this can be made clearer. > > Changed the text to read: > > Within 'mailto' URIs, the characters "?", "=3D", and "&" are reserved,=20 > serving as delimiters. They must be escaped (as "%3F", "%3D", and=20 > "%26", respectively) when not serving as delimiters. Sounds good to me. > But these are explained elsewhere in the spec, too, so that may now be=20 > too much, and may get reduced again on proofreading (after careful=20 > cross-checking). Ok. > > 4. Percent-encoding can be used in the part of an > spec>, in order to denote an internationalized domain name. The > > considerations for in [STD66] apply. In particular, > > non-ASCII characters must > > > > s/must/MUST ? > > > > first be encoded according to UTF-8 > > [STD63], and then each octet of the corresponding UTF-8 sequence > > must > > > > s/must/MUST ? > > > > be percent-encoded to be represented as URI characters. URI > > producing applications must not > > > > s/must not/MUST NOT ? > > Fixed all of those. Sometimes adjusted wording, sometimes upper-casing=20 > and sometimes using clearly non-normative wording. Ok. > > use percent-encoding in domain > > names unless it is used to represent a UTF-8 character sequence. > > When the internationalized domain name is used to compose a > > message, the name must be transformed to the IDNA encoding where > > appropriate [RFC3490]. URI producers should provide these domain > > names in the IDNA encoding, rather than percent-encoded, if they > > wish to maximize interoperability with legacy 'mailto' URI > > interpreters. > > > > As per IRI bar BOF in Stockholm: this needs to be aligned with any > > [potential] changes to the IRI spec. > > Yes. I personally don't think we need to change this (except for some=20 > more careful wording). [...] > > [...] > > > > MIME encoded words and UTF-8-based percent-encoding SHOULD NOT both > > be used sequentially in the same , and MUST NOT be combined. > > > > Can you clarify what you are trying to say here? > > In particular I am not clear on the meaning of "sequentially" here. > Ok. Sequentially means e.g. using MIME for the first word in the=20 > subject, and UTF-8-based percent-encoding for the second word. > > As for the "MUST NOT be combined", that either makes MIME completely=20 > impossible ('?' and '=3D' used in MIME encoded words have to be=20 > reencoded, but that isn't allowed) or leaves that provision hanging in=20 > the air ('?' and '=3D' are US-ASCII, so UTF-8 is irrelevant when=20 > percent-encoding them) depending on the interpretation of 'UTF-8'. So=20 > that has to be fixed. > > First I was thinking about replacing the paragraph with something like: > "In mailto: URIs, UTF-8-based percent-encoding is preferred to MIME=20 > encoded words because for the later, the '=3D' and '?' characters have=20 > to be percent-encoded." > > But then that's also slightly inappropriate because MIME encoded words=20 > may work in some old implementations where UTF-8 doesn't. Then I went=20 > ahead and deleted that paragraph (because even 'sequential' mixing may=20 > be okay assuming implementations peel off one encoding layer after the=20 > other), and just inserted a short notice about the need to=20 > percent-encode '=3D' and '?' in point 1. a few lines above. Some explanation of this in the document might be useful though. > > In Section 3: > > > > In current practice, resolving URIs such as those in the 'http' URI > > scheme causes an immediate interaction between client software and a > > host running an interactive server. The 'mailto' URI has unusual > > semantics because resolving such a URI does not cause an immediate > > interaction. Instead, the client creates a message to the designated > > address with the various header fields set as default. The user can > > edit the message, send this message unedited, or choose not to send > > the message. The operation of how any URI scheme is resolved is not > > mandated by the URI specifications. > > > > The last sentence doesn't seem to be related to the rest of the > > paragraph. Should it be deleted or moved to a separate paragraph? > > This sentence is giving the motivation for why the paragraph starts=20 > with "in current practice" and why there isn't a more normative=20 > definition along the lines of "to resolve a 'mailto' URI scheme, you=20 > MUST ...". So the position of this sentence seems okay to me. If you=20 > have any proposal for how to make this clearer, I'll be glad to use that. It might be better to move this sentence to the beginning of this paragraph? > > In Section 4: > > > > The creator of a 'mailto' URI cannot expect the resolver of a URI to > > understand more than the "subject" header field and "body". > > > > What about the "To" header field? > > I don't know too much about actual implementations, but the fact that=20 > what corresponds to 'To' is usually given befor the '?' seems to=20 > suggest to me that universal support for 'To' is neither necessary nor=20 > therefore guaranteed. It might be good to do some research on this. If mailto URI parameters are handled at all, I would be expecting To and=20 the address at the beginning to be always handled. > > Clients > > that resolve 'mailto' URIs into mail messages MUST be able to > > correctly create [RFC5322]-compliant mail messages using the > > "subject" header field and "body". [...] > > message destination, but also any header fields. Unrecognized header > > fields, or header fields with values inconsistent with those the mail > > client would normally send should be especially suspect. MIME header > > fields (MIME- Version, Content-*) are most likely inappropriate, > > except when added by the MUA to correctly encode the text(s) being > > sent, as are those relating to routing (From, Apparently-To, etc.) > > > > > > 9. IANA Considerations > > > > This document changes the definition of the 'mailto' URI scheme; the > > registry of URI schemes needs to be updated to refer to this document > > rather than its predecessor, [RFC2368]. > > > > It doesn't look like the proper URI registration template was ever > > specified in this document or its predecessor. > > Of course not in its predecessor, that was before we had any=20 > templates, I guess. Anyway, I added a template, please have a look at=20 > it when I post the draft. Thanks. From root@core3.amsl.com Thu Oct 22 14:30:08 2009 Return-Path: X-Original-To: ima@ietf.org Delivered-To: ima@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 80FFF3A6896; Thu, 22 Oct 2009 14:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091022213008.80FFF3A6896@core3.amsl.com> Date: Thu, 22 Oct 2009 14:30:01 -0700 (PDT) Cc: ima@ietf.org Subject: [EAI] I-D Action:draft-ietf-eai-pop-08.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: , X-List-Received-Date: Thu, 22 Oct 2009 21:30:08 -0000 --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) : R. Gellens, C. Newman Filename : draft-ietf-eai-pop-08.txt Pages : 16 Date : 2009-10-22 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-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-eai-pop-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-22142506.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Sun Oct 25 19:30:01 2009 Return-Path: X-Original-To: ima@ietf.org Delivered-To: ima@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C15913A6805; Sun, 25 Oct 2009 19:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091026023001.C15913A6805@core3.amsl.com> Date: Sun, 25 Oct 2009 19:30:01 -0700 (PDT) Cc: ima@ietf.org Subject: [EAI] I-D Action:draft-ietf-eai-pop-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: , X-List-Received-Date: Mon, 26 Oct 2009 02:30:01 -0000 --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) : R. Gellens, C. Newman Filename : draft-ietf-eai-pop-09.txt Pages : 17 Date : 2009-10-25 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-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-eai-pop-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-25192727.I-D@ietf.org> --NextPart-- From duerst@it.aoyama.ac.jp Mon Oct 26 00:52:25 2009 Return-Path: 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 4FDFD3A6A32 for ; Mon, 26 Oct 2009 00:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.056 X-Spam-Level: * X-Spam-Status: No, score=1.056 tagged_above=-999 required=5 tests=[AWL=0.846, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] 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 TdZfvI7ONRdP for ; Mon, 26 Oct 2009 00:52:23 -0700 (PDT) Received: from scmailgw02.scop.aoyama.ac.jp (scmailgw02.scop.aoyama.ac.jp [133.2.251.42]) by core3.amsl.com (Postfix) with ESMTP id 051333A6898 for ; Mon, 26 Oct 2009 00:52:22 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp (scmse01.scbb.aoyama.ac.jp [133.2.253.158]) by scmailgw02.scop.aoyama.ac.jp (secret/secret) with SMTP id n9Q7qPZS006769 for ; Mon, 26 Oct 2009 16:52:25 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 76eb_8002ae14_c204_11de_b2d8_001d096c566a; Mon, 26 Oct 2009 16:52:25 +0900 Received: from [IPv6:::1] ([133.2.210.1]:57867) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 26 Oct 2009 16:48:56 +0900 Message-ID: <4AE5552D.6000406@it.aoyama.ac.jp> Date: Mon, 26 Oct 2009 16:52:13 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: Alexey Melnikov References: <4A78218E.90608@isode.com> <4AD5558B.9060203@it.aoyama.ac.jp> <4AD8CE34.1030800@isode.com> In-Reply-To: <4AD8CE34.1030800@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "public-iri@w3.org" , Jamie Zawinsky , "ima@ietf.org" Subject: Re: [EAI] [Fwd: AD review of draft-duerst-mailto-bis-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: , X-List-Received-Date: Mon, 26 Oct 2009 07:52:25 -0000 Hello Alex, others, Sorry to be late with this answer. Please check draft-duerst-mailto-bis-07.txt (soon to appear) to see whether the updates are according to your expectations. On 2009/10/17 4:49, Alexey Melnikov wrote: > Martin J. Dürst wrote: > >> Hello Alex, > > Hi Martin, > >> On 2009/08/04 20:54, Alexey Melnikov wrote: >> >>> I believe I completed the todo item assigned to me during the Stockholm >>> meeting. >> >> Many thanks for your review. Very helpful. >> >> > as it seems to be blocking some EAI drafts. >> >> Which? EAI seems to move forward nicely. > > I think it was either the "mailing lists" or the "downgrade" document. Ok. >> > In Section 2: >> > >> > addr-spec = local-part "@" domain >> > local-part = dot-atom / quoted-string >> > >> > I don't think this change goes all the way to clarify that obsolete RFC >> > 5322 syntax and comments are disallowed. >> > RFC 5322: >> > domain = dot-atom / domain-literal / obs-domain >> > >> > domain-literal = [CFWS] "[" *([FWS] dtext) [FWS] "]" [CFWS] >> > >> > dot-atom-text = 1*atext *("." 1*atext) >> > >> > dot-atom = [CFWS] dot-atom-text [CFWS] >> > >> > atom = [CFWS] 1*atext [CFWS] >> > >> > obs-domain = atom *("." atom) >> > >> > I think "obs-domain" and "domain-literal" definitions are problematic >> > (at least). >> >> I changed 'domain' too simply be 'dot-atom'. I hope this works. >> (not exactly my area of expertise) > > I think a version of "domain-literal" which doesn't allow CFWS/FWS is > also needed. E.g. to allow IPv6. > Ok, this might be obscure. But I think earlier versions allowed for that. Can you (or somebody else) tell me exactly what to do? For me, all this mail-related syntax is very unsure ground. >> > 4. Percent-encoding can be used in the part of an > > spec>, in order to denote an internationalized domain name. The >> > considerations for in [STD66] apply. In particular, >> > non-ASCII characters must >> > >> > s/must/MUST ? >> > >> > first be encoded according to UTF-8 >> > [STD63], and then each octet of the corresponding UTF-8 sequence >> > must >> > >> > s/must/MUST ? >> > >> > be percent-encoded to be represented as URI characters. URI >> > producing applications must not >> > >> > s/must not/MUST NOT ? >> >> Fixed all of those. Sometimes adjusted wording, sometimes upper-casing >> and sometimes using clearly non-normative wording. > > Ok. Please check the newest draft. >> > [...] >> > >> > MIME encoded words and UTF-8-based percent-encoding SHOULD NOT both >> > be used sequentially in the same , and MUST NOT be combined. >> > >> > Can you clarify what you are trying to say here? >> > In particular I am not clear on the meaning of "sequentially" here. > >> Ok. Sequentially means e.g. using MIME for the first word in the >> subject, and UTF-8-based percent-encoding for the second word. >> >> As for the "MUST NOT be combined", that either makes MIME completely >> impossible ('?' and '=' used in MIME encoded words have to be >> reencoded, but that isn't allowed) or leaves that provision hanging in >> the air ('?' and '=' are US-ASCII, so UTF-8 is irrelevant when >> percent-encoding them) depending on the interpretation of 'UTF-8'. So >> that has to be fixed. >> >> First I was thinking about replacing the paragraph with something like: >> "In mailto: URIs, UTF-8-based percent-encoding is preferred to MIME >> encoded words because for the later, the '=' and '?' characters have >> to be percent-encoded." >> >> But then that's also slightly inappropriate because MIME encoded words >> may work in some old implementations where UTF-8 doesn't. Then I went >> ahead and deleted that paragraph (because even 'sequential' mixing may >> be okay assuming implementations peel off one encoding layer after the >> other), and just inserted a short notice about the need to >> percent-encode '=' and '?' in point 1. a few lines above. > > Some explanation of this in the document might be useful though. I have looked through the document again. I think that points 1. and 2. (just after "Non-ASCII characters can be encoded in hfvalue as follows:") are perfectly enough. There's also an example of both using UTF-8 and encoded-word syntax at the start of Section 6.3. If you really think more is needed, then please propose some wording. >> > In Section 3: >> > >> > In current practice, resolving URIs such as those in the 'http' URI >> > scheme causes an immediate interaction between client software and a >> > host running an interactive server. The 'mailto' URI has unusual >> > semantics because resolving such a URI does not cause an immediate >> > interaction. Instead, the client creates a message to the designated >> > address with the various header fields set as default. The user can >> > edit the message, send this message unedited, or choose not to send >> > the message. The operation of how any URI scheme is resolved is not >> > mandated by the URI specifications. >> > >> > The last sentence doesn't seem to be related to the rest of the >> > paragraph. Should it be deleted or moved to a separate paragraph? >> >> This sentence is giving the motivation for why the paragraph starts >> with "in current practice" and why there isn't a more normative >> definition along the lines of "to resolve a 'mailto' URI scheme, you >> MUST ...". So the position of this sentence seems okay to me. If you >> have any proposal for how to make this clearer, I'll be glad to use that. > > It might be better to move this sentence to the beginning of this > paragraph? done. >> > In Section 4: >> > >> > The creator of a 'mailto' URI cannot expect the resolver of a URI to >> > understand more than the "subject" header field and "body". >> > >> > What about the "To" header field? >> >> I don't know too much about actual implementations, but the fact that >> what corresponds to 'To' is usually given befor the '?' seems to >> suggest to me that universal support for 'To' is neither necessary nor >> therefore guaranteed. > > It might be good to do some research on this. > If mailto URI parameters are handled at all, I would be expecting To and > the address at the beginning to be always handled. My expectation is different. The mailto scheme started just with the part before the '?', nothing else. Later, "Subject", and even later, "Body" were added, because they proved to be most useful (e.g. for subscription/unsubscription links,...). From such a historic viewpoint, "To" is least important, because it essentially just duplicates functionality. It's also more difficult to implement correctly than the average header field, because the data has to be merged. Of course if somebody can come up with some research that shows something else, I'm glad to adjust the wording. Regards, Martin. -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From duerst@it.aoyama.ac.jp Mon Oct 26 01:41:35 2009 Return-Path: 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 B0CE93A689A for ; Mon, 26 Oct 2009 01:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.844 X-Spam-Level: X-Spam-Status: No, score=0.844 tagged_above=-999 required=5 tests=[AWL=0.634, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] 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 IcGtebpX5Thm for ; Mon, 26 Oct 2009 01:41:34 -0700 (PDT) Received: from scmailgw01.scop.aoyama.ac.jp (scmailgw01.scop.aoyama.ac.jp [133.2.251.41]) by core3.amsl.com (Postfix) with ESMTP id 9F69D3A6774 for ; Mon, 26 Oct 2009 01:41:34 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp (scmse02.scbb.aoyama.ac.jp [133.2.253.159]) by scmailgw01.scop.aoyama.ac.jp (secret/secret) with SMTP id n9Q8fatG017063 for ; Mon, 26 Oct 2009 17:41:36 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 503e_5f2e68ac_c20b_11de_9b9d_001d096c5782; Mon, 26 Oct 2009 17:41:36 +0900 Received: from [IPv6:::1] ([133.2.210.1]:50241) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 26 Oct 2009 17:38:08 +0900 Message-ID: <4AE560B4.2040804@it.aoyama.ac.jp> Date: Mon, 26 Oct 2009 17:41:24 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: "ima@ietf.org" , "public-iri@w3.org" Content-Type: multipart/mixed; boundary="------------040403090607060501060900" Subject: [EAI] [Fwd: I-D Action:draft-duerst-mailto-bis-07.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: , X-List-Received-Date: Mon, 26 Oct 2009 08:41:35 -0000 This is a multi-part message in MIME format. --------------040403090607060501060900 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit [Comments welcome to me or to public-iri@w3.org; please note that this is one of the drafts that we will take up in an IRI WG (BOF at Hiroshima)] -------- Original Message -------- Subject: I-D Action:draft-duerst-mailto-bis-07.txt Date: Mon, 26 Oct 2009 01:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The 'mailto' URI Scheme Author(s) : M. Duerst, et al. Filename : draft-duerst-mailto-bis-07.txt Pages : 21 Date : 2009-10-26 This document defines the format of Uniform Resource Identifiers (URI) to identify resources that are reached using Internet mail. It adds better internationalization and compatibility with IRIs (RFC 3987) to the previous syntax of 'mailto' URIs (RFC 2368). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-duerst-mailto-bis-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp --------------040403090607060501060900 Content-Type: Message/External-body; name="draft-duerst-mailto-bis-07.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-duerst-mailto-bis-07.txt" Content-Type: text/plain Content-ID: <2009-10-26010905.I-D@ietf.org> --------------040403090607060501060900 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1B bm5vdW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURy YWZ0IGRpcmVjdG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBm dHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0KDQo= --------------040403090607060501060900-- From Shawn.Steele@microsoft.com Mon Oct 26 12:26:37 2009 Return-Path: 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 3E54D3A6952 for ; Mon, 26 Oct 2009 12:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.11 X-Spam-Level: X-Spam-Status: No, score=-9.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8] 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 QrxvoP3YG4PP for ; Mon, 26 Oct 2009 12:26:36 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 7959E3A69AA for ; Mon, 26 Oct 2009 12:26:36 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 26 Oct 2009 12:26:49 -0700 Received: from TK5EX14MBXC137.redmond.corp.microsoft.com ([169.254.5.70]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi; Mon, 26 Oct 2009 12:26:48 -0700 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: [Fwd: AD review of draft-duerst-mailto-bis-06.txt] Thread-Index: AcpWcFByxPpxinzdRdOo8BBzPl0UJQ== Date: Mon, 26 Oct 2009 19:26:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [EAI] [Fwd: AD review of draft-duerst-mailto-bis-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: , X-List-Received-Date: Mon, 26 Oct 2009 19:26:37 -0000 Q3VycmVudGx5IGxvdHMgb2Ygc29mdHdhcmUgc2VlbSB0byBqdXN0IGFsbG93IFVuaWNvZGUgaW4g dGhlIG1haWx0bzogIChPciBhY3R1YWxseSBjb252ZXJ0IGl0IGJhc2VkIG9uIHRoZSBlbmNvZGlu ZyBvZiB0aGUgd2ViIHBhZ2UpLiAgSSdtIG5vdCBnb2luZyB0byBhcmd1ZSB3aGV0aGVyIHRoYXQn cyAiY29ycmVjdCIgb3Igbm90LCBidXQgaXQgZG9lcyBzZWVtIHRvIGJlIHRoZSBwcmV2YWlsaW5n IGN1cnJlbnQgcHJhY3RpY2UuDQoNCkZyb20gdGhlIGV4cGVyaWVuY2Ugd2l0aCBJRE4gd2hlcmUg bm9uLUFTQ0lJIHZhbHVlcyBhcmUgYmVpbmcgZGlyZWN0bHkgZW5jb2RlZCBpbiBodHRwLCBJIHRo aW5rIGl0J3MgdW5yZWFsaXN0aWMgdGhhdCBhbGwgbWFpbHRvOiBVUklzIHdpbGwgYmUgImNvcnJl Y3RseSIgJSBlc2NhcGVkLiAgT24gdGhlIGNvbnRyYXJ5LCBJIHRoaW5rIG1vc3QgcHJvYmFibHkg d29uJ3QgYmUuDQoNClNvIEknZCBsaWtlIHRoZSBtYWlsdG8tYmlzIHRvIGFsbG93IHRoYXQgYXBw bGljYXRpb25zIE1BWSByZWNvZ25pemUgdW5lc2NhcGVkIFVURi04IGluIFVURi04IGRvY3VtZW50 cy4NCg0KLVNoYXduDQoNClAuUzogWWVzLCAibG90cyIgaW5jbHVkZXMgTWljcm9zb2Z0IHNvZnR3 YXJlIHNpbmNlIGl0J3MgZWFzeSB0byBwbGF5IHdpdGguICBPbiBteSBtYWNoaW5lIGlmIEkgb3Bl biAicnVuIiwgdGhlbiB0eXBlIG1haWx0bzpzaMOkd24sIHRoZW4gT3V0bG9vayBvcGVucyB1cCB3 aXRoIHNow6R3biBpbiB0aGUgVG86IGxpbmUuICBTYW1lIHRoaW5nIGhhcHBlbnMgaWYgSSBzdGlj ayBpdCBpbiBhbiBocmVmIGluIGFuIEhUTUwgZG9jdW1lbnQuICBJIHRoaW5rIEkgZXZlbiB0cmll ZCBpdCB3aXRoIGEgZGlmZmVyZW50IGJyb3dzZXIgKHNvcnJ5LCBkb24ndCByZW1lbWJlciB3aGlj aCBvbmUsIGRvbid0IGhhdmUgb3RoZXJzIGluc3RhbGxlZCBhdCB0aGUgbW9tZW50KS4gIE9mIGNv dXJzZSBJIGNvdWxkbid0IGFjdHVhbGx5IHNlbmQgdGhlIG1haWwsIGJ1dCB0aGUgIm1haWx0byIg cGFydCB3b3JrZWQuDQoNCg0K From ted.ietf@gmail.com Mon Oct 26 13:03:43 2009 Return-Path: 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 9A2AE28C371 for ; Mon, 26 Oct 2009 13:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 rT3B7Dt8gGZL for ; Mon, 26 Oct 2009 13:03:42 -0700 (PDT) Received: from mail-px0-f173.google.com (mail-px0-f173.google.com [209.85.216.173]) by core3.amsl.com (Postfix) with ESMTP id DBADE28C361 for ; Mon, 26 Oct 2009 13:03:42 -0700 (PDT) Received: by pxi3 with SMTP id 3so2715911pxi.29 for ; Mon, 26 Oct 2009 13:03:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EWkM46dei05jevTAOFwYj5Qrj8ZvsoN7+rVdhc1vVdU=; b=REeKA7VbswwV3A5Hof2kSFPtvqQBfaNW1+yqCinyFusS1n2p+Nmw22WompJwkLVjhY N+MZJdyISrheOtojK4VeweOwX2LOYLj8Ef4B6UgJN3G2vZ/vCk8ZuTzXkKQ/kQkPSbl3 f8eVJmYJCf4GCrE9iwXfq4UiwkTfcBXnqYpoE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=gNz6q6ggsg4gRj+vbLQD+6zd9rGlTKB5pRPM0zNRvaK8LJRcXYOJDTHrXjQoedG6Za 7W8N81CSFIUdw/l7Q8+f21B4XPuHziyAYSYNr9HZc+S2p7HoxOZveVeWkUGpGekazNVm F61bRBZtglOWYxvZnzwMsXFuO1coFLCPZdnqI= MIME-Version: 1.0 Received: by 10.143.27.39 with SMTP id e39mr1192581wfj.212.1256587434084; Mon, 26 Oct 2009 13:03:54 -0700 (PDT) In-Reply-To: References: Date: Mon, 26 Oct 2009 13:03:54 -0700 Message-ID: <6e04e83a0910261303sec61a11v68d0092a5c6ae62f@mail.gmail.com> From: Ted Hardie To: Shawn Steele Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ima@ietf.org" Subject: Re: [EAI] [Fwd: AD review of draft-duerst-mailto-bis-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: , X-List-Received-Date: Mon, 26 Oct 2009 20:03:43 -0000 On Mon, Oct 26, 2009 at 12:26 PM, Shawn Steele wrote: =A0On my machine if I open "run", then type mailto:sh=E4wn, then Outlook opens up with sh=E4wn in the To: line. =A0Same thing happens if I stick it in an href in an HTML document. =A0I think I even tried it with a different browser (sorry, don't remember which one, don't have others installed at the moment). =A0Of course I couldn't actually send the mail, but the "mailto" part worked. For "the 'mailto part" to be considered to have worked, the mail has to get end to end, at least in my opinion. The problem here is fundamentally that some part of the system has to take what the user thinks is correct and turn into something that the mail system can deliver. The more pieces we allow to contain "what the user thinks is correct" rather than "what the mail system can deliver", the further down into the system any translation between the two must occur. Unless "sh=E4wn" is a valid email address, showing that in a protocol slot (which mailto is) seems like the wrong trade-off to me. YMMV; offer not good in jurisdictions legislating the value of pi. Ted From Shawn.Steele@microsoft.com Mon Oct 26 13:07:40 2009 Return-Path: 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 3586E3A65A6 for ; Mon, 26 Oct 2009 13:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.854 X-Spam-Level: X-Spam-Status: No, score=-9.854 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 SXt4oP7zxZLJ for ; Mon, 26 Oct 2009 13:07:39 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 4ED463A68B1 for ; Mon, 26 Oct 2009 13:07:39 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 26 Oct 2009 13:08:04 -0700 Received: from TK5EX14MBXC137.redmond.corp.microsoft.com ([169.254.5.70]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi; Mon, 26 Oct 2009 13:07:51 -0700 From: Shawn Steele To: Ted Hardie Thread-Topic: [EAI] [Fwd: AD review of draft-duerst-mailto-bis-06.txt] Thread-Index: AQHKVnecB+R1zgGDekCib//tdQ/nbJEYQnJw Date: Mon, 26 Oct 2009 20:07:50 +0000 Message-ID: References: <6e04e83a0910261303sec61a11v68d0092a5c6ae62f@mail.gmail.com> In-Reply-To: <6e04e83a0910261303sec61a11v68d0092a5c6ae62f@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ima@ietf.org" Subject: Re: [EAI] [Fwd: AD review of draft-duerst-mailto-bis-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: , X-List-Received-Date: Mon, 26 Oct 2009 20:07:40 -0000 Yes, end-to-end would be working, however consider if Office-That-Supports-= EAI is installed on Win7, then this would've worked. If the OS is then upg= raded, users will expect it to continue working. -Shawn -----Original Message----- From: Ted Hardie [mailto:ted.ietf@gmail.com]=20 Sent: Monday, October 26, 2009 1:04 PM To: Shawn Steele Cc: ima@ietf.org Subject: Re: [EAI] [Fwd: AD review of draft-duerst-mailto-bis-06.txt] On Mon, Oct 26, 2009 at 12:26 PM, Shawn Steele = wrote: =A0On my machine if I open "run", then type mailto:sh=E4wn, then Outlook op= ens up with sh=E4wn in the To: line. =A0Same thing happens if I stick it in= an href in an HTML document. =A0I think I even tried it with a different b= rowser (sorry, don't remember which one, don't have others installed at the= moment). =A0Of course I couldn't actually send the mail, but the "mailto" = part worked. For "the 'mailto part" to be considered to have worked, the mail has to get= end to end, at least in my opinion. The problem here is fundamentally that some part of the system has to take = what the user thinks is correct and turn into something that the mail syste= m can deliver. The more pieces we allow to contain "what the user thinks i= s correct" rather than "what the mail system can deliver", the further down= into the system any translation between the two must occur. Unless "sh=E4wn" is a valid email address, showing that in a protocol slot = (which mailto is) seems like the wrong trade-off to me. YMMV; offer not good in jurisdictions legislating the value of pi. Ted From barryleiba.mailing.lists@gmail.com Mon Oct 26 13:11:08 2009 Return-Path: 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 C283C3A69C2 for ; Mon, 26 Oct 2009 13:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 rE-NmteiPXDi for ; Mon, 26 Oct 2009 13:11:08 -0700 (PDT) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id D86B03A67AC for ; Mon, 26 Oct 2009 13:11:07 -0700 (PDT) Received: by yxe30 with SMTP id 30so15273627yxe.29 for ; Mon, 26 Oct 2009 13:11:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=D+UA02Zp/NMqfclrh+tflOzFQCxU9H1J0U+ns3/jhRw=; b=MkHORZNYCErPtMuJT+ut5kKO+iFkhsz1Emu4LHt5lvpwmoz8FLicpzHO7JfRSC5Z/+ T0IIej8sSpJ/eL2yOFUmzy2nWm9pOx0Z2ccKMoWg9gJkLOTc4Rt691JKg9hr8WYbDKgP fvTqU9tycnvcYE0trfEY+g2fMM2AB19vSk8c0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; b=n50QYtzq7vUuHDfNXan7fqNURGtI3eeTrxQL+o3iyLNVx+SC6YcS5iPalHv4jFeELI sO77nh/5NIRkcvizT1Lvgs/rLa3lXiVIfyxUB8yh4G3LbUjUvB1VPBtZVarR+J+Rnxsj yyLp8ZG88jqSVGOKgRVaRQrinRjO7V/2NBdFc= MIME-Version: 1.0 Received: by 10.150.210.5 with SMTP id i5mr24704079ybg.174.1256587873680; Mon, 26 Oct 2009 13:11:13 -0700 (PDT) In-Reply-To: <4AD3B75C.9070201@isode.com> References: <4AD3B75C.9070201@isode.com> Date: Mon, 26 Oct 2009 16:11:13 -0400 Message-ID: <6c9fcc2a0910261311v24e65e99j4abb662f09307dd8@mail.gmail.com> From: Barry Leiba To: ima@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [EAI] Status of draft-ietf-eai-downgraded-display-02.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: barryleiba@computer.org List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 20:11:08 -0000 After looking at Pasi's DISCUSS comment on this, I re-read sections 3 and 4, and I think they're both quite difficult, and not ready for publication. I can't understand the point of section 3 at all, in fact -- it seems to tell me about something I might do, and then tells me not to do it. If someone will try explaining the real point, here, I'll take a stab at re-writing it. I'm in the process of re-writing section 4, and I'll post the result here when I'm done, for the WG to review and see if it works. Barry From duerst@it.aoyama.ac.jp Mon Oct 26 18:35:50 2009 Return-Path: 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 E6F523A67C0 for ; Mon, 26 Oct 2009 18:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.717 X-Spam-Level: X-Spam-Status: No, score=0.717 tagged_above=-999 required=5 tests=[AWL=0.508, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] 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 eMYq3bxTAlIb for ; Mon, 26 Oct 2009 18:35:49 -0700 (PDT) Received: from scmailgw01.scop.aoyama.ac.jp (scmailgw01.scop.aoyama.ac.jp [133.2.251.41]) by core3.amsl.com (Postfix) with ESMTP id 0EA5C3A67B8 for ; Mon, 26 Oct 2009 18:35:48 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp (scmse01.scbb.aoyama.ac.jp [133.2.253.158]) by scmailgw01.scop.aoyama.ac.jp (secret/secret) with SMTP id n9R1ZpJl030286 for ; Tue, 27 Oct 2009 10:35:51 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 4850_0fcab728_c299_11de_a622_001d096c566a; Tue, 27 Oct 2009 10:35:51 +0900 Received: from [IPv6:::1] ([133.2.210.1]:46902) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 27 Oct 2009 10:32:23 +0900 Message-ID: <4AE64E6A.90205@it.aoyama.ac.jp> Date: Tue, 27 Oct 2009 10:35:38 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: Shawn Steele References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "public-iri@w3.org" , "ima@ietf.org" Subject: Re: [EAI] [Fwd: AD review of draft-duerst-mailto-bis-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: , X-List-Received-Date: Tue, 27 Oct 2009 01:35:51 -0000 [cc'ed to public-iri@w3.org] Hello Shawn, Many thanks for your comments. On 2009/10/27 4:26, Shawn Steele wrote: > Currently lots of software seem to just allow Unicode in the mailto: (Or actually convert it based on the encoding of the web page). I'm not going to argue whether that's "correct" or not, but it does seem to be the prevailing current practice. Of course. These are mailto: IRIs. Nothing wrong with that, as far as I understand. Actually, one main point of update from RFC 2368 is to allow that, by allowing mailto: URIs to use UTF-8-based %-encoding. > From the experience with IDN where non-ASCII values are being directly encoded in http, I think it's unrealistic that all mailto: URIs will be "correctly" % escaped. On the contrary, I think most probably won't be. If by "not correctly escaped" you mean "not escaped", then that's just fine, they are IRIs. If you meant "not escaped based on UTF-8, but based on some other encoding", then than would be a problem. > So I'd like the mailto-bis to allow that applications MAY recognize unescaped UTF-8 in UTF-8 documents. It's not the mailto: URI scheme definition, but the spec for that application that has to say whether you can use IRIs or not. Once you can use IRIs, you can use unescaped UTF-8 in UTF-8 documents, unescaped Shift_JIS in Shift_JIS documents (being converted to UTF-8 when conversion to an URI is necessary), and so on. So I don't see the need for any textual changes. If you think some textual changes are necessary, please send a more concrete proposal. > -Shawn > > P.S: Yes, "lots" includes Microsoft software since it's easy to play with. On my machine if I open "run", then type mailto:shäwn, then Outlook opens up with shäwn in the To: line. Same thing happens if I stick it in an href in an HTML document. I think I even tried it with a different browser (sorry, don't remember which one, don't have others installed at the moment). Of course I couldn't actually send the mail, but the "mailto" part worked. I'm not sure who at Microsoft writes the spec for the "run" command, and whether this spec is publicly viewable or not, but essentially it seems to treat input that looks like an IRI/URI as an IRI, and do the right encoding conversion (I assume that internally, it uses UTF-16, not UTF-8, or might even use some OEM encoding or whatever). Also, while the HTML spec only allows IRI processing as error behavior, implementations actually allow IRIs. So everything is fine as far as I understand. Regards, Martin. -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From Shawn.Steele@microsoft.com Mon Oct 26 18:42:48 2009 Return-Path: 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 5F6F93A6824 for ; Mon, 26 Oct 2009 18:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.077 X-Spam-Level: X-Spam-Status: No, score=-10.077 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] 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 3jNY4dA1x4Pz for ; Mon, 26 Oct 2009 18:42:43 -0700 (PDT) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 03B8D3A6818 for ; Mon, 26 Oct 2009 18:42:42 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 26 Oct 2009 18:43:08 -0700 Received: from TK5EX14MBXC137.redmond.corp.microsoft.com ([169.254.5.70]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi; Mon, 26 Oct 2009 18:42:56 -0700 From: Shawn Steele To: =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Thread-Topic: [EAI] [Fwd: AD review of draft-duerst-mailto-bis-06.txt] Thread-Index: AQHKVqXbFDbn0mwL3EiOGBVyFhw4Y5EYnx+Q Date: Tue, 27 Oct 2009 01:42:55 +0000 Message-ID: References: <4AE64E6A.90205@it.aoyama.ac.jp> In-Reply-To: <4AE64E6A.90205@it.aoyama.ac.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "public-iri@w3.org" , "ima@ietf.org" Subject: Re: [EAI] [Fwd: AD review of draft-duerst-mailto-bis-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: , X-List-Received-Date: Tue, 27 Oct 2009 01:42:48 -0000 SG1tLCB0aGF0IG1ha2VzIHNlbnNlIHRoZW4sIEkgbWlzc2VkIHRoZSBJUkkgdnMgVVJJIHBhcnQu DQoNCkluIHRoYXQgY2FzZSBJJ2QgbGlrZSB0byBzdWdnZXN0IHdvcmRpbmcgdG8gdGhlIGVmZmVj dCB0aGF0ICJBcHBsaWNhdGlvbnMgU0hPVUxEIGNvbnNpZGVyIHN1cHBvcnRpbmcgSVJJIGluc3Rl YWQgb2YgVVJJIGZvciBtYWlsdG8uIg0KDQpTaW5jZSB0aGlzIGlzIG5ldyBiZWhhdmlvciBhbnl3 YXksIEknbSBub3Qgc3VyZSBob3cgdXNlZnVsIGl0IGlzIHRvIGRlZmluZSBhbiB1cGdyYWRlIHRv IGEgJWVuY29kZWQgVVJJIGZvcm0gd2hlbiB0aGUgYXBwbGljYXRpb24gbWlnaHQgYmUgYmV0dGVy IHNlcnZlZCBieSBtb3ZpbmcgdG8gYW4gSVJJIGluc3RlYWQuICBFZzogd2hhdCBwcm9ibGVtIGlz IHRoaXMgc29sdmluZyB0aGF0IElSSXMgd291bGRuJ3Q/DQoNCi1TaGF3bg0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogIk1hcnRpbiBKLiBEw7xyc3QiIFttYWlsdG86ZHVlcnN0 QGl0LmFveWFtYS5hYy5qcF0gDQpTZW50OiBNb25kYXksIE9jdG9iZXIgMjYsIDIwMDkgNjozNiBQ TQ0KVG86IFNoYXduIFN0ZWVsZQ0KQ2M6IGltYUBpZXRmLm9yZzsgcHVibGljLWlyaUB3My5vcmcN ClN1YmplY3Q6IFJlOiBbRUFJXSBbRndkOiBBRCByZXZpZXcgb2YgZHJhZnQtZHVlcnN0LW1haWx0 by1iaXMtMDYudHh0XQ0KDQpbY2MnZWQgdG8gcHVibGljLWlyaUB3My5vcmddDQoNCkhlbGxvIFNo YXduLA0KDQpNYW55IHRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4NCg0KT24gMjAwOS8xMC8yNyA0 OjI2LCBTaGF3biBTdGVlbGUgd3JvdGU6DQo+IEN1cnJlbnRseSBsb3RzIG9mIHNvZnR3YXJlIHNl ZW0gdG8ganVzdCBhbGxvdyBVbmljb2RlIGluIHRoZSBtYWlsdG86ICAoT3IgYWN0dWFsbHkgY29u dmVydCBpdCBiYXNlZCBvbiB0aGUgZW5jb2Rpbmcgb2YgdGhlIHdlYiBwYWdlKS4gIEknbSBub3Qg Z29pbmcgdG8gYXJndWUgd2hldGhlciB0aGF0J3MgImNvcnJlY3QiIG9yIG5vdCwgYnV0IGl0IGRv ZXMgc2VlbSB0byBiZSB0aGUgcHJldmFpbGluZyBjdXJyZW50IHByYWN0aWNlLg0KDQpPZiBjb3Vy c2UuIFRoZXNlIGFyZSBtYWlsdG86IElSSXMuIE5vdGhpbmcgd3Jvbmcgd2l0aCB0aGF0LCBhcyBm YXIgYXMgSSANCnVuZGVyc3RhbmQuIEFjdHVhbGx5LCBvbmUgbWFpbiBwb2ludCBvZiB1cGRhdGUg ZnJvbSBSRkMgMjM2OCBpcyB0byBhbGxvdyANCnRoYXQsIGJ5IGFsbG93aW5nIG1haWx0bzogVVJJ cyB0byB1c2UgVVRGLTgtYmFzZWQgJS1lbmNvZGluZy4NCg0KDQo+ICBGcm9tIHRoZSBleHBlcmll bmNlIHdpdGggSUROIHdoZXJlIG5vbi1BU0NJSSB2YWx1ZXMgYXJlIGJlaW5nIGRpcmVjdGx5IGVu Y29kZWQgaW4gaHR0cCwgSSB0aGluayBpdCdzIHVucmVhbGlzdGljIHRoYXQgYWxsIG1haWx0bzog VVJJcyB3aWxsIGJlICJjb3JyZWN0bHkiICUgZXNjYXBlZC4gIE9uIHRoZSBjb250cmFyeSwgSSB0 aGluayBtb3N0IHByb2JhYmx5IHdvbid0IGJlLg0KDQpJZiBieSAibm90IGNvcnJlY3RseSBlc2Nh cGVkIiB5b3UgbWVhbiAibm90IGVzY2FwZWQiLCB0aGVuIHRoYXQncyBqdXN0IA0KZmluZSwgdGhl eSBhcmUgSVJJcy4gSWYgeW91IG1lYW50ICJub3QgZXNjYXBlZCBiYXNlZCBvbiBVVEYtOCwgYnV0 IGJhc2VkIA0Kb24gc29tZSBvdGhlciBlbmNvZGluZyIsIHRoZW4gdGhhbiB3b3VsZCBiZSBhIHBy b2JsZW0uDQoNCg0KPiBTbyBJJ2QgbGlrZSB0aGUgbWFpbHRvLWJpcyB0byBhbGxvdyB0aGF0IGFw cGxpY2F0aW9ucyBNQVkgcmVjb2duaXplIHVuZXNjYXBlZCBVVEYtOCBpbiBVVEYtOCBkb2N1bWVu dHMuDQoNCkl0J3Mgbm90IHRoZSBtYWlsdG86IFVSSSBzY2hlbWUgZGVmaW5pdGlvbiwgYnV0IHRo ZSBzcGVjIGZvciB0aGF0IA0KYXBwbGljYXRpb24gdGhhdCBoYXMgdG8gc2F5IHdoZXRoZXIgeW91 IGNhbiB1c2UgSVJJcyBvciBub3QuIE9uY2UgeW91IA0KY2FuIHVzZSBJUklzLCB5b3UgY2FuIHVz ZSB1bmVzY2FwZWQgVVRGLTggaW4gVVRGLTggZG9jdW1lbnRzLCB1bmVzY2FwZWQgDQpTaGlmdF9K SVMgaW4gU2hpZnRfSklTIGRvY3VtZW50cyAoYmVpbmcgY29udmVydGVkIHRvIFVURi04IHdoZW4g DQpjb252ZXJzaW9uIHRvIGFuIFVSSSBpcyBuZWNlc3NhcnkpLCBhbmQgc28gb24uDQoNClNvIEkg ZG9uJ3Qgc2VlIHRoZSBuZWVkIGZvciBhbnkgdGV4dHVhbCBjaGFuZ2VzLiBJZiB5b3UgdGhpbmsg c29tZSANCnRleHR1YWwgY2hhbmdlcyBhcmUgbmVjZXNzYXJ5LCBwbGVhc2Ugc2VuZCBhIG1vcmUg Y29uY3JldGUgcHJvcG9zYWwuDQoNCj4gLVNoYXduDQo+DQo+IFAuUzogWWVzLCAibG90cyIgaW5j bHVkZXMgTWljcm9zb2Z0IHNvZnR3YXJlIHNpbmNlIGl0J3MgZWFzeSB0byBwbGF5IHdpdGguICBP biBteSBtYWNoaW5lIGlmIEkgb3BlbiAicnVuIiwgdGhlbiB0eXBlIG1haWx0bzpzaMOkd24sIHRo ZW4gT3V0bG9vayBvcGVucyB1cCB3aXRoIHNow6R3biBpbiB0aGUgVG86IGxpbmUuICBTYW1lIHRo aW5nIGhhcHBlbnMgaWYgSSBzdGljayBpdCBpbiBhbiBocmVmIGluIGFuIEhUTUwgZG9jdW1lbnQu ICBJIHRoaW5rIEkgZXZlbiB0cmllZCBpdCB3aXRoIGEgZGlmZmVyZW50IGJyb3dzZXIgKHNvcnJ5 LCBkb24ndCByZW1lbWJlciB3aGljaCBvbmUsIGRvbid0IGhhdmUgb3RoZXJzIGluc3RhbGxlZCBh dCB0aGUgbW9tZW50KS4gIE9mIGNvdXJzZSBJIGNvdWxkbid0IGFjdHVhbGx5IHNlbmQgdGhlIG1h aWwsIGJ1dCB0aGUgIm1haWx0byIgcGFydCB3b3JrZWQuDQoNCkknbSBub3Qgc3VyZSB3aG8gYXQg TWljcm9zb2Z0IHdyaXRlcyB0aGUgc3BlYyBmb3IgdGhlICJydW4iIGNvbW1hbmQsIGFuZCANCndo ZXRoZXIgdGhpcyBzcGVjIGlzIHB1YmxpY2x5IHZpZXdhYmxlIG9yIG5vdCwgYnV0IGVzc2VudGlh bGx5IGl0IHNlZW1zIA0KdG8gdHJlYXQgaW5wdXQgdGhhdCBsb29rcyBsaWtlIGFuIElSSS9VUkkg YXMgYW4gSVJJLCBhbmQgZG8gdGhlIHJpZ2h0IA0KZW5jb2RpbmcgY29udmVyc2lvbiAoSSBhc3N1 bWUgdGhhdCBpbnRlcm5hbGx5LCBpdCB1c2VzIFVURi0xNiwgbm90IA0KVVRGLTgsIG9yIG1pZ2h0 IGV2ZW4gdXNlIHNvbWUgT0VNIGVuY29kaW5nIG9yIHdoYXRldmVyKS4NCg0KQWxzbywgd2hpbGUg dGhlIEhUTUwgc3BlYyBvbmx5IGFsbG93cyBJUkkgcHJvY2Vzc2luZyBhcyBlcnJvciBiZWhhdmlv ciwgDQppbXBsZW1lbnRhdGlvbnMgYWN0dWFsbHkgYWxsb3cgSVJJcy4NCg0KU28gZXZlcnl0aGlu ZyBpcyBmaW5lIGFzIGZhciBhcyBJIHVuZGVyc3RhbmQuDQoNClJlZ2FyZHMsICAgIE1hcnRpbi4N Cg0KLS0gDQojLSMgTWFydGluIEouIETDvHJzdCwgUHJvZmVzc29yLCBBb3lhbWEgR2FrdWluIFVu aXZlcnNpdHkNCiMtIyBodHRwOi8vd3d3LnN3Lml0LmFveWFtYS5hYy5qcCAgIG1haWx0bzpkdWVy c3RAaXQuYW95YW1hLmFjLmpwDQoNCg== From duerst@it.aoyama.ac.jp Mon Oct 26 20:56:47 2009 Return-Path: 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 2053028C0F6 for ; Mon, 26 Oct 2009 20:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.633 X-Spam-Level: X-Spam-Status: No, score=0.633 tagged_above=-999 required=5 tests=[AWL=0.423, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] 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 Xl848npC9q68 for ; Mon, 26 Oct 2009 20:56:45 -0700 (PDT) Received: from scmailgw02.scop.aoyama.ac.jp (scmailgw02.scop.aoyama.ac.jp [133.2.251.42]) by core3.amsl.com (Postfix) with ESMTP id 218833A6821 for ; Mon, 26 Oct 2009 20:56:44 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp (scmse02.scbb.aoyama.ac.jp [133.2.253.159]) by scmailgw02.scop.aoyama.ac.jp (secret/secret) with SMTP id n9R3ulb9009508 for ; Tue, 27 Oct 2009 12:56:47 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 3178_bfb0fa86_c2ac_11de_b9aa_001d096c5782; Tue, 27 Oct 2009 12:56:47 +0900 Received: from [IPv6:::1] ([133.2.210.1]:40361) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 27 Oct 2009 12:53:18 +0900 Message-ID: <4AE66F71.1060106@it.aoyama.ac.jp> Date: Tue, 27 Oct 2009 12:56:33 +0900 From: =?windows-1252?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: Ted Hardie References: <6e04e83a0910261303sec61a11v68d0092a5c6ae62f@mail.gmail.com> In-Reply-To: <6e04e83a0910261303sec61a11v68d0092a5c6ae62f@mail.gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "public-iri@w3.org" , Shawn Steele , "ima@ietf.org" Subject: Re: [EAI] [Fwd: AD review of draft-duerst-mailto-bis-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: , X-List-Received-Date: Tue, 27 Oct 2009 03:56:47 -0000 [copying public-iri@w3.org] Hello Ted, others, [everybody: There is a short summary at the end of this mail.] On 2009/10/27 5:03, Ted Hardie wrote: > On Mon, Oct 26, 2009 at 12:26 PM, Shawn Steele > wrote: >> On my machine if I open "run", then type mailto:shäwn, then Outlook >> opens up with shäwn in the To: line. Same thing happens if I stick it >> in an href in an HTML document. I think I even tried it with a >> different browser (sorry, don't remember which one, don't have others >> installed at the moment). Of course I couldn't actually send the >> mail, but the "mailto" part worked. > > For "the 'mailto part" to be considered to have worked, the mail has > to get end to end, at least in my opinion. At first sight, this seems reasonable. But it's basically the same difference as the difference between an http: URI/IRI that is *syntactically* correct and one that *actually resolves* (i.e. not produces a 404 or something similar). > The problem here is fundamentally that some part of the system has to > take what the user thinks is correct and turn into something that the > mail system can deliver. The more pieces we allow to contain "what > the user thinks is correct" rather than "what the mail system can > deliver", the further down into the system any translation between the > two must occur. There are two problems with mailto:shäwn: 1) There's no At-sign 2) In particular for LHS, shäwn only works under EAI For your everyday email user agent, both of these mean that the mail won't be sent. > Unless "shäwn" is a valid email address, showing that in a protocol > slot (which mailto is) seems like the wrong trade-off to me. First, the current draft clearly says that an at-sign is needed, by using (http://tools.ietf.org/html/rfc5322#section-3.4.1). So mailto:shäwn is not a valid IRI even according to an updated mailto: spec. So to conform to the spec, we may have to try with something like mailto:shawn@shäwn.com or so. But the question is where this should be checked. An important principle that many people often forget is that IRIs/URIs are just "carriers". Because there are many schemes, it is completely unrealistic to expect a generic IRI/URI handler to check these. So checking is up to the application that "resolves" the mailto: IRI/URI, which is the mail user agent. Now what does the average mail user agent do if you put "shäwn" into a To: field? I can only report about Thunderbird (Eudora version, 3.0b1pre). It absolutely has no problem putting "shäwn" into a To: field (I have to admit that I actually tested with a Cc: field, but I don't think there would be any difference for a To: field). Thinking about it, that's quite understandable, it also shouldn't produce an error if I put "Dürst” into such a field, in particular if I continue input with " ". The "Dürst” will result in an encoded word, but it would be weird to ask the user to input that encoded word, or to show that encoded word to the user. [The syntax proposed in the draft, as far as I understand, excludes something like "name " anyway. This is different in RFC 2368, which I thinks allows this, but I got told that this wasn't actually supported well, and RFC 2368's predecessor (RFC 1738) also didn't allow it. (see http://tools.ietf.org/html/rfc1738#section-3.5)] When putting "shäwn" into a Cc: field, what happened is that when I tried to send the mail, there was an error message that to me suggested that between the mail user agent and the server, the non-7bit byte caused a connection abort. Not a very helpful message for a general user, but not an issue for the mailto: spec. I have no idea whether other mail user agents do better here (e.g. checking and telling the user that the address isn't well-formed before they actually try to send something). On top of all the above thoughts, if we want to claim: > For "the 'mailto part" to be considered to have worked, the mail has > to get end to end, at least in my opinion. then that would also exclude things such as mailto:nobody@nonexistent.example.com would also not be valid mailto: IRIs/URIs. I hope you agree that it doesn't make sense to actually send an email just to figure out whether a mailto: URI/IRI is valid or not. So I don't think it makes sense to include the existence of a mail address a precondition for the validity of a mailto: URI. Also, the draft does not contain any syntax restrictions for any of the other fields (body, Subject:, To:, Cc:, Bcc:,...). So according to the draft, there has to be an at-sign before the '?', but there is no check for an at-sign in the "foo" part of mailto:a@b.c?cc=foo. So in summary: - It's the responsibility of the resolver (in this case the mail user agent), not some generic IRI/URI software, to check for possible syntax problems in the IRI/URI. - There's a whole series of different cases ranging from a fully workable example to a syntactically totally invalid example. Therefore, problems may be detected (or show up) sooner or later. - IDNA-aware slots, or EAI, may be a different protocol from old-style SMTP without any extensions, but the former use (somewhat different) protocol elements nevertheless. - If and where interoperability can be achieved with a protocol element that is closer to the user (i.e. an IDN, or an IRI,...), there is no reason to use a lower-level protocol element (e.g. xn--... or lots of %-escapes or a mime encoded word (maybe with %-escapes on top of that). > YMMV; offer not good in jurisdictions legislating the value of pi. IMHO, offer not good even in jurisdictions that leave the value of pi to mathematicians :-) Regards, Martin. -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From duerst@it.aoyama.ac.jp Mon Oct 26 21:00:23 2009 Return-Path: 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 B9B0C28C1C8 for ; Mon, 26 Oct 2009 21:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.572 X-Spam-Level: X-Spam-Status: No, score=0.572 tagged_above=-999 required=5 tests=[AWL=0.362, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] 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 HBMElPPwlyQR for ; Mon, 26 Oct 2009 21:00:22 -0700 (PDT) Received: from scmailgw02.scop.aoyama.ac.jp (scmailgw02.scop.aoyama.ac.jp [133.2.251.42]) by core3.amsl.com (Postfix) with ESMTP id A2CF028C1C2 for ; Mon, 26 Oct 2009 21:00:22 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp (scmse01.scbb.aoyama.ac.jp [133.2.253.158]) by scmailgw02.scop.aoyama.ac.jp (secret/secret) with SMTP id n9R40ZPE013195 for ; Tue, 27 Oct 2009 13:00:35 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 6049_47e6388a_c2ad_11de_beb2_001d096c566a; Tue, 27 Oct 2009 13:00:35 +0900 Received: from [IPv6:::1] ([133.2.210.1]:47432) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 27 Oct 2009 12:57:07 +0900 Message-ID: <4AE67055.5000604@it.aoyama.ac.jp> Date: Tue, 27 Oct 2009 13:00:21 +0900 From: =?windows-1252?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: Shawn Steele References: <6e04e83a0910261303sec61a11v68d0092a5c6ae62f@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "ima@ietf.org" Subject: Re: [EAI] [Fwd: AD review of draft-duerst-mailto-bis-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: , X-List-Received-Date: Tue, 27 Oct 2009 04:00:23 -0000 On 2009/10/27 5:07, Shawn Steele wrote: > Yes, end-to-end would be working, however consider if Office-That-Supports-EAI is installed on Win7, then this would've worked. If the OS is then upgraded, users will expect it to continue working. Hello Shawn, Just to double-check: would "shäwn" be a valid email address on some windows system? I understand that with EAI, "shäwn@shäwn.com" or something like that would be valid, but just "shäwn" doesn't look like a valid email address to me even in EAI. Regards, Martin. > -Shawn > > -----Original Message----- > From: Ted Hardie [mailto:ted.ietf@gmail.com] > Sent: Monday, October 26, 2009 1:04 PM > To: Shawn Steele > Cc: ima@ietf.org > Subject: Re: [EAI] [Fwd: AD review of draft-duerst-mailto-bis-06.txt] > > On Mon, Oct 26, 2009 at 12:26 PM, Shawn Steele wrote: > On my machine if I open "run", then type mailto:shäwn, then Outlook opens up with shäwn in the To: line. Same thing happens if I stick it in an href in an HTML document. I think I even tried it with a different browser (sorry, don't remember which one, don't have others installed at the moment). Of course I couldn't actually send the mail, but the "mailto" part worked. > > For "the 'mailto part" to be considered to have worked, the mail has to get end to end, at least in my opinion. > > The problem here is fundamentally that some part of the system has to take what the user thinks is correct and turn into something that the mail system can deliver. The more pieces we allow to contain "what the user thinks is correct" rather than "what the mail system can deliver", the further down into the system any translation between the two must occur. > > Unless "shäwn" is a valid email address, showing that in a protocol slot (which mailto is) seems like the wrong trade-off to me. > > YMMV; offer not good in jurisdictions legislating the value of pi. > > Ted > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From Shawn.Steele@microsoft.com Tue Oct 27 09:36:38 2009 Return-Path: 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 996983A69A7 for ; Tue, 27 Oct 2009 09:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.851 X-Spam-Level: X-Spam-Status: No, score=-9.851 tagged_above=-999 required=5 tests=[AWL=-0.152, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] 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 RxoOKPiZLBxP for ; Tue, 27 Oct 2009 09:36:37 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 5CEC928C0F9 for ; Tue, 27 Oct 2009 09:36:37 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 27 Oct 2009 09:36:51 -0700 Received: from TK5EX14MBXC137.redmond.corp.microsoft.com ([169.254.5.70]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi; Tue, 27 Oct 2009 09:36:51 -0700 From: Shawn Steele To: =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Thread-Topic: [EAI] [Fwd: AD review of draft-duerst-mailto-bis-06.txt] Thread-Index: AQHKVnecB+R1zgGDekCib//tdQ/nbJEYQnJwgAD5+YCAAFvkUg== Date: Tue, 27 Oct 2009 16:36:50 +0000 Message-ID: References: <6e04e83a0910261303sec61a11v68d0092a5c6ae62f@mail.gmail.com> , <4AE67055.5000604@it.aoyama.ac.jp> In-Reply-To: <4AE67055.5000604@it.aoyama.ac.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ima@ietf.org" Subject: Re: [EAI] [Fwd: AD review of draft-duerst-mailto-bis-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: , X-List-Received-Date: Tue, 27 Oct 2009 16:36:38 -0000 Sorry, I was only focusing on the local part as whatever's after @ is alrea= dy an example with IDN. So mailto:sh=E4wn@sh=E4wn.com would be a better ex= ample. Note that however mailto:shawn would work on a local system. (Like an intr= anet, link from an internal web page to the internal maintainer of that pag= e for example.) -Shawn ________________________________________ From: "Martin J. D=FCrst" [duerst@it.aoyama.ac.jp] Sent: Monday, October 26, 2009 9:00 PM To: Shawn Steele Cc: Ted Hardie; ima@ietf.org Subject: Re: [EAI] [Fwd: AD review of draft-duerst-mailto-bis-06.txt] On 2009/10/27 5:07, Shawn Steele wrote: > Yes, end-to-end would be working, however consider if Office-That-Support= s-EAI is installed on Win7, then this would've worked. If the OS is then u= pgraded, users will expect it to continue working. Hello Shawn, Just to double-check: would "sh=E4wn" be a valid email address on some windows system? I understand that with EAI, "sh=E4wn@sh=E4wn.com" or something like that would be valid, but just "sh=E4wn" doesn't look like a valid email address to me even in EAI. Regards, Martin. > -Shawn > > -----Original Message----- > From: Ted Hardie [mailto:ted.ietf@gmail.com] > Sent: Monday, October 26, 2009 1:04 PM > To: Shawn Steele > Cc: ima@ietf.org > Subject: Re: [EAI] [Fwd: AD review of draft-duerst-mailto-bis-06.txt] > > On Mon, Oct 26, 2009 at 12:26 PM, Shawn Steele wrote: > On my machine if I open "run", then type mailto:sh=E4wn, then Outlook o= pens up with sh=E4wn in the To: line. Same thing happens if I stick it in = an href in an HTML document. I think I even tried it with a different brow= ser (sorry, don't remember which one, don't have others installed at the mo= ment). Of course I couldn't actually send the mail, but the "mailto" part = worked. > > For "the 'mailto part" to be considered to have worked, the mail has to g= et end to end, at least in my opinion. > > The problem here is fundamentally that some part of the system has to tak= e what the user thinks is correct and turn into something that the mail sys= tem can deliver. The more pieces we allow to contain "what the user thinks= is correct" rather than "what the mail system can deliver", the further do= wn into the system any translation between the two must occur. > > Unless "sh=E4wn" is a valid email address, showing that in a protocol slo= t (which mailto is) seems like the wrong trade-off to me. > > YMMV; offer not good in jurisdictions legislating the value of pi. > > Ted > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > -- #-# Martin J. D=FCrst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp= From Shawn.Steele@microsoft.com Tue Oct 27 16:11:59 2009 Return-Path: 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 0B2C53A682F for ; Tue, 27 Oct 2009 16:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.262 X-Spam-Level: X-Spam-Status: No, score=-10.262 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_HI=-8] 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 Y8yxwXkjOh5L for ; Tue, 27 Oct 2009 16:11:56 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 9304B3A680A for ; Tue, 27 Oct 2009 16:11:56 -0700 (PDT) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 27 Oct 2009 16:12:23 -0700 Received: from TK5EX14MBXC137.redmond.corp.microsoft.com ([169.254.5.70]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi; Tue, 27 Oct 2009 16:12:10 -0700 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: fulfil misspelled. Thread-Index: AcpXWui8Kva70vQwTEyLdnC5HyLaSw== Importance: low X-Priority: 5 Date: Tue, 27 Oct 2009 23:12:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E14011F8737B524BB564B05FF748464A04424BB9TK5EX14MBXC137r_" MIME-Version: 1.0 Subject: [EAI] fulfil misspelled. 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: , X-List-Received-Date: Tue, 27 Oct 2009 23:11:59 -0000 --_000_E14011F8737B524BB564B05FF748464A04424BB9TK5EX14MBXC137r_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I don't know if anyone really cares much at this point, but http://tools.ie= tf.org/html/draft-ietf-idnabis-bidi-06 has fulfill misspelled several times= (missing the last l) - Shawn ???? ????? http://blogs.msdn.com/shawnste --_000_E14011F8737B524BB564B05FF748464A04424BB9TK5EX14MBXC137r_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I don’t kn= ow if anyone really cares much at this point, but http://tools.ietf.org/html/draft-i= etf-idnabis-bidi-06 has fulfill misspelled several times (missing the l= ast l) =A0

 

<= p class=3DMsoNormal>- Shawn

 <= /o:p>

= 

http://blo= gs.msdn.com/shawnste

&nb= sp;

= --_000_E14011F8737B524BB564B05FF748464A04424BB9TK5EX14MBXC137r_-- From Shawn.Steele@microsoft.com Tue Oct 27 16:12:21 2009 Return-Path: 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 5432F3A69CD for ; Tue, 27 Oct 2009 16:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.329 X-Spam-Level: X-Spam-Status: No, score=-10.329 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 hvwq5BwpFitL for ; Tue, 27 Oct 2009 16:12:18 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id C5CF03A680A for ; Tue, 27 Oct 2009 16:12:18 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 27 Oct 2009 16:12:46 -0700 Received: from TK5EX14MBXC137.redmond.corp.microsoft.com ([169.254.5.70]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi; Tue, 27 Oct 2009 16:12:32 -0700 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: fulfil misspelled. Thread-Index: AcpXWui8Kva70vQwTEyLdnC5HyLaSwAAAdRA Importance: low X-Priority: 5 Date: Tue, 27 Oct 2009 23:12:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E14011F8737B524BB564B05FF748464A04424BC9TK5EX14MBXC137r_" MIME-Version: 1.0 Subject: Re: [EAI] fulfil misspelled. 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: , X-List-Received-Date: Tue, 27 Oct 2009 23:12:21 -0000 --_000_E14011F8737B524BB564B05FF748464A04424BC9TK5EX14MBXC137r_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Whoops, wrong list :) From: Shawn Steele Sent: Tuesday, October 27, 2009 4:12 PM To: ima@ietf.org Subject: fulfil misspelled. Importance: Low I don=92t know if anyone really cares much at this point, but http://tools.= ietf.org/html/draft-ietf-idnabis-bidi-06 has fulfill misspelled several tim= es (missing the last l) - Shawn ???? ????? http://blogs.msdn.com/shawnste --_000_E14011F8737B524BB564B05FF748464A04424BC9TK5EX14MBXC137r_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Whoops, wrong list J

 

From: Shawn Steele
Sent: = Tuesday, October 27, 2009 4:12 PM
To: ima@ietf.org
Subject:= fulfil misspelled.
Importance: Low

 

I do= n=92t know if anyone really cares much at this point, but http://tools.ietf.org/html= /draft-ietf-idnabis-bidi-06 has fulfill misspelled several times (missi= ng the last l)  

 =

- Shawn

<= o:p> 

ɽ= 19; 

http://blogs.msdn.com/shaw= nste

 

= --_000_E14011F8737B524BB564B05FF748464A04424BC9TK5EX14MBXC137r_-- From duerst@it.aoyama.ac.jp Wed Oct 28 02:18:31 2009 Return-Path: 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 514063A6A3F for ; Wed, 28 Oct 2009 02:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.794 X-Spam-Level: X-Spam-Status: No, score=0.794 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_65=0.6, MIME_8BIT_HEADER=0.3] 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 92VbeApZtPLE for ; Wed, 28 Oct 2009 02:18:30 -0700 (PDT) Received: from scmailgw01.scop.aoyama.ac.jp (scmailgw01.scop.aoyama.ac.jp [133.2.251.41]) by core3.amsl.com (Postfix) with ESMTP id EC8B53A699D for ; Wed, 28 Oct 2009 02:18:29 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp (scmse02.scbb.aoyama.ac.jp [133.2.253.159]) by scmailgw01.scop.aoyama.ac.jp (secret/secret) with SMTP id n9S9IXPK002661 for ; Wed, 28 Oct 2009 18:18:33 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 6b71_dd42e5b8_c3a2_11de_970b_001d096c5782; Wed, 28 Oct 2009 18:18:33 +0900 Received: from [IPv6:::1] ([133.2.210.1]:39498) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 28 Oct 2009 18:15:04 +0900 Message-ID: <4AE80C58.9040807@it.aoyama.ac.jp> Date: Wed, 28 Oct 2009 18:18:16 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: Shawn Steele References: <6e04e83a0910261303sec61a11v68d0092a5c6ae62f@mail.gmail.com> , <4AE67055.5000604@it.aoyama.ac.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "ima@ietf.org" Subject: Re: [EAI] [Fwd: AD review of draft-duerst-mailto-bis-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: , X-List-Received-Date: Wed, 28 Oct 2009 09:18:31 -0000 Hello Shawn, others, On 2009/10/28 1:36, Shawn Steele wrote: > Sorry, I was only focusing on the local part as whatever's after @ is already an example with IDN. So mailto:shäwn@shäwn.com would be a better example. > > Note that however mailto:shawn would work on a local system. (Like an intranet, link from an internal web page to the internal maintainer of that page for example.) Yes, it would probably work. Of course, such local addresses are a problem, because some work will have to be done to change them when e.g. a page goes public. It's somehow similar to file: URIs, which are also local. Anyway, currently, the syntax of the mailto: URI/IRI requires an @, but in practice, mailto: URIs/IRIs without an @ may get through, of course. Regards, Martin. > -Shawn > > ________________________________________ > From: "Martin J. Dürst" [duerst@it.aoyama.ac.jp] > Sent: Monday, October 26, 2009 9:00 PM > To: Shawn Steele > Cc: Ted Hardie; ima@ietf.org > Subject: Re: [EAI] [Fwd: AD review of draft-duerst-mailto-bis-06.txt] > > On 2009/10/27 5:07, Shawn Steele wrote: >> Yes, end-to-end would be working, however consider if Office-That-Supports-EAI is installed on Win7, then this would've worked. If the OS is then upgraded, users will expect it to continue working. > > Hello Shawn, > > Just to double-check: would "shäwn" be a valid email address on some > windows system? I understand that with EAI, "shäwn@shäwn.com" or > something like that would be valid, but just "shäwn" doesn't look like a > valid email address to me even in EAI. > > Regards, Martin. > >> -Shawn >> >> -----Original Message----- >> From: Ted Hardie [mailto:ted.ietf@gmail.com] >> Sent: Monday, October 26, 2009 1:04 PM >> To: Shawn Steele >> Cc: ima@ietf.org >> Subject: Re: [EAI] [Fwd: AD review of draft-duerst-mailto-bis-06.txt] >> >> On Mon, Oct 26, 2009 at 12:26 PM, Shawn Steele wrote: >> On my machine if I open "run", then type mailto:shäwn, then Outlook opens up with shäwn in the To: line. Same thing happens if I stick it in an href in an HTML document. I think I even tried it with a different browser (sorry, don't remember which one, don't have others installed at the moment). Of course I couldn't actually send the mail, but the "mailto" part worked. >> >> For "the 'mailto part" to be considered to have worked, the mail has to get end to end, at least in my opinion. >> >> The problem here is fundamentally that some part of the system has to take what the user thinks is correct and turn into something that the mail system can deliver. The more pieces we allow to contain "what the user thinks is correct" rather than "what the mail system can deliver", the further down into the system any translation between the two must occur. >> >> Unless "shäwn" is a valid email address, showing that in a protocol slot (which mailto is) seems like the wrong trade-off to me. >> >> YMMV; offer not good in jurisdictions legislating the value of pi. >> >> Ted >> >> _______________________________________________ >> IMA mailing list >> IMA@ietf.org >> https://www.ietf.org/mailman/listinfo/ima >> > > -- > #-# Martin J. Dürst, Professor, Aoyama Gakuin University > #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From Shawn.Steele@microsoft.com Wed Oct 28 12:38:52 2009 Return-Path: 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 A737A3A6A60 for ; Wed, 28 Oct 2009 12:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.375 X-Spam-Level: X-Spam-Status: No, score=-10.375 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 gV9O2+cUxj9a for ; Wed, 28 Oct 2009 12:38:51 -0700 (PDT) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id C95F33A6A41 for ; Wed, 28 Oct 2009 12:38:51 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 28 Oct 2009 12:39:18 -0700 Received: from TK5EX14MBXC137.redmond.corp.microsoft.com ([169.254.5.70]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi; Wed, 28 Oct 2009 12:39:06 -0700 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: @ in Intranets Thread-Index: AcpYBIC1TX4r87F8TkiXAL8VozojfA== Date: Wed, 28 Oct 2009 19:36:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] @ in Intranets 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: , X-List-Received-Date: Wed, 28 Oct 2009 19:38:52 -0000 > Yes, it would probably work. Of course, such local addresses are a proble= m, because some work > will have to be done to change them when e.g. a page goes public. > It's somehow similar to file: URIs, which are also local. More similar, perhaps, to an Intranet web site where the full domain name i= sn't specified, nor available to the rest of the world. In my experience s= uch links are usually for the contact of an intranet web site or group or s= omething and they never "go public." (If they might go public, the full fo= rm would be much better.) > Anyway, currently, the syntax of the mailto: URI/IRI requires an @, but i= n practice,=20 > mailto: URIs/IRIs without an @ may get through, of course. It seems common, in enterprises at least, to have such internal/intranet re= sources that aren't fully specified. I wonder if perhaps the standard shou= ld allow that mailto: without an @ MAY be used for Intranet use only? Of c= ourse I could argue that if it's for Intranet use only, then it doesn't nee= d to be in an IETF standard :) Since many tools work in both Internet and = Intranet environments, it might be good to allow the common practice. -Shawn From sm@resistor.net Wed Oct 28 13:40:49 2009 Return-Path: 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 558D43A6995 for ; Wed, 28 Oct 2009 13:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 oxDZqENF+7gG for ; Wed, 28 Oct 2009 13:40:48 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 0424E3A68E7 for ; Wed, 28 Oct 2009 13:40:47 -0700 (PDT) Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4.Beta0/8.14.4.Beta0) with ESMTP id n9SKerdv019811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Oct 2009 13:40:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1256762461; x=1256848861; bh=jLRy+7WtyowYluSX/5EcpXpo5lRQCg8jWWFBrwm7eb0=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=p8FefxGiRALnBSXgOgjk7y/hrvhyImM5nsVeOqPObKZXqQbYdVR2G3tCjbjPy5Y1y 4vyJ7vP8OhtJDKH7MgfzYHm0kCR25Tc7i+wZRavD6ecM9XzmbPM5NPn7gSpLBj9Z51 yr0AHJfQpUtq+OzWdGszGthOXxCmi3T1UqorBpRc= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=Pmhz/sgAqNg4Aejk4rRV3qIKyfTxeNn458XQII+94f/Jcbluu5So2GRCO84uFn9el HItYlMAfTgld1vO/DfYEjhMbM4WOhPXerwUJXBWdTrv0K3tQKHiGxKVbnfa9spj6mov gHuUBWDjFjuguWm7zk8aLSaiq6Crunsjuhsbfe8= Message-Id: <6.2.5.6.2.20091028130232.02e68f18@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 28 Oct 2009 13:40:30 -0700 To: Shawn Steele From: SM In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ima@ietf.org Subject: Re: [EAI] @ in Intranets 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: , X-List-Received-Date: Wed, 28 Oct 2009 20:40:49 -0000 Hi Shawn, At 12:36 28-10-2009, Shawn Steele wrote: >It seems common, in enterprises at least, to have such >internal/intranet resources that aren't fully specified. I wonder >if perhaps the standard should allow that mailto: without an @ MAY >be used for Intranet use only? Of course I could argue that if it's >for Intranet use only, then it doesn't need to be in an IETF >standard :) Since many tools work in both Internet and Intranet >environments, it might be good to allow the common practice. By diverging from RFC 5321, you may be introducing some ambiguity. Today's Intranet environment might be moved to the Internet tomorrow. Your mailto:local-part will be qualified and you cannot tell where the message may end up. Standardizing (not IETF) is generally less work. If you do not take out the "@", you still have some semblance of an email address. If you keep "At-domain", you make it easier for the IETF. :-) I adopted an approach similar to yours many years ago in an environment that was not an Intranet. I would not adopt the same approach now as the boundary between private and public is blurry. Regards, -sm From wwwrun@core3.amsl.com Thu Oct 29 10:21:19 2009 Return-Path: X-Original-To: ima@ietf.org Delivered-To: ima@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 7A5DD3A6882; Thu, 29 Oct 2009 10:21:19 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20091029172119.7A5DD3A6882@core3.amsl.com> Date: Thu, 29 Oct 2009 10:21:19 -0700 (PDT) Cc: Internet Architecture Board , eai mailing list , eai chair , RFC Editor Subject: [EAI] Document Action: 'POP3 Support for UTF-8' to Experimental RFC 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: , X-List-Received-Date: Thu, 29 Oct 2009 17:21:19 -0000 The IESG has approved the following document: - 'POP3 Support for UTF-8 ' as an Experimental RFC This document is the product of the Email Address Internationalization Working Group. The IESG contact persons are Alexey Melnikov and Lisa Dusseault. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-pop-09.txt Technical Summary 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. Working Group Summary The WG explored a couple of different designs for this extension. The path chosen (a global switch to UTF-8 only mode) has the consensus of the WG. Document Quality At least one existing implementation of the document exists. Personnel Harald Alvestrand is the document shepherd. Alexey Melnikov is the responsible AD. RFC Editor Note In Section 3.2, change the 4th paragraph to read: OLD: When applying SASLprep [RFC4013], servers MUST reject UTF-8 user names or passwords which contain a Unicode character listed in section 2.3 of SASLprep [RFC4013]. NEW: When applying SASLprep [RFC4013], servers MUST reject UTF-8 user names or passwords which contain a Unicode character listed in section 2.3 of SASLprep [RFC4013]. When applying SASLPrep to the USER argument, to the PASS argument or to the APOP username argument, a compliant server or client MUST treat them as a query string (i.e., unassigned Unicode codepoints are allowed). When applying SASLPrep to the APOP password argument, a compliant server or client MUST treat them as a stored string (i.e., unassigned Unicode codepoints are prohibited). From barryleiba.mailing.lists@gmail.com Fri Oct 30 13:10:01 2009 Return-Path: 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 820083A6867 for ; Fri, 30 Oct 2009 13:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 bCjM1blN7Wjy for ; Fri, 30 Oct 2009 13:10:00 -0700 (PDT) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id 9EAB73A67BD for ; Fri, 30 Oct 2009 13:10:00 -0700 (PDT) Received: by ywh13 with SMTP id 13so3450521ywh.29 for ; Fri, 30 Oct 2009 13:10:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=TLZPh9t8pfm2OdNAUIXIdgikHzPAcp3i9XJvFI+1Zfs=; b=GpAlDP0S21QKwr7oXG5ZXRS3TSHIIcqlCDYL68kffbLmv1zZNEHoSgCXskAPKtrJF5 Ogd0i0dAxbLAfoQgs7gWU/7z42NecxRYlDUp1lGsfPVpVEfl1HuREy8GNlZk6vSVhpZk MkHHFU5QHP5TkBJ71tlwX/qJMeD37bLWhqoJg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; b=G6iTg8mkfGdsspk2vleD3y7WuIQzds09i3w4Hly25cVXoGvxWQfysjMuoGYBPKs8fL Tg/2/1HLQPn5h/VVz1guYYgxJx6n7ePHJOfxNIWDtKJttIP3LVUwdva4kiP+5eWMOV7+ i5TVUHrbQQI+BKlZp9OGQp2qjQT2RRRFkKWCA= MIME-Version: 1.0 Received: by 10.150.88.25 with SMTP id l25mr3775605ybb.170.1256933414085; Fri, 30 Oct 2009 13:10:14 -0700 (PDT) In-Reply-To: <6c9fcc2a0910261311v24e65e99j4abb662f09307dd8@mail.gmail.com> References: <4AD3B75C.9070201@isode.com> <6c9fcc2a0910261311v24e65e99j4abb662f09307dd8@mail.gmail.com> Date: Fri, 30 Oct 2009 16:10:13 -0400 Message-ID: <6c9fcc2a0910301310g4d57c30aoa1527e25c1e5e1d4@mail.gmail.com> From: Barry Leiba To: ima@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [EAI] Status of draft-ietf-eai-downgraded-display-02.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: barryleiba@computer.org List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 20:10:01 -0000 > After looking at Pasi's DISCUSS comment on this, I re-read sections 3 > and 4, and I think they're both quite =A0difficult, and not ready for > publication. =A0I can't understand the point of section 3 at all, in > fact -- it seems to tell me about something I might do, and then tells > me not to do it. =A0If someone will try explaining the real point, here, > I'll take a stab at re-writing it. > > I'm in the process of re-writing section 4, and I'll post the result > here when I'm done, for the WG to review and see if it works. I've gotten stuck on the re-write of section 4, as well -- I can't figure out what I'm supposed to do after step 4, and step 6, in particular, doesn't make sense to me. I presume that, since the working group sent this up to the IESG, some others in the WG understand the process. Will someone who does please get in touch with me so we can work on re-wording? I'm happy to do the writing, but I need consultation on the procedure that's being defined. Barry From sm@resistor.net Fri Oct 30 14:21:30 2009 Return-Path: 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 3F5FB3A69C1 for ; Fri, 30 Oct 2009 14:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 BiG+QdB6ZA-L for ; Fri, 30 Oct 2009 14:21:29 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 7AB4D3A6977 for ; Fri, 30 Oct 2009 14:21:29 -0700 (PDT) Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4.Beta0/8.14.4.Beta0) with ESMTP id n9ULLOGt014101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Oct 2009 14:21:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1256937692; x=1257024092; bh=T9ZCwl+pR8ZS6rvNoJEbHowZ9FeWaXfi4ZCvGsLhzI4=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=0nX5/2LsrouQpg9LCKN6vE2Y2QXfo+tWZPwRFnbzcR43Q4g1RHGCrYHalf9hWWBs6 Xq3yJqYk0HftqM5sRIqRg4ZTVk5rFjhMScbJSXprRjRlAPBgpSAwjZlyOOKSgzjW8b uuao2pXAr65jGPAZPkQb9x0dOEbDrSJloGzow3qA= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=01firjKOsHx9a+WdmKT9pepYoQsLiWuI0/cB6NbBXQx8fymT+WPveNVpG9utNUszS CB2M/N0SPrpYQRpC1mTnwlXY1ZYmmPkOe95tvdqYglOgGAa82aft4MOGyW9bKjz6HHd EEAasAPPSk1EICSlYZ7FKcw4OTcgQfz5OEbizhs= Message-Id: <6.2.5.6.2.20091030141306.02f82810@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 30 Oct 2009 14:20:58 -0700 To: barryleiba@computer.org From: SM In-Reply-To: <6c9fcc2a0910301310g4d57c30aoa1527e25c1e5e1d4@mail.gmail.co m> References: <4AD3B75C.9070201@isode.com> <6c9fcc2a0910261311v24e65e99j4abb662f09307dd8@mail.gmail.com> <6c9fcc2a0910301310g4d57c30aoa1527e25c1e5e1d4@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ima@ietf.org Subject: Re: [EAI] Status of draft-ietf-eai-downgraded-display-02.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: , X-List-Received-Date: Fri, 30 Oct 2009 21:21:30 -0000 Hi Barry, At 13:10 30-10-2009, Barry Leiba wrote: >I've gotten stuck on the re-write of section 4, as well -- I can't >figure out what I'm supposed to do after step 4, and step 6, in >particular, doesn't make sense to me. I exchanged some emails with Fujiwara as I commented on that section. I'll try and find some time over the weekend to go over them. I got the procedure wrong at first when I tried to do a re-write and Fujiwara helped me out. Regards, -sm