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

John C Klensin <john-ietf@jck.com> Wed, 01 April 2020 17:05 UTC

Return-Path: <john-ietf@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 1F94A3A13A5 for <ima@ietfa.amsl.com>; Wed, 1 Apr 2020 10:05:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 3bwjbygT2v5T for <ima@ietfa.amsl.com>; Wed, 1 Apr 2020 10:05:17 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F38AD3A13A1 for <ima@ietf.org>; Wed, 1 Apr 2020 10:05:16 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1jJgnN-00023N-Ak; Wed, 01 Apr 2020 13:04:53 -0400
Date: Wed, 01 Apr 2020 13:04:47 -0400
From: John C Klensin <john-ietf@jck.com>
To: 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
Message-ID: <6D9862819E9E4071B83CC6D5@PSB>
In-Reply-To: <20200401083756.5D051F40723@rfc-editor.org>
References: <20200401083756.5D051F40723@rfc-editor.org>
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
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ima/WYnxa6ZrrOqPsxTf6dbFaq5bOMg>
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:05:22 -0000

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