From duerst@it.aoyama.ac.jp  Mon Aug  1 03:06:53 2011
Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888E021F876A for <ima@ietfa.amsl.com>; Mon,  1 Aug 2011 03:06:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.736
X-Spam-Level: 
X-Spam-Status: No, score=-99.736 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265,  MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UduqCAmisTkr for <ima@ietfa.amsl.com>; Mon,  1 Aug 2011 03:06:52 -0700 (PDT)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 171AC21F8764 for <ima@ietf.org>; Mon,  1 Aug 2011 03:06:50 -0700 (PDT)
Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id p71A6noO024529 for <ima@ietf.org>; Mon, 1 Aug 2011 19:06:50 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 0f3c_7864_f8ef8848_bc25_11e0_af69_001d096c566a; Mon, 01 Aug 2011 19:06:49 +0900
Received: from [IPv6:::1] ([133.2.210.1]:53999) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id <S1537436> for <ima@ietf.org> from <duerst@it.aoyama.ac.jp>; Mon, 1 Aug 2011 19:06:53 +0900
Message-ID: <4E367AB8.7090200@it.aoyama.ac.jp>
Date: Mon, 01 Aug 2011 19:06:48 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: =?UTF-8?B?TWFyayBEYXZpcyDimJU=?= <mark@macchiato.com>
References: <CA+FsOYasAd7w21vpX3gv0ZiHsmkiVCKfSa9hz+98THQGshmnsA@mail.gmail.com>	<4E1EEFFA.1080007@gulbrandsen.priv.no>	<CA+FsOYaFhXhD4LW4cmfZ3nz4AhEiBJ+E_TEHcE_rBetWpa_N1A@mail.gmail.com>	<C480FC7B47C5BC56FF265009@PST.JCK.COM>	<CA+FsOYY0ghirGe3ahrqM6DuXw51morONF6By0OfZ48f16KgvFA@mail.gmail.com>	<4E328CFC.2010502@it.aoyama.ac.jp> <CAJ2xs_E_OunHR3yPf7FO+W0xpqRyRqBDOoeM3jZqswWbqNaxfw@mail.gmail.com>
In-Reply-To: <CAJ2xs_E_OunHR3yPf7FO+W0xpqRyRqBDOoeM3jZqswWbqNaxfw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>, ima@ietf.org
Subject: Re: [EAI] Unicode's PRI #185 & EAI: should the UBA be revised to handle bidi email addresses better too?
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Aug 2011 10:06:53 -0000

Hello Mark,

Many thanks for your quick answer.

On 2011/08/01 10:52, Mark Davis ☕ wrote:
> I'm glad you're submitting this; a thoughtful analysis, as I'd expect from
> you.
>
> The UTC will be discussing this during this week, but I thought I'd say a
> few things now.
>
> On the bidi algorithm issues:
>
>     - first, the committee approaches the UBA very carefully -- it has proven
>     to be quite sensitive, and any changes have to be done carefully. I expect
>     any actions at this meeting to still be in a proposal state. The earliest
>     possible point for any release is U6.1, which is in February. There are 2
>     F2F meetings before then.

Good to hear. I really think this needs time.

>     - we've seen a number of major companies extending or wanting to extend
>     the BIDI algorithm for display.
> http://unicode.org/reports/tr9/#HL3permits this, but what we really
> don't want to happen is for the extensions
>     to be incompatible. That's really what is driving this; and probably any
>     change would be in the form of a defined extension, which would have a more
>     or less strong recommendation (depending on what the committee decides). It
>     may be cast as 'experimental' -- we'll just have to see.

I understand that there is some pressure, and that it is better to let 
the pressure go into a channel than explode all over the place.

> On the feedback issue: One area where the ed committee has been moving to is
> using the Unicode forum, which provides for much nicer archival and
> searching than an email list.

The forum may work well, in particular if the mailing list archive isn't 
very good. I know that the W3C spent quite a bit of time on getting a 
rather usable archive, but it still has problems such as linking threads 
across months/quarters. The Unicode archive 
(http://www.unicode.org/mail-arch/unicode-ml/) is slightly better than 
the IETF archives because it's organized by month.

What would be really nice with the forum would be to have a (voluntary, 
of course) facility to get email notifications. Otherwise, one has to 
poll for new comments actively, with is really a big pain. Most bug 
trackers provide email notification, but I haven't found it in the 
forum. Maybe I overlooked something?

> We could do a lot more, and also make it clearer that we want discussion to
> go on via email and forum discussions, but then want specific proposals that
> sum up different viewpoints to be submitted for the committee.

That would be great. That's actually not that different from how the 
IETF works.


Another thing that I mentioned in my mail is that there is a need for 
coordination between the IETF, the W3C, and Unicode on this issue, so 
that we can have an overall idea of what needs to be done to address the 
overall problem and who will deal with what parts of the problem. If you 
can give us your take on this coordination issue, that would also be 
appreciated.

Regards,   Martin.

> Mark
> *— Il meglio è l’inimico del bene —*
>
>
> On Fri, Jul 29, 2011 at 03:35, "Martin J. Dürst"<duerst@it.aoyama.ac.jp>wrote:
>
>> [This is a copy of a comment that I submitted via the Unicode Review Form
>> and posted on the member-only Unicode mailing list. I'm sending it here to
>> have a public record, because this's the mailing list where most of the
>> discussion about this draft in the IETF happened, as far as I'm aware of.]
>>
>>
>> Context
>> =======
>>
>> I'm an individual Unicode member, but I'll paste this in to the reporting
>> form because that's easier. Please make a 'document' out of it (or more than
>> one, if that helps to better address the issues raised here). I apologize
>> for being late with my comments.
>>
>>
>> Substantive Comments
>> ====================
>>
>> On substance, I don't agree with every detail of what Jonathan Rosenne,
>> Behdad Esfahbod, Aharon Lanin and others have said, I agree with them in
>> general. If their documents/messages are not properly submitted, I include
>> them herewith by reference.
>>
>> The proposal is an enormous change in the Bidi algorithm, changing its
>> nature in huge ways. Whatever the details eventually may look like, it won't
>> be possible to get everything right in one step, and probably countless
>> tweaks will follow (not that they necessarily will make things better,
>> though). Also, dealing with IRIs will increase the appetite/pressure for
>> dealing with various other syntactical constructs in texts.
>>
>> The introduction of the new algorithm will create numerous compatibility
>> issues (and attack surfaces for phishing, the main thing the proposal tries
>> to address) for a long period of time. Given that the Unicode Consortium has
>> been working hard to address (compared to this issue) even extremely minor
>> compatibility issues re. IDNs in TR46, it's difficult for me to see how this
>> fits together.
>>
>>
>> Taking One Step Back
>> ====================
>>
>> As one of the first people involved with what's now called IDNs and IRIs, I
>> know that the problem of such Bidi identifiers is extremely hard. The IETF,
>> as the standards organization responsible for (Internationalized) Domain
>> Names and for URIs/IRIs, has taken some steps to address it (there's a Bidi
>> section in RFC 3987 (http://tools.ietf.org/html/**rfc3987#section-4<http://tools.ietf.org/html/rfc3987#section-4>),
>> and for IDNs, there is http://tools.ietf.org/html/**rfc5893<http://tools.ietf.org/html/rfc5893>
>> ).
>>
>> I don't think these are necessarily sufficient or anything. And I don't
>> think that the proposal at hand is completely useless. However, the proposal
>> touches many aspects (e.g. recognizing IRIs in plain text,...) that are
>> vastly more adequate for definition in another standards organization or
>> where a high-bandwidth coordination with such an organization is crucial
>> (roughly speaking, first on feasibility of various approaches, then on how
>> to split up the work between the relevant organizations, then on
>> coordination in details.) Without such a step back and high-bandwidth
>> coordination, there is a strong chance of producing something highly
>> suboptimal.
>>
>> (Side comment on  detail: It would be better for the document to use
>> something like
>> http://tools.ietf.org/html/**rfc3987#section-2.2<http://tools.ietf.org/html/rfc3987#section-2.2>rather than the totally obscure and no longer maintained
>> http://rfc-ref.org/RFC-TEXTS/**3987/chapter2.html<http://rfc-ref.org/RFC-TEXTS/3987/chapter2.html>,
>> in the same way the Unicode Consortium would probably prefer to have its own
>> Web site referenced for its work rather than some third-party Web site.)
>>
>>
>> Taking Another Step Back
>> ========================
>>
>> I mention 'high-bandwidth' above. The Unicode "Public Review" process is
>> definitely not suited for this. It has various problems:
>> - The announcements are often very short, formalistic, and cryptic
>>   (I can dig up examples if needed.)
>> - The announcements go to a single list; forwarding them to other
>>   relevant places is mostly a matter of chance. This should be improved
>>   by identifying the relevant parties and contacting them directly.
>> - To find the Web form, one has to traverse several links.
>> - The submission is via a Web form, without any confirmation that the
>>   comment has been received.
>> - The space for comments on the form is very small.
>> - There is no way to make a comment public (except for publishing it
>>   separately).
>> - There is no official response to a comment submitted to the Web form.
>>   One finds out about what happened by chance or not at all.
>>   (compare to W3C process, where WGs are required to address each
>>    comment formally, and most of them including the responses are
>>    public)
>> - The turnaround is slow. Decisions get made (or postponed) at UTCs
>>   only.
>> Overall, from an outsider's point of view, the review process and the
>> review form feel like a needle's ear connected to a black hole.
>>
>> [I very much understand that part of the reason the UTC works the way it
>> works is because of its collaboration with ISO/IEC committees. And I don't
>> think any other standards organization has a perfect process. But what's
>> appropriate for one part of the UTCs work may not be appropriate for other
>> parts of its work (such as the matter at hand).]
>>
>>
>>
>> Conclusion
>> ==========
>>
>> I herewith very strongly recommend that the UTC, besides using the upcoming
>> meeting to advance discussion on the technical issues that the proposal
>> raises,
>> a) Postpone the decision to adopt any of the proposed changes, independent
>> of details, until such time as point b) is implemented and executed.
>> b) Swiftly take the necessary steps for a much better, high-bandwith
>> coordination of this topic and the various issues it encompasses, both using
>> the existing liaison mechanism and using public discussion on an appropriate
>> forum (e.g. one of the relevant IETF mailing lists (idna/eai/iri)).
>> c) Seriously work on improving the process for soliciting and addressing
>> comments from the public and relevant stakeholders.
>>
>>
>> Regards,    Martin.
>> ______________________________**_________________
>>
>> IMA mailing list
>> IMA@ietf.org
>> https://www.ietf.org/mailman/**listinfo/ima<https://www.ietf.org/mailman/listinfo/ima>
>>
>

From jyee@afilias.info  Mon Aug  1 07:56:07 2011
Return-Path: <jyee@afilias.info>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 287C721F8AB0 for <ima@ietfa.amsl.com>; Mon,  1 Aug 2011 07:56:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.265
X-Spam-Level: 
X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZjhFJF+YrZ8 for <ima@ietfa.amsl.com>; Mon,  1 Aug 2011 07:56:06 -0700 (PDT)
Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfa.amsl.com (Postfix) with ESMTP id 00FA121F8A80 for <ima@ietf.org>; Mon,  1 Aug 2011 07:56:05 -0700 (PDT)
Received: from ms6.yyz2.afilias-ops.info ([10.50.129.112] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from <jyee@afilias.info>) id 1Qntud-0005kc-9U for ima@ietf.org; Mon, 01 Aug 2011 14:56:12 +0000
Received: from mail-yw0-f50.google.com ([209.85.213.50]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from <jyee@afilias.info>) id 1Qntud-0000Ie-8T for ima@ietf.org; Mon, 01 Aug 2011 14:56:11 +0000
Received: by ywa12 with SMTP id 12so768735ywa.9 for <ima@ietf.org>; Mon, 01 Aug 2011 07:56:11 -0700 (PDT)
Received: by 10.151.88.35 with SMTP id q35mr883191ybl.32.1312210571089; Mon, 01 Aug 2011 07:56:11 -0700 (PDT)
Received: from [192.168.0.106] (75-119-235-2.dsl.teksavvy.com [75.119.235.2]) by mx.google.com with ESMTPS id o2sm2271951yhl.43.2011.08.01.07.56.09 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 01 Aug 2011 07:56:10 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Joseph Yee <jyee@afilias.info>
In-Reply-To: <4E360132.3050803@isode.com>
Date: Mon, 1 Aug 2011 10:56:08 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <C9B1BFFD-A539-4BFF-849C-C7B62FA58F25@afilias.info>
References: <20110711100444.26679.38042.idtracker@ietfa.amsl.com> <1323A97FB2432B0CCB92372B@dhcp-1764.meeting.ietf.org> <4E360132.3050803@isode.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>
X-Mailer: Apple Mail (2.1084)
Cc: ima@ietf.org
Subject: Re: [EAI] I-D Action: draft-ietf-eai-5738bis-01.txt
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Aug 2011 14:56:07 -0000

Hi Chris, Alexey and all,

joseph ENABLE HAT=3DIMPELMENTOR

On 2011-07-31, at 9:28 PM, Alexey Melnikov wrote:

> Hi Chris,
>=20
> Chris Newman wrote:
>> --On July 11, 2011 3:04:44 -0700 internet-drafts@ietf.org wrote:
>>>    Title           : IMAP Support for UTF-8
>>>    Author(s)       : Pete Resnick
>>>                          Chris Newman
>>>                          Sean Shen
>>>    Filename        : draft-ietf-eai-5738bis-01.txt
>>>    Pages           : 16
>>>    Date            : 2011-07-11
>> I re-read this and tried putting on my somewhat dusty "IMAP =
implementer hat" rather than my "protocol designer" hat. This =
unfortunately resulted in a lot of substantive issues :-(
>>=20
>> There is one change I feel would be most helpful to make. I have =
learned that LIST extended is quite difficult to implement in a =
distributed server deployment and I believe that requirement will be a =
barrier to deployment of this extension. I suggest the document be =
changed so that the UTF8 LIST selection and return options can be used =
without requiring full implementation of the LIST extended extension. If =
the working group has rough consensus to go this direction, then I can =
provide the ABNF and text so that capability can be provided with or =
without the LIST extended extension.
>>=20
>> This benefits servers because servers that make simpler =
implementation choices (such as UTF-8-only mailboxes) would no longer be =
forced to implement the entire LIST extended structure to allow =
interoperability. It also removes a "conditional" from the client (the =
code the client uses presently has to be different based on the presence =
of the LIST-EXTENDED capability).
> I might be agreeable to this change, but I would like to see a bit =
more details before unconditionally supporting it. Can you suggest some =
text/show an example on how this would look like?

Same to Alexey, would love to see some text and example.

>> I then subsequently asked myself what features could be removed from =
this document while keeping the document sufficiently complete. There =
are three options here:
>>=20
>> 1. Remove the "UTF8=3DUSER" capability. Since there's no password =
change or account creation command in IMAP, this information is not =
strictly necessary for clients. UTF-8 usernames and passwords will =
either work or not based on the identity subsystem.
> I tend to agree.
>> The client doesn't have to know, so unless there's a client that =
really needs to know for some reason, this should probably be removed =
just to make the protocol less cluttered. The same could be done for =
POP3, FYI.
> Base IMAP (RFC 3501) doesn't require support for non-ASCII usernames. =
In practice I suspect that many server implementations are ignoring the =
"ASCII-only" restriction and that UTF-8 usernames are just going to =
work.
>=20
> I am undecided on whether this capability should be removed or not.  I =
think it is basically advertising whether the identity subsystem =
supports non-ASCII usernames/passwords or not, so adding advertisement =
of this capability if a particular identity subsystem is compliant =
should be easy.
> If we are going to remove this capability, I would like to at least =
have a SHOULD about supporting UTF-8 username/passwords. As email =
addresses are frequently used as IMAP usernames, this can even be a =
MUST.

I would assume "UTF8=3DUSER" meant to notify client about SASL on =
username & password rather than support of UTF8 on username & password.

If it's about SASL, I think we are safe to remove the tag, with client =
needs to check the SASL tag.  If it's about supporting UTF8 in username =
& password, then I think it's ok to remove "UTF8=3DUSER", but only =
stating "UTF8=3DACCEPT" MUST imply the support of UTF8 to username & =
password.


>> 2. Remove the up-conversion requirements. The goal was to make it =
simpler for clients by allowing clients without 2047/2231 to work =
sooner. But this might be an additional barrier to server implementers, =
especially now that down-conversion has become more prominent than in =
the previous model. I'm thinking the deployment concern may be more =
important now than the hope of a protocol-designer to get rid of the =
ugly encodings sooner.
> +1.

+1.

>> 3. Remove the UTF8=3DAPPEND capability. This is a direct =
server-implementer vs. client-implementer tradeoff. Not having that =
capability and requiring servers to support this in any mailbox that =
supports SELECT/EXAMINE UTF8 makes things simpler and more predictable =
for clients, but at the expense of the server implementer. In hindsight, =
I think this is one where the server implementers should suffer to make =
things easier for the clients and to make the protocol look simpler.
> Just to clarify: are you saying that this functionality should always =
be supported by compliant servers? If yes, do you also propose to remove =
the UTF-8 signaling in the APPEND command?

I think this is good, but haven't think deep enough on this, including =
the UTF8  signalling in APPEND command.  Haven't thought completely yet =
where we may need the signalling.

-Joseph

>> And yes, you can be annoyed at me proposing simplifications/changes =
that remove things I put into the original document several years ago =
;-) But I must admit that working in the more constrained post-bubble =
environment has given me a greater respect and attention to the nuances =
of simplicity.
>>=20
>> Note that I did not see any technical errors in the current document, =
so if the WG decided to ignore my =
guilt-in-hindsight-for-unnecessary-complexity, I would not object to =
publishing the current document. But I do think it could be made more =
deployable and that is a significant concern. I'd really appreciate if =
others spoke up on this topic.
>=20
>=20
> _______________________________________________
> IMA mailing list
> IMA@ietf.org
> https://www.ietf.org/mailman/listinfo/ima


From chris.newman@oracle.com  Mon Aug  1 11:18:06 2011
Return-Path: <chris.newman@oracle.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89F4011E808E for <ima@ietfa.amsl.com>; Mon,  1 Aug 2011 11:18:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.929
X-Spam-Level: 
X-Spam-Status: No, score=-105.929 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfhUmK7tTNxv for <ima@ietfa.amsl.com>; Mon,  1 Aug 2011 11:18:06 -0700 (PDT)
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5C45E8007 for <ima@ietf.org>; Mon,  1 Aug 2011 11:17:48 -0700 (PDT)
Received: from brmsunmail2-sfbay.uk.sun.com ([10.79.11.101]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id p71IHlA1004784; Mon, 1 Aug 2011 18:17:48 GMT
Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by brmsunmail2-sfbay.uk.sun.com (8.14.4+Sun/8.14.4/ENSMAIL,v2.4) with ESMTP id p71IHkJQ007229; Mon, 1 Aug 2011 18:17:46 GMT
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-disposition: inline
Content-type: text/plain; CHARSET=US-ASCII; format=flowed
Received: from [10.145.239.205] (nifty-silver.us.oracle.com [10.145.239.205]) by gotmail.us.oracle.com (Oracle Communications Messaging Exchange Server 7u5-4.01 64bit (built May 4 2011)) with ESMTPA id <0LP90002IHHGND00@gotmail.us.oracle.com>; Mon, 01 Aug 2011 11:17:45 -0700 (PDT)
Date: Mon, 01 Aug 2011 11:17:39 -0700
From: Chris Newman <chris.newman@oracle.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>
Message-id: <1934C0CD07D06963F62C8D8C@96B2F16665FF96BAE59E9B90>
In-reply-to: <4E360132.3050803@isode.com>
References: <20110711100444.26679.38042.idtracker@ietfa.amsl.com> <1323A97FB2432B0CCB92372B@dhcp-1764.meeting.ietf.org> <4E360132.3050803@isode.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
Cc: ima@ietf.org
Subject: Re: [EAI] I-D Action: draft-ietf-eai-5738bis-01.txt
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Aug 2011 18:18:06 -0000

--On July 31, 2011 21:28:18 -0400 Alexey Melnikov 
<alexey.melnikov@isode.com> wrote:
> I might be agreeable to this change, but I would like to see a bit more
> details before unconditionally supporting it. Can you suggest some
> text/show an example on how this would look like?

Basically, I'd copy a subset of the LIST EXTENDED support into the draft 
and say that subset is activated by UTF8=ACCEPT even if LIST EXTENDED is 
not advertised.

That subset would not include multiple list patterns, remote, childinfo, or 
recursivematch. I think the subset would have to include SUBSCRIBED to 
avoid mucking with LSUB.

So the result would be syntactically upwards-compatible with list extended 
(the client could send commands within the subset regardless of whether 
LIST-EXTENDED was advertised), and would support the SUBSCRIBED, UTF8 and 
UTF8ONLY selection options and the UTF8 and SUBSCRIBED return options.

>> 3. Remove the UTF8=APPEND capability. This is a direct
>> server-implementer vs. client-implementer tradeoff. Not having that
>> capability and requiring servers to support this in any mailbox that
>> supports SELECT/EXAMINE UTF8 makes things simpler and more predictable
>> for clients, but at the expense of the server implementer. In
>> hindsight, I think this is one where the server implementers should
>> suffer to make things easier for the clients and to make the protocol
>> look simpler.
> Just to clarify: are you saying that this functionality should always be
> supported by compliant servers? If yes, do you also propose to remove the
> UTF-8 signaling in the APPEND command?

I think the answer should be YES and NO. That is UTF8=ACCEPT implies what 
is presently implied by UTF8=APPEND, but no changes to the document 
otherwise.

I think the signaling in the APPEND command needs to be left for symmetry 
with the signaling we have in SMTP. But if someone wants to make the 
contrary argument, that would interest me.

		- Chris


From chris.newman@oracle.com  Mon Aug  1 11:51:42 2011
Return-Path: <chris.newman@oracle.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83E2E11E812C for <ima@ietfa.amsl.com>; Mon,  1 Aug 2011 11:51:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.937
X-Spam-Level: 
X-Spam-Status: No, score=-105.937 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UoDKApEsBio2 for <ima@ietfa.amsl.com>; Mon,  1 Aug 2011 11:51:42 -0700 (PDT)
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by ietfa.amsl.com (Postfix) with ESMTP id E22E511E8077 for <ima@ietf.org>; Mon,  1 Aug 2011 11:51:39 -0700 (PDT)
Received: from brmsunmail1-sfbay.uk.sun.com ([10.79.11.100]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id p71IpN7j012936; Mon, 1 Aug 2011 18:51:23 GMT
Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by brmsunmail1-sfbay.uk.sun.com (8.14.4+Sun/8.14.4/ENSMAIL,v2.4) with ESMTP id p71IpMJH064268; Mon, 1 Aug 2011 18:51:22 GMT
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-disposition: inline
Content-type: text/plain; CHARSET=US-ASCII; format=flowed
Received: from [10.145.239.205] (nifty-silver.us.oracle.com [10.145.239.205]) by gotmail.us.oracle.com (Oracle Communications Messaging Exchange Server 7u5-4.01 64bit (built May 4 2011)) with ESMTPA id <0LP90002MJ1JND00@gotmail.us.oracle.com>; Mon, 01 Aug 2011 11:51:21 -0700 (PDT)
Date: Mon, 01 Aug 2011 11:51:19 -0700
From: Chris Newman <chris.newman@oracle.com>
To: Joseph Yee <jyee@afilias.info>, Alexey Melnikov <alexey.melnikov@isode.com>
Message-id: <A8C82FE85233D49F061CBB4D@96B2F16665FF96BAE59E9B90>
In-reply-to: <C9B1BFFD-A539-4BFF-849C-C7B62FA58F25@afilias.info>
References: <20110711100444.26679.38042.idtracker@ietfa.amsl.com> <1323A97FB2432B0CCB92372B@dhcp-1764.meeting.ietf.org> <4E360132.3050803@isode.com> <C9B1BFFD-A539-4BFF-849C-C7B62FA58F25@afilias.info>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
Cc: ima@ietf.org
Subject: Re: [EAI] I-D Action: draft-ietf-eai-5738bis-01.txt
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Aug 2011 18:51:42 -0000

--On August 1, 2011 10:56:08 -0400 Joseph Yee <jyee@afilias.info> wrote:
> I would assume "UTF8=USER" meant to notify client about SASL on username
> & password rather than support of UTF8 on username & password.
>
> If it's about SASL, I think we are safe to remove the tag, with client
> needs to check the SASL tag.  If it's about supporting UTF8 in username &
> password, then I think it's ok to remove "UTF8=USER", but only stating
> "UTF8=ACCEPT" MUST imply the support of UTF8 to username & password.

The IMAP AUTHENTICATE command already supports UTF-8 if the SASL mechanism 
selected does. The PLAIN mechanism supports UTF-8.

So UTF8=USER was only about the IMAP LOGIN command. So I'd replace section 
5 with something like:

5.  LOGIN Command

   If the "UTF8=ACCEPT" capability is advertised, that indicates the
   server understands UTF-8 user names and passwords in the LOGIN
   command. This is not a guarantee that they underlying identity
   system will allow the creation of accounts with UTF-8 user names
   and/or passwords. However, if the identity system does allow such
   accounts, then the server MUST apply SASLprep [RFC4013] to both
   arguments of the LOGIN command. The server MUST reject UTF-8 that
   fails to comply with the formal syntax in RFC 3629 [RFC3629] or
   if it encounters Unicode characters disallowed by SASLprep.

		- Chris





From mark.edward.davis@gmail.com  Sun Jul 31 18:52:21 2011
Return-Path: <mark.edward.davis@gmail.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 249435E8005 for <ima@ietfa.amsl.com>; Sun, 31 Jul 2011 18:52:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.704
X-Spam-Level: 
X-Spam-Status: No, score=-0.704 tagged_above=-999 required=5 tests=[AWL=-0.578, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X01XCbftAF7a for <ima@ietfa.amsl.com>; Sun, 31 Jul 2011 18:52:19 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 531685E8001 for <ima@ietf.org>; Sun, 31 Jul 2011 18:52:19 -0700 (PDT)
Received: by gyd5 with SMTP id 5so3859476gyd.31 for <ima@ietf.org>; Sun, 31 Jul 2011 18:52:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=+as+EkuSObu7rrnFX3i6fFuZlxhRPKywrljogsaFa9Q=; b=Akebdc8X0PPUjCfykoR+uNCYGzzbEbAjSdZdu5SCftBCknkXWpYeUaHypwyVT11H0W 1jHiTuqZap1N6/EJwgdESMZduGYK1H5gdVHTjU4FfoHOwzVDGKVeDFnkbUFYOZPXXaxL UA7j6RHIMrr+P9dT1SzJazaeK/CUv9lNzQEAw=
MIME-Version: 1.0
Received: by 10.150.170.10 with SMTP id s10mr429425ybe.76.1312163543884; Sun, 31 Jul 2011 18:52:23 -0700 (PDT)
Sender: mark.edward.davis@gmail.com
Received: by 10.151.148.6 with HTTP; Sun, 31 Jul 2011 18:52:23 -0700 (PDT)
In-Reply-To: <4E328CFC.2010502@it.aoyama.ac.jp>
References: <CA+FsOYasAd7w21vpX3gv0ZiHsmkiVCKfSa9hz+98THQGshmnsA@mail.gmail.com> <4E1EEFFA.1080007@gulbrandsen.priv.no> <CA+FsOYaFhXhD4LW4cmfZ3nz4AhEiBJ+E_TEHcE_rBetWpa_N1A@mail.gmail.com> <C480FC7B47C5BC56FF265009@PST.JCK.COM> <CA+FsOYY0ghirGe3ahrqM6DuXw51morONF6By0OfZ48f16KgvFA@mail.gmail.com> <4E328CFC.2010502@it.aoyama.ac.jp>
Date: Sun, 31 Jul 2011 18:52:23 -0700
X-Google-Sender-Auth: Jq4o9kvk4fP8sF5NVyROUVJAPr8
Message-ID: <CAJ2xs_E_OunHR3yPf7FO+W0xpqRyRqBDOoeM3jZqswWbqNaxfw@mail.gmail.com>
From: =?UTF-8?B?TWFyayBEYXZpcyDimJU=?= <mark@macchiato.com>
To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= <duerst@it.aoyama.ac.jp>
Content-Type: multipart/alternative; boundary=000e0cd58c6eeba5ce04a967e17e
X-Mailman-Approved-At: Mon, 01 Aug 2011 18:07:14 -0700
Cc: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>, ima@ietf.org
Subject: Re: [EAI] Unicode's PRI #185 & EAI: should the UBA be revised to handle bidi email addresses better too?
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Aug 2011 01:52:21 -0000

--000e0cd58c6eeba5ce04a967e17e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I'm glad you're submitting this; a thoughtful analysis, as I'd expect from
you.

The UTC will be discussing this during this week, but I thought I'd say a
few things now.

On the bidi algorithm issues:

   - first, the committee approaches the UBA very carefully -- it has prove=
n
   to be quite sensitive, and any changes have to be done carefully. I expe=
ct
   any actions at this meeting to still be in a proposal state. The earlies=
t
   possible point for any release is U6.1, which is in February. There are =
2
   F2F meetings before then.
   - we've seen a number of major companies extending or wanting to extend
   the BIDI algorithm for display.
http://unicode.org/reports/tr9/#HL3permits this, but what we really
don't want to happen is for the extensions
   to be incompatible. That's really what is driving this; and probably any
   change would be in the form of a defined extension, which would have a m=
ore
   or less strong recommendation (depending on what the committee decides).=
 It
   may be cast as 'experimental' -- we'll just have to see.

On the feedback issue: One area where the ed committee has been moving to i=
s
using the Unicode forum, which provides for much nicer archival and
searching than an email list.

We could do a lot more, and also make it clearer that we want discussion to
go on via email and forum discussions, but then want specific proposals tha=
t
sum up different viewpoints to be submitted for the committee.

Mark
*=E2=80=94 Il meglio =C3=A8 l=E2=80=99inimico del bene =E2=80=94*


On Fri, Jul 29, 2011 at 03:35, "Martin J. D=C3=BCrst" <duerst@it.aoyama.ac.=
jp>wrote:

> [This is a copy of a comment that I submitted via the Unicode Review Form
> and posted on the member-only Unicode mailing list. I'm sending it here t=
o
> have a public record, because this's the mailing list where most of the
> discussion about this draft in the IETF happened, as far as I'm aware of.=
]
>
>
> Context
> =3D=3D=3D=3D=3D=3D=3D
>
> I'm an individual Unicode member, but I'll paste this in to the reporting
> form because that's easier. Please make a 'document' out of it (or more t=
han
> one, if that helps to better address the issues raised here). I apologize
> for being late with my comments.
>
>
> Substantive Comments
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> On substance, I don't agree with every detail of what Jonathan Rosenne,
> Behdad Esfahbod, Aharon Lanin and others have said, I agree with them in
> general. If their documents/messages are not properly submitted, I includ=
e
> them herewith by reference.
>
> The proposal is an enormous change in the Bidi algorithm, changing its
> nature in huge ways. Whatever the details eventually may look like, it wo=
n't
> be possible to get everything right in one step, and probably countless
> tweaks will follow (not that they necessarily will make things better,
> though). Also, dealing with IRIs will increase the appetite/pressure for
> dealing with various other syntactical constructs in texts.
>
> The introduction of the new algorithm will create numerous compatibility
> issues (and attack surfaces for phishing, the main thing the proposal tri=
es
> to address) for a long period of time. Given that the Unicode Consortium =
has
> been working hard to address (compared to this issue) even extremely mino=
r
> compatibility issues re. IDNs in TR46, it's difficult for me to see how t=
his
> fits together.
>
>
> Taking One Step Back
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> As one of the first people involved with what's now called IDNs and IRIs,=
 I
> know that the problem of such Bidi identifiers is extremely hard. The IET=
F,
> as the standards organization responsible for (Internationalized) Domain
> Names and for URIs/IRIs, has taken some steps to address it (there's a Bi=
di
> section in RFC 3987 (http://tools.ietf.org/html/**rfc3987#section-4<http:=
//tools.ietf.org/html/rfc3987#section-4>),
> and for IDNs, there is http://tools.ietf.org/html/**rfc5893<http://tools.=
ietf.org/html/rfc5893>
> ).
>
> I don't think these are necessarily sufficient or anything. And I don't
> think that the proposal at hand is completely useless. However, the propo=
sal
> touches many aspects (e.g. recognizing IRIs in plain text,...) that are
> vastly more adequate for definition in another standards organization or
> where a high-bandwidth coordination with such an organization is crucial
> (roughly speaking, first on feasibility of various approaches, then on ho=
w
> to split up the work between the relevant organizations, then on
> coordination in details.) Without such a step back and high-bandwidth
> coordination, there is a strong chance of producing something highly
> suboptimal.
>
> (Side comment on  detail: It would be better for the document to use
> something like
> http://tools.ietf.org/html/**rfc3987#section-2.2<http://tools.ietf.org/ht=
ml/rfc3987#section-2.2>rather than the totally obscure and no longer mainta=
ined
> http://rfc-ref.org/RFC-TEXTS/**3987/chapter2.html<http://rfc-ref.org/RFC-=
TEXTS/3987/chapter2.html>,
> in the same way the Unicode Consortium would probably prefer to have its =
own
> Web site referenced for its work rather than some third-party Web site.)
>
>
> Taking Another Step Back
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> I mention 'high-bandwidth' above. The Unicode "Public Review" process is
> definitely not suited for this. It has various problems:
> - The announcements are often very short, formalistic, and cryptic
>  (I can dig up examples if needed.)
> - The announcements go to a single list; forwarding them to other
>  relevant places is mostly a matter of chance. This should be improved
>  by identifying the relevant parties and contacting them directly.
> - To find the Web form, one has to traverse several links.
> - The submission is via a Web form, without any confirmation that the
>  comment has been received.
> - The space for comments on the form is very small.
> - There is no way to make a comment public (except for publishing it
>  separately).
> - There is no official response to a comment submitted to the Web form.
>  One finds out about what happened by chance or not at all.
>  (compare to W3C process, where WGs are required to address each
>   comment formally, and most of them including the responses are
>   public)
> - The turnaround is slow. Decisions get made (or postponed) at UTCs
>  only.
> Overall, from an outsider's point of view, the review process and the
> review form feel like a needle's ear connected to a black hole.
>
> [I very much understand that part of the reason the UTC works the way it
> works is because of its collaboration with ISO/IEC committees. And I don'=
t
> think any other standards organization has a perfect process. But what's
> appropriate for one part of the UTCs work may not be appropriate for othe=
r
> parts of its work (such as the matter at hand).]
>
>
>
> Conclusion
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> I herewith very strongly recommend that the UTC, besides using the upcomi=
ng
> meeting to advance discussion on the technical issues that the proposal
> raises,
> a) Postpone the decision to adopt any of the proposed changes, independen=
t
> of details, until such time as point b) is implemented and executed.
> b) Swiftly take the necessary steps for a much better, high-bandwith
> coordination of this topic and the various issues it encompasses, both us=
ing
> the existing liaison mechanism and using public discussion on an appropri=
ate
> forum (e.g. one of the relevant IETF mailing lists (idna/eai/iri)).
> c) Seriously work on improving the process for soliciting and addressing
> comments from the public and relevant stakeholders.
>
>
> Regards,    Martin.
> ______________________________**_________________
>
> IMA mailing list
> IMA@ietf.org
> https://www.ietf.org/mailman/**listinfo/ima<https://www.ietf.org/mailman/=
listinfo/ima>
>

--000e0cd58c6eeba5ce04a967e17e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<font face=3D"times new roman,serif">I&#39;m glad you&#39;re submitting thi=
s; a thoughtful analysis, as I&#39;d expect from you.<br clear=3D"all"></fo=
nt><div><font face=3D"&#39;times new roman&#39;, serif"><div style=3D"backg=
round-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;ma=
rgin-right:0px;font-family:Times;font-size:medium">
<span style=3D"font-family:&#39;times new roman&#39;, serif;font-size:small=
"><br></span></div><div style=3D"background-color:transparent;margin-top:0p=
x;margin-left:0px;margin-bottom:0px;margin-right:0px;font-family:Times;font=
-size:medium">
<span style=3D"font-family:&#39;times new roman&#39;, serif;font-size:small=
">The UTC will be discussing this during this week, but I thought I&#39;d s=
ay a few things now.</span></div><div style=3D"background-color:transparent=
;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px;font-fam=
ily:Times;font-size:medium">
<span style=3D"font-family:&#39;times new roman&#39;, serif;font-size:small=
"><br></span></div><div style=3D"background-color:transparent;margin-top:0p=
x;margin-left:0px;margin-bottom:0px;margin-right:0px;font-family:Times;font=
-size:medium">
<span style=3D"font-family:&#39;times new roman&#39;, serif;font-size:small=
">On the bidi algorithm issues:=C2=A0</span></div><div style=3D"background-=
color: transparent; margin-top: 0px; margin-left: 0px; margin-bottom: 0px; =
margin-right: 0px; ">
<ul style=3D"font-family: Times; font-size: medium; "><li><span class=3D"Ap=
ple-style-span" style=3D"font-family: &#39;times new roman&#39;, serif; fon=
t-size: small; ">first, the committee approaches the UBA very carefully -- =
it has proven to be quite sensitive, and any changes have to be done carefu=
lly. I expect any actions at this meeting to still be in a proposal state. =
The earliest possible point for any release is U6.1, which is in February. =
There are 2 F2F meetings before then.</span></li>
<li><span class=3D"Apple-style-span" style=3D"font-family: &#39;times new r=
oman&#39;, serif; font-size: small; ">we&#39;ve seen a number of major comp=
anies extending or wanting to extend the BIDI algorithm for display.=C2=A0<=
a href=3D"http://unicode.org/reports/tr9/#HL3">http://unicode.org/reports/t=
r9/#HL3</a> permits this, but what we really don&#39;t want to happen is fo=
r the extensions to be incompatible. That&#39;s really what is driving this=
; and probably any change would be in the form of a defined extension, whic=
h would have a more or less strong recommendation (depending on what the co=
mmittee decides). It may be cast as &#39;experimental&#39; -- we&#39;ll jus=
t have to see.</span></li>
</ul><meta charset=3D"utf-8"><div>On the feedback issue:=C2=A0One area wher=
e the ed committee has been moving to is using the Unicode forum, which pro=
vides for much nicer archival and searching than an email list.=C2=A0</div>=
<div><br>
</div><div>We could do a lot more, and also make it clearer that we want di=
scussion to go on via email and forum discussions, but then want specific p=
roposals that sum up different viewpoints to be submitted for the committee=
.</div>
<meta charset=3D"utf-8"></div><div style=3D"background-color:transparent;ma=
rgin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px;font-family=
:Times;font-size:medium"><span style=3D"font-family:&#39;times new roman&#3=
9;, serif;font-size:small"><br>
</span></div><div style=3D"background-color:transparent;margin-top:0px;marg=
in-left:0px;margin-bottom:0px;margin-right:0px;font-family:Times;font-size:=
medium"><span style=3D"font-family:&#39;times new roman&#39;, serif;font-si=
ze:small">Mark</span></div>
<i>=E2=80=94 Il meglio =C3=A8 l=E2=80=99inimico del bene =E2=80=94</i></fon=
t><br>
<br><br><div class=3D"gmail_quote">On Fri, Jul 29, 2011 at 03:35, &quot;Mar=
tin J. D=C3=BCrst&quot; <span dir=3D"ltr">&lt;<a href=3D"mailto:duerst@it.a=
oyama.ac.jp">duerst@it.aoyama.ac.jp</a>&gt;</span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex;">
[This is a copy of a comment that I submitted via the Unicode Review Form a=
nd posted on the member-only Unicode mailing list. I&#39;m sending it here =
to have a public record, because this&#39;s the mailing list where most of =
the discussion about this draft in the IETF happened, as far as I&#39;m awa=
re of.]<br>

<br>
<br>
Context<br>
=3D=3D=3D=3D=3D=3D=3D<br>
<br>
I&#39;m an individual Unicode member, but I&#39;ll paste this in to the rep=
orting form because that&#39;s easier. Please make a &#39;document&#39; out=
 of it (or more than one, if that helps to better address the issues raised=
 here). I apologize for being late with my comments.<br>

<br>
<br>
Substantive Comments<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
<br>
On substance, I don&#39;t agree with every detail of what Jonathan Rosenne,=
 Behdad Esfahbod, Aharon Lanin and others have said, I agree with them in g=
eneral. If their documents/messages are not properly submitted, I include t=
hem herewith by reference.<br>

<br>
The proposal is an enormous change in the Bidi algorithm, changing its natu=
re in huge ways. Whatever the details eventually may look like, it won&#39;=
t be possible to get everything right in one step, and probably countless t=
weaks will follow (not that they necessarily will make things better, thoug=
h). Also, dealing with IRIs will increase the appetite/pressure for dealing=
 with various other syntactical constructs in texts.<br>

<br>
The introduction of the new algorithm will create numerous compatibility is=
sues (and attack surfaces for phishing, the main thing the proposal tries t=
o address) for a long period of time. Given that the Unicode Consortium has=
 been working hard to address (compared to this issue) even extremely minor=
 compatibility issues re. IDNs in TR46, it&#39;s difficult for me to see ho=
w this fits together.<br>

<br>
<br>
Taking One Step Back<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
<br>
As one of the first people involved with what&#39;s now called IDNs and IRI=
s, I know that the problem of such Bidi identifiers is extremely hard. The =
IETF, as the standards organization responsible for (Internationalized) Dom=
ain Names and for URIs/IRIs, has taken some steps to address it (there&#39;=
s a Bidi section in RFC 3987 (<a href=3D"http://tools.ietf.org/html/rfc3987=
#section-4" target=3D"_blank">http://tools.ietf.org/html/<u></u>rfc3987#sec=
tion-4</a>), and for IDNs, there is <a href=3D"http://tools.ietf.org/html/r=
fc5893" target=3D"_blank">http://tools.ietf.org/html/<u></u>rfc5893</a>).<b=
r>

<br>
I don&#39;t think these are necessarily sufficient or anything. And I don&#=
39;t think that the proposal at hand is completely useless. However, the pr=
oposal touches many aspects (e.g. recognizing IRIs in plain text,...) that =
are vastly more adequate for definition in another standards organization o=
r where a high-bandwidth coordination with such an organization is crucial =
(roughly speaking, first on feasibility of various approaches, then on how =
to split up the work between the relevant organizations, then on coordinati=
on in details.) Without such a step back and high-bandwidth coordination, t=
here is a strong chance of producing something highly suboptimal.<br>

<br>
(Side comment on =C2=A0detail: It would be better for the document to use s=
omething like<br>
<a href=3D"http://tools.ietf.org/html/rfc3987#section-2.2" target=3D"_blank=
">http://tools.ietf.org/html/<u></u>rfc3987#section-2.2</a> rather than the=
 totally obscure and no longer maintained <a href=3D"http://rfc-ref.org/RFC=
-TEXTS/3987/chapter2.html" target=3D"_blank">http://rfc-ref.org/RFC-TEXTS/<=
u></u>3987/chapter2.html</a>, in the same way the Unicode Consortium would =
probably prefer to have its own Web site referenced for its work rather tha=
n some third-party Web site.)<br>

<br>
<br>
Taking Another Step Back<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br=
>
<br>
I mention &#39;high-bandwidth&#39; above. The Unicode &quot;Public Review&q=
uot; process is definitely not suited for this. It has various problems:<br=
>
- The announcements are often very short, formalistic, and cryptic<br>
 =C2=A0(I can dig up examples if needed.)<br>
- The announcements go to a single list; forwarding them to other<br>
 =C2=A0relevant places is mostly a matter of chance. This should be improve=
d<br>
 =C2=A0by identifying the relevant parties and contacting them directly.<br=
>
- To find the Web form, one has to traverse several links.<br>
- The submission is via a Web form, without any confirmation that the<br>
 =C2=A0comment has been received.<br>
- The space for comments on the form is very small.<br>
- There is no way to make a comment public (except for publishing it<br>
 =C2=A0separately).<br>
- There is no official response to a comment submitted to the Web form.<br>
 =C2=A0One finds out about what happened by chance or not at all.<br>
 =C2=A0(compare to W3C process, where WGs are required to address each<br>
 =C2=A0 comment formally, and most of them including the responses are<br>
 =C2=A0 public)<br>
- The turnaround is slow. Decisions get made (or postponed) at UTCs<br>
 =C2=A0only.<br>
Overall, from an outsider&#39;s point of view, the review process and the r=
eview form feel like a needle&#39;s ear connected to a black hole.<br>
<br>
[I very much understand that part of the reason the UTC works the way it wo=
rks is because of its collaboration with ISO/IEC committees. And I don&#39;=
t think any other standards organization has a perfect process. But what&#3=
9;s appropriate for one part of the UTCs work may not be appropriate for ot=
her parts of its work (such as the matter at hand).]<br>

<br>
<br>
<br>
Conclusion<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
<br>
I herewith very strongly recommend that the UTC, besides using the upcoming=
 meeting to advance discussion on the technical issues that the proposal ra=
ises,<br>
a) Postpone the decision to adopt any of the proposed changes, independent =
of details, until such time as point b) is implemented and executed.<br>
b) Swiftly take the necessary steps for a much better, high-bandwith coordi=
nation of this topic and the various issues it encompasses, both using the =
existing liaison mechanism and using public discussion on an appropriate fo=
rum (e.g. one of the relevant IETF mailing lists (idna/eai/iri)).<br>

c) Seriously work on improving the process for soliciting and addressing co=
mments from the public and relevant stakeholders.<br>
<br>
<br>
Regards, =C2=A0 =C2=A0Martin.<br>
______________________________<u></u>_________________<div><div></div><div =
class=3D"h5"><br>
IMA mailing list<br>
<a href=3D"mailto:IMA@ietf.org" target=3D"_blank">IMA@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/ima" target=3D"_blank">htt=
ps://www.ietf.org/mailman/<u></u>listinfo/ima</a><br>
</div></div></blockquote></div><br></div>

--000e0cd58c6eeba5ce04a967e17e--

From jyee@afilias.info  Mon Aug  1 18:55:40 2011
Return-Path: <jyee@afilias.info>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F145E21F8D34 for <ima@ietfa.amsl.com>; Mon,  1 Aug 2011 18:55:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.265
X-Spam-Level: 
X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1wC6bCLSBiU for <ima@ietfa.amsl.com>; Mon,  1 Aug 2011 18:55:38 -0700 (PDT)
Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfa.amsl.com (Postfix) with ESMTP id AF2B921F8D12 for <ima@ietf.org>; Mon,  1 Aug 2011 18:55:38 -0700 (PDT)
Received: from ms5.yyz2.afilias-ops.info ([10.50.129.111] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from <jyee@afilias.info>) id 1Qo4Ct-0004qR-7t for ima@ietf.org; Tue, 02 Aug 2011 01:55:43 +0000
Received: from mail-yi0-f50.google.com ([209.85.218.50]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from <jyee@afilias.info>) id 1Qo4Ct-00065V-44 for ima@ietf.org; Tue, 02 Aug 2011 01:55:43 +0000
Received: by yib19 with SMTP id 19so3892255yib.9 for <ima@ietf.org>; Mon, 01 Aug 2011 18:55:42 -0700 (PDT)
Received: by 10.236.146.4 with SMTP id q4mr2350365yhj.3.1312250142786; Mon, 01 Aug 2011 18:55:42 -0700 (PDT)
Received: from [192.168.0.106] (75-119-235-2.dsl.teksavvy.com [75.119.235.2]) by mx.google.com with ESMTPS id c63sm4275311yhe.46.2011.08.01.18.55.41 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 01 Aug 2011 18:55:42 -0700 (PDT)
From: Joseph Yee <jyee@afilias.info>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Mon, 1 Aug 2011 21:55:40 -0400
To: "ima@ietf.org WG" <ima@ietf.org>
Message-Id: <19FC9CA3-0E2C-4727-81A8-37AD80B7F393@afilias.info>
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [EAI] Announcement: WG Consensus reached from IETF81 Quebec City
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Aug 2011 01:55:40 -0000

Hi All,

The WG had made the following tentative consensus calls during meeting =
at IETF 81 Quebec City.  These results are considered final unless new =
substantive argument are raised on the list by August 8, 17:00 US =
Pacific Time.

(1)
WG Consensus on Message-ID header field:
Message-ID allows UTF-8 in any part of its value.

(2)
WG Consensus on Commentary Materials in RFC5335-bis:
RC5335bis will keep the draft's commentary materials in appendix =
section.


Best,
Joseph, co-chair of EAI=

From healthyao@gmail.com  Mon Aug  1 19:18:15 2011
Return-Path: <healthyao@gmail.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD3921F8BA9 for <ima@ietfa.amsl.com>; Mon,  1 Aug 2011 19:18:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.465
X-Spam-Level: 
X-Spam-Status: No, score=-1.465 tagged_above=-999 required=5 tests=[AWL=-0.819, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBkolZicum11 for <ima@ietfa.amsl.com>; Mon,  1 Aug 2011 19:18:13 -0700 (PDT)
Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id EA66021F8BB6 for <ima@ietf.org>; Mon,  1 Aug 2011 19:18:12 -0700 (PDT)
Received: by pzk6 with SMTP id 6so11633762pzk.26 for <ima@ietf.org>; Mon, 01 Aug 2011 19:18:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:from:to:subject:date:mime-version:content-type :x-priority:x-msmail-priority:x-mailer:x-mimeole; bh=hVyXIJ8KI6uh7O2VqpKurG4gqmA3KjH+Azj6BZu/tAg=; b=EwubmDj0fNZEQdQx5wqJxnMDD3ZzBCtzL7b5tsXccyryqjLF8lYD7bSFC4blRl/g0m AzWwWaoL/2SeKjZ7aOfMu93N7iPCQvXyHKlsZTT7a58+SktJ3YdoFBQG93fUkZrH/aJC fjw5LPTTNqUnY/4YKxBGip+H+Xggo+kyBee/I=
Received: by 10.68.31.8 with SMTP id w8mr4812020pbh.379.1312251493892; Mon, 01 Aug 2011 19:18:13 -0700 (PDT)
Received: from LENOVO47E041CF ([218.241.111.35]) by mx.google.com with ESMTPS id e6sm1050249pbm.87.2011.08.01.19.18.11 (version=SSLv3 cipher=OTHER); Mon, 01 Aug 2011 19:18:13 -0700 (PDT)
Message-ID: <3B41F7A50742454987AC87127305F889@LENOVO47E041CF>
From: "Jiankang Yao" <healthyao@gmail.com>
To: <ima@ietf.org>
Date: Tue, 2 Aug 2011 10:18:09 +0800
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0304_01CC50FD.7A6FFF90"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
Subject: [EAI] 81 IETF EAI meeting minutes
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Aug 2011 02:18:15 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_0304_01CC50FD.7A6FFF90
Content-Type: text/plain;
	charset="windows-1252"
Content-Transfer-Encoding: base64

RGVhciBhbGwsDQoNCg0KUGxzIHNlZSB0aGUgaW5pdGlhbCA4MSBJRVRGIEVBSSBtZWV0aW5nIG1p
bnV0ZXMgYmVsb3cgb3IgYXR0YWNoZWQuDQoNClBscyBraW5kbHkgZ2l2ZSB5b3VyIGNvbW1lbnRz
IGJlZm9yZSA4IEF1Zy4NCg0KDQpKaWFua2FuZyBZYW8NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSANCk1lZXRpbmcgDQogDQpFbWFpbCBBZGRyZXNzIEludGVy
bmF0aW9uYWxpemF0aW9uIChFQUkpIFdHIG1pbnV0ZXMgDQogDQpJRVRGIDgxLCBUdWVzZGF5LCBK
dWx5IDI2LCAyMDExDQowOTAwLTExMzAgDQpSb29tOiAyMTAzDQpDaGFpcnM6IEpvaG4gS2xlbnNp
biAgDQogICAgICAgSm9zZXBoIFllZQ0KU2NyaWJlOiBBbmRyZXcgU3VsbGl2YW4NCk1pbnV0ZXM6
IEppYW5rYW5nIFlhbw0KIA0KDQpBZ2VuZGEgQmFzaGluZyANCi0gbm9uZSANCiANCkRpc2N1c3Np
b24gU3VtbWFyeSANCiANClNNVFAtYmlzIChkcmFmdC1pZXRmLWVhaS1yZmM1MzM2YmlzLTExKTog
DQphKVRoaXMgZHJhZnQgbmVlZHMgYSBsaXR0bGUgcmVmaW5lbWVudCBidXQgaXMgbmVhcmx5DQog
ICByZWFkeSBmb3IgV29ya2luZyBHcm91cCBMYXN0IENhbGwNCmIpTmV3IHZlcnNpb24gb2YgdGhp
cyBkcmFmdCBzaG91bGQgYmUgc3VibWl0dGVkIGJlZm9yZSAxMSBBdWcuDQpjKVRoZSBXb3JraW5n
IEdyb3VwIExhc3QgQ2FsbCB3aWxsIGJlIGlzc3VlZCBhcm91bmQgMTEgQXVnLg0KIA0KSGVhZGVy
LWJpcyAoZHJhZnQtaWV0Zi1lYWktcmZjNTMzNWJpcy0xMSk6IA0KYSkgVGVudGF0aXZlIGNvbnNl
bnN1cyByZXN1bHRzOg0KLSBHZW5lcmFsIHN1cHBvcnQgZm9yIFVURi04IGluIE1lc3NhZ2UtSURz
DQotIEdlbmVyYWwgc3VwcG9ydCBmb3IgaW5jbHVkaW5nIGltcG9ydGFudCBjb21tZW50YXJ5DQog
IG1hdGVyaWFsIGZyb20gZWFybGllciB2ZXJzaW9ucyBpbiBvbmUgb3IgbW9yZSBhcHBlbmRpY2Vz
DQogIHRvIHRoZSBjdXJyZW50IG9yZ2FuaXphdGlvbiBvZiB0aGUgZHJhZnQuDQoqKk5PVEUqKg0K
VGhlc2UgcmVzdWx0cyB3aWxsIGJlIGNvbnNpZGVyZWQgZmluYWwgaWYgb2JqZWN0aW9ucyBhcmUN
Cm5vdCByYWlzZWQgb24gdGhlIGxpc3Qgd2l0aCBuZXcgc3Vic3RhbnRpdmUgYXJndW1lbnRzDQpi
ZWZvcmUgOCBBdWd1c3QNCmIpIE5ldyB2ZXJzaW9uIG9mIHRoaXMgZHJhZnQgKC0xMikgc2hvdWxk
IGJlIHN1Ym1pdHRlZA0KYXJvdW5kIDExIEF1ZyBhc3N1bWluZyB0aGF0IHRoZSBjb25zZW5zdXMg
aXNuJ3QNCm92ZXJ0dXJuZWQgYnkgdGhlIHBvc3NpYmxlIG9iamVjdGlvbiANCmMpIEJhcnJ5IGNv
bW1pdHRlZCB0byByZXZpZXcgYWZ0ZXIgcmV2aXNpb24gLTEyIGlzIHVwIA0KZCkgVGhlIFdvcmtp
bmcgR3JvdXAgTGFzdCBDYWxsIHdpbGwgYmUgaXNzdWVkIGFyb3VuZCAxMQ0KQXVnLg0KDQogDQpE
U04tYmlzIChkcmFmdC1pZXRmLWVhaS1yZmM1MzM3YmlzLWRzbi0wMyk6IA0KYSkgTm8ga25vd24g
aXNzdWVzDQpiKSBNb3JlIGV4dGVuc2l2ZSByZXZpZXdzIGFyZSBuZWVkZWQgYnkgbW9yZSBwZW9w
bGUNCmMpIENocmlzIE5ld21hbiBjb21taXR0ZWQgdG8gcmV2aWV3IGl0DQpkKSBUaGUgV29ya2lu
ZyBHcm91cCBMYXN0IENhbGwgd2lsbCBiZSBpc3N1ZWQgYXJvdW5kIDExIEF1Zy4NCiANClBPUC1i
aXMgKGRyYWZ0LWlldGYtZWFpLXJmYzU3MjFiaXMtMDIpOiANCmEpIE5vIGtub3duIGlzc3VlcyAN
CmIpIGVkaXRvcnMgbmVlZCBtb3JlIHJldmlldyBmcm9tIFdHIChodHRwOi8vd3d3LmlldGYub3Jn
L3Byb2NlZWRpbmdzLzgxL3NsaWRlcy9lYWktMi5wZGYpDQoNCklNQVAtYmlzIChkcmFmdC1pZXRm
LWVhaS1yZmM1NzM4YmlzLTAxKTogDQphKSBlZGl0b3JzIG5lZWQgbW9yZSByZXZpZXcgZnJvbSBX
RyAoaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84MS9zbGlkZXMvZWFpLTIucGRmKQ0K
YikgVGhlIEFCTkYgc3ludGF4IGluIHNlY3Rpb24gMiBuZWVkcyBzb21lIHVwZGF0ZXMNCmMpIGZl
dyBlZGl0b3JpYWxzIGlzc3VlcyByZW1haW4NCmQpIGZldyBwYXJ0aWNpcGFudHMgYXJlIGNvbmNl
cm5lZCBhYm91dCBJTUFQIGNvbXBsZXhpdHksIGFuZCB3b3VsZCBsb3ZlIHRvIGhhdmUgd29ya2lu
ZyANCg0KaW1wbGVtZW50YXRpb24gdG8gYmFjayB0aGUgZHJhZnQNCg0KDQpQb3N0LWRlbGl2ZXJ5
IE1lc3NhZ2UgRG93bmdyYWRpbmcgZm9yIEludGVybmF0aW9uYWxpemVkIEVtYWlsIE1lc3NhZ2Vz
IA0KKGRyYWZ0LWlldGYtZWFpLXBvcGltYXAtZG93bmdyYWRlLTAyKSANCmEpIEZ1aml3YXJhIHBy
ZXNlbnRlZCBzbGlkZXMgb24gRUFJIGNvbnNlbnN1cyBmcm9tIElFVEYgQmVpamluZyBtZWV0aW5n
IGFuZCB0aGUgbmV3IEFCTkYgaW4gDQoNCmN1cnJlbnQgZHJhZnQNCmIpIEVkaXRvcnMgbmVlZCBt
b3JlIGlucHV0cyBmb3IgbmV4dCByZXZpc2lvbg0KYykgVGhlIFdHIGRpc2N1c3NlZCBob3cgdG8g
cHJvY2VlZCB0byBpbmNvcnBvcmF0ZSBhIHByb3Zpc2lvbg0KZm9yIGdyb3VwIHN5bnRheCAoYW5k
IGhlbmNlIG5vIHVzYWJsZSBhZGRyZXNzZXMgZm9yIHJlcGxpZXMpIGF0DQpiYWNrd2FyZCBwb2lu
dGluZyBhZGRyZXNzLiAgVGhlcmUgYXJlIHR3byBsb2dpY2FsIHBvc3NpYmlsaXRpZXM6DQotICgx
KSBjcmVhdGUgYSBuYXJyb3dseS1mb2N1c2VkIHVwZGF0ZSB0byA1MzIyIG91dHNpZGUNCkVBSSwg
Z2V0IGl0IGFwcHJvdmVkLCBhbmQgdGhlbiBoYXZlIHBvcGltYXAtZG93bmdyYWRlDQpyZWZlciB0
byBpdC4NCi0gKDIpIHVwZGF0ZSA1MzIyIGFzIHBhcnQgb2YgdGhlIEVBSSB3b3JrDQoNClRoZXJl
IHdhcyBnZW5lcmFsIGFncmVlbWVudCB0aGF0IGl0IHdhcyBhcHByb3ByaWF0ZSBhbmQNCmVmZmlj
aWVudCB0byBtYWtlIHRoZSBjaGFuZ2VzIHdpdGhpbiB0aGUgRUFJIFdHIGVmZm9ydC4gDQpDaGFp
cnMgd2lsbCBkaXNjdXNzIHByb2NlZHVyZXMgd2l0aCBBRHMgb2ZmbGluZSBhcyBuZWVkZWQuDQoN
CmQpIENoYWlycyB3aWxsIGhhdmUgb2ZmbGluZSBkaXNjdXNzaW9uICh3aXRoIElFU0cpIHJlZ2Fy
ZGluZyBEb3duZ3JhZGVkLSogaGVhZGVycw0KZSkgRWRpdG9ycyBuZWVkIG1vcmUgcmV2aWV3IGZy
b20gV0cgKGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvODEvc2xpZGVzL2VhaS0yLnBk
ZikNCmYpIEpvaG4gS2xlbnNpbiBjb21taXR0ZWQgdG8gaGVscCBkcmFmdCB0aGUgaW5pdGlhbCB0
ZXh0IHJlZ2FyZGluZyBNZXNzYWdlLUlEDQoNCiANCiANCkEuTy5CDQphKUlTT0MgUXVlYmVjIGNo
YXB0ZXIgcHJlc2lkZW50IG9mZmVycyBzb21lIHJlbWFya3MgYWJvdXQgY3VsdHVyZSAmIGludGVy
bmF0aW9uYWxpemVkIA0KIA0KZW52aXJvbm1lbnQgYW5kIHRoYW5rcyB0aGUgd29yayBvZiBFQUkN
CiANCg0KcmVtaW5kZXI6IA0KQW55b25lIHdobyBjb21taXR0ZWQgdG8gcmV2aWV3IGRvY3MgDQpz
aG91bGQgZG8gc28gYXMgcHJvbWlzZWQuIA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLQ==

------=_NextPart_000_0304_01CC50FD.7A6FFF90
Content-Type: text/plain;
	name="eai-81.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="eai-81.txt"

-------------------------------------------=20
Meeting=20
=20
Email Address Internationalization (EAI) WG minutes=20
=20
IETF 81, Tuesday, July 26, 2011
0900-1130=20
Room: 2103
Chairs: John Klensin =20
       Joseph Yee
Scribe: Andrew Sullivan
Minutes: Jiankang Yao
=20

Agenda Bashing=20
- none=20
=20
Discussion Summary=20
=20
SMTP-bis (draft-ietf-eai-rfc5336bis-11):=20
a)This draft needs a little refinement but is nearly
   ready for Working Group Last Call
b)New version of this draft should be submitted before 11 Aug.
c)The Working Group Last Call will be issued around 11 Aug.
=20
Header-bis (draft-ietf-eai-rfc5335bis-11):=20
a) Tentative consensus results:
- General support for UTF-8 in Message-IDs
- General support for including important commentary
  material from earlier versions in one or more appendices
  to the current organization of the draft.
**NOTE**
These results will be considered final if objections are
not raised on the list with new substantive arguments
before 8 August
b) New version of this draft (-12) should be submitted
around 11 Aug assuming that the consensus isn't
overturned by the possible objection=20
c) Barry committed to review after revision -12 is up=20
d) The Working Group Last Call will be issued around 11
Aug.

=20
DSN-bis (draft-ietf-eai-rfc5337bis-dsn-03):=20
a) No known issues
b) More extensive reviews are needed by more people
c) Chris Newman committed to review it
d) The Working Group Last Call will be issued around 11 Aug.
=20
POP-bis (draft-ietf-eai-rfc5721bis-02):=20
a) No known issues=20
b) editors need more review from WG =
(http://www.ietf.org/proceedings/81/slides/eai-2.pdf)

IMAP-bis (draft-ietf-eai-rfc5738bis-01):=20
a) editors need more review from WG =
(http://www.ietf.org/proceedings/81/slides/eai-2.pdf)
b) The ABNF syntax in section 2 needs some updates
c) few editorials issues remain
d) few participants are concerned about IMAP complexity, and would love =
to have working implementation to back the draft


Post-delivery Message Downgrading for Internationalized Email Messages=20
(draft-ietf-eai-popimap-downgrade-02)=20
a) Fujiwara presented slides on EAI consensus from IETF Beijing meeting =
and the new ABNF in current draft
b) Editors need more inputs for next revision
c) The WG discussed how to proceed to incorporate a provision
for group syntax (and hence no usable addresses for replies) at
backward pointing address.  There are two logical possibilities:
- (1) create a narrowly-focused update to 5322 outside
EAI, get it approved, and then have popimap-downgrade
refer to it.
- (2) update 5322 as part of the EAI work

There was general agreement that it was appropriate and
efficient to make the changes within the EAI WG effort.=20
Chairs will discuss procedures with ADs offline as needed.

d) Chairs will have offline discussion (with IESG) regarding =
Downgraded-* headers
e) Editors need more review from WG =
(http://www.ietf.org/proceedings/81/slides/eai-2.pdf)
f) John Klensin committed to help draft the initial text regarding =
Message-ID

=20
=20
A.O.B
a)ISOC Quebec chapter president offers some remarks about culture & =
internationalized=20
=20
environment and thanks the work of EAI
=20

reminder:=20
Anyone who committed to review docs=20
should do so as promised.=20
----------------------------------------

------=_NextPart_000_0304_01CC50FD.7A6FFF90--


From johnl@iecc.com  Tue Aug  2 08:23:24 2011
Return-Path: <johnl@iecc.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85AC221F85AA for <ima@ietfa.amsl.com>; Tue,  2 Aug 2011 08:23:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -111.199
X-Spam-Level: 
X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FiaGMvnGdJl2 for <ima@ietfa.amsl.com>; Tue,  2 Aug 2011 08:23:24 -0700 (PDT)
Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id D38BA21F8586 for <ima@ietf.org>; Tue,  2 Aug 2011 08:23:23 -0700 (PDT)
Received: (qmail 69601 invoked from network); 2 Aug 2011 15:23:30 -0000
Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 2 Aug 2011 15:23:30 -0000
Received: (qmail 94116 invoked from network); 2 Aug 2011 15:23:30 -0000
Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 2 Aug 2011 15:23:30 -0000
Date: 2 Aug 2011 15:23:07 -0000
Message-ID: <20110802152307.52262.qmail@joyce.lan>
From: "John Levine" <johnl@taugh.com>
To: ima@ietf.org
In-Reply-To: <3B41F7A50742454987AC87127305F889@LENOVO47E041CF>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 7bit
Cc: healthyao@gmail.com
Subject: Re: [EAI] 81 IETF EAI meeting minutes
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Aug 2011 15:23:24 -0000

>Header-bis (draft-ietf-eai-rfc5335bis-11): 
>a) Tentative consensus results:
>- General support for UTF-8 in Message-IDs
>- General support for including important commentary
>  material from earlier versions in one or more appendices
>  to the current organization of the draft.

I think there was support for my request to reword sec 3.4 a little to
clarify that it's OK to use message/global for messages that would be
valid message/rfc822, although for maximum backward compatibility it's
preferable not to do so.

R's,
John

From klensin@jck.com  Tue Aug  2 10:15:28 2011
Return-Path: <klensin@jck.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 923EB21F8559 for <ima@ietfa.amsl.com>; Tue,  2 Aug 2011 10:15:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.671
X-Spam-Level: 
X-Spam-Status: No, score=-2.671 tagged_above=-999 required=5 tests=[AWL=-0.072, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ywl+aw+UqIL9 for <ima@ietfa.amsl.com>; Tue,  2 Aug 2011 10:15:28 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id CFD6721F8532 for <ima@ietf.org>; Tue,  2 Aug 2011 10:15:27 -0700 (PDT)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QoIZ6-0006Il-Co; Tue, 02 Aug 2011 13:15:36 -0400
Date: Tue, 02 Aug 2011 13:15:35 -0400
From: John C Klensin <klensin@jck.com>
To: John Levine <johnl@taugh.com>, ima@ietf.org
Message-ID: <EDED1F9FA483FE03008F423C@PST.JCK.COM>
In-Reply-To: <20110802152307.52262.qmail@joyce.lan>
References: <20110802152307.52262.qmail@joyce.lan>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: healthyao@gmail.com
Subject: Re: [EAI] 81 IETF EAI meeting minutes
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Aug 2011 17:15:28 -0000

Agreed.

The text should parallel the text that describes the use of the
UTF8SMTPbis parameter when the contents of the message or
envelope are not known to require EAI (i.e., non-ASCII)
capability.  That means that those who are concerned about that
type of advice should check the existing text carefully to be
sure it reflects WG agreements about the matter.

   john


--On Tuesday, August 02, 2011 15:23 +0000 John Levine
<johnl@taugh.com> wrote:

> 
>> Header-bis (draft-ietf-eai-rfc5335bis-11): 
>> a) Tentative consensus results:
>> - General support for UTF-8 in Message-IDs
>> - General support for including important commentary
>>  material from earlier versions in one or more appendices
>>  to the current organization of the draft.
> 
> I think there was support for my request to reword sec 3.4 a
> little to clarify that it's OK to use message/global for
> messages that would be valid message/rfc822, although for
> maximum backward compatibility it's preferable not to do so.
> 
> R's,
> John
> _______________________________________________
> IMA mailing list
> IMA@ietf.org
> https://www.ietf.org/mailman/listinfo/ima





From tony@att.com  Tue Aug  2 20:12:50 2011
Return-Path: <tony@att.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0E211E8081 for <ima@ietfa.amsl.com>; Tue,  2 Aug 2011 20:12:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.061
X-Spam-Level: 
X-Spam-Status: No, score=-106.061 tagged_above=-999 required=5 tests=[AWL=0.538, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PNZbJZAjjbFU for <ima@ietfa.amsl.com>; Tue,  2 Aug 2011 20:12:49 -0700 (PDT)
Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED1411E80F7 for <ima@ietf.org>; Tue,  2 Aug 2011 20:12:49 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: tony@att.com
X-Msg-Ref: server-14.tower-120.messagelabs.com!1312341177!30939875!1
X-StarScan-Version: 6.2.17; banners=-,-,-
X-Originating-IP: [144.160.20.145]
Received: (qmail 746 invoked from network); 3 Aug 2011 03:12:58 -0000
Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-14.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Aug 2011 03:12:58 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p733DNbI001593 for <ima@ietf.org>; Tue, 2 Aug 2011 23:13:23 -0400
Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p733DJFv001567 for <ima@ietf.org>; Tue, 2 Aug 2011 23:13:19 -0400
Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p733Cr0C002220 for <ima@ietf.org>; Tue, 2 Aug 2011 23:12:53 -0400
Received: from mailgw1.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p733Co61002189 for <ima@ietf.org>; Tue, 2 Aug 2011 23:12:50 -0400
Received: from [135.70.123.113] (vpn-135-70-123-113.vpn.swst.att.com[135.70.123.113]) by maillennium.att.com (mailgw1) with ESMTP id <20110803031249gw100e4lsfe> (Authid: tony); Wed, 3 Aug 2011 03:12:49 +0000
X-Originating-IP: [135.70.123.113]
Message-ID: <4E38BCAF.9080201@att.com>
Date: Tue, 02 Aug 2011 23:12:47 -0400
From: Tony Hansen <tony@att.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: ima@ietf.org
References: <20110802152307.52262.qmail@joyce.lan>
In-Reply-To: <20110802152307.52262.qmail@joyce.lan>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [EAI] 81 IETF EAI meeting minutes
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Aug 2011 03:12:50 -0000

On 8/2/2011 11:23 AM, John Levine wrote:
>> Header-bis (draft-ietf-eai-rfc5335bis-11):
>> a) Tentative consensus results:
>> - General support for UTF-8 in Message-IDs
>> - General support for including important commentary
>>   material from earlier versions in one or more appendices
>>   to the current organization of the draft.
> I think there was support for my request to reword sec 3.4 a little to
> clarify that it's OK to use message/global for messages that would be
> valid message/rfc822, although for maximum backward compatibility it's
> preferable not to do so.

+1


From dhc2@dcrocker.net  Tue Aug  2 20:38:48 2011
Return-Path: <dhc2@dcrocker.net>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C276D11E8081 for <ima@ietfa.amsl.com>; Tue,  2 Aug 2011 20:38:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.666
X-Spam-Level: 
X-Spam-Status: No, score=-6.666 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFrgMYxWxY65 for <ima@ietfa.amsl.com>; Tue,  2 Aug 2011 20:38:47 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id C952111E811B for <ima@ietf.org>; Tue,  2 Aug 2011 20:38:47 -0700 (PDT)
Received: from [192.168.1.156] (adsl-67-124-149-98.dsl.pltn13.pacbell.net [67.124.149.98]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p733crC4008420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ima@ietf.org>; Tue, 2 Aug 2011 20:38:58 -0700
Message-ID: <4E38C2CB.6060502@dcrocker.net>
Date: Tue, 02 Aug 2011 20:38:51 -0700
From: Dave CROCKER <dhc2@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: ima@ietf.org
References: <20110802152307.52262.qmail@joyce.lan> <4E38BCAF.9080201@att.com>
In-Reply-To: <4E38BCAF.9080201@att.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 02 Aug 2011 20:38:58 -0700 (PDT)
Subject: Re: [EAI] 81 IETF EAI meeting minutes
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Aug 2011 03:38:48 -0000

On 8/2/2011 8:12 PM, Tony Hansen wrote:
> On 8/2/2011 11:23 AM, John Levine wrote:
>>> Header-bis (draft-ietf-eai-rfc5335bis-11):
>>> a) Tentative consensus results:
>>> - General support for UTF-8 in Message-IDs
>>> - General support for including important commentary
>>> material from earlier versions in one or more appendices
>>> to the current organization of the draft.
>> I think there was support for my request to reword sec 3.4 a little to
>> clarify that it's OK to use message/global for messages that would be
>> valid message/rfc822, although for maximum backward compatibility it's
>> preferable not to do so.
>
> +1


+1

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From jyee@afilias.info  Wed Aug  3 11:43:50 2011
Return-Path: <jyee@afilias.info>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04E2211E808D for <ima@ietfa.amsl.com>; Wed,  3 Aug 2011 11:43:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.105
X-Spam-Level: 
X-Spam-Status: No, score=-6.105 tagged_above=-999 required=5 tests=[AWL=0.160,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDWS8Wr0b-Tx for <ima@ietfa.amsl.com>; Wed,  3 Aug 2011 11:43:49 -0700 (PDT)
Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfa.amsl.com (Postfix) with ESMTP id 50E5211E8084 for <ima@ietf.org>; Wed,  3 Aug 2011 11:43:49 -0700 (PDT)
Received: from ms5.yyz2.afilias-ops.info ([10.50.129.111] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from <jyee@afilias.info>) id 1QogQD-00022V-4n for ima@ietf.org; Wed, 03 Aug 2011 18:44:01 +0000
Received: from mail-gy0-f178.google.com ([209.85.160.178]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from <jyee@afilias.info>) id 1QogQD-0000at-41 for ima@ietf.org; Wed, 03 Aug 2011 18:44:01 +0000
Received: by gyf1 with SMTP id 1so667051gyf.9 for <ima@ietf.org>; Wed, 03 Aug 2011 11:44:00 -0700 (PDT)
Received: by 10.151.8.5 with SMTP id l5mr986164ybi.300.1312397040689; Wed, 03 Aug 2011 11:44:00 -0700 (PDT)
Received: from jyee-lt.tor.afilias-int.info (tor-gateway.afilias.info [199.15.87.4]) by mx.google.com with ESMTPS id a16sm2282939ybn.2.2011.08.03.11.43.58 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 03 Aug 2011 11:43:59 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Joseph Yee <jyee@afilias.info>
In-Reply-To: <4E38C2CB.6060502@dcrocker.net>
Date: Wed, 3 Aug 2011 14:43:56 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <B05F9004-D416-4A4E-99E2-90083809016F@afilias.info>
References: <20110802152307.52262.qmail@joyce.lan> <4E38BCAF.9080201@att.com> <4E38C2CB.6060502@dcrocker.net>
To: dcrocker@bbiw.net
X-Mailer: Apple Mail (2.1084)
Cc: ima@ietf.org
Subject: Re: [EAI] 81 IETF EAI meeting minutes
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Aug 2011 18:43:50 -0000

On 2011-08-02, at 11:38 PM, Dave CROCKER wrote:

> 
> 
> On 8/2/2011 8:12 PM, Tony Hansen wrote:
>> On 8/2/2011 11:23 AM, John Levine wrote:
>>>> Header-bis (draft-ietf-eai-rfc5335bis-11):
>>>> a) Tentative consensus results:
>>>> - General support for UTF-8 in Message-IDs
>>>> - General support for including important commentary
>>>> material from earlier versions in one or more appendices
>>>> to the current organization of the draft.
>>> I think there was support for my request to reword sec 3.4 a little to
>>> clarify that it's OK to use message/global for messages that would be
>>> valid message/rfc822, although for maximum backward compatibility it's
>>> preferable not to do so.
>> 
>> +1
> 
> 
> +1

+1

> 
> -- 
> 
>  Dave Crocker
>  Brandenburg InternetWorking
>  bbiw.net
> _______________________________________________
> IMA mailing list
> IMA@ietf.org
> https://www.ietf.org/mailman/listinfo/ima


From jyee@afilias.info  Wed Aug  3 11:44:02 2011
Return-Path: <jyee@afilias.info>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43DD011E8084 for <ima@ietfa.amsl.com>; Wed,  3 Aug 2011 11:44:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.12
X-Spam-Level: 
X-Spam-Status: No, score=-6.12 tagged_above=-999 required=5 tests=[AWL=0.145,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AH-ch0pg8jC4 for <ima@ietfa.amsl.com>; Wed,  3 Aug 2011 11:44:01 -0700 (PDT)
Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfa.amsl.com (Postfix) with ESMTP id EEA8711E8097 for <ima@ietf.org>; Wed,  3 Aug 2011 11:43:59 -0700 (PDT)
Received: from ms5.yyz2.afilias-ops.info ([10.50.129.111] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from <jyee@afilias.info>) id 1QogQO-00065J-7l for ima@ietf.org; Wed, 03 Aug 2011 18:44:12 +0000
Received: from mail-gy0-f178.google.com ([209.85.160.178]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from <jyee@afilias.info>) id 1QogQO-0000au-3d for ima@ietf.org; Wed, 03 Aug 2011 18:44:12 +0000
Received: by mail-gy0-f178.google.com with SMTP id 1so667052gyf.9 for <ima@ietf.org>; Wed, 03 Aug 2011 11:44:12 -0700 (PDT)
Received: by 10.150.62.12 with SMTP id k12mr1090583yba.45.1312397051887; Wed, 03 Aug 2011 11:44:11 -0700 (PDT)
Received: from jyee-lt.tor.afilias-int.info (tor-gateway.afilias.info [199.15.87.4]) by mx.google.com with ESMTPS id a16sm2282939ybn.2.2011.08.03.11.44.09 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 03 Aug 2011 11:44:11 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Joseph Yee <jyee@afilias.info>
In-Reply-To: <F9F980ED2E4A14AD798EB0D8@dhcp-1764.meeting.ietf.org>
Date: Wed, 3 Aug 2011 14:44:06 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <B963AB1A-39F2-4890-BAAC-DA47F6E54DF2@afilias.info>
References: <20110708012352.14365.62590.idtracker@ietfa.amsl.com> <511610891.05212@cnnic.cn> <DE4565887EBE42A9A6E8F987CEC6BCA7@LENOVO47E041CF> <F9F980ED2E4A14AD798EB0D8@dhcp-1764.meeting.ietf.org>
To: Chris Newman <chris.newman@oracle.com>
X-Mailer: Apple Mail (2.1084)
Cc: ima@ietf.org, Jiankang Yao <healthyao@gmail.com>
Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-11.txt
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Aug 2011 18:44:02 -0000

On 2011-07-26, at 9:57 AM, Chris Newman wrote:

> --On July 26, 2011 19:51:37 +0800 Jiankang Yao <healthyao@gmail.com> =
wrote:
>>> 1. Somewhere this needs to say: If a server advertises both =
UTF8SMTPbis
>>> and  DSN, then that server MUST support UTF-8 in the ORCPT =
parameter.
>>> This also  has ABNF impact.
>>>=20
>>=20
>> my concern is that, if we choose to add the sentence above we cause
>> another problems.
>>=20
>> Is it really necessary to add such a sentence?
>=20
> Yes.
>=20
> Without this sentence, a server can implement old DSN and be compliant =
with the old DSN spec and implement UTF8SMTPbis and be compliant with =
rfc5336bis, and not support UTF-8 in ORCPT. Such a server will break =
interoperability with clients that are compliant with 4952bis which =
requires this behavior.

I believed that RFC5337bis (section 3) covered this already.  Maybe just =
need to add text to reference RFC5337bis.


>=20
>>> 3. I suggest adding a statement to the end of section 3.5:
>>>=20
>>>     SMTP servers are encouraged to detect that recipients can not
>>>     accept internationalized email headers and return an error
>>>     earlier in the transaction whenever possible.
>>>=20
>>=20
>> similar comments to Dave's
>>=20
>> http://www.ietf.org/mail-archive/web/ima/current/msg04285.html
>>=20
>> another question is
>>=20
>> adding this sentence is more clear than without it?
>=20
> Let me attempt to re-word based on Dave's feedback:
>=20
>     SMTP servers are encouraged to detect that recipients can not =
accept
>     internationalized email headers and generate an error after the =
RCPT
>     command rather than waiting until after the DATA command to issue =
an
>     error.

Personally I see this as best practice, but I think adding either text =
is ok.

>=20
>>> 4. In section 3.5, I suggest adding an enhanced status code for the =
case
>>> where a U-label can not be converted to an A-label. This is =
semantically
>>> quite different from X.6.7 and X.6.9
>>=20
>> based on rfc5890, U-label must be transformed to A-label, otherwise, =
it
>> can not be called U-label.
>>=20
>> John should be authoritive about the defintion of U-label.
>=20
> This does not prevent a broken client from generating a UTF-8 domain =
that is not a valid U-label and thus can not be converted to an A-label. =
It's an error a well-intentioned client implementer can make by mistake. =
And it's a subtle error condition a processor may not expect. For those =
reasons, I think it's useful to distinguish it from the class of =
"recipient-can't-handle" errors.

I'm not sure if a different error code can help end users at the moment. =
 Unless you mean MSA/MTA to detect and report U-label =3D> A-label =
failure, otherwise it is only "recipient-can't-handle" or =
"host-not-found".

Would love to hear more feedback from everyone regarding this.

Best
Joseph

>=20
> 		- Chris
>=20
> _______________________________________________
> IMA mailing list
> IMA@ietf.org
> https://www.ietf.org/mailman/listinfo/ima


From jyee@afilias.info  Wed Aug  3 12:23:34 2011
Return-Path: <jyee@afilias.info>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F4621F8B29 for <ima@ietfa.amsl.com>; Wed,  3 Aug 2011 12:23:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.132
X-Spam-Level: 
X-Spam-Status: No, score=-6.132 tagged_above=-999 required=5 tests=[AWL=0.133,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghAGZJSprw8E for <ima@ietfa.amsl.com>; Wed,  3 Aug 2011 12:23:33 -0700 (PDT)
Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfa.amsl.com (Postfix) with ESMTP id BDE2721F8A1A for <ima@ietf.org>; Wed,  3 Aug 2011 12:23:33 -0700 (PDT)
Received: from ms6.yyz2.afilias-ops.info ([10.50.129.112] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from <jyee@afilias.info>) id 1Qoh2e-0003jT-67 for ima@ietf.org; Wed, 03 Aug 2011 19:23:44 +0000
Received: from mail-gw0-f50.google.com ([74.125.83.50]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from <jyee@afilias.info>) id 1Qoh2e-0003Sy-8c for ima@ietf.org; Wed, 03 Aug 2011 19:23:44 +0000
Received: by gwj16 with SMTP id 16so695042gwj.9 for <ima@ietf.org>; Wed, 03 Aug 2011 12:23:44 -0700 (PDT)
Received: by 10.101.106.25 with SMTP id i25mr5849806anm.80.1312399423757; Wed, 03 Aug 2011 12:23:43 -0700 (PDT)
Received: from jyee-lt.tor.afilias-int.info (tor-gateway.afilias.info [199.15.87.4]) by mx.google.com with ESMTPS id h15sm865003ank.39.2011.08.03.12.23.41 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 03 Aug 2011 12:23:42 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Joseph Yee <jyee@afilias.info>
In-Reply-To: <A8C82FE85233D49F061CBB4D@96B2F16665FF96BAE59E9B90>
Date: Wed, 3 Aug 2011 15:23:38 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <D5BDE7B9-7132-450B-A1A0-8760DECB6C51@afilias.info>
References: <20110711100444.26679.38042.idtracker@ietfa.amsl.com> <1323A97FB2432B0CCB92372B@dhcp-1764.meeting.ietf.org> <4E360132.3050803@isode.com> <C9B1BFFD-A539-4BFF-849C-C7B62FA58F25@afilias.info> <A8C82FE85233D49F061CBB4D@96B2F16665FF96BAE59E9B90>
To: Chris Newman <chris.newman@oracle.com>
X-Mailer: Apple Mail (2.1084)
Cc: ima@ietf.org
Subject: Re: [EAI] I-D Action: draft-ietf-eai-5738bis-01.txt
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Aug 2011 19:23:34 -0000

On 2011-08-01, at 2:51 PM, Chris Newman wrote:

> --On August 1, 2011 10:56:08 -0400 Joseph Yee <jyee@afilias.info> =
wrote:
>> I would assume "UTF8=3DUSER" meant to notify client about SASL on =
username
>> & password rather than support of UTF8 on username & password.
>>=20
>> If it's about SASL, I think we are safe to remove the tag, with =
client
>> needs to check the SASL tag.  If it's about supporting UTF8 in =
username &
>> password, then I think it's ok to remove "UTF8=3DUSER", but only =
stating
>> "UTF8=3DACCEPT" MUST imply the support of UTF8 to username & =
password.
>=20
> The IMAP AUTHENTICATE command already supports UTF-8 if the SASL =
mechanism selected does. The PLAIN mechanism supports UTF-8.
>=20
> So UTF8=3DUSER was only about the IMAP LOGIN command. So I'd replace =
section 5 with something like:
>=20
> 5.  LOGIN Command
>=20
>  If the "UTF8=3DACCEPT" capability is advertised, that indicates the
>  server understands UTF-8 user names and passwords in the LOGIN
>  command. This is not a guarantee that they underlying identity
>  system will allow the creation of accounts with UTF-8 user names
>  and/or passwords. However, if the identity system does allow such
>  accounts, then the server MUST apply SASLprep [RFC4013] to both
>  arguments of the LOGIN command. The server MUST reject UTF-8 that
>  fails to comply with the formal syntax in RFC 3629 [RFC3629] or
>  if it encounters Unicode characters disallowed by SASLprep.

as individual, this works with a minor suggestion to the end
"disallowed by SASLprep in Section 2.3 of RFC4013 [RFC4013]."

-Joseph

>=20
> 		- Chris
>=20
>=20
>=20
>=20


From chris.newman@oracle.com  Wed Aug  3 16:18:10 2011
Return-Path: <chris.newman@oracle.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6136321F876A for <ima@ietfa.amsl.com>; Wed,  3 Aug 2011 16:18:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.944
X-Spam-Level: 
X-Spam-Status: No, score=-105.944 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyD+Dd68FdwG for <ima@ietfa.amsl.com>; Wed,  3 Aug 2011 16:18:10 -0700 (PDT)
Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by ietfa.amsl.com (Postfix) with ESMTP id D34FF21F875C for <ima@ietf.org>; Wed,  3 Aug 2011 16:18:09 -0700 (PDT)
Received: from brmsunmail2-sfbay.uk.sun.com ([10.79.11.101]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id p73NHx8H004511; Wed, 3 Aug 2011 23:17:59 GMT
Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by brmsunmail2-sfbay.uk.sun.com (8.14.4+Sun/8.14.4/ENSMAIL,v2.4) with ESMTP id p73NHwtX017850; Wed, 3 Aug 2011 23:17:59 GMT
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-disposition: inline
Content-type: text/plain; CHARSET=US-ASCII; format=flowed
Received: from [10.159.55.214] (nifty-silver.us.oracle.com [10.145.239.205]) by gotmail.us.oracle.com (Oracle Communications Messaging Exchange Server 7u5-4.01 64bit (built May 4 2011)) with ESMTPA id <0LPD00C3PKPW7L00@gotmail.us.oracle.com>; Wed, 03 Aug 2011 16:17:58 -0700 (PDT)
Date: Wed, 03 Aug 2011 16:17:54 -0700
From: Chris Newman <chris.newman@oracle.com>
To: Joseph Yee <jyee@afilias.info>
Message-id: <A58B9FD0B88ADDB801774B3C@dhcp-rmdc-twvpn-2-vpnpool-10-159-55-214.vpn.oracle.com>
In-reply-to: <B963AB1A-39F2-4890-BAAC-DA47F6E54DF2@afilias.info>
References: <20110708012352.14365.62590.idtracker@ietfa.amsl.com> <511610891.05212@cnnic.cn> <DE4565887EBE42A9A6E8F987CEC6BCA7@LENOVO47E041CF> <F9F980ED2E4A14AD798EB0D8@dhcp-1764.meeting.ietf.org> <B963AB1A-39F2-4890-BAAC-DA47F6E54DF2@afilias.info>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
Cc: ima@ietf.org, Jiankang Yao <healthyao@gmail.com>
Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-11.txt
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Aug 2011 23:18:10 -0000

--On August 3, 2011 14:44:06 -0400 Joseph Yee <jyee@afilias.info> wrote:
> On 2011-07-26, at 9:57 AM, Chris Newman wrote:
>
>> --On July 26, 2011 19:51:37 +0800 Jiankang Yao <healthyao@gmail.com>
>> wrote:
>>>> 1. Somewhere this needs to say: If a server advertises both UTF8SMTPbis
>>>> and  DSN, then that server MUST support UTF-8 in the ORCPT parameter.
>>>> This also  has ABNF impact.
>>>>
>>>
>>> my concern is that, if we choose to add the sentence above we cause
>>> another problems.
>>>
>>> Is it really necessary to add such a sentence?
>>
>> Yes.
>>
>> Without this sentence, a server can implement old DSN and be compliant
>> with the old DSN spec and implement UTF8SMTPbis and be compliant with
>> rfc5336bis, and not support UTF-8 in ORCPT. Such a server will break
>> interoperability with clients that are compliant with 4952bis which
>> requires this behavior.
>
> I believed that RFC5337bis (section 3) covered this already.  Maybe just
> need to add text to reference RFC5337bis.

Rules in RFC 5337bis do not impact RFC 5336bis implementations, unless RFC 
5336bis explicitly states that implementations MUST follow that rule (or 
all rules) in RFC 5337bis.

		- Chris


From healthyao@gmail.com  Thu Aug  4 21:02:52 2011
Return-Path: <healthyao@gmail.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89D0911E80BE for <ima@ietfa.amsl.com>; Thu,  4 Aug 2011 21:02:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level: 
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[AWL=-0.355, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFHTpE-9zT2T for <ima@ietfa.amsl.com>; Thu,  4 Aug 2011 21:02:52 -0700 (PDT)
Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 18C7D11E80B7 for <ima@ietf.org>; Thu,  4 Aug 2011 21:02:52 -0700 (PDT)
Received: by pzk33 with SMTP id 33so7465199pzk.18 for <ima@ietf.org>; Thu, 04 Aug 2011 21:03:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; bh=1tiCc+1ppF+ixysAYRh/MFhu1c+998P7vsr5Oel+UFk=; b=JYQKtLn3167sOf/JdTWu0CHd5z/vyK9xzD6v1kKtm6elmn+JWJjZ15LpBl+ZtKQtFD LhJlovkmFPAc44LLtqNsEWvzXlvI6OnTcIRjsi4eeNXW5m7GKIXIQFUuJ7eL11FRUvel qBNl8aaOU8n3CXETXWhCD4imVmfzIqtDPmLns=
Received: by 10.142.128.1 with SMTP id a1mr1607033wfd.438.1312516986171; Thu, 04 Aug 2011 21:03:06 -0700 (PDT)
Received: from LENOVO47E041CF ([218.241.111.35]) by mx.google.com with ESMTPS id l7sm2866586pbh.42.2011.08.04.21.03.03 (version=SSLv3 cipher=OTHER); Thu, 04 Aug 2011 21:03:04 -0700 (PDT)
Message-ID: <DBA3AA49AFED46E88CFD08F6CE393A57@LENOVO47E041CF>
From: "Jiankang Yao" <healthyao@gmail.com>
To: "Chris Newman" <chris.newman@oracle.com>
References: <20110708012352.14365.62590.idtracker@ietfa.amsl.com><511610891.05212@cnnic.cn><DE4565887EBE42A9A6E8F987CEC6BCA7@LENOVO47E041CF><F9F980ED2E4A14AD798EB0D8@dhcp-1764.meeting.ietf.org><B963AB1A-39F2-4890-BAAC-DA47F6E54DF2@afilias.info> <512413510.07777@cnnic.cn>
Date: Fri, 5 Aug 2011 12:03:00 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: base64
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
Cc: ima@ietf.org
Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-11.txt
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Aug 2011 04:02:52 -0000

DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkNocmlzIE5ld21hbiIgPGNo
cmlzLm5ld21hbkBvcmFjbGUuY29tPg0KVG86ICJKb3NlcGggWWVlIiA8anllZUBhZmlsaWFzLmlu
Zm8+DQpDYzogPGltYUBpZXRmLm9yZz47ICJKaWFua2FuZyBZYW8iIDxoZWFsdGh5YW9AZ21haWwu
Y29tPg0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAwNCwgMjAxMSA3OjE3IEFNDQpTdWJqZWN0OiBS
ZTogW0VBSV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1lYWktcmZjNTMzNmJpcy0xMS50eHQNCg0K
DQo+IC0tT24gQXVndXN0IDMsIDIwMTEgMTQ6NDQ6MDYgLTA0MDAgSm9zZXBoIFllZSA8anllZUBh
ZmlsaWFzLmluZm8+IHdyb3RlOg0KPj4gT24gMjAxMS0wNy0yNiwgYXQgOTo1NyBBTSwgQ2hyaXMg
TmV3bWFuIHdyb3RlOg0KPj4NCj4+PiAtLU9uIEp1bHkgMjYsIDIwMTEgMTk6NTE6MzcgKzA4MDAg
SmlhbmthbmcgWWFvIDxoZWFsdGh5YW9AZ21haWwuY29tPg0KPj4+IHdyb3RlOg0KPj4+Pj4gMS4g
U29tZXdoZXJlIHRoaXMgbmVlZHMgdG8gc2F5OiBJZiBhIHNlcnZlciBhZHZlcnRpc2VzIGJvdGgg
VVRGOFNNVFBiaXMNCj4+Pj4+IGFuZCAgRFNOLCB0aGVuIHRoYXQgc2VydmVyIE1VU1Qgc3VwcG9y
dCBVVEYtOCBpbiB0aGUgT1JDUFQgcGFyYW1ldGVyLg0KPj4+Pj4gVGhpcyBhbHNvICBoYXMgQUJO
RiBpbXBhY3QuDQo+Pj4+Pg0KPj4+Pg0KPj4+PiBteSBjb25jZXJuIGlzIHRoYXQsIGlmIHdlIGNo
b29zZSB0byBhZGQgdGhlIHNlbnRlbmNlIGFib3ZlIHdlIGNhdXNlDQo+Pj4+IGFub3RoZXIgcHJv
YmxlbXMuDQo+Pj4+DQo+Pj4+IElzIGl0IHJlYWxseSBuZWNlc3NhcnkgdG8gYWRkIHN1Y2ggYSBz
ZW50ZW5jZT8NCj4+Pg0KPj4+IFllcy4NCj4+Pg0KPj4+IFdpdGhvdXQgdGhpcyBzZW50ZW5jZSwg
YSBzZXJ2ZXIgY2FuIGltcGxlbWVudCBvbGQgRFNOIGFuZCBiZSBjb21wbGlhbnQNCj4+PiB3aXRo
IHRoZSBvbGQgRFNOIHNwZWMgYW5kIGltcGxlbWVudCBVVEY4U01UUGJpcyBhbmQgYmUgY29tcGxp
YW50IHdpdGgNCj4+PiByZmM1MzM2YmlzLCBhbmQgbm90IHN1cHBvcnQgVVRGLTggaW4gT1JDUFQu
IFN1Y2ggYSBzZXJ2ZXIgd2lsbCBicmVhaw0KPj4+IGludGVyb3BlcmFiaWxpdHkgd2l0aCBjbGll
bnRzIHRoYXQgYXJlIGNvbXBsaWFudCB3aXRoIDQ5NTJiaXMgd2hpY2gNCj4+PiByZXF1aXJlcyB0
aGlzIGJlaGF2aW9yLg0KPj4NCj4+IEkgYmVsaWV2ZWQgdGhhdCBSRkM1MzM3YmlzIChzZWN0aW9u
IDMpIGNvdmVyZWQgdGhpcyBhbHJlYWR5LiAgTWF5YmUganVzdA0KPj4gbmVlZCB0byBhZGQgdGV4
dCB0byByZWZlcmVuY2UgUkZDNTMzN2Jpcy4NCj4gDQo+IFJ1bGVzIGluIFJGQyA1MzM3YmlzIGRv
IG5vdCBpbXBhY3QgUkZDIDUzMzZiaXMgaW1wbGVtZW50YXRpb25zLCB1bmxlc3MgUkZDIA0KPiA1
MzM2YmlzIGV4cGxpY2l0bHkgc3RhdGVzIHRoYXQgaW1wbGVtZW50YXRpb25zIE1VU1QgZm9sbG93
IHRoYXQgcnVsZSAob3IgDQo+IGFsbCBydWxlcykgaW4gUkZDIDUzMzdiaXMuDQo+IA0KDQppbiB0
aGUgZW5kIG9mICBzZWN0aW9uICAzLjIuICBUaGUgVVRGOFNNVFBiaXMgRXh0ZW5zaW9uDQoNCmhv
dyBhYm91dCBhZGRpbmcgb25lIHNlbnRlbmNlIGJlbG93Pw0KDQoNCklmIHRoZSBVVEY4U01UUGJp
cy1hd2FyZSBTTVRQIHNlcnZlcnMgdHJ5IHRvIHN1cHBvcnQgRFNOW1JGQyAzNDYxXSAsIHRoZXkg
TVVTVCBzdXBwb3J0IA0KUkZDNTMzN2Jpcy4NCg0KDQpkb2VzIHN1Y2ggc2VudGVuY2Ugc2F0aXNp
ZnkgeW91ciBleHBlY3RhdGlvbj8NCg0KSmlhbmthbmcgWWFvDQoNCg0KPiAtIENocmlzDQo+IA0K
PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJTUEg
bWFpbGluZyBsaXN0DQo+IElNQUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL2ltYQ==


From chris.newman@oracle.com  Fri Aug  5 16:28:00 2011
Return-Path: <chris.newman@oracle.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236E021F85EE for <ima@ietfa.amsl.com>; Fri,  5 Aug 2011 16:28:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.651
X-Spam-Level: 
X-Spam-Status: No, score=-105.651 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VI2rJ1JnCp7 for <ima@ietfa.amsl.com>; Fri,  5 Aug 2011 16:27:59 -0700 (PDT)
Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by ietfa.amsl.com (Postfix) with ESMTP id B6F0821F865E for <ima@ietf.org>; Fri,  5 Aug 2011 16:27:59 -0700 (PDT)
Received: from brmsunmail1-sfbay.uk.sun.com ([10.79.11.100]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id p75NRvrV005713; Fri, 5 Aug 2011 23:28:17 GMT
Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by brmsunmail1-sfbay.uk.sun.com (8.14.4+Sun/8.14.4/ENSMAIL,v2.4) with ESMTP id p75NRu0k051405; Fri, 5 Aug 2011 23:27:57 GMT
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-disposition: inline
Content-type: text/plain; CHARSET=US-ASCII; format=flowed
Received: from [10.145.239.205] (nifty-silver.us.oracle.com [10.145.239.205]) by gotmail.us.oracle.com (Oracle Communications Messaging Exchange Server 7u5-4.01 64bit (built May 4 2011)) with ESMTPA id <0LPH00G3NAIIYO00@gotmail.us.oracle.com>; Fri, 05 Aug 2011 16:27:56 -0700 (PDT)
Date: Fri, 05 Aug 2011 16:27:53 -0700
From: Chris Newman <chris.newman@oracle.com>
To: Jiankang Yao <healthyao@gmail.com>
Message-id: <51207C7682EC63DF8CB98DA1@96B2F16665FF96BAE59E9B90>
In-reply-to: <DBA3AA49AFED46E88CFD08F6CE393A57@LENOVO47E041CF>
References: <20110708012352.14365.62590.idtracker@ietfa.amsl.com> <511610891.05212@cnnic.cn> <DE4565887EBE42A9A6E8F987CEC6BCA7@LENOVO47E041CF> <F9F980ED2E4A14AD798EB0D8@dhcp-1764.meeting.ietf.org> <B963AB1A-39F2-4890-BAAC-DA47F6E54DF2@afilias.info> <512413510.07777@cnnic.cn> <DBA3AA49AFED46E88CFD08F6CE393A57@LENOVO47E041CF>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
Cc: ima@ietf.org
Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-11.txt
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Aug 2011 23:28:00 -0000

--On August 5, 2011 12:03:00 +0800 Jiankang Yao <healthyao@gmail.com> wrote:
> in the end of  section  3.2.  The UTF8SMTPbis Extension
>
> how about adding one sentence below?
>
>
> If the UTF8SMTPbis-aware SMTP servers try to support DSN[RFC 3461] , they
> MUST support  RFC5337bis.
>
>
> does such sentence satisify your expectation?

I don't know what "try to support" means in a spec. How about:

If a UTF8SMTPbis-aware SMTP server advertises the Delivery Status 
Notification [RFC3461] extension, it MUST implement RFC 5337bis.

		- Chris


From healthyao@gmail.com  Sun Aug  7 20:26:27 2011
Return-Path: <healthyao@gmail.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAF6421F877F for <ima@ietfa.amsl.com>; Sun,  7 Aug 2011 20:26:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.842
X-Spam-Level: 
X-Spam-Status: No, score=-1.842 tagged_above=-999 required=5 tests=[AWL=0.004,  BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvmh6k1hkaEl for <ima@ietfa.amsl.com>; Sun,  7 Aug 2011 20:26:27 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 16BB921F8753 for <ima@ietf.org>; Sun,  7 Aug 2011 20:26:27 -0700 (PDT)
Received: by gxk19 with SMTP id 19so664878gxk.31 for <ima@ietf.org>; Sun, 07 Aug 2011 20:26:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; bh=e7TgiFSQfe6flmRnZq9bPQx6Epn9eq94EQWIDBxy3k8=; b=fQzjFBvAgNbCisy5npwq01a65r6gjDop0ciR9LGGrhbleTABts+IWcYSrB3gnSMrcU gUCH6uQLgbZYoloYSmfS/1rPUflZ/iYaL3+DNuXvItLZ28rCnYTM2raK5AUk0H/ezbvY pQo0Q/KGG4pREejRtWHBWDu4d4a65CjlREiSE=
Received: by 10.142.237.21 with SMTP id k21mr5336542wfh.271.1312774011252; Sun, 07 Aug 2011 20:26:51 -0700 (PDT)
Received: from LENOVO47E041CF ([218.241.103.182]) by mx.google.com with ESMTPS id s9sm1519763pbk.34.2011.08.07.20.26.48 (version=SSLv3 cipher=OTHER); Sun, 07 Aug 2011 20:26:49 -0700 (PDT)
Message-ID: <0BAE9BE71A784FB0B555E32729CFECBB@LENOVO47E041CF>
From: "Jiankang Yao" <healthyao@gmail.com>
To: "Joseph Yee" <jyee@afilias.info>, "Chris Newman" <chris.newman@oracle.com>
References: <20110708012352.14365.62590.idtracker@ietfa.amsl.com> <511610891.05212@cnnic.cn> <DE4565887EBE42A9A6E8F987CEC6BCA7@LENOVO47E041CF> <F9F980ED2E4A14AD798EB0D8@dhcp-1764.meeting.ietf.org> <B963AB1A-39F2-4890-BAAC-DA47F6E54DF2@afilias.info>
Date: Mon, 8 Aug 2011 11:26:46 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: base64
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
Cc: ima@ietf.org
Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-11.txt
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Aug 2011 03:26:27 -0000

SSBhZ3JlZSB3aXRoIEpvc2VwaCdzIGNvbW1lbnRzIGFib3V0IHRoaXMgaXNzdWUuDQpPbiB0aGUg
b3RoZXIgaGFuZCwgU01UUCBkb2VzIG5vdCBhbGxvdyB0byBqdWRnZSB3aGV0aGVyIHRoZSBkb21h
aW4gbmFtZSBpcyB2YWxpZCBvciBub3QuDQoNCg0KSmlhbmthbmcgWWFvDQoNCi0tLS0tIE9yaWdp
bmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiSm9zZXBoIFllZSIgPGp5ZWVAYWZpbGlhcy5pbmZv
Pg0KVG86ICJDaHJpcyBOZXdtYW4iIDxjaHJpcy5uZXdtYW5Ab3JhY2xlLmNvbT4NCkNjOiAiSmlh
bmthbmcgWWFvIiA8aGVhbHRoeWFvQGdtYWlsLmNvbT47IDxpbWFAaWV0Zi5vcmc+DQpTZW50OiBU
aHVyc2RheSwgQXVndXN0IDA0LCAyMDExIDI6NDQgQU0NClN1YmplY3Q6IFJlOiBbRUFJXSBJLUQg
QWN0aW9uOiBkcmFmdC1pZXRmLWVhaS1yZmM1MzM2YmlzLTExLnR4dA0KDQoNCg0KDQo+IA0KPj4+
IDQuIEluIHNlY3Rpb24gMy41LCBJIHN1Z2dlc3QgYWRkaW5nIGFuIGVuaGFuY2VkIHN0YXR1cyBj
b2RlIGZvciB0aGUgY2FzZQ0KPj4+IHdoZXJlIGEgVS1sYWJlbCBjYW4gbm90IGJlIGNvbnZlcnRl
ZCB0byBhbiBBLWxhYmVsLiBUaGlzIGlzIHNlbWFudGljYWxseQ0KPj4+IHF1aXRlIGRpZmZlcmVu
dCBmcm9tIFguNi43IGFuZCBYLjYuOQ0KPj4gDQo+PiBiYXNlZCBvbiByZmM1ODkwLCBVLWxhYmVs
IG11c3QgYmUgdHJhbnNmb3JtZWQgdG8gQS1sYWJlbCwgb3RoZXJ3aXNlLCBpdA0KPj4gY2FuIG5v
dCBiZSBjYWxsZWQgVS1sYWJlbC4NCj4+IA0KPj4gSm9obiBzaG91bGQgYmUgYXV0aG9yaXRpdmUg
YWJvdXQgdGhlIGRlZmludGlvbiBvZiBVLWxhYmVsLg0KPiANCj4gVGhpcyBkb2VzIG5vdCBwcmV2
ZW50IGEgYnJva2VuIGNsaWVudCBmcm9tIGdlbmVyYXRpbmcgYSBVVEYtOCBkb21haW4gdGhhdCBp
cyBub3QgYSB2YWxpZCBVLWxhYmVsIGFuZCB0aHVzIGNhbiBub3QgYmUgY29udmVydGVkIHRvIGFu
IEEtbGFiZWwuIEl0J3MgYW4gZXJyb3IgYSB3ZWxsLWludGVudGlvbmVkIGNsaWVudCBpbXBsZW1l
bnRlciBjYW4gbWFrZSBieSBtaXN0YWtlLiBBbmQgaXQncyBhIHN1YnRsZSBlcnJvciBjb25kaXRp
b24gYSBwcm9jZXNzb3IgbWF5IG5vdCBleHBlY3QuIEZvciB0aG9zZSByZWFzb25zLCBJIHRoaW5r
IGl0J3MgdXNlZnVsIHRvIGRpc3Rpbmd1aXNoIGl0IGZyb20gdGhlIGNsYXNzIG9mICJyZWNpcGll
bnQtY2FuJ3QtaGFuZGxlIiBlcnJvcnMuDQoNCkknbSBub3Qgc3VyZSBpZiBhIGRpZmZlcmVudCBl
cnJvciBjb2RlIGNhbiBoZWxwIGVuZCB1c2VycyBhdCB0aGUgbW9tZW50LiAgVW5sZXNzIHlvdSBt
ZWFuIE1TQS9NVEEgdG8gZGV0ZWN0IGFuZCByZXBvcnQgVS1sYWJlbCA9PiBBLWxhYmVsIGZhaWx1
cmUsIG90aGVyd2lzZSBpdCBpcyBvbmx5ICJyZWNpcGllbnQtY2FuJ3QtaGFuZGxlIiBvciAiaG9z
dC1ub3QtZm91bmQiLg0KDQpXb3VsZCBsb3ZlIHRvIGhlYXIgbW9yZSBmZWVkYmFjayBmcm9tIGV2
ZXJ5b25lIHJlZ2FyZGluZyB0aGlzLg0KDQpCZXN0DQpKb3NlcGgNCg0KPiANCj4gLSBDaHJpcw0K
PiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g
SU1BIG1haWxpbmcgbGlzdA0KPiBJTUFAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9pbWENCg==


From ned+ima@mrochek.com  Sun Aug  7 20:33:39 2011
Return-Path: <ned+ima@mrochek.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B042421F8726 for <ima@ietfa.amsl.com>; Sun,  7 Aug 2011 20:33:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.382
X-Spam-Level: 
X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hK-UmFhokHVr for <ima@ietfa.amsl.com>; Sun,  7 Aug 2011 20:33:39 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 269AD21F8715 for <ima@ietf.org>; Sun,  7 Aug 2011 20:33:39 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O4KYEWDIA800RIGK@mauve.mrochek.com> for ima@ietf.org; Sun, 7 Aug 2011 20:33:08 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O4CJSMR6GG00VHKR@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Sun, 7 Aug 2011 20:33:05 -0700 (PDT)
From: ned+ima@mrochek.com
Message-id: <01O4KYEUZVME00VHKR@mauve.mrochek.com>
Date: Sun, 07 Aug 2011 20:31:37 -0700 (PDT)
In-reply-to: "Your message dated Mon, 01 Aug 2011 21:55:40 -0400" <19FC9CA3-0E2C-4727-81A8-37AD80B7F393@afilias.info>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <19FC9CA3-0E2C-4727-81A8-37AD80B7F393@afilias.info>
To: Joseph Yee <jyee@afilias.info>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1312774312; bh=d90uOjjbXe3RUebD/q76OyMm1SCsI+UuA8BoZqElRs8=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=POYYVvrzftZXv3WXO3IdSKnbAH4Var+xDSxwAWoj3DPp+dS3v9R7zZWkz4B9mHl6A Ed/lPp9IysXsCetCGU46uuojlf1OSPcHhP/6EyIgKr0iq4vRUBM8qQULf0/bnRTorY CsPzTYsJhvEXiboV+5Sm1T00vJVnGhN8sG8ABw1Y=
Cc: "ima@ietf.org WG" <ima@ietf.org>
Subject: Re: [EAI] Announcement: WG Consensus reached from IETF81 Quebec City
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Aug 2011 03:33:39 -0000

> Hi All,

> The WG had made the following tentative consensus calls during meeting at IETF 81 Quebec City.  These results are considered final unless new substantive argument are raised on the list by August 8, 17:00 US Pacific Time.

> (1)
> WG Consensus on Message-ID header field:
> Message-ID allows UTF-8 in any part of its value.

I think this is a good simplification.

> (2)
> WG Consensus on Commentary Materials in RFC5335-bis:
> RC5335bis will keep the draft's commentary materials in appendix section.

This, OTOH, I'm less pleased with. I'd actually rather put this material
in a separate document - the question is, is there a suitable document where
it can go?

				Ned

From klensin@jck.com  Sun Aug  7 21:06:20 2011
Return-Path: <klensin@jck.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0EC821F86BF for <ima@ietfa.amsl.com>; Sun,  7 Aug 2011 21:06:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.648
X-Spam-Level: 
X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIByskvAJwUP for <ima@ietfa.amsl.com>; Sun,  7 Aug 2011 21:06:19 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id B6E9621F86B9 for <ima@ietf.org>; Sun,  7 Aug 2011 21:06:19 -0700 (PDT)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QqH6p-00016i-8P; Mon, 08 Aug 2011 00:06:35 -0400
Date: Mon, 08 Aug 2011 00:06:34 -0400
From: John C Klensin <klensin@jck.com>
To: ned+ima@mrochek.com, Joseph Yee <jyee@afilias.info>
Message-ID: <086D24B1FC28568E5D116E5B@PST.JCK.COM>
In-Reply-To: <01O4KYEUZVME00VHKR@mauve.mrochek.com>
References: <19FC9CA3-0E2C-4727-81A8-37AD80B7F393@afilias.info> <01O4KYEUZVME00VHKR@mauve.mrochek.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: "ima@ietf.org WG" <ima@ietf.org>
Subject: Re: [EAI] Announcement: WG Consensus reached from IETF81 Quebec City
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Aug 2011 04:06:20 -0000

--On Sunday, August 07, 2011 20:31 -0700 ned+ima@mrochek.com
wrote:

>> (2)
>> WG Consensus on Commentary Materials in RFC5335-bis:
>> RC5335bis will keep the draft's commentary materials in
>> appendix section.
> 
> This, OTOH, I'm less pleased with. I'd actually rather put
> this material in a separate document - the question is, is
> there a suitable document where it can go?

If it is not to be in an appendix to 5335bis, the three logical
places are:

(1) To reopen "framework" (draft-ietf-eai-frmwrk-4952bis) and
put it there.  That would require an ok from Pete because the
document has been approved and is sitting in the RFC Editor
queue waiting for other documents to catch up.  But it could be
done.

(2) To create an entirely separate document for that material.
Such a document would presumably require a charter update, but
that isn't a very big deal if we had an editor lined up (and
something I'd oppose if we didn't).

(3) To break it into pieces and fold them into one or more of
the "Advice for..." documents that are listed in the WG charter.
The disadvantage of doing this is that, once the base and
IMAP/POP documents are done, we are going to need to very
carefully consider how much energy the WG has for more work, an
evaluation that will have to reflect the fact that we are at
least a year behind at this point and have had a lot of trouble
getting reviews.

     john


From chris.newman@oracle.com  Mon Aug  8 14:45:51 2011
Return-Path: <chris.newman@oracle.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17EC411E80B0 for <ima@ietfa.amsl.com>; Mon,  8 Aug 2011 14:45:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.939
X-Spam-Level: 
X-Spam-Status: No, score=-105.939 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rYm+PjcATES for <ima@ietfa.amsl.com>; Mon,  8 Aug 2011 14:45:50 -0700 (PDT)
Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB3911E807D for <ima@ietf.org>; Mon,  8 Aug 2011 14:45:50 -0700 (PDT)
Received: from brmsunmail1-sfbay.uk.sun.com ([10.79.11.100]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id p78LkCs9007248; Mon, 8 Aug 2011 21:46:12 GMT
Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by brmsunmail1-sfbay.uk.sun.com (8.14.4+Sun/8.14.4/ENSMAIL,v2.4) with ESMTP id p78LkB49035407; Mon, 8 Aug 2011 21:46:11 GMT
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-disposition: inline
Content-type: text/plain; CHARSET=US-ASCII; format=flowed
Received: from [10.145.239.205] (nifty-silver.us.oracle.com [10.145.239.205]) by gotmail.us.oracle.com (Oracle Communications Messaging Exchange Server 7u5-4.01 64bit (built May 4 2011)) with ESMTPA id <0LPM00732PSWNH00@gotmail.us.oracle.com>; Mon, 08 Aug 2011 14:46:10 -0700 (PDT)
Date: Mon, 08 Aug 2011 13:39:30 -0700
From: Chris Newman <chris.newman@oracle.com>
To: Joseph Yee <jyee@afilias.info>
Message-id: <4946125E24FCBF4AF22EF329@96B2F16665FF96BAE59E9B90>
In-reply-to: <B963AB1A-39F2-4890-BAAC-DA47F6E54DF2@afilias.info>
References: <20110708012352.14365.62590.idtracker@ietfa.amsl.com> <511610891.05212@cnnic.cn> <DE4565887EBE42A9A6E8F987CEC6BCA7@LENOVO47E041CF> <F9F980ED2E4A14AD798EB0D8@dhcp-1764.meeting.ietf.org> <B963AB1A-39F2-4890-BAAC-DA47F6E54DF2@afilias.info>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
Cc: ima@ietf.org, Jiankang Yao <healthyao@gmail.com>
Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-11.txt
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Aug 2011 21:45:51 -0000

--On August 3, 2011 14:44:06 -0400 Joseph Yee <jyee@afilias.info> wrote:
>>>> 4. In section 3.5, I suggest adding an enhanced status code for the
>>>> case where a U-label can not be converted to an A-label. This is
>>>> semantically quite different from X.6.7 and X.6.9
>>>
>>> based on rfc5890, U-label must be transformed to A-label, otherwise, it
>>> can not be called U-label.
>>>
>>> John should be authoritive about the defintion of U-label.
>>
>> This does not prevent a broken client from generating a UTF-8 domain
>> that is not a valid U-label and thus can not be converted to an A-label.
>> It's an error a well-intentioned client implementer can make by mistake.
>> And it's a subtle error condition a processor may not expect. For those
>> reasons, I think it's useful to distinguish it from the class of
>> "recipient-can't-handle" errors.
>
> I'm not sure if a different error code can help end users at the moment.
> Unless you mean MSA/MTA to detect and report U-label => A-label failure,
> otherwise it is only "recipient-can't-handle" or "host-not-found".
>
> Would love to hear more feedback from everyone regarding this.

A "host-not-found" error is close but not entirely accurate since a UTF-8 
domain that can't be converted to an A-label can't even be looked up to 
determine if the host exists...

But I looked in RFC 3463 again and noticed there are correct codes that an 
MSA/MTA could use for this case.

MAIL FROM:   501 5.1.7 Bad sender's mailbox address syntax
RCPT TO:     501 5.1.3 Bad destination mailbox address syntax

So I think mentioning those codes for the case where a UTF-8 domain can't 
be converted to an A-label would be helpful.

		- Chris



From healthyao@gmail.com  Mon Aug  8 23:49:51 2011
Return-Path: <healthyao@gmail.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44E0511E80B1 for <ima@ietfa.amsl.com>; Mon,  8 Aug 2011 23:49:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.843
X-Spam-Level: 
X-Spam-Status: No, score=-1.843 tagged_above=-999 required=5 tests=[AWL=0.003,  BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3f6YHmSES1xQ for <ima@ietfa.amsl.com>; Mon,  8 Aug 2011 23:49:50 -0700 (PDT)
Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id B458A11E8093 for <ima@ietf.org>; Mon,  8 Aug 2011 23:49:50 -0700 (PDT)
Received: by pzk33 with SMTP id 33so4029303pzk.18 for <ima@ietf.org>; Mon, 08 Aug 2011 23:50:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; bh=fRbBSBAudUp19I526MjEwMJ0dC/36VgJUX1QAfxxBAw=; b=ETjLi11BY49OVOnevc6jyFuE6oVzUaoWiOlEiUK1DWNbJexHdEYGRdGr5btZ+rkdZ8 uIC4hGIfBN/d1RSrDx0bkXLVPydwDivqGmygEHSzSdJEuog8U4sQQrKUOUv3zNBpJDhe GLDqHSTlWINyUAx2w7uJzlzRdzkInExW3mJT8=
Received: by 10.142.207.9 with SMTP id e9mr6519840wfg.125.1312872618609; Mon, 08 Aug 2011 23:50:18 -0700 (PDT)
Received: from LENOVO47E041CF ([218.241.111.35]) by mx.google.com with ESMTPS id k3sm6830180pbj.45.2011.08.08.23.50.15 (version=SSLv3 cipher=OTHER); Mon, 08 Aug 2011 23:50:17 -0700 (PDT)
Message-ID: <25FA2FF29588418FB0C200EBE21E4639@LENOVO47E041CF>
From: "Jiankang Yao" <healthyao@gmail.com>
To: "Chris Newman" <chris.newman@oracle.com>, "Joseph Yee" <jyee@afilias.info>
References: <20110708012352.14365.62590.idtracker@ietfa.amsl.com><511610891.05212@cnnic.cn><DE4565887EBE42A9A6E8F987CEC6BCA7@LENOVO47E041CF><F9F980ED2E4A14AD798EB0D8@dhcp-1764.meeting.ietf.org><B963AB1A-39F2-4890-BAAC-DA47F6E54DF2@afilias.info> <512839995.38187@cnnic.cn>
Date: Tue, 9 Aug 2011 14:50:13 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: base64
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
Cc: ima@ietf.org
Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-11.txt
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Aug 2011 06:49:51 -0000

DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkNocmlzIE5ld21hbiIgPGNo
cmlzLm5ld21hbkBvcmFjbGUuY29tPg0KVG86ICJKb3NlcGggWWVlIiA8anllZUBhZmlsaWFzLmlu
Zm8+DQpDYzogPGltYUBpZXRmLm9yZz47ICJKaWFua2FuZyBZYW8iIDxoZWFsdGh5YW9AZ21haWwu
Y29tPg0KU2VudDogVHVlc2RheSwgQXVndXN0IDA5LCAyMDExIDQ6MzkgQU0NClN1YmplY3Q6IFJl
OiBbRUFJXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWVhaS1yZmM1MzM2YmlzLTExLnR4dA0KDQoN
Cj4gLS1PbiBBdWd1c3QgMywgMjAxMSAxNDo0NDowNiAtMDQwMCBKb3NlcGggWWVlIDxqeWVlQGFm
aWxpYXMuaW5mbz4gd3JvdGU6DQo+Pj4+PiA0LiBJbiBzZWN0aW9uIDMuNSwgSSBzdWdnZXN0IGFk
ZGluZyBhbiBlbmhhbmNlZCBzdGF0dXMgY29kZSBmb3IgdGhlDQo+Pj4+PiBjYXNlIHdoZXJlIGEg
VS1sYWJlbCBjYW4gbm90IGJlIGNvbnZlcnRlZCB0byBhbiBBLWxhYmVsLiBUaGlzIGlzDQo+Pj4+
PiBzZW1hbnRpY2FsbHkgcXVpdGUgZGlmZmVyZW50IGZyb20gWC42LjcgYW5kIFguNi45DQo+Pj4+
DQo+Pj4+IGJhc2VkIG9uIHJmYzU4OTAsIFUtbGFiZWwgbXVzdCBiZSB0cmFuc2Zvcm1lZCB0byBB
LWxhYmVsLCBvdGhlcndpc2UsIGl0DQo+Pj4+IGNhbiBub3QgYmUgY2FsbGVkIFUtbGFiZWwuDQo+
Pj4+DQo+Pj4+IEpvaG4gc2hvdWxkIGJlIGF1dGhvcml0aXZlIGFib3V0IHRoZSBkZWZpbnRpb24g
b2YgVS1sYWJlbC4NCj4+Pg0KPj4+IFRoaXMgZG9lcyBub3QgcHJldmVudCBhIGJyb2tlbiBjbGll
bnQgZnJvbSBnZW5lcmF0aW5nIGEgVVRGLTggZG9tYWluDQo+Pj4gdGhhdCBpcyBub3QgYSB2YWxp
ZCBVLWxhYmVsIGFuZCB0aHVzIGNhbiBub3QgYmUgY29udmVydGVkIHRvIGFuIEEtbGFiZWwuDQo+
Pj4gSXQncyBhbiBlcnJvciBhIHdlbGwtaW50ZW50aW9uZWQgY2xpZW50IGltcGxlbWVudGVyIGNh
biBtYWtlIGJ5IG1pc3Rha2UuDQo+Pj4gQW5kIGl0J3MgYSBzdWJ0bGUgZXJyb3IgY29uZGl0aW9u
IGEgcHJvY2Vzc29yIG1heSBub3QgZXhwZWN0LiBGb3IgdGhvc2UNCj4+PiByZWFzb25zLCBJIHRo
aW5rIGl0J3MgdXNlZnVsIHRvIGRpc3Rpbmd1aXNoIGl0IGZyb20gdGhlIGNsYXNzIG9mDQo+Pj4g
InJlY2lwaWVudC1jYW4ndC1oYW5kbGUiIGVycm9ycy4NCj4+DQo+PiBJJ20gbm90IHN1cmUgaWYg
YSBkaWZmZXJlbnQgZXJyb3IgY29kZSBjYW4gaGVscCBlbmQgdXNlcnMgYXQgdGhlIG1vbWVudC4N
Cj4+IFVubGVzcyB5b3UgbWVhbiBNU0EvTVRBIHRvIGRldGVjdCBhbmQgcmVwb3J0IFUtbGFiZWwg
PT4gQS1sYWJlbCBmYWlsdXJlLA0KPj4gb3RoZXJ3aXNlIGl0IGlzIG9ubHkgInJlY2lwaWVudC1j
YW4ndC1oYW5kbGUiIG9yICJob3N0LW5vdC1mb3VuZCIuDQo+Pg0KPj4gV291bGQgbG92ZSB0byBo
ZWFyIG1vcmUgZmVlZGJhY2sgZnJvbSBldmVyeW9uZSByZWdhcmRpbmcgdGhpcy4NCj4gDQo+IEEg
Imhvc3Qtbm90LWZvdW5kIiBlcnJvciBpcyBjbG9zZSBidXQgbm90IGVudGlyZWx5IGFjY3VyYXRl
IHNpbmNlIGEgVVRGLTggDQo+IGRvbWFpbiB0aGF0IGNhbid0IGJlIGNvbnZlcnRlZCB0byBhbiBB
LWxhYmVsIGNhbid0IGV2ZW4gYmUgbG9va2VkIHVwIHRvIA0KPiBkZXRlcm1pbmUgaWYgdGhlIGhv
c3QgZXhpc3RzLi4uDQo+IA0KPiBCdXQgSSBsb29rZWQgaW4gUkZDIDM0NjMgYWdhaW4gYW5kIG5v
dGljZWQgdGhlcmUgYXJlIGNvcnJlY3QgY29kZXMgdGhhdCBhbiANCj4gTVNBL01UQSBjb3VsZCB1
c2UgZm9yIHRoaXMgY2FzZS4NCj4gDQo+IE1BSUwgRlJPTTogICA1MDEgNS4xLjcgQmFkIHNlbmRl
cidzIG1haWxib3ggYWRkcmVzcyBzeW50YXgNCj4gUkNQVCBUTzogICAgIDUwMSA1LjEuMyBCYWQg
ZGVzdGluYXRpb24gbWFpbGJveCBhZGRyZXNzIHN5bnRheA0KPiANCj4gU28gSSB0aGluayBtZW50
aW9uaW5nIHRob3NlIGNvZGVzIGZvciB0aGUgY2FzZSB3aGVyZSBhIFVURi04IGRvbWFpbiBjYW4n
dCANCj4gYmUgY29udmVydGVkIHRvIGFuIEEtbGFiZWwgd291bGQgYmUgaGVscGZ1bC4NCj4gDQoN
CkluIHRoZSAgY2FzZSB3aGVyZSBhIFVURi04IGRvbWFpbiBjYW4ndCAgYmUgY29udmVydGVkIHRv
IGFuIEEtbGFiZWwsIA0KIHdlIGNhbiByZWdhcmQgaXQgYXMgdGhlIGJhZCBtYWlsYm94IGFkZHJl
c3Mgc3ludGF4IGFzIHBvaW50ZWQgb3V0IGJ5IHlvdXIgZXhhbXBsZSBhYm92ZS4NClRoZSBpbnZh
bGlkIGFkZHJlc3MgbWF5IGJlIGNhdXNlZCBieSBpbnZhbGlkIFUtbGFibGUgb3IgTG9jYWwtcGFy
dC4NCg0KU2luY2UgdGhlIFJGQyAzNDYzIGhhcyBkZWZpbmVkIGl0LCBnaXZpbmcgaXQgbW9yZSBk
ZXRhaWxlZCBkaXN0aW5jdGlvbiBtYXkgbm90IGJyaW5nIHVzIG1vcmUgaGVscC4NCg0KDQpKaWFu
a2FuZyBZYW8NCg0KDQo+IC0gQ2hyaXMNCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJTUEgbWFpbGluZyBsaXN0DQo+IElNQUBpZXRm
Lm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ltYQ==


From internet-drafts@ietf.org  Wed Aug 10 23:53:43 2011
Return-Path: <internet-drafts@ietf.org>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A607B21F888A; Wed, 10 Aug 2011 23:53:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.566
X-Spam-Level: 
X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDQzdu-AgKGg; Wed, 10 Aug 2011 23:53:43 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48DBE21F8797; Wed, 10 Aug 2011 23:53:43 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.57
Message-ID: <20110811065343.24089.49958.idtracker@ietfa.amsl.com>
Date: Wed, 10 Aug 2011 23:53:43 -0700
Cc: ima@ietf.org
Subject: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-12.txt
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Aug 2011 06:53:43 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Email Address Internationalization Wo=
rking Group of the IETF.

	Title           : SMTP Extension for Internationalized Email
	Author(s)       : Jiankang Yao
                          W. Mao
	Filename        : draft-ietf-eai-rfc5336bis-12.txt
	Pages           : 20
	Date            : 2011-08-10

   This document specifies an SMTP extension for transport and delivery
   of email messages with internationalized email addresses or header
   information.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-eai-rfc5336bis-12.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-eai-rfc5336bis-12.txt

From alexey.melnikov@isode.com  Thu Aug 11 04:41:29 2011
Return-Path: <alexey.melnikov@isode.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA63E21F8AAA for <ima@ietfa.amsl.com>; Thu, 11 Aug 2011 04:41:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.491
X-Spam-Level: 
X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVV5hP+YGkK9 for <ima@ietfa.amsl.com>; Thu, 11 Aug 2011 04:41:29 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 1683E21F8A91 for <ima@ietf.org>; Thu, 11 Aug 2011 04:41:29 -0700 (PDT)
Received: from [192.168.1.124] ((unknown) [62.3.217.253])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <TkPACQALhKS4@rufus.isode.com>; Thu, 11 Aug 2011 12:42:02 +0100
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <4E43C008.5010407@isode.com>
Date: Thu, 11 Aug 2011 12:42:00 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
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: Jiankang Yao <healthyao@gmail.com>, Chris Newman <chris.newman@oracle.com>
References: <20110708012352.14365.62590.idtracker@ietfa.amsl.com> <511610891.05212@cnnic.cn> <D11E5292C3D94CC8A5B4D5033CDCBD58@LENOVO47E041CF>
In-Reply-To: <D11E5292C3D94CC8A5B4D5033CDCBD58@LENOVO47E041CF>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: ima@ietf.org
Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-11.txt
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Aug 2011 11:41:29 -0000

Jiankang Yao wrote:

>----- Original Message ----- 
>From: "Chris Newman" <chris.newman@oracle.com>
>To: <ima@ietf.org>
>Sent: Monday, July 25, 2011 10:16 PM
>Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-11.txt
>  
>
 [...]

>>2. I would prefer this ABNF rule be removed:
>>
>>  quoted-pairSMTP  =/ %d92 UTF8-non-ascii
>>   ; extend the definition of quoted-pairSMTP in RFC5321, section 4.1.2
>>
>>This is an unnecessary change and makes 5336bis quoting even less 
>>consistent with 5335bis quoting. Conservative generators should never emit 
>>\ followed by anything other than \ or double-quote anyway, so adding 
>>complexity to explicitly allow generation of useless forms is not helpful.    
>>
>
>I agreed it here.
>  
>
I am very happy that this ABNF rule is gone.


From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com  Sat Aug 13 13:23:02 2011
Return-Path: <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C2C21F86C3 for <ima@ietfa.amsl.com>; Sat, 13 Aug 2011 13:23:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.654
X-Spam-Level: 
X-Spam-Status: No, score=-102.654 tagged_above=-999 required=5 tests=[AWL=0.293, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yx26CnMs3VxM for <ima@ietfa.amsl.com>; Sat, 13 Aug 2011 13:23:02 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id E624C21F86BF for <ima@ietf.org>; Sat, 13 Aug 2011 13:23:01 -0700 (PDT)
Received: by yxp4 with SMTP id 4so3044065yxp.31 for <ima@ietf.org>; Sat, 13 Aug 2011 13:23:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=Ga4o4yAat2azVYjvp6SlYHaF1s9OoLzuezIRuKzziMQ=; b=d00+59dzsM2Z+GkBh2B86BKTjiRLJYBz3TlemrN6ZVFOKSw8JHyDYckZxWNfptC681 ZB/J3RT5BxbRg6RSz0lwsR7KGzgSZnWc2NFpwrJGRZoWerDqlvdfsX8cGsHgTK2Xr3rc d+3k/dCdZWhFq6taeCTw/hwQlqAYeNzziEe+M=
Received: by 10.143.21.4 with SMTP id y4mr994463wfi.48.1313267022075; Sat, 13 Aug 2011 13:23:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.143.157.2 with HTTP; Sat, 13 Aug 2011 13:23:22 -0700 (PDT)
From: Frank Ellermann <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>
Date: Sat, 13 Aug 2011 22:23:22 +0200
Message-ID: <CAHhFybo47--0YjCRcvSO4asoV_R89+ULDB3tyij+ba=O_6gKsQ@mail.gmail.com>
To: ima@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: [EAI] UTF-8 in Message-IDs
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Aug 2011 20:23:02 -0000

Hi,

looking for something else (= state of the art wrt EAI
and SPF) yesterday I stumbled over the "81 IETF EAI
meeting minutes" in the mailing list archive, with a
note about "UTF-8 in Message-IDs".

That was certainly (bad) news from my POV, and whining
about it off list I got the tip that waiting for an
IETF Last Call is a bad plan when this could be also
addressed before WG Last Call.

>From my POV the "globally unique forever Message-ID"
in mail and news is in essence an early form of what
is now a GUID/UUID in other protocols.  Maybe a bit
more so, in theory there could be UUID collisions,
and that's not possible for Message-IDs (in theory).

This theory is relevant for NetNews, gateways from or
to NetNews, mail and news threading, APOP, and likely
other use cases I'm not aware of.

Nobody would say replace hex. by UTF-8 in GUID/UUIDs,
therefore I fail to see the point of trying something
in this direction in Message-IDs.  Gateway operators
stating that UTF-8 in Message-IDs would be no problem
in practise, or that this would be only a minor point
when they adopt EAI, might convince me that I'm only
paranoid, but I doubt it.

And the "EAI experiment" phase did not test this plan,
there's no evidence I'm aware of that UTF-8 in Message-
IDs is harmless.  Did you really check all RFCs using
or mentioning Message-IDs for potential side-effects
of introducing UTF-8 in the "local", "unique", "left"
etc. part of a Message-ID?  E.g., does it fly with the
Message-ID concept in APOP and CRAM-MD5, or do you
intend something in the direction of "updates 2195"
to make it work?

-Frank

From ned+ima@mrochek.com  Sat Aug 13 15:15:28 2011
Return-Path: <ned+ima@mrochek.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8018621F86BD for <ima@ietfa.amsl.com>; Sat, 13 Aug 2011 15:15:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.337
X-Spam-Level: 
X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=0.110,  BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxA5V3poLLGU for <ima@ietfa.amsl.com>; Sat, 13 Aug 2011 15:15:27 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id CC41D21F86B3 for <ima@ietf.org>; Sat, 13 Aug 2011 15:15:27 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O4T11P5D00012KF0@mauve.mrochek.com> for ima@ietf.org; Sat, 13 Aug 2011 15:15:07 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O4CJSMR6GG00VHKR@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Sat, 13 Aug 2011 15:15:04 -0700 (PDT)
From: ned+ima@mrochek.com
Message-id: <01O4T11O8X4M00VHKR@mauve.mrochek.com>
Date: Sat, 13 Aug 2011 15:08:48 -0700 (PDT)
In-reply-to: "Your message dated Sat, 13 Aug 2011 22:23:22 +0200" <CAHhFybo47--0YjCRcvSO4asoV_R89+ULDB3tyij+ba=O_6gKsQ@mail.gmail.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <CAHhFybo47--0YjCRcvSO4asoV_R89+ULDB3tyij+ba=O_6gKsQ@mail.gmail.com>
To: Frank Ellermann <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1313273609; bh=J9Z0/+6Pot3bOrQ+q9FbW0lno0sBmWTNOBxJalCJ7Sw=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=XiW0hs+6wol3tTuLkUzAzOjQwkNpr2xBUl76jtkxSa0i0JKwVtOFUTm8kIpl+VhZz iw24NMMIMO0MX8q7PP90axsnBsy4ctzbBB2etm6OnCznb6fGBIgqojldEQEhXWHsHO 6JtNFAEo8rxhmG9r8DP9WyDPsBU/OfKMMc2ccxJQ=
Cc: ima@ietf.org
Subject: Re: [EAI] UTF-8 in Message-IDs
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Aug 2011 22:15:28 -0000

> looking for something else (= state of the art wrt EAI
> and SPF) yesterday I stumbled over the "81 IETF EAI
> meeting minutes" in the mailing list archive, with a
> note about "UTF-8 in Message-IDs".

> That was certainly (bad) news from my POV, and whining
> about it off list I got the tip that waiting for an
> IETF Last Call is a bad plan when this could be also
> addressed before WG Last Call.

> From my POV the "globally unique forever Message-ID"
> in mail and news is in essence an early form of what
> is now a GUID/UUID in other protocols.  Maybe a bit
> more so, in theory there could be UUID collisions,
> and that's not possible for Message-IDs (in theory).

> This theory is relevant for NetNews, gateways from or
> to NetNews, mail and news threading, APOP, and likely
> other use cases I'm not aware of.

> Nobody would say replace hex. by UTF-8 in GUID/UUIDs,
> therefore I fail to see the point of trying something
> in this direction in Message-IDs.  Gateway operators
> stating that UTF-8 in Message-IDs would be no problem
> in practise, or that this would be only a minor point
> when they adopt EAI, might convince me that I'm only
> paranoid, but I doubt it.

> And the "EAI experiment" phase did not test this plan,
> there's no evidence I'm aware of that UTF-8 in Message-
> IDs is harmless.

I'm sure it is not, just as utf-8 in addresses is far from harmless and is
going to require all sorts of infrastructure changes.

But I fail to see how this is in any way relevant. We're defining a new message
format here that *cannot* be downgraded to the old format and retain all
semantics. This is true irrespective of how message-ids are handled. As such,
utf-8 in message-ids is a small additional cost.

It's also a cost that I doubt can be avoided no matter what the specification
says. Once utf-8 is in domains in messages it's going to leak into message-ids
no matter what the specifications say.

> Did you really check all RFCs using
> or mentioning Message-IDs for potential side-effects
> of introducing UTF-8 in the "local", "unique", "left"
> etc. part of a Message-ID?

Nope. Given the approach the WG is taking to this problem, such an analysis
would be a pointless waste of time.

Maybe, if we were taking the MIME approach, such a check would make sense.
But we're not doing that.

> E.g., does it fly with the
> Message-ID concept in APOP and CRAM-MD5, or do you
> intend something in the direction of "updates 2195"
> to make it work?

Why would that be coupled to this new message format?

				Ned

From chl@clerew.man.ac.uk  Mon Aug 15 02:17:07 2011
Return-Path: <chl@clerew.man.ac.uk>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4007D21F85C0 for <ima@ietfa.amsl.com>; Mon, 15 Aug 2011 02:17:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.399
X-Spam-Level: 
X-Spam-Status: No, score=-4.399 tagged_above=-999 required=5 tests=[AWL=-0.952, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40ra45AKwnSQ for <ima@ietfa.amsl.com>; Mon, 15 Aug 2011 02:17:06 -0700 (PDT)
Received: from outbound-queue-2.mail.thdo.gradwell.net (outbound-queue-2.mail.thdo.gradwell.net [212.11.70.35]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5EA21F85B5 for <ima@ietf.org>; Mon, 15 Aug 2011 02:17:05 -0700 (PDT)
Received: from outbound-edge-2.mail.thdo.gradwell.net (bonnie.gradwell.net [212.11.70.2]) by outbound-queue-2.mail.thdo.gradwell.net (Postfix) with ESMTP id 2FBC321E91 for <ima@ietf.org>; Mon, 15 Aug 2011 10:17:48 +0100 (BST)
Received: from port-89.xxx.th.newnet.co.uk (HELO clerew.man.ac.uk) (80.175.135.89) (smtp-auth username postmaster%pop3.clerew.man.ac.uk, mechanism cram-md5) by outbound-edge-2.mail.thdo.gradwell.net (qpsmtpd/0.83) with (DES-CBC3-SHA encrypted) ESMTPSA; Mon, 15 Aug 2011 10:17:48 +0100
Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id p7F9Hjdt005253 for <ima@ietf.org>; Mon, 15 Aug 2011 10:17:47 +0100 (BST)
Date: Mon, 15 Aug 2011 10:17:45 +0100
To: IMA <ima@ietf.org>
From: "Charles Lindsey" <chl@clerew.man.ac.uk>
Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1
MIME-Version: 1.0
References: <CAHhFybo47--0YjCRcvSO4asoV_R89+ULDB3tyij+ba=O_6gKsQ@mail.gmail.com> <01O4T11O8X4M00VHKR@mauve.mrochek.com>
Content-Transfer-Encoding: 8bit
Message-ID: <op.vz8z3v0a6hl8nm@clerew.man.ac.uk>
In-Reply-To: <01O4T11O8X4M00VHKR@mauve.mrochek.com>
User-Agent: Opera Mail/9.25 (SunOS)
X-Gradwell-MongoId: 4e48e43c.3a49-b55-2
X-Gradwell-Auth-Method: mailbox
X-Gradwell-Auth-Credentials: postmaster@pop3.clerew.man.ac.uk
Subject: Re: [EAI] UTF-8 in Message-IDs
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Aug 2011 09:17:07 -0000

On Sat, 13 Aug 2011 23:08:48 +0100, <ned+ima@mrochek.com> wrote:

>> And the "EAI experiment" phase did not test this plan,
>> there's no evidence I'm aware of that UTF-8 in Message-
>> IDs is harmless.
>
> I'm sure it is not, just as utf-8 in addresses is far from harmless and  
> is
> going to require all sorts of infrastructure changes.
>
> But I fail to see how this is in any way relevant. We're defining a new  
> message
> format here that *cannot* be downgraded to the old format and retain all
> semantics. This is true irrespective of how message-ids are handled. As  
> such,
> utf-8 in message-ids is a small additional cost.

Yes, but you have to consider all the other protocols using mail-like  
formats and their use of the Message-ID. For exmaple, if EAI were to be  
carried over into Netnews (quite a likely development) it would NOT be  
regarded as a "new message format" since the transport paths for Netnews  
are already 8-bit clean and it would simply be necessary for those who  
wish to take advantage of the new facilities to ensure that their user  
agents were suitably upgraded. There will never be a need for  
"downgrading" except at gateways back into the email system.

But within Netnews the Message-ID plays a crucial role, so it is  
reasonable to ask whether UTF-8 in it would cause problems. According to  
the current standards it would not be allowed, of course, but in practice  
the transport paths might or might not barf. So the question has to be  
asked (and I do not know the answer off the top of my head).

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

From ned+ima@mrochek.com  Mon Aug 15 08:35:42 2011
Return-Path: <ned+ima@mrochek.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C8A21F8B94 for <ima@ietfa.amsl.com>; Mon, 15 Aug 2011 08:35:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.351
X-Spam-Level: 
X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.096,  BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IN1dbcZssutL for <ima@ietfa.amsl.com>; Mon, 15 Aug 2011 08:35:42 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7C521F85B8 for <ima@ietf.org>; Mon, 15 Aug 2011 08:35:42 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O4VFNNX5IO0111EM@mauve.mrochek.com> for ima@ietf.org; Mon, 15 Aug 2011 08:35:19 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O4CJSMR6GG00VHKR@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Mon, 15 Aug 2011 08:35:11 -0700 (PDT)
From: ned+ima@mrochek.com
Message-id: <01O4VFNKDGEE00VHKR@mauve.mrochek.com>
Date: Mon, 15 Aug 2011 08:19:44 -0700 (PDT)
In-reply-to: "Your message dated Mon, 15 Aug 2011 10:17:45 +0100" <op.vz8z3v0a6hl8nm@clerew.man.ac.uk>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=iso-8859-1; Format=flowed; DelSp=yes
References: <CAHhFybo47--0YjCRcvSO4asoV_R89+ULDB3tyij+ba=O_6gKsQ@mail.gmail.com> <01O4T11O8X4M00VHKR@mauve.mrochek.com> <op.vz8z3v0a6hl8nm@clerew.man.ac.uk>
To: Charles Lindsey <chl@clerew.man.ac.uk>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1313422415; bh=zRNxqcNAuzITt5J84CDYKKr9Fz6M3oc+ectOblzHdj4=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=MaLlp/X2WD+DBumppeznpjUTdOiCEqSMnZYocZ2abVb8jcZ2ayGL3sVcU2rbdkMh2 OLmWVzT4HPi4A61VqimlFeplfaW2UfMPIFdntpcWVm/Pm17YtVs+YR9ZbksA1cGXRW +I1sUPdct2hr6qU9Y0smBhP+89SyDiZsuWu7j/Gg=
Cc: IMA <ima@ietf.org>
Subject: Re: [EAI] UTF-8 in Message-IDs
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Aug 2011 15:35:42 -0000

> On Sat, 13 Aug 2011 23:08:48 +0100, <ned+ima@mrochek.com> wrote:

> >> And the "EAI experiment" phase did not test this plan,
> >> there's no evidence I'm aware of that UTF-8 in Message-
> >> IDs is harmless.
> >
> > I'm sure it is not, just as utf-8 in addresses is far from harmless and
> > is
> > going to require all sorts of infrastructure changes.
> >
> > But I fail to see how this is in any way relevant. We're defining a new
> > message
> > format here that *cannot* be downgraded to the old format and retain all
> > semantics. This is true irrespective of how message-ids are handled. As
> > such,
> > utf-8 in message-ids is a small additional cost.

> Yes, but you have to consider all the other protocols using mail-like
> formats and their use of the Message-ID.

These protocols don't make use of email addresses? 

> For exmaple, if EAI were to be
> carried over into Netnews (quite a likely development) it would NOT be
> regarded as a "new message format" since the transport paths for Netnews
> are already 8-bit clean and it would simply be necessary for those who
> wish to take advantage of the new facilities to ensure that their user
> agents were suitably upgraded. There will never be a need for
> "downgrading" except at gateways back into the email system.

And all netnews applications properly handle the construction and display of
utf-8 addresses in message headers? Just as one example, netnews already
suports the proper form of Unicode normalization on input for this. Right?

An 8-bit clean transport is nowhere near sufficient to accomodate the other
changes to the format we're making here. Message ids are actually the least of
it since they are machine generated.

> But within Netnews the Message-ID plays a crucial role, so it is
> reasonable to ask whether UTF-8 in it would cause problems. According to
> the current standards it would not be allowed, of course, but in practice
> the transport paths might or might not barf. So the question has to be
> asked (and I do not know the answer off the top of my head).

I'm sorry, but the entire approach of this WG is to define a format that is NOT
downgradeable to previous formats without substantial information loss. Given
that's the context here, how can the question of "how well does this downgrade
in this particular case" possibly be relevant?

Look, I'll be the first to state that the approach being taken here is risky.
In fact I would never have chosen this approach myself. But that doesn't
change the fact that there's a consensus to proceed in this fashion.

				Ned


From dhc2@dcrocker.net  Mon Aug 15 08:46:02 2011
Return-Path: <dhc2@dcrocker.net>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E0B21F8B70 for <ima@ietfa.amsl.com>; Mon, 15 Aug 2011 08:46:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.778
X-Spam-Level: 
X-Spam-Status: No, score=-5.778 tagged_above=-999 required=5 tests=[AWL=0.669,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGS9L-x6VFcx for <ima@ietfa.amsl.com>; Mon, 15 Aug 2011 08:46:01 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id B67BD21F8B6A for <ima@ietf.org>; Mon, 15 Aug 2011 08:46:01 -0700 (PDT)
Received: from [192.168.1.156] (adsl-68-122-69-114.dsl.pltn13.pacbell.net [68.122.69.114]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p7FFkguf028340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ima@ietf.org>; Mon, 15 Aug 2011 08:46:47 -0700
Message-ID: <4E493F62.20806@dcrocker.net>
Date: Mon, 15 Aug 2011 08:46:42 -0700
From: Dave CROCKER <dhc2@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: ima@ietf.org
References: <CAHhFybo47--0YjCRcvSO4asoV_R89+ULDB3tyij+ba=O_6gKsQ@mail.gmail.com> <01O4T11O8X4M00VHKR@mauve.mrochek.com> <op.vz8z3v0a6hl8nm@clerew.man.ac.uk> <01O4VFNKDGEE00VHKR@mauve.mrochek.com>
In-Reply-To: <01O4VFNKDGEE00VHKR@mauve.mrochek.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 15 Aug 2011 08:46:47 -0700 (PDT)
Subject: Re: [EAI] UTF-8 in Message-IDs
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Aug 2011 15:46:02 -0000

On 8/15/2011 8:19 AM, ned+ima@mrochek.com wrote:
> I'm sorry, but the entire approach of this WG is to define a format that is NOT
> downgradeable to previous formats without substantial information loss. Given
> that's the context here, how can the question of "how well does this downgrade
> in this particular case" possibly be relevant?

+1


> Look, I'll be the first to state that the approach being taken here is risky.
> In fact I would never have chosen this approach myself. But that doesn't
> change the fact that there's a consensus to proceed in this fashion.

+1

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From klensin@jck.com  Mon Aug 15 09:46:28 2011
Return-Path: <klensin@jck.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D46721F8C50 for <ima@ietfa.amsl.com>; Mon, 15 Aug 2011 09:46:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.568
X-Spam-Level: 
X-Spam-Status: No, score=-3.568 tagged_above=-999 required=5 tests=[AWL=0.879,  BAYES_00=-2.599, GB_I_LETTER=-2, SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2xcyzHKwMkz for <ima@ietfa.amsl.com>; Mon, 15 Aug 2011 09:46:27 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 28F9E21F8C4E for <ima@ietf.org>; Mon, 15 Aug 2011 09:46:27 -0700 (PDT)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Qt0Ja-0005EL-LR; Mon, 15 Aug 2011 12:47:03 -0400
Date: Mon, 15 Aug 2011 12:47:01 -0400
From: John C Klensin <klensin@jck.com>
To: ned+ima@mrochek.com, Charles Lindsey <chl@clerew.man.ac.uk>
Message-ID: <C31E821E731AC23ED7EE191F@PST.JCK.COM>
In-Reply-To: <01O4VFNKDGEE00VHKR@mauve.mrochek.com>
References: <CAHhFybo47--0YjCRcvSO4asoV_R89+ULDB3tyij+ba=O_6gKsQ@mail.gmail.com> <01O4T11O8X4M00VHKR@mauve.mrochek.com> <op.vz8z3v0a6hl8nm@clerew.man.ac.uk> <01O4VFNKDGEE00VHKR@mauve.mrochek.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Cc: IMA <ima@ietf.org>
Subject: Re: [EAI] UTF-8 in Message-IDs
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Aug 2011 16:46:28 -0000

Ned, Charles, and others,

(strictly personal opinion)

Let me give a different perspective on this, in the hope of
drawing us together on the conclusions if not on the reasoning.

I'm not (personally) wildly comfortable with unrestricted
Message-IDs.  I don't find arguments based on "we chose this
general model and therefore Message-IDs can't/shouldn't be
restricted" persuasive, precisely because we've said "protocol
identifier" before and, IMO, our ability to say that is critical
to getting any i18n design process right.  In particular, I note
that we have not permitted non-ASCII characters in new/optional
header field names by modifying RFC5322's <optional-field> to
permit <ftext> to be a much less restricted range of characters.
I think that it would be a mistake to make that extension
(indeed, I personally think that we'd be much better off if
<ftext> were restricted to ASCII letters, digits, and hyphen
rather than excluding only non-printable characters and colon).
But, if one argues that Message-ID has to be permitted to be
non-ASCII because we've adopted a "UTF-8 nearly everywhere"
model, the case for excluding field names has not been made (or
even really discussed)... and a field name of, e.g.,
   =D7=93=D7=A8=D7=A2=D7=A7=D7=A7: ...
has a certain appeal (as well as some nightmare aspects).

However, other arguments are much more persuasive to me, with
the two critical ones being:

	(1) An MUA, or MTA pretending to be an MUA for message
	analysis purposes, that can handle non-ASCII UTF-8 in
	addresses or other header fields will need to go to very
	small marginal extra effort to handle a Message-ID with
	non-ASCII content.  Indeed, most sensible
	implementations would see a restriction that Message-IDs
	be ASCII as a requirement for added code to support an
	unnecessary requirement.    We have not had good luck
	with restrictions like that.
	
	(2) Given what we know about how Message-IDs are
	constructed in practice, we can expect non-ASCII forms
	to appear no matter what the spec says.  There is no
	point in writing a spec that we know will be ignored.
	For that reason, I think those arguing to restrict
	Message-IDs to ASCII need to come up with a clear,
	concise, and powerful explanation of why non-ASCII
	Message-IDs would be harmful -- an explanation that can
	be included in our documentation to persuade
	implementers that the requirement is really worth
	enforcing. =20

To me, the "unnecessary requirement" and "will be ignored in
practice" positions strongly suggest that the burden of
demonstrating likely harm -- and producing that clear, concise,
and powerful explanation-- falls on those who would like to keep
Message-IDs ASCII-only.   If one believes in the "we adopted a
different model" story, it just strengthens that position.

In all of these discussions, I haven't seen that explanation
emerge.

I can think of one set of scenarios that might provide a
foundation for it, even though I'm not convinced that they are
strong enough to restrict Message-IDs.  The scenario goes
somewhat like this (and parallels some of the discussion about
message changes in Submission Servers). =20

	(1) Suppose I'm a user who receives a message. =20
	
	(2) Suppose I have an EAI-capable delivery MTA, message
	store, MUA, and whatever connects the MUA to the message
	store (i.e., none of the edge cases that are a headache
	for POP and IMAP apply).  Suppose the message I receive
	contains a non-ASCII Message-ID and very little other
	non-ASCII header field content.   As one example among
	many, suppose that only the contents of the Subject
	header field are non-ASCII (in addition to the
	Message-ID). =20

	(3) For simplification, suppose that my outgoing mail
	server's primary domain name does not contain any IDN
	components and Message-IDs I generate are all-ASCII.
	
	(4) Now I decide to reply to the originator (note that
	neither my address nor the address that appears in the
	"From:" header are non-ASCII).  I also add a recipient
	to the reply whose system is not EAI-capable (I know
	that from out of band information -- how is not
	important).   So, in addition to adding the additional
	address, I edit the Subject line so it is ASCII-only.
	(Remember this is a reply and I'm the user, so both of
	those changes are perfectly legitimate according to
	everything we've specified).

Now there is a problem.  An automatically-generated In-reply-to
header field, generated as recommended in 5322 (unchanged in
5335bis) is going to contain that non-ASCII Message-ID.  That
requires EAI handling (i.e., the UTF8SMTPbis extension) for the
outgoing message even though the In-reply-to field is the only
header field containing non-ASCII characters.  Given the
scenario above, that makes the message non-deliverable to my
intended new recipient.

That is bad news... and bad news that could have been completely
prevented by requiring that Message-IDs be restricted to ASCII.

The question, IMO, is whether cases of that type are likely to
be prevalent enough to justify a restriction.  I contend that
they are more than sufficient to justify some explanatory text
and a recommendation that there are cases in which having a
sending system be conservative enough to generate only all-ASCII
Message-IDs will provide some marginal robustness against
delivery rejections.  But I don't think it is nearly persuasive
enough to justify an outright ban on non-ASCII Message-IDs.

YMMD.

     john


From johnl@iecc.com  Mon Aug 15 10:51:55 2011
Return-Path: <johnl@iecc.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B73421F8C41 for <ima@ietfa.amsl.com>; Mon, 15 Aug 2011 10:51:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -111.123
X-Spam-Level: 
X-Spam-Status: No, score=-111.123 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tN6GFiP2aeaQ for <ima@ietfa.amsl.com>; Mon, 15 Aug 2011 10:51:50 -0700 (PDT)
Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id A506221F8C40 for <ima@ietf.org>; Mon, 15 Aug 2011 10:51:50 -0700 (PDT)
Received: (qmail 13444 invoked from network); 15 Aug 2011 17:52:36 -0000
Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 15 Aug 2011 17:52:36 -0000
Received: (qmail 88810 invoked from network); 15 Aug 2011 17:52:36 -0000
Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 15 Aug 2011 17:52:36 -0000
Date: 15 Aug 2011 17:52:14 -0000
Message-ID: <20110815175214.4833.qmail@joyce.lan>
From: "John Levine" <johnl@taugh.com>
To: ima@ietf.org
In-Reply-To: <C31E821E731AC23ED7EE191F@PST.JCK.COM>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 7bit
Subject: Re: [EAI] UTF-8 in Message-IDs
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Aug 2011 17:51:55 -0000

>Now there is a problem.  An automatically-generated In-reply-to
>header field, generated as recommended in 5322 (unchanged in
>5335bis) is going to contain that non-ASCII Message-ID.  That
>requires EAI handling (i.e., the UTF8SMTPbis extension) for the
>outgoing message even though the In-reply-to field is the only
>header field containing non-ASCII characters.  Given the
>scenario above, that makes the message non-deliverable to my
>intended new recipient. ...

If I may try to peek inside the can while trying to keep the worms
from escaping, I think many of us have an informal mental model of a
poorly specified downgrade process at submission time, since that's
the point at which it's more likely that software will have access to
address books with alternate addresses and so forth.  With that in
mind, it would be nice to have an ASCII message-id to make the poorly
specified process easier.  But I don't think we should go there,
except perhaps in an entirely separate document that makes it as clear
as possible that it's not part of the normal EAI transmission process.

I find the most compelling argument the one that there'll be UTF-8 in
message-ID's no matter what we say, so let's not specify something
that we expect implementors to get wrong.

R's,
John

From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com  Mon Aug 15 12:13:15 2011
Return-Path: <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F090611E80D7 for <ima@ietfa.amsl.com>; Mon, 15 Aug 2011 12:13:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.663
X-Spam-Level: 
X-Spam-Status: No, score=-102.663 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlRtRMViJzxI for <ima@ietfa.amsl.com>; Mon, 15 Aug 2011 12:13:15 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id AA8EC11E80D4 for <ima@ietf.org>; Mon, 15 Aug 2011 12:13:13 -0700 (PDT)
Received: by gyf3 with SMTP id 3so3832985gyf.31 for <ima@ietf.org>; Mon, 15 Aug 2011 12:13:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=Nth8/LMrVTRh0YtRtHREsVTPu9gq/YXRGzvQDRM/uKM=; b=ZgmErNXAgZ/3CBLmr5O/B7vPFAEPN2ETYySAr5yKP8kZz0EXStBZ+d+mreJPDo9AJH 55Eoq19wuaPKxvQ+bXlWWcJ1MDGWoXWNo0TO7267CwZBHqHN92btWhOELRsh4x8pu1oV EpaiFrBWCQKCeImG75plsD8n8Vo4lw40+wgPk=
Received: by 10.143.20.12 with SMTP id x12mr2227385wfi.105.1313435638125; Mon, 15 Aug 2011 12:13:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.142.98.5 with HTTP; Mon, 15 Aug 2011 12:13:38 -0700 (PDT)
In-Reply-To: <01O4T11O8X4M00VHKR@mauve.mrochek.com>
References: <CAHhFybo47--0YjCRcvSO4asoV_R89+ULDB3tyij+ba=O_6gKsQ@mail.gmail.com> <01O4T11O8X4M00VHKR@mauve.mrochek.com>
From: Frank Ellermann <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>
Date: Mon, 15 Aug 2011 21:13:38 +0200
Message-ID: <CAHhFybp6GNoCggfCbtCcmh0eqSHqD_=Z4rMZWrs_xticMDP5ow@mail.gmail.com>
To: ima@ietf.org, Ned Freed <ned.freed@mrochek.com>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [EAI] UTF-8 in Message-IDs
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Aug 2011 19:13:16 -0000

Sorry, apparently I forgot the CC: to the list, resent:

On 15 August 2011 17:19,  Ned Freed wrote:

> I'll be the first to state that the approach being taken here is risky.
> In fact I would never have chosen this approach myself. But that doesn't
> change the fact that there's a consensus to proceed in this fashion.

Maybe my original idea to start the whining in an IETF Last Call was not
completely wrong, because I certainly missed whatever resulted in this
consensus, and just *assumed* that EAI just moves on to "standards track",
because the Internet at large obviously survived the EAI "experiment".

In another mail you wrote about checking all Message-IDs in other RFCs:

| Maybe, if we were taking the MIME approach, such a check would make
| sense. But we're not doing that.

That is rather disturbing for me, "not taking the MIME approach" is not
something I'd consider.  Apart from breaking the concept of Message-IDs
without any immediately visible reasons after more than three decades,
what else does it encompass?  Whatever it might be, shouldn't this be
stated in 4952bis, preferably in upper case?

>From my POV the A in IDNA means Applications, and the first I in IRI is
not an U, no matter what XML or HTML5 say or wish.  E.g., if email users
try to use a mailto:acsii@example?in-reply-to=mid link in a mailing list
archive this is supposed to result in a message/rfc822 with an ordinary
In-Reply-To header field, unless this user intentionally uses some EAI
features.

Message-IDs don't need to be "pretty" or "human readable" or something,
their main point is to work as designed under almost all circumstances.

-Frank

From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com  Mon Aug 15 12:29:10 2011
Return-Path: <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A68B411E80EB for <ima@ietfa.amsl.com>; Mon, 15 Aug 2011 12:29:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.671
X-Spam-Level: 
X-Spam-Status: No, score=-102.671 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLx-cGYRuzDf for <ima@ietfa.amsl.com>; Mon, 15 Aug 2011 12:29:10 -0700 (PDT)
Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2A72111E80D7 for <ima@ietf.org>; Mon, 15 Aug 2011 12:29:10 -0700 (PDT)
Received: by pzk33 with SMTP id 33so5728789pzk.18 for <ima@ietf.org>; Mon, 15 Aug 2011 12:29:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=4+vQdqDnnKAYY/OhCIMgxrDuWOCpE5Top/OCD31Uuf8=; b=UL0AVx7uTs5aLw0K8N2i/w3Vkmon21AxmsAHEgvheVuNJBumhNAhGOA7yaENPVDuMA GAQb9R+3iLqqgmnnzEMSjkQluYDhyyqOdBW8XvCGVTSrDjHI25rx7SnWVpgs64YloTva mMOhTRAKOFjTTvvwB/kjAF3p7/nrershN6UH4=
Received: by 10.142.169.7 with SMTP id r7mr461539wfe.13.1313436596200; Mon, 15 Aug 2011 12:29:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.142.98.5 with HTTP; Mon, 15 Aug 2011 12:29:36 -0700 (PDT)
In-Reply-To: <20110815175214.4833.qmail@joyce.lan>
References: <C31E821E731AC23ED7EE191F@PST.JCK.COM> <20110815175214.4833.qmail@joyce.lan>
From: Frank Ellermann <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>
Date: Mon, 15 Aug 2011 21:29:36 +0200
Message-ID: <CAHhFybo9PxBHehzTxkwj+-bCNvGcc0A66vnhbXOJi3AssMOPdw@mail.gmail.com>
To: John Levine <johnl@taugh.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: ima@ietf.org
Subject: Re: [EAI] UTF-8 in Message-IDs
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Aug 2011 19:29:10 -0000

On 15 August 2011 19:52, John Levine <johnl@taugh.com> wrote:

> I find the most compelling argument the one that there'll be UTF-8 in
> message-ID's no matter what we say, so let's not specify something
> that we expect implementors to get wrong.

Why do you all say that implementors will get this simple point wrong,
while you expect them to get far more convoluted syntax details right?

I don't see anything "compelling" in that line of reasoning, otherwise
we could also say that using 8bit in DNS queries works, and therefore
it's okay to use UTF-8 in host names (example).  Bugs in new apps can
be fixed, but limitations in old apps will never go away (until nobody
uses such old apps anymore).

-Frank

From ned+ima@mrochek.com  Mon Aug 15 13:35:28 2011
Return-Path: <ned+ima@mrochek.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 001AA11E8105 for <ima@ietfa.amsl.com>; Mon, 15 Aug 2011 13:35:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.34
X-Spam-Level: 
X-Spam-Status: No, score=-3.34 tagged_above=-999 required=5 tests=[AWL=1.063,  BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, GB_I_LETTER=-2, SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HI1Ya+K5ex+x for <ima@ietfa.amsl.com>; Mon, 15 Aug 2011 13:35:26 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id B9FB911E80E5 for <ima@ietf.org>; Mon, 15 Aug 2011 13:35:26 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O4VQ5DWCHC00X2RW@mauve.mrochek.com> for ima@ietf.org; Mon, 15 Aug 2011 13:35:08 -0700 (PDT)
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=utf-8
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O4CJSMR6GG00VHKR@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Mon, 15 Aug 2011 13:35:02 -0700 (PDT)
From: ned+ima@mrochek.com
Message-id: <01O4VQ5BI2B200VHKR@mauve.mrochek.com>
Date: Mon, 15 Aug 2011 10:32:30 -0700 (PDT)
In-reply-to: "Your message dated Mon, 15 Aug 2011 12:47:01 -0400" <C31E821E731AC23ED7EE191F@PST.JCK.COM>
References: <CAHhFybo47--0YjCRcvSO4asoV_R89+ULDB3tyij+ba=O_6gKsQ@mail.gmail.com> <01O4T11O8X4M00VHKR@mauve.mrochek.com> <op.vz8z3v0a6hl8nm@clerew.man.ac.uk> <01O4VFNKDGEE00VHKR@mauve.mrochek.com> <C31E821E731AC23ED7EE191F@PST.JCK.COM>
To: John C Klensin <klensin@jck.com>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1313440403; bh=/j3ko5f7LzDqMTo1dV5qeS7MVnz13mOYxFCzgHpv9wY=; h=MIME-version:Content-type:From:Cc:Message-id:Date:Subject: In-reply-to:References:To; b=RO9vvCy3wCbW8NdwkdGdRNEV0JrysWE4/lFIDaT9DHHDRnlR9bTTrRB5H7i16XRWw kXYFCvkIWxwNxXULkdidGR+Y/47HxJ1MV+RQWin1bcaHJs3yY5dZchfKOj1nD1i9+f UCDdd3NFaspxJPGWxrYVt9vKBrm1FT6DjuX9Wgj0=
Cc: Charles Lindsey <chl@clerew.man.ac.uk>, IMA <ima@ietf.org>
Subject: Re: [EAI] UTF-8 in Message-IDs
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Aug 2011 20:35:28 -0000

> Ned, Charles, and others,

> (strictly personal opinion)

> Let me give a different perspective on this, in the hope of
> drawing us together on the conclusions if not on the reasoning.

> I'm not (personally) wildly comfortable with unrestricted
> Message-IDs.  I don't find arguments based on "we chose this
> general model and therefore Message-IDs can't/shouldn't be
> restricted" persuasive,

That's good, because AFAIK nobody is making that argument. The argument we're
making is threefold:

(1) Because of structural issues in the RFC 5322 ABNF, it's much easier
    to make some changes to low-level rules than to try and add utf-8 at
    a higher leve. But one consequence of the low-level approach is that
    message-ids are also affected. This is fixable with a handful of
    additional rules that are still much cleaner and simpler than the
    higher level approach, but it's still something of a wart.

(2) An overwhemlming amount of deployed software generates message-ids by
    blindly appending @domain to some random string. A smaller but significant
    number also place some portion of the local part of the user's address
    on the left hand side. When domains and local parts start having
    utf-8 in them, the chances of all these code paths noticing and doing the
    right thing (which I suppose would be to encode it, but the encoding
    needs to be consistent or collisions are possible) are very, very low.
    So the issue of utf-8 in message-ids has to be faced and dealt with
    irrespective of what the standards say. 

(3) Most of the software that will be affected by utf-8 in message-ids is also
    going to be affected by utf-8 in addresses. (Actually, in most cases
    addresses present a much more difficult problem.) As long as you're prying
    the lid off, might as well deal with the issue a little more generally.

Given all this, the argument is we might as well bite the bullet and allow
it. Frankly, given how boundary markers are generated by some clients, I
think we're going to have enough fun dealing with that leakage case.

> precisely because we've said "protocol
> identifier" before and, IMO, our ability to say that is critical
> to getting any i18n design process right.  In particular, I note
> that we have not permitted non-ASCII characters in new/optional
> header field names by modifying RFC5322's <optional-field> to
> permit <ftext> to be a much less restricted range of characters.

That's because none of the arguments regarding message-ids apply to <ftext>.
<ftext> isn't affected by the ABNF changes, there's essentially no leakage from
domains or addresses into field names, and common code paths between field name
processing and address or message-id processing would seem to be ... unlikely.

> I think that it would be a mistake to make that extension
> (indeed, I personally think that we'd be much better off if
> <ftext> were restricted to ASCII letters, digits, and hyphen
> rather than excluding only non-printable characters and colon).
> But, if one argues that Message-ID has to be permitted to be
> non-ASCII because we've adopted a "UTF-8 nearly everywhere"
> model, the case for excluding field names has not been made (or
> even really discussed)... and a field name of, e.g.,
>    דרעקק: ...
> has a certain appeal (as well as some nightmare aspects).

See above.

> However, other arguments are much more persuasive to me, with
> the two critical ones being:

> 	(1) An MUA, or MTA pretending to be an MUA for message
> 	analysis purposes, that can handle non-ASCII UTF-8 in
> 	addresses or other header fields will need to go to very
> 	small marginal extra effort to handle a Message-ID with
> 	non-ASCII content.  Indeed, most sensible
> 	implementations would see a restriction that Message-IDs
> 	be ASCII as a requirement for added code to support an
> 	unnecessary requirement.    We have not had good luck
> 	with restrictions like that.

Another good point.

> 	(2) Given what we know about how Message-IDs are
> 	constructed in practice, we can expect non-ASCII forms
> 	to appear no matter what the spec says.  There is no
> 	point in writing a spec that we know will be ignored.
> 	For that reason, I think those arguing to restrict
> 	Message-IDs to ASCII need to come up with a clear,
> 	concise, and powerful explanation of why non-ASCII
> 	Message-IDs would be harmful -- an explanation that can
> 	be included in our documentation to persuade
> 	implementers that the requirement is really worth
> 	enforcing.

This is the second point above, more or less.

> To me, the "unnecessary requirement" and "will be ignored in
> practice" positions strongly suggest that the burden of
> demonstrating likely harm -- and producing that clear, concise,
> and powerful explanation-- falls on those who would like to keep
> Message-IDs ASCII-only.   If one believes in the "we adopted a
> different model" story, it just strengthens that position.

> In all of these discussions, I haven't seen that explanation
> emerge.

> I can think of one set of scenarios that might provide a
> foundation for it, even though I'm not convinced that they are
> strong enough to restrict Message-IDs.  The scenario goes
> somewhat like this (and parallels some of the discussion about
> message changes in Submission Servers).

> 	(1) Suppose I'm a user who receives a message.

> 	(2) Suppose I have an EAI-capable delivery MTA, message
> 	store, MUA, and whatever connects the MUA to the message
> 	store (i.e., none of the edge cases that are a headache
> 	for POP and IMAP apply).  Suppose the message I receive
> 	contains a non-ASCII Message-ID and very little other
> 	non-ASCII header field content.   As one example among
> 	many, suppose that only the contents of the Subject
> 	header field are non-ASCII (in addition to the
> 	Message-ID).

> 	(3) For simplification, suppose that my outgoing mail
> 	server's primary domain name does not contain any IDN
> 	components and Message-IDs I generate are all-ASCII.

> 	(4) Now I decide to reply to the originator (note that
> 	neither my address nor the address that appears in the
> 	"From:" header are non-ASCII).  I also add a recipient
> 	to the reply whose system is not EAI-capable (I know
> 	that from out of band information -- how is not
> 	important).   So, in addition to adding the additional
> 	address, I edit the Subject line so it is ASCII-only.
> 	(Remember this is a reply and I'm the user, so both of
> 	those changes are perfectly legitimate according to
> 	everything we've specified).

> Now there is a problem.

No, not really. Again, this work is premised on semantic-preserving downgrades
not being necessary. You are considering an odd corner case where were it not
for the utf-8 in the message-id, such a downgrade would be possible.

So what? If you really care about being able to send *any* subset of EAI
messages to non-EAI recipients without semantic loss, then this entire effort
is misdesigned: We should be using some 7-bit encoding scheme and not utf-8.

> An automatically-generated In-reply-to
> header field, generated as recommended in 5322 (unchanged in
> 5335bis) is going to contain that non-ASCII Message-ID.  That
> requires EAI handling (i.e., the UTF8SMTPbis extension) for the
> outgoing message even though the In-reply-to field is the only
> header field containing non-ASCII characters.  Given the
> scenario above, that makes the message non-deliverable to my
> intended new recipient.

> That is bad news... and bad news that could have been completely
> prevented by requiring that Message-IDs be restricted to ASCII.

Again, so what? We could send an even larger portion of those EAI messages to
the non-EAI recipient if we were to impose similar restrictions on addresses,
which we could easily do by using some other encoding of Unicode. And so on.
This logic puts you on a slippery slope that unavoidably leads to most of the
design decisions this group has made being wrong.

> The question, IMO, is whether cases of that type are likely to
> be prevalent enough to justify a restriction.  I contend that
> they are more than sufficient to justify some explanatory text
> and a recommendation that there are cases in which having a
> sending system be conservative enough to generate only all-ASCII
> Message-IDs will provide some marginal robustness against
> delivery rejections.  But I don't think it is nearly persuasive
> enough to justify an outright ban on non-ASCII Message-IDs.

Well, while I don't find your example here persuasive, I also don't have a
problem with saying utf-8 SHOULD NOT be used in message-ids. My guess is this
will have no more effect on utf-8 showing up there than an outright ban will,
but it's defensible recommendation.

				Ned

From ned+ima@mrochek.com  Mon Aug 15 13:58:14 2011
Return-Path: <ned+ima@mrochek.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29C5F11E8087 for <ima@ietfa.amsl.com>; Mon, 15 Aug 2011 13:58:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.468
X-Spam-Level: 
X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkOXhvHS7uz9 for <ima@ietfa.amsl.com>; Mon, 15 Aug 2011 13:58:13 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 654D011E8085 for <ima@ietf.org>; Mon, 15 Aug 2011 13:58:13 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O4VQXMRV2800ZIFM@mauve.mrochek.com> for ima@ietf.org; Mon, 15 Aug 2011 13:57:55 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O4CJSMR6GG00VHKR@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Mon, 15 Aug 2011 13:57:46 -0700 (PDT)
From: ned+ima@mrochek.com
Message-id: <01O4VQXIL46E00VHKR@mauve.mrochek.com>
Date: Mon, 15 Aug 2011 13:37:42 -0700 (PDT)
In-reply-to: "Your message dated Mon, 15 Aug 2011 21:13:38 +0200" <CAHhFybp6GNoCggfCbtCcmh0eqSHqD_=Z4rMZWrs_xticMDP5ow@mail.gmail.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <CAHhFybo47--0YjCRcvSO4asoV_R89+ULDB3tyij+ba=O_6gKsQ@mail.gmail.com> <01O4T11O8X4M00VHKR@mauve.mrochek.com> <CAHhFybp6GNoCggfCbtCcmh0eqSHqD_=Z4rMZWrs_xticMDP5ow@mail.gmail.com>
To: Frank Ellermann <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1313441769; bh=MWeVH9BM32pwPCgZ6fHIOZquNF3VNJVJ+fvd3h1oHek=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=FxMrCc+qV8oIeBwhoyGcRlFsWm2nqWcB67qd89FFOII5qYvveuQG5eotr0tRi3xgw o5/PI+PjnQQoPPc2Dmq02rat6Nv98VOCn7NLTpLpvLEeomFKFTye03Tswm7lqtsveM boZcRDk/sV/Kt5mijFn4DrbtvD6Ookf8AMynJaQs=
Cc: Ned Freed <ned.freed@mrochek.com>, ima@ietf.org
Subject: Re: [EAI] UTF-8 in Message-IDs
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Aug 2011 20:58:14 -0000

> Sorry, apparently I forgot the CC: to the list, resent:

> On 15 August 2011 17:19,  Ned Freed wrote:

> > I'll be the first to state that the approach being taken here is risky.
> > In fact I would never have chosen this approach myself. But that doesn't
> > change the fact that there's a consensus to proceed in this fashion.

> Maybe my original idea to start the whining in an IETF Last Call was not
> completely wrong, because I certainly missed whatever resulted in this
> consensus, and just *assumed* that EAI just moves on to "standards track",
> because the Internet at large obviously survived the EAI "experiment".

First of all, I don't think the EAI experiment showed us diddley-squat about
how the Internet "survived" EAI - it was much too small for that.

What the EAI experiment did show was that the original EAI approach, which
provided for message downgrade by including the information needed for
downgrade in each message, was unworkable. It's unworkable because people are
not going to spend the time to provide that information. And without that
information useful downgrading of message cannot occur.

In hindsight, this should have been obvious. Providing alternate addresses is
work that the originator needs to do but the direct benefits of that work only
accrue to the non-EAI recipient. As such, even assuming there weren't any UI
issues (and I'll bet there were), it should not be surprising that people were
unwilling/unable to do this.

Given that result, the options for moving forward boil down to either:

(1) Stop worrying about semantic-preserving downgrades in order to preserve
    the no-new-encodings goal the group has had from the start.

(2) Abandon the no-new-encodings goal. (In other words, the approach MIME
    took.)

I would have been a lot more comfortable with (2) personally, but the WG
consensus went the other way.

> In another mail you wrote about checking all Message-IDs in other RFCs:

> | Maybe, if we were taking the MIME approach, such a check would make
> | sense. But we're not doing that.

> That is rather disturbing for me, "not taking the MIME approach" is not
> something I'd consider.

Then your objection is to the WG's entire approach, and should have been
registered months or years ago when the group was rechartered and this 
direction was chosen.

And while I'm sympathetic to your position, I'm a lot more sympathetic to
not endless revisiting decisions we've already made.

In other words: You're much too late, and this is out of order.

> Apart from breaking the concept of Message-IDs
> without any immediately visible reasons after more than three decades,
> what else does it encompass?  Whatever it might be, shouldn't this be
> stated in 4952bis, preferably in upper case?

4952bis should already state that downgrades to non-EAI formats are not a
consideration, period. I don't mean to be overly dismissive, but against that
backdrop message-ids seem like extremely small beer.

> From my POV the A in IDNA means Applications, and the first I in IRI is
> not an U, no matter what XML or HTML5 say or wish.  E.g., if email users
> try to use a mailto:acsii@example?in-reply-to=mid link in a mailing list
> archive this is supposed to result in a message/rfc822 with an ordinary
> In-Reply-To header field, unless this user intentionally uses some EAI
> features.

> Message-IDs don't need to be "pretty" or "human readable" or something,
> their main point is to work as designed under almost all circumstances.

And once again I come back to: What about addresses? There's no downgrade
path for them either and they have a lot more immediate importance.

				Ned

From ned+ima@mrochek.com  Mon Aug 15 14:13:45 2011
Return-Path: <ned+ima@mrochek.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 157E821F8D1D for <ima@ietfa.amsl.com>; Mon, 15 Aug 2011 14:13:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.466
X-Spam-Level: 
X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTC8RAcVxNE5 for <ima@ietfa.amsl.com>; Mon, 15 Aug 2011 14:13:44 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 773AC21F8D19 for <ima@ietf.org>; Mon, 15 Aug 2011 14:13:44 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O4VRGTXIK000IEY1@mauve.mrochek.com> for ima@ietf.org; Mon, 15 Aug 2011 14:13:24 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O4CJSMR6GG00VHKR@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Mon, 15 Aug 2011 14:13:18 -0700 (PDT)
From: ned+ima@mrochek.com
Message-id: <01O4VRGRKZH800VHKR@mauve.mrochek.com>
Date: Mon, 15 Aug 2011 14:03:49 -0700 (PDT)
In-reply-to: "Your message dated Mon, 15 Aug 2011 21:29:36 +0200" <CAHhFybo9PxBHehzTxkwj+-bCNvGcc0A66vnhbXOJi3AssMOPdw@mail.gmail.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <C31E821E731AC23ED7EE191F@PST.JCK.COM> <20110815175214.4833.qmail@joyce.lan> <CAHhFybo9PxBHehzTxkwj+-bCNvGcc0A66vnhbXOJi3AssMOPdw@mail.gmail.com>
To: Frank Ellermann <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1313442699; bh=La819nA3PqJ64Gtit2J5AZk6ti11nCpSbWAbU11NNeA=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=V0wzvuVX+b8P6nM5q9xmkLYgH/z4pT7LndldS4+QEiVZJlgQkCCIOWBT5xPfPawPP S7+122EDJigfxENL6IgDYjEYkIvze86hbCM1NJU6b9RwJzD1wguRz0s58chk1ZyyZr +5zOrs0Ikxm7eqK7V39o3IQd9XZ7ZaJluvgt3sXw=
Cc: ima@ietf.org
Subject: Re: [EAI] UTF-8 in Message-IDs
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Aug 2011 21:13:45 -0000

> On 15 August 2011 19:52, John Levine <johnl@taugh.com> wrote:

> > I find the most compelling argument the one that there'll be UTF-8 in
> > message-ID's no matter what we say, so let's not specify something
> > that we expect implementors to get wrong.

> Why do you all say that implementors will get this simple point wrong,
> while you expect them to get far more convoluted syntax details right?

Because getting those convoluted syntax details right and getting the handling
of message-id wrong are how email code works today. It's all sunk costs, in
other words.

The addition of utf-8 to various syntactic elements isn't convoluted. In fact,
having looked at the impact on our code base, it's going to be pretty easy to
add.

The additional negotiation and failure handling code are more difficult, but it
all follows well established design patterns. When you get right down to it the
impact of EAI on MTAs isn't going to be that large. (MUAs are another story,
but because of addresses and other elements, not message-ids.)

> I don't see anything "compelling" in that line of reasoning, otherwise
> we could also say that using 8bit in DNS queries works, and therefore
> it's okay to use UTF-8 in host names (example).

Except that it doesn't - the DNS protocols may support 8-bit but there are
specific restrictions on host names that some deployed software honors. And if
this wasn't the case you'd probably hear exactly this argument being made.

				Ned

From klensin@jck.com  Mon Aug 15 14:22:02 2011
Return-Path: <klensin@jck.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8688D21F8D0E for <ima@ietfa.amsl.com>; Mon, 15 Aug 2011 14:22:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.578
X-Spam-Level: 
X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pd9+QGMTL-P for <ima@ietfa.amsl.com>; Mon, 15 Aug 2011 14:22:01 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 9260D21F8C63 for <ima@ietf.org>; Mon, 15 Aug 2011 14:22:01 -0700 (PDT)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Qt4cI-000AXy-Qc; Mon, 15 Aug 2011 17:22:39 -0400
Date: Mon, 15 Aug 2011 17:22:37 -0400
From: John C Klensin <klensin@jck.com>
To: Ned Freed <ned.freed@mrochek.com>
Message-ID: <619143DE42BB97B26A53920D@PST.JCK.COM>
In-Reply-To: <01O4VQ5BI2B200VHKR@mauve.mrochek.com>
References: <01O4VQ5BI2B200VHKR@mauve.mrochek.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: Charles Lindsey <chl@clerew.man.ac.uk>, IMA <ima@ietf.org>
Subject: Re: [EAI] UTF-8 in Message-IDs
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Aug 2011 21:22:02 -0000

Ned,

Let me try again with a note short enough that my conclusion and
intentions are not obscured (I think that happened the last
time; my apologies).

I think several of us have reasoned to the conclusion that, on
balance, Message-IDs should not be restricted to ASCII (in the
formal syntax or more generally).  Some of us find some of those
arguments more persuasive than others; others of us would choose
a different mix, but the conclusion is the same.

Given the multiple reasons for that conclusion; the apparent
consensus about it in email discussions before, during, and
after IETF 80; and the fairly general impression that an ASCII
restriction would be generally ignored because of the way
Message-IDs are often contructed, I believe that anyone who
continues to believe that non-ASCII Message-IDs should be
prohibited needs to persuasively demonstrate to the WG that they
would cause significant harm.

That demonstration has not appeared.  We can create edge cases
that show that messages with Message-IDs with non-ASCII content
are slightly less robust that Message-IDs that are ASCII-only,
but far more likely cases can be shown to demonstrate that
messages with only ASCII addresses are more robust than messages
that contain non-ASCII text in addresses, etc.  To go down that
path is to argue that any message with UTF-8 strings in _any_
header field is less robust than a corresponding message with
only ASCII in those fields.  While that is undoubtedly true, the
WG (and the IETF by issuing the WG a charter) have decided that
the advantages of having internationalized addressing and header
fields far exceed the disadvantages of that drop in robustness.
Moreover, the marginal drop due to non-ASCII Message-IDs alone
(once the risks of any non-ASCII material are accepted) appears
to be close to trivial... making a persuasive demonstration of
harm even less likely.

I urge Joseph to review the history of this discussion and then
close it out.

      john

p.s. As far as "SHOULD keep Message-IDs in ASCII" is concerned,
I could live with it but would actually oppose it.  The reasons
are implicit in the above, in your recent notes, and in other
recent discussions: (i) restrictions that we unlikely to be
obeyed are just bad for standards and (ii) to whatever extent
Message-IDs (including values in In-Reply-To and other fields)
are ever examined by humans, forcing id-right to use A-labels
for the most obvious and common cases is just inconsistent with
multiple design goals.  So I would prefer a bit of
implementation advice that points the issue out, not a
conformance statement.  YMMD but, if you agree even slightly,
let me try to draft a paragraph that we can then figure out
where to put.


--On Monday, August 15, 2011 10:32 -0700 Ned Freed
<ned.freed@mrochek.com> wrote:

>...
> That's good, because AFAIK nobody is making that argument. The
> argument we're making is threefold:
> 
> (1) Because of structural issues in the RFC 5322 ABNF, it's
> much easier     to make some changes to low-level rules than
> to try and add utf-8 at     a higher leve. But one consequence
>...


From ned+ima@mrochek.com  Mon Aug 15 19:30:35 2011
Return-Path: <ned+ima@mrochek.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D256521F8CA6 for <ima@ietfa.amsl.com>; Mon, 15 Aug 2011 19:30:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.465
X-Spam-Level: 
X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2R3-s-t1L2Sk for <ima@ietfa.amsl.com>; Mon, 15 Aug 2011 19:30:35 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 087AE21F8C8A for <ima@ietf.org>; Mon, 15 Aug 2011 19:30:35 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O4W2JPN06O0141CN@mauve.mrochek.com> for ima@ietf.org; Mon, 15 Aug 2011 19:30:16 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O4CJSMR6GG00VHKR@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Mon, 15 Aug 2011 19:30:09 -0700 (PDT)
From: ned+ima@mrochek.com
Message-id: <01O4W2JLCGQA00VHKR@mauve.mrochek.com>
Date: Mon, 15 Aug 2011 19:26:42 -0700 (PDT)
In-reply-to: "Your message dated Mon, 15 Aug 2011 17:22:37 -0400" <619143DE42BB97B26A53920D@PST.JCK.COM>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <01O4VQ5BI2B200VHKR@mauve.mrochek.com> <619143DE42BB97B26A53920D@PST.JCK.COM>
To: John C Klensin <klensin@jck.com>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1313461711; bh=MNCMnMKL6nonbQFnHKWkxItODqt7NYN23zy040AhBxg=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=pVVC4LS/y7PsyNfCQDnBPU/B9V7bkyB9zLweMSlnUG1Bdju0sPmJ3BDT0/rBhgQkx 017NYq+n2QPDqZuhZG4aNSiesys6gVjYcm7bJOSl/WfJiivgN3sU1ozMqywpGKpgyj xes/gssSAUVPkRO4MMwHJb6mDHMacbBTZIAWAaFM=
Cc: Charles Lindsey <chl@clerew.man.ac.uk>, Ned Freed <ned.freed@mrochek.com>, IMA <ima@ietf.org>
Subject: Re: [EAI] UTF-8 in Message-IDs
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Aug 2011 02:30:35 -0000

> Ned,

> Let me try again with a note short enough that my conclusion and
> intentions are not obscured (I think that happened the last
> time; my apologies).

No problem!

> I think several of us have reasoned to the conclusion that, on
> balance, Message-IDs should not be restricted to ASCII (in the
> formal syntax or more generally).  Some of us find some of those
> arguments more persuasive than others; others of us would choose
> a different mix, but the conclusion is the same.

I'm actually more concerned about this dragging out than which way it gets
decided.

> Given the multiple reasons for that conclusion; the apparent
> consensus about it in email discussions before, during, and
> after IETF 80; and the fairly general impression that an ASCII
> restriction would be generally ignored because of the way
> Message-IDs are often contructed, I believe that anyone who
> continues to believe that non-ASCII Message-IDs should be
> prohibited needs to persuasively demonstrate to the WG that they
> would cause significant harm.

My comment here is that harm has to be associated with operation inside the EAI
"zone". Downgrading issues don't count.

> That demonstration has not appeared.  We can create edge cases
> that show that messages with Message-IDs with non-ASCII content
> are slightly less robust that Message-IDs that are ASCII-only,
> but far more likely cases can be shown to demonstrate that
> messages with only ASCII addresses are more robust than messages
> that contain non-ASCII text in addresses, etc.  To go down that
> path is to argue that any message with UTF-8 strings in _any_
> header field is less robust than a corresponding message with
> only ASCII in those fields.  While that is undoubtedly true, the
> WG (and the IETF by issuing the WG a charter) have decided that
> the advantages of having internationalized addressing and header
> fields far exceed the disadvantages of that drop in robustness.
> Moreover, the marginal drop due to non-ASCII Message-IDs alone
> (once the risks of any non-ASCII material are accepted) appears
> to be close to trivial... making a persuasive demonstration of
> harm even less likely.

OK, now I see what you were getting at. Sorry for not seeing it the first
time.

> I urge Joseph to review the history of this discussion and then
> close it out.

+1

> p.s. As far as "SHOULD keep Message-IDs in ASCII" is concerned,
> I could live with it but would actually oppose it.  The reasons
> are implicit in the above, in your recent notes, and in other
> recent discussions: (i) restrictions that we unlikely to be
> obeyed are just bad for standards and (ii) to whatever extent
> Message-IDs (including values in In-Reply-To and other fields)
> are ever examined by humans, forcing id-right to use A-labels
> for the most obvious and common cases is just inconsistent with
> multiple design goals.  So I would prefer a bit of
> implementation advice that points the issue out, not a
> conformance statement.  YMMD but, if you agree even slightly,
> let me try to draft a paragraph that we can then figure out
> where to put.

I certainly can do that.

				Ned

From chl@clerew.man.ac.uk  Wed Aug 17 03:31:57 2011
Return-Path: <chl@clerew.man.ac.uk>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86D0921F8AFA for <ima@ietfa.amsl.com>; Wed, 17 Aug 2011 03:31:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.349
X-Spam-Level: 
X-Spam-Status: No, score=-4.349 tagged_above=-999 required=5 tests=[AWL=-0.902, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9r2eTWtTDr15 for <ima@ietfa.amsl.com>; Wed, 17 Aug 2011 03:31:56 -0700 (PDT)
Received: from outbound-queue-2.mail.thdo.gradwell.net (outbound-queue-2.mail.thdo.gradwell.net [212.11.70.35]) by ietfa.amsl.com (Postfix) with ESMTP id 207BD21F8AF0 for <ima@ietf.org>; Wed, 17 Aug 2011 03:31:55 -0700 (PDT)
Received: from outbound-edge-2.mail.thdo.gradwell.net (bonnie.gradwell.net [212.11.70.2]) by outbound-queue-2.mail.thdo.gradwell.net (Postfix) with ESMTP id 9240B220E7 for <ima@ietf.org>; Wed, 17 Aug 2011 11:32:45 +0100 (BST)
Received: from port-89.xxx.th.newnet.co.uk (HELO clerew.man.ac.uk) (80.175.135.89) (smtp-auth username postmaster%pop3.clerew.man.ac.uk, mechanism cram-md5) by outbound-edge-2.mail.thdo.gradwell.net (qpsmtpd/0.83) with (DES-CBC3-SHA encrypted) ESMTPSA; Wed, 17 Aug 2011 11:32:45 +0100
Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id p7HAWgYW013411 for <ima@ietf.org>; Wed, 17 Aug 2011 11:32:44 +0100 (BST)
Date: Wed, 17 Aug 2011 11:32:42 +0100
To: IMA <ima@ietf.org>
From: "Charles Lindsey" <chl@clerew.man.ac.uk>
Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1
MIME-Version: 1.0
References: <CAHhFybo47--0YjCRcvSO4asoV_R89+ULDB3tyij+ba=O_6gKsQ@mail.gmail.com> <01O4T11O8X4M00VHKR@mauve.mrochek.com> <op.vz8z3v0a6hl8nm@clerew.man.ac.uk> <01O4VFNKDGEE00VHKR@mauve.mrochek.com>
Content-Transfer-Encoding: 8bit
Message-ID: <op.v0cswsg76hl8nm@clerew.man.ac.uk>
In-Reply-To: <01O4VFNKDGEE00VHKR@mauve.mrochek.com>
User-Agent: Opera Mail/9.25 (SunOS)
X-Gradwell-MongoId: 4e4b98cd.48f3-3d50-2
X-Gradwell-Auth-Method: mailbox
X-Gradwell-Auth-Credentials: postmaster@pop3.clerew.man.ac.uk
Subject: Re: [EAI] UTF-8 in Message-IDs
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Aug 2011 10:31:57 -0000

On Mon, 15 Aug 2011 16:19:44 +0100, <ned+ima@mrochek.com> wrote:

>> On Sat, 13 Aug 2011 23:08:48 +0100, <ned+ima@mrochek.com> wrote:

>> Yes, but you have to consider all the other protocols using mail-like
>> formats and their use of the Message-ID.
>
> These protocols don't make use of email addresses?

Some do some don't. In Netnews they are not used except to reply to the  
author or an article by email.

>> For exmaple, if EAI were to be
>> carried over into Netnews (quite a likely development) it would NOT be
>> regarded as a "new message format" since the transport paths for Netnews
>> are already 8-bit clean and it would simply be necessary for those who
>> wish to take advantage of the new facilities to ensure that their user
>> agents were suitably upgraded. There will never be a need for
>> "downgrading" except at gateways back into the email system.
>
> And all netnews applications properly handle the construction and  
> display of
> utf-8 addresses in message headers? Just as one example, netnews already
> suports the proper form of Unicode normalization on input for this.  
> Right?

No. If you want to participate in newsgroups where strange characters are  
likely to be used, then you need to ensure your MUA has the necessary  
capability. That's your problem.
>
> An 8-bit clean transport is nowhere near sufficient to accomodate the  
> other
> changes to the format we're making here. Message ids are actually the  
> least of
> it since they are machine generated.

It is sufficient for the existing Netnews transport to deliver articles  
with utf-8 headers to participants; its their problem to get them  
displayed. The only two headers that are necessary in the transport layer  
are the Newsgroups header and the Message-ID. It has already been  
demonstrated that a Newsgroups header with utf-8 will be delivered  
correctly, but a standard would be needed to ensure proper normalization.  
The Message-ID is crucial to the correct operation of the Netnews  
transport, and the effect of using utf-8 in it has not been investigated  
(but should be). It is expected that some ancient transport agents might  
not like it but even that might not be a show stopper, since Netnews is  
very good at navigating around such obstacles.

> I'm sorry, but the entire approach of this WG is to define a format that  
> is NOT
> downgradeable to previous formats without substantial information loss.

Utter rubbish!

We are not designing a protocol that goes out of its way to make  
downgrading impossible. We are designing a protocol in which downgrading  
is not REQUIRED to be possible, but we should still avoid putting  
unnecessary obstacles in its way.

And, as I have said, in Netnews downgrading is not an issue (except at  
gateways out of Netnews).

Returning now to email, the Message-ID is only important when used in the  
References and In-Reply-To headers, where is is generally used by MUAs for  
threading purposes. So the worst that can happen if Message-IDs get  
garbled in transport is that threading fails to work.

My suggestion is that we retain a requirement that Message-ID remain in  
pure ASCII but add a remark that this position is likely to be reviewed in  
a future version of the standard.

If then, as is likely, they start to appear, then we will see how they  
cope and decide how best to regulate them in a future standard. In the  
meantime, they will do little harm. But when that future standard comes,  
it have to pay attention to exactly what sorts of things can appear in  
them (as indeed 5322 places quite a lot of restrictions) and, in addition,  
it will have to pay careful attention to normalization if threading it to  
continue to work.

And I don't think we want to go into that sort of detail at this present  
stage of our work.

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

From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com  Wed Aug 17 06:59:18 2011
Return-Path: <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33FEC21F85CE for <ima@ietfa.amsl.com>; Wed, 17 Aug 2011 06:59:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.353
X-Spam-Level: 
X-Spam-Status: No, score=-101.353 tagged_above=-999 required=5 tests=[AWL=-1.050, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, FRT_VALIUM2=2.643, FUZZY_VLIUM=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aU7LJMAYKYP4 for <ima@ietfa.amsl.com>; Wed, 17 Aug 2011 06:59:17 -0700 (PDT)
Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9CECA21F84F9 for <ima@ietf.org>; Wed, 17 Aug 2011 06:59:17 -0700 (PDT)
Received: by pzk33 with SMTP id 33so1937158pzk.18 for <ima@ietf.org>; Wed, 17 Aug 2011 07:00:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=kapFjIS/KDCPG+n0M8HmcjjgQvIXu6/19G+Krmv0NDE=; b=s6nFBLaZGlcCFtbhp1A5Qn1aRjrxKu7kUoScsgHq7+RaK/r21ZQFWwI6WWafjEuIiZ lp2/JskoOFQwy2IIV0PmDYZps0eJJcpLEdrhayWzC0MdsWWnGY50WIPG9g49cOylKgSv Qy4KFn3uXS/U00P3ObUivq+KhI9X6/Vd3v8E8=
Received: by 10.143.60.19 with SMTP id n19mr505462wfk.241.1313589607222; Wed, 17 Aug 2011 07:00:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.142.98.5 with HTTP; Wed, 17 Aug 2011 06:59:47 -0700 (PDT)
In-Reply-To: <op.v0cswsg76hl8nm@clerew.man.ac.uk>
References: <CAHhFybo47--0YjCRcvSO4asoV_R89+ULDB3tyij+ba=O_6gKsQ@mail.gmail.com> <01O4T11O8X4M00VHKR@mauve.mrochek.com> <op.vz8z3v0a6hl8nm@clerew.man.ac.uk> <01O4VFNKDGEE00VHKR@mauve.mrochek.com> <op.v0cswsg76hl8nm@clerew.man.ac.uk>
From: Frank Ellermann <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>
Date: Wed, 17 Aug 2011 15:59:47 +0200
Message-ID: <CAHhFybppBegPYo2Eh4BTMUGDy9+91z8d5E8LonopqqO_oeawFg@mail.gmail.com>
To: Charles Lindsey <chl@clerew.man.ac.uk>
Content-Type: text/plain; charset=ISO-8859-1
Cc: IMA <ima@ietf.org>
Subject: Re: [EAI] UTF-8 in Message-IDs
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Aug 2011 13:59:18 -0000

On 17 August 2011 12:32, Charles Lindsey wrote:

> Returning now to email, the Message-ID is only important when used in the
> References and In-Reply-To headers, where is is generally used by MUAs for
> threading purposes. So the worst that can happen if Message-IDs get garbled
> in transport is that threading fails to work.

That includes the cute mailto:list@example?In-Rreply-To=unique@example use
to get correct threading in replies to messages in list archives.  Covered
in RFC 6068 section 6.1 and AFAICT invented by "pipermail" many years ago.

Likewise RFC 5538 section 6 used a crystal ball to claim that whatever EAI
will do, it won't touch Message-IDs for the spectacle of a news URI turned
into a news IRI without anybody knowing what happened, and what consequences
it might have on NNTP servers.  RFC 3977 section 10.3 "outstanding issues"
discusses newsgroup names in its i18n considerations, and I think EAI uses
some ABNF from this RFC.  Its Message-ID concept could live without an "@",
but otherwise <A-NOTGT> is "ASCII excluding '>'".  RFC 5536 section 4 does
not mention that "there be dragons" wrt "prettier" Message-IDs, because it
is easier to change the syntax at a low level in EAI and see what happens.

-Frank

From ned+ima@mrochek.com  Wed Aug 17 07:02:04 2011
Return-Path: <ned+ima@mrochek.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D150F21F8549 for <ima@ietfa.amsl.com>; Wed, 17 Aug 2011 07:02:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.463
X-Spam-Level: 
X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrFtAspqcdIU for <ima@ietfa.amsl.com>; Wed, 17 Aug 2011 07:02:04 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADE921F8520 for <ima@ietf.org>; Wed, 17 Aug 2011 07:02:04 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O4Y4ZGCJ2O011HS5@mauve.mrochek.com> for ima@ietf.org; Wed, 17 Aug 2011 07:01:48 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O4CJSMR6GG00VHKR@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Wed, 17 Aug 2011 07:01:45 -0700 (PDT)
From: ned+ima@mrochek.com
Message-id: <01O4Y4ZEMLHG00VHKR@mauve.mrochek.com>
Date: Wed, 17 Aug 2011 06:54:56 -0700 (PDT)
In-reply-to: "Your message dated Wed, 17 Aug 2011 11:32:42 +0100" <op.v0cswsg76hl8nm@clerew.man.ac.uk>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=iso-8859-1; Format=flowed; DelSp=yes
References: <CAHhFybo47--0YjCRcvSO4asoV_R89+ULDB3tyij+ba=O_6gKsQ@mail.gmail.com> <01O4T11O8X4M00VHKR@mauve.mrochek.com> <op.vz8z3v0a6hl8nm@clerew.man.ac.uk> <01O4VFNKDGEE00VHKR@mauve.mrochek.com> <op.v0cswsg76hl8nm@clerew.man.ac.uk>
To: Charles Lindsey <chl@clerew.man.ac.uk>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1313589771; bh=meDQ032zJKzJLkVsH3MdVkUF7yOus1MIydt+obeZUck=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=FAyMv3vH+O5qyIkkxNj0mDj2jHIqvNNBAkaMFBTgrsOsM7zcO7ZMc6jDyt68MvBk0 HkLLc1HrT2Vn6fii7WoDrzQa6taF/rt5ycluaUFkinlIEKWJNFwsmBW29PPW/ZnFYq f7hIuDgwg6ifcRqkgm9Ldw8OyHaNVo5ySY5FRbpM=
Cc: IMA <ima@ietf.org>
Subject: Re: [EAI] UTF-8 in Message-IDs
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Aug 2011 14:02:04 -0000

> We are not designing a protocol that goes out of its way to make
> downgrading impossible. We are designing a protocol in which downgrading
> is not REQUIRED to be possible, but we should still avoid putting
> unnecessary obstacles in its way.

Funny, I don't see anything about that in the charter or any of the
current architecture descriptions.

> And, as I have said, in Netnews downgrading is not an issue (except at
> gateways out of Netnews).

Nor is support of netnews mentioned anywhere.

> Returning now to email, the Message-ID is only important when used in the
> References and In-Reply-To headers, where is is generally used by MUAs for
> threading purposes. So the worst that can happen if Message-IDs get
> garbled in transport is that threading fails to work.

> My suggestion is that we retain a requirement that Message-ID remain in
> pure ASCII but add a remark that this position is likely to be reviewed in
> a future version of the standard.

It is completely unrealistic to believe such a requirement will be honored,
for reasons already given.

> If then, as is likely, they start to appear, then we will see how they
> cope and decide how best to regulate them in a future standard. In the
> meantime, they will do little harm. But when that future standard comes,
> it have to pay attention to exactly what sorts of things can appear in
> them (as indeed 5322 places quite a lot of restrictions) and, in addition,
> it will have to pay careful attention to normalization if threading it to
> continue to work.

> And I don't think we want to go into that sort of detail at this present
> stage of our work.

Well, your position is noted.

				Ned

From chris.newman@oracle.com  Wed Aug 17 15:03:34 2011
Return-Path: <chris.newman@oracle.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1C8821F8A67 for <ima@ietfa.amsl.com>; Wed, 17 Aug 2011 15:03:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.945
X-Spam-Level: 
X-Spam-Status: No, score=-105.945 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ceoqAh0XYemZ for <ima@ietfa.amsl.com>; Wed, 17 Aug 2011 15:03:34 -0700 (PDT)
Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1896821F8ABD for <ima@ietf.org>; Wed, 17 Aug 2011 15:03:34 -0700 (PDT)
Received: from brmsunmail2-sfbay.uk.sun.com ([10.79.11.101]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id p7HM47ef025672 for <ima@ietf.org>; Wed, 17 Aug 2011 22:04:24 GMT
Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by brmsunmail2-sfbay.uk.sun.com (8.14.4+Sun/8.14.4/ENSMAIL, v2.4) with ESMTP id p7HM47IX036234 for <ima@ietf.org>; Wed, 17 Aug 2011 22:04:07 GMT
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-disposition: inline
Content-type: text/plain; CHARSET=US-ASCII; format=flowed
Received: from [10.145.239.205] (nifty-silver.us.oracle.com [10.145.239.205]) by gotmail.us.oracle.com (Oracle Communications Messaging Exchange Server 7u5-4.01 64bit (built May 4 2011)) with ESMTPA id <0LQ300H36EMTC700@gotmail.us.oracle.com> for ima@ietf.org; Wed, 17 Aug 2011 15:04:06 -0700 (PDT)
Date: Wed, 17 Aug 2011 15:04:04 -0700
From: Chris Newman <chris.newman@oracle.com>
To: ima@ietf.org
Message-id: <65FCFCB3127952ED27509706@96B2F16665FF96BAE59E9B90>
In-reply-to: <39219EF2FDAFC35947168EBC@96B2F16665FF96BAE59E9B90> <20110811065343.24089.49958.idtracker@ietfa.amsl.com>
References: <20110708012352.14365.62590.idtracker@ietfa.amsl.com> <39219EF2FDAFC35947168EBC@96B2F16665FF96BAE59E9B90>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-12.txt
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Aug 2011 22:03:35 -0000

I've reviewed revision -12 and find it acceptable except the ABNF does not 
allow UTF-8 in ESMTP parameter values. So we need:

   esmtp-value  =/  UTF8-non-ascii

added to the ABNF.

		- Chris


From chris.newman@oracle.com  Wed Aug 17 15:35:22 2011
Return-Path: <chris.newman@oracle.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C0F21F8A4E for <ima@ietfa.amsl.com>; Wed, 17 Aug 2011 15:35:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.874
X-Spam-Level: 
X-Spam-Status: No, score=-105.874 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJKdoBWuYnt8 for <ima@ietfa.amsl.com>; Wed, 17 Aug 2011 15:35:21 -0700 (PDT)
Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by ietfa.amsl.com (Postfix) with ESMTP id 595A321F8997 for <ima@ietf.org>; Wed, 17 Aug 2011 15:35:21 -0700 (PDT)
Received: from brmsunmail1-sfbay.uk.sun.com ([10.79.11.100]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id p7HMa9N5028383; Wed, 17 Aug 2011 22:36:13 GMT
Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by brmsunmail1-sfbay.uk.sun.com (8.14.4+Sun/8.14.4/ENSMAIL,v2.4) with ESMTP id p7HMa8iY019620; Wed, 17 Aug 2011 22:36:08 GMT
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-disposition: inline
Content-type: text/plain; CHARSET=US-ASCII; format=flowed
Received: from [10.145.239.205] (nifty-silver.us.oracle.com [10.145.239.205]) by gotmail.us.oracle.com (Oracle Communications Messaging Exchange Server 7u5-4.01 64bit (built May 4 2011)) with ESMTPA id <0LQ300H3CG45C700@gotmail.us.oracle.com>; Wed, 17 Aug 2011 15:36:07 -0700 (PDT)
Date: Wed, 17 Aug 2011 15:36:04 -0700
From: Chris Newman <chris.newman@oracle.com>
To: Frank Ellermann <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>, ima@ietf.org
Message-id: <18B1642B54C3604C98866093@96B2F16665FF96BAE59E9B90>
In-reply-to: <CAHhFybo47--0YjCRcvSO4asoV_R89+ULDB3tyij+ba=O_6gKsQ@mail.gmail.com>
References: <CAHhFybo47--0YjCRcvSO4asoV_R89+ULDB3tyij+ba=O_6gKsQ@mail.gmail.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
Subject: Re: [EAI] UTF-8 in Message-IDs
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Aug 2011 22:35:22 -0000

Thank you for raising this use case.

I believe a downgraded EAI message constitutes a "subsequent revision" as 
described in RFC 5322 section 3.6.4. Specifically, it is likely that 
attempts to reply to the author, sender and recipients of a downgraded EAI 
message will fail so it is a fundamentally different message. And thus it 
is important that it gets a new message id.

So perhaps we should change the advice in RFC5335bis to say:

  The Message-ID SHOULD include at least one UTF-8 character.

By including a UTF-8 character, any gateway to a non-EAI system will have 
to replace the Message-ID with a new one, thus correctly indicating that 
the resulting downgraded message is a subsequent revision. Systems wishing 
to identify the original EAI message id for a damaged downgraded message 
can look at the Downgraded-Message-ID header.

		- Chris

--On August 13, 2011 22:23:22 +0200 Frank Ellermann 
<hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com> wrote:

> Hi,
>
> looking for something else (= state of the art wrt EAI
> and SPF) yesterday I stumbled over the "81 IETF EAI
> meeting minutes" in the mailing list archive, with a
> note about "UTF-8 in Message-IDs".
>
> That was certainly (bad) news from my POV, and whining
> about it off list I got the tip that waiting for an
> IETF Last Call is a bad plan when this could be also
> addressed before WG Last Call.
>
>> From my POV the "globally unique forever Message-ID"
> in mail and news is in essence an early form of what
> is now a GUID/UUID in other protocols.  Maybe a bit
> more so, in theory there could be UUID collisions,
> and that's not possible for Message-IDs (in theory).
>
> This theory is relevant for NetNews, gateways from or
> to NetNews, mail and news threading, APOP, and likely
> other use cases I'm not aware of.
>
> Nobody would say replace hex. by UTF-8 in GUID/UUIDs,
> therefore I fail to see the point of trying something
> in this direction in Message-IDs.  Gateway operators
> stating that UTF-8 in Message-IDs would be no problem
> in practise, or that this would be only a minor point
> when they adopt EAI, might convince me that I'm only
> paranoid, but I doubt it.
>
> And the "EAI experiment" phase did not test this plan,
> there's no evidence I'm aware of that UTF-8 in Message-
> IDs is harmless.  Did you really check all RFCs using
> or mentioning Message-IDs for potential side-effects
> of introducing UTF-8 in the "local", "unique", "left"
> etc. part of a Message-ID?  E.g., does it fly with the
> Message-ID concept in APOP and CRAM-MD5, or do you
> intend something in the direction of "updates 2195"
> to make it work?
>
> -Frank
> _______________________________________________
> IMA mailing list
> IMA@ietf.org
> https://www.ietf.org/mailman/listinfo/ima
>





From klensin@jck.com  Wed Aug 17 16:16:09 2011
Return-Path: <klensin@jck.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A68D21F8A96 for <ima@ietfa.amsl.com>; Wed, 17 Aug 2011 16:16:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.575
X-Spam-Level: 
X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLTCUBHkBGvp for <ima@ietfa.amsl.com>; Wed, 17 Aug 2011 16:16:08 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 5188621F8A95 for <ima@ietf.org>; Wed, 17 Aug 2011 16:16:08 -0700 (PDT)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QtpM0-000AuE-QF; Wed, 17 Aug 2011 19:16:57 -0400
Date: Wed, 17 Aug 2011 19:16:55 -0400
From: John C Klensin <klensin@jck.com>
To: Chris Newman <chris.newman@oracle.com>, Frank Ellermann <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>, ima@ietf.org
Message-ID: <96FFE3C1B209E0FB349436D2@PST.JCK.COM>
In-Reply-To: <18B1642B54C3604C98866093@96B2F16665FF96BAE59E9B90>
References: <CAHhFybo47--0YjCRcvSO4asoV_R89+ULDB3tyij+ba=O_6gKsQ@mail.gmail.com> <18B1642B54C3604C98866093@96B2F16665FF96BAE59E9B90>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Subject: Re: [EAI] UTF-8 in Message-IDs
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Aug 2011 23:16:09 -0000

--On Wednesday, August 17, 2011 15:36 -0700 Chris Newman
<chris.newman@oracle.com> wrote:

>...
>   The Message-ID SHOULD include at least one UTF-8 character.
> 
> By including a UTF-8 character, any gateway to a non-EAI
> system will have to replace the Message-ID with a new one,
> thus correctly indicating that the resulting downgraded
> message is a subsequent revision. Systems wishing to identify
> the original EAI message id for a damaged downgraded message
> can look at the Downgraded-Message-ID header.

Chris, while I agree with your analysis of "subsequent
revision", I don't get from their to your conclusion for two
reasons:

(1) Other than in the POP/IMAP downgrade path, there is no such
thing as a Downgraded-Message-ID header.   One can imagine a
number of scenarios that would involve a need to send a message
back out in ASCII-only form that do not involve that header or
any downgrading we are going to specify.  Note especially that
the user generating a reply may have sufficient out of band
information available to supply deliverable addresses for some
or all of the author, sender and recipients of the message as
appropriate.

(2) Per one of my examples of some days ago, if we allow UTF-8
in Message-IDs at all, it is quite possible to have a message
that requires UTF8SMTPbis extension handling but that contains
no non-ASCII data in either header fields or addresses other
than that UTF-8 Message-ID.  Indeed, one interpretation of the
statement you suggest above virtually guarantees a lot of
messages of that type (probably it can be rewritten to reduce
the number, but that doesn't change things much).  Now we have
an interesting problem: the message is reply-able (and, more
important, forward-able without creating a message/global body
part) and new recipients with all-ASCII addresses can be added.
Certainly in the forwarding case, there is no "subsequent
revision".   It can be handled strictly as a legacy message
except for that pesky Message-ID.  And, again, except for
replacing or otherwise dealing with the Message-ID, there is no
need to downgrade anything.

As I've said before, I don't think those scenarios (including
Frank's) are adequate to make a case for a protocol restriction
to ASCII.  I think they are sufficient to justify a
recommendation that systems sending mail into environments they
consider fragile should confine themselves to ASCII message
ID's.  Requiring non-ASCII characters in Message-IDs would not
only defeat that recommendation, it would run counter to the
core of the "if we tell them ASCII-only, they will ignore us"
observation that Ned, I, and others have been making.  

To review that observation (at least my version), MUAs have ways
to construct Message-IDs, usually by cramming some local
information and a domain name together.  For all sorts of
reasons, they are likely to continue doing whatever they are
doing, using a domain name with U-labels in it if they consider
such a domain name primary.  If we ask them to do anything else,
it is going to create a requirement for extra code and extra
work -- whether that be converting the domain name to use
U-labels or to artificially add a non-ASCII character because
some other header field contains at least one non-ASCII
character.  We can provide them very little motivation for doing
that other than the WG's exploration of transition cases and
edge cases.  Experience indicates that extra work, especially
extra work that creates additional code paths, with no even
slightly compelling motivation, translates into an unimplemented
requirement.

(personal opinion only)
    john





From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com  Wed Aug 17 16:20:38 2011
Return-Path: <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7C621F8B9B for <ima@ietfa.amsl.com>; Wed, 17 Aug 2011 16:20:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.734
X-Spam-Level: 
X-Spam-Status: No, score=-102.734 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3iX3l882Jltk for <ima@ietfa.amsl.com>; Wed, 17 Aug 2011 16:20:38 -0700 (PDT)
Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id F22B121F8B98 for <ima@ietf.org>; Wed, 17 Aug 2011 16:20:37 -0700 (PDT)
Received: by pzk33 with SMTP id 33so3093264pzk.18 for <ima@ietf.org>; Wed, 17 Aug 2011 16:21:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=6P8JoLJwj7CHXWT6UOw36gBPgcPJSobP7UF0FlWIq3E=; b=okYpMHMkl1F+i5h39vMJeSr5x4KLf6jJuZv+BRaVSqXQ7UyW/EJk19JjPTz8SyTB5p ARU73UMiNk+wzX15RkMufoSmmUbpZ+Rcm+nRhTPyJOOUUDk3hxuIx1vem3qgw17psgw7 eE0myrJ/oe/aR8toD6aUGZfYu1AvgKBst6i48=
Received: by 10.142.229.11 with SMTP id b11mr28595wfh.13.1313623290205; Wed, 17 Aug 2011 16:21:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.142.98.5 with HTTP; Wed, 17 Aug 2011 16:21:10 -0700 (PDT)
In-Reply-To: <65FCFCB3127952ED27509706@96B2F16665FF96BAE59E9B90>
References: <20110708012352.14365.62590.idtracker@ietfa.amsl.com> <39219EF2FDAFC35947168EBC@96B2F16665FF96BAE59E9B90> <20110811065343.24089.49958.idtracker@ietfa.amsl.com> <65FCFCB3127952ED27509706@96B2F16665FF96BAE59E9B90>
From: Frank Ellermann <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>
Date: Thu, 18 Aug 2011 01:21:10 +0200
Message-ID: <CAHhFybox+zBiMZJD+SPWKQ6emVAxvomGqsJ7Sw7J5zODwNnTZg@mail.gmail.com>
To: IMA <ima@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-12.txt
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Aug 2011 23:20:38 -0000

On 18 August 2011 00:04, Chris Newman wrote:

> So we need:

> =A0esmtp-value =A0=3D/ =A0UTF8-non-ascii

> added to the ABNF.

My personal EAI 2011 experiment, can I grok what folks are talking
about if it is not related to Message-IDs...

RFC 5321 says that <esmtp-value> follows the RFC 3461 <xtext> syntax
for addresses, and I-D.eai-rfc5337bis specifies <utf-8-addr-xtext>
for this job.  That is hex. encoded UTF-8, or in other words ASCII.

With <UTF8-non-ascii> in <esmtp-value> that has (obviously) to be
limited to states when UTF8SMTPbis is already negotiated.  And if
that is the case using <utf-8-addr-xtext> outside of ORCPT could be
confusing.  If it is not only me who is confused, please add also
an explanation in I-D.eai-rfc5336bis when you update <esmtp-value>.

Examples in the direction of "do this if outside of UTF8SMTPbis" vs.
"do that in UTF8SMTPbis" maybe followed by a BUT for ORCPT could be
good.

-Frank

From healthyao@gmail.com  Wed Aug 17 23:42:50 2011
Return-Path: <healthyao@gmail.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC88511E8098 for <ima@ietfa.amsl.com>; Wed, 17 Aug 2011 23:42:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.843
X-Spam-Level: 
X-Spam-Status: No, score=-1.843 tagged_above=-999 required=5 tests=[AWL=0.003,  BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mm5sEJuFfpJ0 for <ima@ietfa.amsl.com>; Wed, 17 Aug 2011 23:42:50 -0700 (PDT)
Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 867095E8002 for <ima@ietf.org>; Wed, 17 Aug 2011 23:42:50 -0700 (PDT)
Received: by pzk33 with SMTP id 33so4032937pzk.18 for <ima@ietf.org>; Wed, 17 Aug 2011 23:43:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; bh=m8ysx0hAEWDRcMhZ6W7wBqMMA0Y7dty61qEc2jbPlfU=; b=oXynCR58Mh0AG/zT2IK/9SIqXAuO1zdWXK4q0FuRXY54Hsgh/jGh+LN6X/bUgSvNIf fon43pf/IFW4jtX9bRW+jjEPptOevc4Ru37Zk7rc+8iJ7XliFeZ/22E/ji5X7WDkp83P CZ2SO9Fv+wkap744OWIFzoiOzX4ogzEPKeCto=
Received: by 10.142.200.3 with SMTP id x3mr234460wff.9.1313649823695; Wed, 17 Aug 2011 23:43:43 -0700 (PDT)
Received: from LENOVO47E041CF ([218.241.111.35]) by mx.google.com with ESMTPS id c4sm1228939pbe.80.2011.08.17.23.43.40 (version=SSLv3 cipher=OTHER); Wed, 17 Aug 2011 23:43:41 -0700 (PDT)
Message-ID: <DA986D019DE544E08E1FFC289FE7FA1E@LENOVO47E041CF>
From: "Jiankang Yao" <healthyao@gmail.com>
To: "Chris Newman" <chris.newman@oracle.com>, <ima@ietf.org>
References: <20110708012352.14365.62590.idtracker@ietfa.amsl.com><39219EF2FDAFC35947168EBC@96B2F16665FF96BAE59E9B90> <513618674.27765@cnnic.cn>
Date: Thu, 18 Aug 2011 14:43:37 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: base64
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-12.txt
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Aug 2011 06:42:51 -0000

DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkNocmlzIE5ld21hbiIgPGNo
cmlzLm5ld21hbkBvcmFjbGUuY29tPg0KVG86IDxpbWFAaWV0Zi5vcmc+DQpTZW50OiBUaHVyc2Rh
eSwgQXVndXN0IDE4LCAyMDExIDY6MDQgQU0NClN1YmplY3Q6IFJlOiBbRUFJXSBJLUQgQWN0aW9u
OiBkcmFmdC1pZXRmLWVhaS1yZmM1MzM2YmlzLTEyLnR4dA0KDQoNCj4gSSd2ZSByZXZpZXdlZCBy
ZXZpc2lvbiAtMTIgYW5kIGZpbmQgaXQgYWNjZXB0YWJsZSANCj4NCg0KdGhhbmtzIGEgbG90IGZv
ciB5b3VyIGtpbmQgcmV2aWV3Lg0KDQo+DQo+ZXhjZXB0IHRoZSBBQk5GIGRvZXMgbm90IA0KPiBh
bGxvdyBVVEYtOCBpbiBFU01UUCBwYXJhbWV0ZXIgdmFsdWVzLiBTbyB3ZSBuZWVkOg0KPiANCj4g
ICBlc210cC12YWx1ZSAgPS8gIFVURjgtbm9uLWFzY2lpDQo+IA0KPiBhZGRlZCB0byB0aGUgQUJO
Ri4NCj4gDQoNCklmIHlvdXIgcHJvcG9zZWQgZXNtdHAtdmFsdWUgc3ludGF4IGV4dGVuc2lvbiBp
biByZmM1MzM2YmlzICBpcyB1c2VkIGZvciBPUkNQVCBpbiBEU04sIHRoZW4gDQpSRkM1MzM2Ymlz
IGhhcyBhbHJlYWR5IHNhaWQgIg0KICAgSWYgYSBVVEY4U01UUGJpcy1hd2FyZSBTTVRQIHNlcnZl
ciBhZHZlcnRpc2VzIHRoZSBEZWxpdmVyeSBTdGF0dXMNCiAgIE5vdGlmaWNhdGlvbiAoRFNOKSBb
UkZDMzQ2MV0gZXh0ZW5zaW9uLCBpdCBNVVNUIGltcGxlbWVudA0KICAgW1JGQzUzMzdiaXNdLg0K
Ig0KDQpEb2VzIGl0IHNhdGlzZnkgeW91ciBleHBlY3RhdGlvbj8NCg0KSSBhbHNvIGxpa2UgdG8g
aGVhciB5b3VyIGNvbW1lbnRzIHRvIEZyYW5rIEVsbGVybWFubidzIGNvbW1lbnRzIHRvIHRoaXMg
aXNzdWUuDQoNCnRoYW5rcyBhIGxvdC4NCg0KSmlhbmthbmcgWWFvDQo+DQo+IC0gQ2hyaXMNCj4g
DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IElN
QSBtYWlsaW5nIGxpc3QNCj4gSU1BQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vaW1h


From chl@clerew.man.ac.uk  Thu Aug 18 08:33:27 2011
Return-Path: <chl@clerew.man.ac.uk>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1858821F8BD3 for <ima@ietfa.amsl.com>; Thu, 18 Aug 2011 08:33:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.304
X-Spam-Level: 
X-Spam-Status: No, score=-4.304 tagged_above=-999 required=5 tests=[AWL=-0.857, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4+JeBfBCHRJ for <ima@ietfa.amsl.com>; Thu, 18 Aug 2011 08:33:26 -0700 (PDT)
Received: from outbound-queue-2.mail.thdo.gradwell.net (outbound-queue-2.mail.thdo.gradwell.net [212.11.70.35]) by ietfa.amsl.com (Postfix) with ESMTP id 5BDEE21F8B8C for <ima@ietf.org>; Thu, 18 Aug 2011 08:33:22 -0700 (PDT)
Received: from outbound-edge-2.mail.thdo.gradwell.net (bonnie.gradwell.net [212.11.70.2]) by outbound-queue-2.mail.thdo.gradwell.net (Postfix) with ESMTP id 9099C21E6F for <ima@ietf.org>; Thu, 18 Aug 2011 16:34:15 +0100 (BST)
Received: from port-89.xxx.th.newnet.co.uk (HELO clerew.man.ac.uk) (80.175.135.89) (smtp-auth username postmaster%pop3.clerew.man.ac.uk, mechanism cram-md5) by outbound-edge-2.mail.thdo.gradwell.net (qpsmtpd/0.83) with (DES-CBC3-SHA encrypted) ESMTPSA; Thu, 18 Aug 2011 16:34:15 +0100
Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id p7IFYCcf021183 for <ima@ietf.org>; Thu, 18 Aug 2011 16:34:14 +0100 (BST)
Date: Thu, 18 Aug 2011 16:34:12 +0100
To: IMA <ima@ietf.org>
From: "Charles Lindsey" <chl@clerew.man.ac.uk>
Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1
MIME-Version: 1.0
References: <CAHhFybo47--0YjCRcvSO4asoV_R89+ULDB3tyij+ba=O_6gKsQ@mail.gmail.com> <18B1642B54C3604C98866093@96B2F16665FF96BAE59E9B90>
Content-Transfer-Encoding: 8bit
Message-ID: <op.v0e1jadu6hl8nm@clerew.man.ac.uk>
In-Reply-To: <18B1642B54C3604C98866093@96B2F16665FF96BAE59E9B90>
User-Agent: Opera Mail/9.25 (SunOS)
X-Gradwell-MongoId: 4e4d30f7.afda-5070-2
X-Gradwell-Auth-Method: mailbox
X-Gradwell-Auth-Credentials: postmaster@pop3.clerew.man.ac.uk
Subject: Re: [EAI] UTF-8 in Message-IDs
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Aug 2011 15:33:27 -0000

On Wed, 17 Aug 2011 23:36:04 +0100, Chris Newman <chris.newman@oracle.com>  
wrote:

> Thank you for raising this use case.
>
> I believe a downgraded EAI message constitutes a "subsequent revision"  
> as described in RFC 5322 section 3.6.4. Specifically, it is likely that  
> attempts to reply to the author, sender and recipients of a downgraded  
> EAI message will fail so it is a fundamentally different message. And  
> thus it is important that it gets a new message id.
>
> So perhaps we should change the advice in RFC5335bis to say:
>
>   The Message-ID SHOULD include at least one UTF-8 character.

Absolutely NO-WAY!

If a message is evidently the SAME message, even though different  
recipients may encounter it in slightly different forms (possibly  
dowgreaded, possibly garbled, but still with the majority of it readable)  
then it MUST have the same Message-ID.

So if, by some complex rerouting, encapsulating, forwarding, someone  
manages to acquire copies of it in both forms, it will be clear it is the  
same (e.g. it will not need to be replied to twice, and in any threaded  
list both will appear together with the same parents and same children).

An essential property of <msg-id>s, which we managed to achieve during the  
discussions that lead to RFC 5322, is that two <msg-id>s can be compared  
for equality by a simnple byte-for-byte comparison. Threading algorithms  
need to rely on this, and within Netnews the same property is essential  
for the transport mechanism to sork (even if the transport proceeds by  
gatewaying into email and then nack into Netnews).

Therefore, IF we are going to permit utf-8 in <msg-id>s, then it is  
essential to include sufficient mandatory requirements on Normalization,  
and to scrutinize the set of allowed characters for troublesome cases. If  
this WG is prepared to put in the work to do then, then well and good, and  
I will support it.

But otherwise, please count me as OPPOSED.

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

From chris.newman@oracle.com  Fri Aug 19 14:13:09 2011
Return-Path: <chris.newman@oracle.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 176F811E80CD for <ima@ietfa.amsl.com>; Fri, 19 Aug 2011 14:13:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.253
X-Spam-Level: 
X-Spam-Status: No, score=-105.253 tagged_above=-999 required=5 tests=[AWL=-0.603, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Id9411YWWIId for <ima@ietfa.amsl.com>; Fri, 19 Aug 2011 14:13:08 -0700 (PDT)
Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by ietfa.amsl.com (Postfix) with ESMTP id 99F0011E80B1 for <ima@ietf.org>; Fri, 19 Aug 2011 14:13:08 -0700 (PDT)
Received: from brmsunmail2-sfbay.uk.sun.com ([10.79.11.101]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id p7JLE4H9003975; Fri, 19 Aug 2011 21:14:04 GMT
Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by brmsunmail2-sfbay.uk.sun.com (8.14.4+Sun/8.14.4/ENSMAIL,v2.4) with ESMTP id p7JLE3dX011710; Fri, 19 Aug 2011 21:14:04 GMT
MIME-version: 1.0
Content-disposition: inline
Content-type: text/plain; charset=utf-8; format=flowed
Received: from [10.159.44.76] (dhcp-rmdc-twvpn-2-vpnpool-10-159-53-10.vpn.oracle.com [10.159.53.10]) by gotmail.us.oracle.com (Oracle Communications Messaging Exchange Server 7u5-4.01 64bit (built May 4 2011)) with ESMTPA id <0LQ7006341ND1W00@gotmail.us.oracle.com>; Fri, 19 Aug 2011 14:14:03 -0700 (PDT)
Date: Fri, 19 Aug 2011 14:14:01 -0700
From: Chris Newman <chris.newman@oracle.com>
To: Frank Ellermann <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>, IMA <ima@ietf.org>
Message-id: <C9A3FCAB6F726EE4A8C093A9@96B2F16665FF96BAE59E9B90>
In-reply-to: <CAHhFybox+zBiMZJD+SPWKQ6emVAxvomGqsJ7Sw7J5zODwNnTZg@mail.gmail.com>
References: <20110708012352.14365.62590.idtracker@ietfa.amsl.com> <39219EF2FDAFC35947168EBC@96B2F16665FF96BAE59E9B90> <20110811065343.24089.49958.idtracker@ietfa.amsl.com> <65FCFCB3127952ED27509706@96B2F16665FF96BAE59E9B90> <CAHhFybox+zBiMZJD+SPWKQ6emVAxvomGqsJ7Sw7J5zODwNnTZg@mail.gmail.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
Content-transfer-encoding: quoted-printable
Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-12.txt
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Aug 2011 21:13:09 -0000

--On August 18, 2011 1:21:10 +0200 Frank Ellermann=20
<hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com> wrote:

> On 18 August 2011 00:04, Chris Newman wrote:
>
>> So we need:
>
>> =C2=A0esmtp-value =C2=A0=3D/ =C2=A0UTF8-non-ascii
>
>> added to the ABNF.
>
> My personal EAI 2011 experiment, can I grok what folks are talking
> about if it is not related to Message-IDs...
>
> RFC 5321 says that <esmtp-value> follows the RFC 3461 <xtext> syntax
> for addresses, and I-D.eai-rfc5337bis specifies <utf-8-addr-xtext>
> for this job.  That is hex. encoded UTF-8, or in other words ASCII.

That comment in 5321 is confusing and unnecessary. If we were to ever=20
revise 5321, I'd support removing it.

The "utf-8-addr-xtext" in RFC 5337 has a misleading name as it is unrelated =

to the 3461 xtext construction. I suggested renaming it to=20
"utf-8-addr-7bit" in 5337bis (on July 28).

> With <UTF8-non-ascii> in <esmtp-value> that has (obviously) to be
> limited to states when UTF8SMTPbis is already negotiated.  And if
> that is the case using <utf-8-addr-xtext> outside of ORCPT could be
> confusing.  If it is not only me who is confused, please add also
> an explanation in I-D.eai-rfc5336bis when you update <esmtp-value>.

I see no confusion on this matter in 5336bis. When UTF8SMTPbis is=20
negotiated, the ABNF in 5335bis/5336bis applies. When it is not negotiated, =

the ABNF in 5321/5322 applies.

> Examples in the direction of "do this if outside of UTF8SMTPbis" vs.
> "do that in UTF8SMTPbis" maybe followed by a BUT for ORCPT could be
> good.

5336bis has to describe what is allowed in ESMTP parameter values when=20
UTF8SMTPbis is negotiated. But discussion of what goes in ORCPT belongs in=20
RFC 5337bis.

		- Chris


From chris.newman@oracle.com  Fri Aug 19 14:20:53 2011
Return-Path: <chris.newman@oracle.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD81C11E80D7 for <ima@ietfa.amsl.com>; Fri, 19 Aug 2011 14:20:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.922
X-Spam-Level: 
X-Spam-Status: No, score=-105.922 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7olaBJe2UDIY for <ima@ietfa.amsl.com>; Fri, 19 Aug 2011 14:20:53 -0700 (PDT)
Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by ietfa.amsl.com (Postfix) with ESMTP id 5363411E80EB for <ima@ietf.org>; Fri, 19 Aug 2011 14:20:52 -0700 (PDT)
Received: from brmsunmail1-sfbay.uk.sun.com ([10.79.11.100]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id p7JLLk2f003341; Fri, 19 Aug 2011 21:21:46 GMT
Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by brmsunmail1-sfbay.uk.sun.com (8.14.4+Sun/8.14.4/ENSMAIL,v2.4) with ESMTP id p7JLLk4H025914; Fri, 19 Aug 2011 21:21:46 GMT
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-disposition: inline
Content-type: text/plain; CHARSET=US-ASCII; format=flowed
Received: from [10.159.44.76] (dhcp-rmdc-twvpn-2-vpnpool-10-159-53-10.vpn.oracle.com [10.159.53.10]) by gotmail.us.oracle.com (Oracle Communications Messaging Exchange Server 7u5-4.01 64bit (built May 4 2011)) with ESMTPA id <0LQ7006372081W00@gotmail.us.oracle.com>; Fri, 19 Aug 2011 14:21:45 -0700 (PDT)
Date: Fri, 19 Aug 2011 14:21:44 -0700
From: Chris Newman <chris.newman@oracle.com>
To: Jiankang Yao <healthyao@gmail.com>, ima@ietf.org
Message-id: <54FDC38939FFB9E2DB2DE21B@96B2F16665FF96BAE59E9B90>
In-reply-to: <DA986D019DE544E08E1FFC289FE7FA1E@LENOVO47E041CF>
References: <20110708012352.14365.62590.idtracker@ietfa.amsl.com> <39219EF2FDAFC35947168EBC@96B2F16665FF96BAE59E9B90> <513618674.27765@cnnic.cn> <DA986D019DE544E08E1FFC289FE7FA1E@LENOVO47E041CF>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-12.txt
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Aug 2011 21:20:53 -0000

--On August 18, 2011 14:43:37 +0800 Jiankang Yao <healthyao@gmail.com> 
wrote:
> ----- Original Message -----
> From: "Chris Newman" <chris.newman@oracle.com>
> To: <ima@ietf.org>
> Sent: Thursday, August 18, 2011 6:04 AM
> Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-12.txt
...
>>
>> except the ABNF does not
>> allow UTF-8 in ESMTP parameter values. So we need:
>>
>>   esmtp-value  =/  UTF8-non-ascii
>>
>> added to the ABNF.
>>
>
> If your proposed esmtp-value syntax extension in rfc5336bis  is used for
> ORCPT in DSN, then  RFC5336bis has already said "
>    If a UTF8SMTPbis-aware SMTP server advertises the Delivery Status
>    Notification (DSN) [RFC3461] extension, it MUST implement
>    [RFC5337bis].
> "
>
> Does it satisfy your expectation?

That creates a contradiction. RFC 5337bis discusses using UTF-8 in the 
ORCPT parameter value, but 5336bis ABNF presently disallows use of UTF-8 in 
ESMTP parameter values. We can make the specifications consistent by 
allowing UTF-8 in ESMTP parameter values.

> I also like to hear your comments to Frank Ellermann's comments to this
> issue.

See separate message.

		- Chris


From alexey.melnikov@isode.com  Sat Aug 20 10:35:19 2011
Return-Path: <alexey.melnikov@isode.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 112A621F876A for <ima@ietfa.amsl.com>; Sat, 20 Aug 2011 10:35:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.799
X-Spam-Level: 
X-Spam-Status: No, score=-102.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjKnFbyBw7dy for <ima@ietfa.amsl.com>; Sat, 20 Aug 2011 10:35:18 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id E1C0D21F884C for <ima@ietf.org>; Sat, 20 Aug 2011 10:35:17 -0700 (PDT)
Received: from [188.29.11.66] (188.29.11.66.threembb.co.uk [188.29.11.66])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <Tk=wjAALhGmo@rufus.isode.com>; Sat, 20 Aug 2011 18:36:15 +0100
Message-ID: <4E4FF07C.7070407@isode.com>
Date: Sat, 20 Aug 2011 18:35:56 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
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: Chris Newman <chris.newman@oracle.com>
References: <20110708012352.14365.62590.idtracker@ietfa.amsl.com> <39219EF2FDAFC35947168EBC@96B2F16665FF96BAE59E9B90> <513618674.27765@cnnic.cn> <DA986D019DE544E08E1FFC289FE7FA1E@LENOVO47E041CF> <54FDC38939FFB9E2DB2DE21B@96B2F16665FF96BAE59E9B90>
In-Reply-To: <54FDC38939FFB9E2DB2DE21B@96B2F16665FF96BAE59E9B90>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: ima@ietf.org, Jiankang Yao <healthyao@gmail.com>
Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-12.txt
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Aug 2011 17:35:19 -0000

Chris Newman wrote:

> --On August 18, 2011 14:43:37 +0800 Jiankang Yao <healthyao@gmail.com> 
> wrote:
>
>> ----- Original Message -----
>> From: "Chris Newman" <chris.newman@oracle.com>
>> To: <ima@ietf.org>
>> Sent: Thursday, August 18, 2011 6:04 AM
>> Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-12.txt
>
> ...
>
>>> except the ABNF does not
>>> allow UTF-8 in ESMTP parameter values. So we need:
>>>
>>>   esmtp-value  =/  UTF8-non-ascii
>>>
>>> added to the ABNF.
>>
>> If your proposed esmtp-value syntax extension in rfc5336bis  is used for
>> ORCPT in DSN, then  RFC5336bis has already said "
>>    If a UTF8SMTPbis-aware SMTP server advertises the Delivery Status
>>    Notification (DSN) [RFC3461] extension, it MUST implement
>>    [RFC5337bis].
>> "
>>
>> Does it satisfy your expectation?
>
> That creates a contradiction. RFC 5337bis discusses using UTF-8 in the 
> ORCPT parameter value, but 5336bis ABNF presently disallows use of 
> UTF-8 in ESMTP parameter values. We can make the specifications 
> consistent by allowing UTF-8 in ESMTP parameter values.

Good point. I support your proposal.


From dhc@dcrocker.net  Sat Aug 20 12:03:43 2011
Return-Path: <dhc@dcrocker.net>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5920721F8744 for <ima@ietfa.amsl.com>; Sat, 20 Aug 2011 12:03:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.315
X-Spam-Level: 
X-Spam-Status: No, score=-6.315 tagged_above=-999 required=5 tests=[AWL=0.283,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNErQdPJUO1h for <ima@ietfa.amsl.com>; Sat, 20 Aug 2011 12:03:42 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id A97E321F86C7 for <ima@ietf.org>; Sat, 20 Aug 2011 12:03:42 -0700 (PDT)
Received: from [192.168.1.7] (adsl-68-122-69-114.dsl.pltn13.pacbell.net [68.122.69.114]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p7KJ4WDO016885 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sat, 20 Aug 2011 12:04:38 -0700
References: <20110708012352.14365.62590.idtracker@ietfa.amsl.com> <39219EF2FDAFC35947168EBC@96B2F16665FF96BAE59E9B90> <513618674.27765@cnnic.cn> <DA986D019DE544E08E1FFC289FE7FA1E@LENOVO47E041CF> <54FDC38939FFB9E2DB2DE21B@96B2F16665FF96BAE59E9B90> <4E4FF07C.7070407@isode.com>
User-Agent: K-9 Mail for Android
In-Reply-To: <4E4FF07C.7070407@isode.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----2C72HO3BTOBP84WUME29KKM8HFYB5C"
From: Dave Crocker <dhc@dcrocker.net>
Date: Sat, 20 Aug 2011 12:04:33 -0700
To: Alexey Melnikov <alexey.melnikov@isode.com>, Chris Newman <chris.newman@oracle.com>
Message-ID: <a8f1c6f0-9c4d-46be-8f9b-d3bafa093013@email.android.com>
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sat, 20 Aug 2011 12:04:38 -0700 (PDT)
Cc: ima@ietf.org, Jiankang Yao <healthyao@gmail.com>
Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-12.txt
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Aug 2011 19:03:43 -0000

------2C72HO3BTOBP84WUME29KKM8HFYB5C
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 8bit

+1

/d

--
Dave Crocker
bbiw.net

via mobile

_____________________________________________
From: Alexey Melnikov <alexey.melnikov@isode.com>
Sent: Sat Aug 20 10:35:56 PDT 2011
To: Chris Newman <chris.newman@oracle.com>
Cc: ima@ietf.org, Jiankang Yao <healthyao@gmail.com>
Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-12.txt


Chris Newman wrote:

> --On August 18, 2011 14:43:37 +0800 Jiankang Yao <healthyao@gmail.com> 
> wrote:
>
>> ----- Original Message -----
>> From: "Chris Newman" <chris.newman@oracle.com>
>> To: <ima@ietf.org>
>> Sent: Thursday, August 18, 2011 6:04 AM
>> Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-12.txt
>
> ...
>
>>> except the ABNF does not
>>> allow UTF-8 in ESMTP parameter values. So we need:
>>>
>>> esmtp-value =/ UTF8-non-ascii
>>>
>>> added to the ABNF.
>>
>> If your proposed esmtp-value syntax extension in rfc5336bis is used for
>> ORCPT in DSN, then RFC5336bis has already said "
>> If a UTF8SMTPbis-aware SMTP server advertises the Delivery Status
>> Notification (DSN) [RFC3461] extension, it MUST implement
>> [RFC5337bis].
>> "
>>
>> Does it satisfy your expectation?
>
> That creates a contradiction. RFC 5337bis discusses using UTF-8 in the 
> ORCPT parameter value, but 5336bis ABNF presently disallows use of 
> UTF-8 in ESMTP parameter values. We can make the specifications 
> consistent by allowing UTF-8 in ESMTP parameter values.

Good point. I support your proposal.

_____________________________________________

IMA mailing list
IMA@ietf.org
https://www.ietf.org/mailman/listinfo/ima

------2C72HO3BTOBP84WUME29KKM8HFYB5C
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: 8bit

<html><head></head><body>+1<br>
<br>
/d<br>
<br>
--<br>
   Dave Crocker<br>
   <a href="http://bbiw.net">bbiw.net</a><br>
<br>
   via mobile<br><br><div style='font-size:10.0pt;font-family:"Tahoma","sans-serif";padding:3.0pt 0in 0in 0in'>
<hr style='border:none;border-top:solid #B5C4DF 1.0pt'>
<b>From:</b> Alexey Melnikov &lt;alexey.melnikov@isode.com&gt;<br>
<b>Sent:</b> Sat Aug 20 10:35:56 PDT 2011<br>
<b>To:</b> Chris Newman &lt;chris.newman@oracle.com&gt;<br>
<b>Cc:</b> ima@ietf.org, Jiankang Yao &lt;healthyao@gmail.com&gt;<br>
<b>Subject:</b> Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-12.txt<br>
</div>
<br>
<pre style="white-space: pre-wrap; word-wrap:break-word; font-family: monospace">Chris Newman wrote:<br /><br />&gt; --On August 18, 2011 14:43:37 +0800 Jiankang Yao &lt;healthyao@gmail.com&gt; <br />&gt; wrote:<br />&gt;<br />&gt;&gt; ----- Original Message -----<br />&gt;&gt; From: "Chris Newman" &lt;chris.newman@oracle.com&gt;<br />&gt;&gt; To: &lt;ima@ietf.org&gt;<br />&gt;&gt; Sent: Thursday, August 18, 2011 6:04 AM<br />&gt;&gt; Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-12.txt<br />&gt;<br />&gt; ...<br />&gt;<br />&gt;&gt;&gt; except the ABNF does not<br />&gt;&gt;&gt; allow UTF-8 in ESMTP parameter values. So we need:<br />&gt;&gt;&gt;<br />&gt;&gt;&gt;   esmtp-value  =/  UTF8-non-ascii<br />&gt;&gt;&gt;<br />&gt;&gt;&gt; added to the ABNF.<br />&gt;&gt;<br />&gt;&gt; If your proposed esmtp-value syntax extension in rfc5336bis  is used for<br />&gt;&gt; ORCPT in DSN, then  RFC5336bis has already said "<br />&gt;&gt;    If a UTF8SMTPbis-aware SMTP server
advertises the Delivery Status<br />&gt;&gt;    Notification (DSN) [RFC3461] extension, it MUST implement<br />&gt;&gt;    [RFC5337bis].<br />&gt;&gt; "<br />&gt;&gt;<br />&gt;&gt; Does it satisfy your expectation?<br />&gt;<br />&gt; That creates a contradiction. RFC 5337bis discusses using UTF-8 in the <br />&gt; ORCPT parameter value, but 5336bis ABNF presently disallows use of <br />&gt; UTF-8 in ESMTP parameter values. We can make the specifications <br />&gt; consistent by allowing UTF-8 in ESMTP parameter values.<br /><br />Good point. I support your proposal.<br /><br /><hr /><br />IMA mailing list<br />IMA@ietf.org<br /><a href="https://www.ietf.org/mailman/listinfo/ima">https://www.ietf.org/mailman/listinfo/ima</a><br /></pre></body></html>
------2C72HO3BTOBP84WUME29KKM8HFYB5C--


From tony@att.com  Mon Aug 22 05:55:39 2011
Return-Path: <tony@att.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD1721F859F for <ima@ietfa.amsl.com>; Mon, 22 Aug 2011 05:55:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.176
X-Spam-Level: 
X-Spam-Status: No, score=-106.176 tagged_above=-999 required=5 tests=[AWL=0.423, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQ4IH++heWvS for <ima@ietfa.amsl.com>; Mon, 22 Aug 2011 05:55:38 -0700 (PDT)
Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id CDEBA21F8591 for <ima@ietf.org>; Mon, 22 Aug 2011 05:55:38 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: tony@att.com
X-Msg-Ref: server-12.tower-120.messagelabs.com!1314017801!34067087!1
X-StarScan-Version: 6.2.17; banners=-,-,-
X-Originating-IP: [144.160.20.145]
Received: (qmail 12261 invoked from network); 22 Aug 2011 12:56:42 -0000
Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-12.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Aug 2011 12:56:42 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p7MCv8Ot012936 for <ima@ietf.org>; Mon, 22 Aug 2011 08:57:08 -0400
Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p7MCv1Fl012860 for <ima@ietf.org>; Mon, 22 Aug 2011 08:57:02 -0400
Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p7MCuZan032759 for <ima@ietf.org>; Mon, 22 Aug 2011 08:56:35 -0400
Received: from mailgw1.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p7MCuS6D032626 for <ima@ietf.org>; Mon, 22 Aug 2011 08:56:29 -0400
Received: from [135.70.41.36] (vpn-135-70-41-36.vpn.west.att.com[135.70.41.36]) by maillennium.att.com (mailgw1) with ESMTP id <20110822125628gw100e4l39e> (Authid: tony); Mon, 22 Aug 2011 12:56:28 +0000
X-Originating-IP: [135.70.41.36]
Message-ID: <4E524CAF.5040003@att.com>
Date: Mon, 22 Aug 2011 08:33:51 -0400
From: Tony Hansen <tony@att.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: ima@ietf.org
References: <20110708012352.14365.62590.idtracker@ietfa.amsl.com> <39219EF2FDAFC35947168EBC@96B2F16665FF96BAE59E9B90> <513618674.27765@cnnic.cn> <DA986D019DE544E08E1FFC289FE7FA1E@LENOVO47E041CF> <54FDC38939FFB9E2DB2DE21B@96B2F16665FF96BAE59E9B90>
In-Reply-To: <54FDC38939FFB9E2DB2DE21B@96B2F16665FF96BAE59E9B90>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-12.txt
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Aug 2011 12:55:39 -0000

On 8/19/2011 5:21 PM, Chris Newman wrote:
> That creates a contradiction. RFC 5337bis discusses using UTF-8 in the 
> ORCPT parameter value, but 5336bis ABNF presently disallows use of 
> UTF-8 in ESMTP parameter values. We can make the specifications 
> consistent by allowing UTF-8 in ESMTP parameter values.

+1

     Tony Hansen

From dhc2@dcrocker.net  Mon Aug 22 13:46:17 2011
Return-Path: <dhc2@dcrocker.net>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 427A121F8B55 for <ima@ietfa.amsl.com>; Mon, 22 Aug 2011 13:46:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.028
X-Spam-Level: 
X-Spam-Status: No, score=-5.028 tagged_above=-999 required=5 tests=[AWL=-0.271, BAYES_00=-2.599, DATE_IN_PAST_96_XX=1.69, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ktJCZHW5zeX for <ima@ietfa.amsl.com>; Mon, 22 Aug 2011 13:46:16 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id A051321F8AAA for <ima@ietf.org>; Mon, 22 Aug 2011 13:46:16 -0700 (PDT)
Received: from [192.168.1.156] (adsl-68-122-69-114.dsl.pltn13.pacbell.net [68.122.69.114]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p7MKlGn5013148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ima@ietf.org>; Mon, 22 Aug 2011 13:47:22 -0700
Message-ID: <4E4A8316.50401@dcrocker.net>
Date: Tue, 16 Aug 2011 07:47:50 -0700
From: Dave CROCKER <dhc2@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: ima@ietf.org
References: <C31E821E731AC23ED7EE191F@PST.JCK.COM> <20110815175214.4833.qmail@joyce.lan> <CAHhFybo9PxBHehzTxkwj+-bCNvGcc0A66vnhbXOJi3AssMOPdw@mail.gmail.com> <01O4VRGRKZH800VHKR@mauve.mrochek.com>
In-Reply-To: <01O4VRGRKZH800VHKR@mauve.mrochek.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 22 Aug 2011 13:47:22 -0700 (PDT)
Subject: Re: [EAI] UTF-8 in Message-IDs
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Aug 2011 20:46:17 -0000

On 8/15/2011 2:03 PM, ned+ima@mrochek.com wrote:
> The addition of utf-8 to various syntactic elements isn't convoluted. In fact,
> having looked at the impact on our code base, it's going to be pretty easy to
> add.

That mirrors the effect I saw when making generic changes to the ABNF, rather 
than by treating UTF-8 as an extended set of special cases around the syntax.


>> I don't see anything "compelling" in that line of reasoning, otherwise
>> we could also say that using 8bit in DNS queries works, and therefore
>> it's okay to use UTF-8 in host names (example).
>
> Except that it doesn't - the DNS protocols may support 8-bit but there are
> specific restrictions on host names that some deployed software honors. And if
> this wasn't the case you'd probably hear exactly this argument being made.

In practical terms (de facto group consensus), the recent version of the EAI 
effort has chosen to design for a hypothetically-pure 8-bit environment. 
Dealing with the much messier hybrid world is deferred, here.

The Unicode effort for the DNS chose to work within the hybrid world and, 
therefore, had to make fundamentally different design choices.

Design DNS support for a truly pure UTF-8 environment, end-to-end, and it well 
might be reasonable to 'just do 8 bits'.  But they didn't have that luxury.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From klensin@jck.com  Tue Aug 23 07:41:39 2011
Return-Path: <klensin@jck.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F72521F8ABE for <ima@ietfa.amsl.com>; Tue, 23 Aug 2011 07:41:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.574
X-Spam-Level: 
X-Spam-Status: No, score=-3.574 tagged_above=-999 required=5 tests=[AWL=0.873,  BAYES_00=-2.599, GB_I_LETTER=-2, SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJyFmoVUmwjD for <ima@ietfa.amsl.com>; Tue, 23 Aug 2011 07:41:39 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id D4FAF21F8A80 for <ima@ietf.org>; Tue, 23 Aug 2011 07:41:38 -0700 (PDT)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QvsBc-000KFW-Vk; Tue, 23 Aug 2011 10:42:41 -0400
Date: Tue, 23 Aug 2011 10:42:40 -0400
From: John C Klensin <klensin@jck.com>
To: dcrocker@bbiw.net, ima@ietf.org
Message-ID: <7B2F664A7C469046D955E05E@PST.JCK.COM>
In-Reply-To: <4E4A8316.50401@dcrocker.net>
References: <C31E821E731AC23ED7EE191F@PST.JCK.COM> <20110815175214.4833.qmail@joyce.lan> <CAHhFybo9PxBHehzTxkwj+-bCNvGcc0A66vnhbXOJi3AssMOPdw@mail.gmail.com> <01O4VRGRKZH800VHKR@mauve.mrochek.com> <4E4A8316.50401@dcrocker.net>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Subject: Re: [EAI] UTF-8 in Message-IDs
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Aug 2011 14:41:39 -0000

--On Tuesday, August 16, 2011 07:47 -0700 Dave CROCKER
<dhc2@dcrocker.net> wrote:

>...
> In practical terms (de facto group consensus), the recent
> version of the EAI effort has chosen to design for a
> hypothetically-pure 8-bit environment. Dealing with the much
> messier hybrid world is deferred, here.

As you know, opinions differ about exactly what that design
decision was, how far it extends, and what implications can be
drawn from it.  Nonetheless...
 
> The Unicode effort for the DNS chose to work within the hybrid
> world and, therefore, had to make fundamentally different
> design choices.
> 
> Design DNS support for a truly pure UTF-8 environment,
> end-to-end, and it well might be reasonable to 'just do 8
> bits'.  But they didn't have that luxury.

To strengthen the distinction, one would need actually need a
lot more than "truly pure UTF-8 environment".  Identifier
comparison in a non-ASCII environment is actually quite
difficult in the general case, requiring a lot of additional
comparison rules and/or restrictions (see RFC 6055 for a partial
discussion).  While we take it for granted these days, that is
even true in the ASCII environment because we have to specify
choices between case-dependent and case-independent comparison.
But, in the DNS case, even if we substituted "pure UTF-8" for
the IETF-invented Punycode encoding, we would still need fairly
extensive rules about permitted characters, normalization, etc.,
to make things work -- and even more extensive rules if any sort
of mapping (or non-exact comparison) was permitted.

See current discussions in PRECIS, the IAB work on identifiers,
the Unicode work on identifiers, and the periodic debates in
DNSEXT and ICANN about extended aliases, matching, variant
names, and so on for examples of how complicated those issues
get.

We are spared most of this problem with email addresses because,
for other reasons, we adopted a very strong "no one gets to
interpret an address other than the delivery server" rule.
Preserving that rule into the EAI work permits us to push "pure
UTF-8" much further than was the case with IDNs and IDNA, which
had no such advantages.  We are probably spared them for other
header fields as well, although, for example, I've seen problems
with comparison and threading of subject lines and searching on
display names that use encoded words.  Those problems will
almost certainly carry forward and become more extensive as we
encourage arbitrary UTF-8 in those fields.  From my point of
view, EAI doesn't change those problems because one can have all
of them when the data are expressed in encoded-word form.  But
we should be careful about assuming that a "pure UTF-8"
environment will be as problem free (or problem-minimal) as
ASCII letters and digits.

    john


From chl@clerew.man.ac.uk  Mon Aug 29 06:24:57 2011
Return-Path: <chl@clerew.man.ac.uk>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD5221F8B0D for <ima@ietfa.amsl.com>; Mon, 29 Aug 2011 06:24:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.963
X-Spam-Level: 
X-Spam-Status: No, score=-2.963 tagged_above=-999 required=5 tests=[AWL=-2.116, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCBJo3E2Fkf4 for <ima@ietfa.amsl.com>; Mon, 29 Aug 2011 06:24:55 -0700 (PDT)
Received: from outbound-queue-1.mail.thdo.gradwell.net (outbound-queue-1.mail.thdo.gradwell.net [212.11.70.34]) by ietfa.amsl.com (Postfix) with ESMTP id 6D09921F8B0E for <ima@ietf.org>; Mon, 29 Aug 2011 06:24:54 -0700 (PDT)
Received: from outbound-edge-2.mail.thdo.gradwell.net (bonnie.gradwell.net [212.11.70.2]) by outbound-queue-1.mail.thdo.gradwell.net (Postfix) with ESMTP id 6771021F6A for <ima@ietf.org>; Mon, 29 Aug 2011 14:26:18 +0100 (BST)
Received: from port-89.xxx.th.newnet.co.uk (HELO clerew.man.ac.uk) (80.175.135.89) (smtp-auth username postmaster%pop3.clerew.man.ac.uk, mechanism cram-md5) by outbound-edge-2.mail.thdo.gradwell.net (qpsmtpd/0.83) with (DES-CBC3-SHA encrypted) ESMTPSA; Mon, 29 Aug 2011 14:26:18 +0100
Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id p7TDQGFn015633 for <ima@ietf.org>; Mon, 29 Aug 2011 14:26:17 +0100 (BST)
Date: Mon, 29 Aug 2011 14:26:16 +0100
To: IMA <ima@ietf.org>
From: "Charles Lindsey" <chl@clerew.man.ac.uk>
Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1
MIME-Version: 1.0
References: <C31E821E731AC23ED7EE191F@PST.JCK.COM> <20110815175214.4833.qmail@joyce.lan> <CAHhFybo9PxBHehzTxkwj+-bCNvGcc0A66vnhbXOJi3AssMOPdw@mail.gmail.com> <01O4VRGRKZH800VHKR@mauve.mrochek.com> <4E4A8316.50401@dcrocker.net> <7B2F664A7C469046D955E05E@PST.JCK.COM>
Content-Transfer-Encoding: 8bit
Message-ID: <op.v0y8x2tq6hl8nm@clerew.man.ac.uk>
In-Reply-To: <7B2F664A7C469046D955E05E@PST.JCK.COM>
User-Agent: Opera Mail/9.25 (SunOS)
X-Gradwell-MongoId: 4e5b937a.8d7d-658e-2
X-Gradwell-Auth-Method: mailbox
X-Gradwell-Auth-Credentials: postmaster@pop3.clerew.man.ac.uk
Subject: Re: [EAI] UTF-8 in Message-IDs
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Aug 2011 13:24:57 -0000

On Tue, 23 Aug 2011 15:42:40 +0100, John C Klensin <klensin@jck.com> wrote:

> To strengthen the distinction, one would need actually need a
> lot more than "truly pure UTF-8 environment".  Identifier
> comparison in a non-ASCII environment is actually quite
> difficult in the general case, requiring a lot of additional
> comparison rules and/or restrictions (see RFC 6055 for a partial
> discussion).  While we take it for granted these days, that is
> even true in the ASCII environment because we have to specify
> choices between case-dependent and case-independent comparison.
> But, in the DNS case, even if we substituted "pure UTF-8" for
> the IETF-invented Punycode encoding, we would still need fairly
> extensive rules about permitted characters, normalization, etc.,
> to make things work -- and even more extensive rules if any sort
> of mapping (or non-exact comparison) was permitted.

All of which is exactly why I oppose allowing UTF-8 in Message-IDs (which  
get treated like identifiers in many situations). Fine if the job is done  
properly by specifying the normalizations etc, but not otherwise.

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