Re: [EAI] [Technical Errata Reported] RFC6532 (6036)

"John R. Levine" <johnl@iecc.com> Wed, 01 April 2020 17:24 UTC

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 446D23A1433 for <ima@ietfa.amsl.com>; Wed, 1 Apr 2020 10:24:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OUx9TSFSujF for <ima@ietfa.amsl.com>; Wed, 1 Apr 2020 10:24:56 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6392A3A13FE for <ima@ietf.org>; Wed, 1 Apr 2020 10:24:51 -0700 (PDT)
Received: (qmail 17684 invoked from network); 1 Apr 2020 17:24:49 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=450d.5e84ce61.k2004; i=johnl-iecc.com@submit.iecc.com; bh=Ol0KRiGD6UasY+naYbR0rp4Qbx8jYrmKt1I0LfKQblI=; b=gxQkOr+0PL1fFbnext7FRFLQIB2nFUNzEiX+s3/I9xDOGm357hZYJubQXWg3rYzcvfduDp9QWD2cnDF7t1zWzjhjGgVX+t7Jv1lBbSdm5Wh2G+fvbokkLoo4NrEcC2pcLc9Dkq0PynHWHRakuFFyUOQKNmkmLZ2WRscBpq2UIi1IsTG57ctoceO52m1PVOP9cM3FmEHZjLtvNioE5BR04rdIFd52+H0ZUfn4m9M+wObhfwRDDz+449+bRTDq3AMz
Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 01 Apr 2020 17:24:49 -0000
Date: 1 Apr 2020 13:24:49 -0400
Message-ID: <alpine.OSX.2.22.407.2004011320470.28780@ary.qy>
From: "John R. Levine" <johnl@iecc.com>
To: "John C Klensin" <john-ietf@jck.com>, "RFC Errata System" <rfc-editor@rfc-editor.org>, abelyang@twnic.net.tw, Shawn.Steele@microsoft.com, ned+ietf@mrochek.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, jyee@afilias.info
Cc: vesely@tana.it, ima@ietf.org
In-Reply-To: <6D9862819E9E4071B83CC6D5@PSB>
References: <20200401083756.5D051F40723@rfc-editor.org> <6D9862819E9E4071B83CC6D5@PSB>
User-Agent: Alpine 2.22 (OSX 407 2020-02-09)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/ima/8Zd2eZ_y39WNEhf10-Sb_CSpKyk>
Subject: Re: [EAI] [Technical Errata Reported] RFC6532 (6036)
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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, 01 Apr 2020 17:24:58 -0000

I would suggest rejecting this erratum.  The motivation is that "token" is 
imported into RFC 8601 where we have found some unfortunate results, but 
the solution is to fix 8601, which we're working on.

R's,
John

On Wed, 1 Apr 2020, John C Klensin wrote:

> My vague recollection is that this was an explicit decision by
> the WG.   Essentially, just as the WG concluded that header
> field names should remain restricted to ASCII, the conclusion
> was that Content-type fields were protocol parameters, not
> information for the user, and that there was no need (and
> potentially some cost and risks) to allow non-ASCII characters
> or free text more generally.  One could revisit that question,
> but I believe that the appropriate way to do it would be to
> generate an Internet draft that explained the issues and
> tradeoffs and proposed a change -- not just to RFC 6532 but to
> the IANA registries related to Content-type parameter values.
>
> In any event not something that is possible as a erratum because
> the change would change the technical requirements for an
> SMTPUTF8 implementation.
>
> best,
>  john
>
>
> --On Wednesday, April 1, 2020 01:37 -0700 RFC Errata System
> <rfc-editor@rfc-editor.org> wrote:
>
>> The following errata report has been submitted for RFC6532,
>> "Internationalized Email Headers".
>>
>> --------------------------------------
>> You may review the report below and at:
>> https://www.rfc-editor.org/errata/eid6036
>>
>> --------------------------------------
>> Type: Technical
>> Reported by: Alessandro Vesely <vesely@tana.it>
>>
>> Section: GLOBAL
>>
>> Original Text
>> -------------
>> A section 3.2bis, "Syntax Extensions to RFC 2045", is missing.
>>
>>
>> Corrected Text
>> --------------
>> In particular, Section 5.1 of RFC 2045, "Syntax of the
>> Content-Type Header Field", deserves an extension:
>>
>>     token /= UTF8-non-ascii
>>
>> similar to the extensions given to various text types given in
>> Section 3.2.
>>
>> Notes
>> -----
>> Various header fields are defined in terms of the grammar
>> defined in RFC 2045.  In particular, the missing extension of
>> token was reported for Authentication-Results:
>> https://mailarchive.ietf.org/arch/msg/dmarc/g1U__axJW5I6OenEuw
>> D48nwptzU
>>
>> Instructions:
>> -------------
>> This erratum is currently posted as "Reported". If necessary,
>> please use "Reply All" to discuss whether it should be
>> verified or rejected. When a decision is reached, the
>> verifying party   can log in to change the status and edit the
>> report, if necessary.
>>
>> --------------------------------------
>> RFC6532 (draft-ietf-eai-rfc5335bis-13)
>> --------------------------------------
>> Title               : Internationalized Email Headers
>> Publication Date    : February 2012
>> Author(s)           : A. Yang, S. Steele, N. Freed
>> Category            : PROPOSED STANDARD
>> Source              : Email Address Internationalization
>> Area                : Applications
>> Stream              : IETF
>> Verifying Party     : IESG
>
>
>

Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly