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

ned+ima@mrochek.com Wed, 17 August 2011 14:02 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 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
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