Re: [EAI] UTF-8 in Message-IDs

ned+ima@mrochek.com Mon, 15 August 2011 20:58 UTC

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
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