[EAI] FWD: Re: I-D Action: draft-ietf-appsawg-mdn-3798bis-07.txt
John C Klensin <john-ietf@jck.com> Sun, 01 May 2016 13:19 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 781AF12B050 for <ima@ietfa.amsl.com>; Sun, 1 May 2016 06:19:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.896
X-Spam-Level:
X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 j1nCyFLXVDcZ for <ima@ietfa.amsl.com>; Sun, 1 May 2016 06:19:12 -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 BAC8D12B027 for <ima@ietf.org>; Sun, 1 May 2016 06:19:12 -0700 (PDT)
Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1awrHD-000FSr-Ph for ima@ietf.org; Sun, 01 May 2016 09:19:11 -0400
Date: Sun, 01 May 2016 09:19:06 -0400
From: John C Klensin <john-ietf@jck.com>
To: ima@ietf.org
Message-ID: <9A1D95FD31BDAF3F0966458B@JcK-HP8200.jck.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
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: <http://mailarchive.ietf.org/arch/msg/ima/m-5HYLCJD6XJICUV46F4auJ1dfM>
Subject: [EAI] FWD: Re: I-D Action: draft-ietf-appsawg-mdn-3798bis-07.txt
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.17
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: Sun, 01 May 2016 13:19:14 -0000
Hi. With apologies to anyone who is already following apps-discuss, people on this list should be aware that this proposed replacement to RFC 3798 (on which RFC 6533, the i18n MDN spec, depends) is in the pipe and the objections I have raised. If you have comments, please address them to the apps-discuss@ietf.org list. john ---------- Forwarded Message ---------- Date: Sunday, May 01, 2016 09:14 -0400 From: John C Klensin <john-ietf@jck.com> To: apps-discuss@ietf.org Subject: Re: I-D Action: draft-ietf-appsawg-mdn-3798bis-07.txt --On Sunday, May 01, 2016 04:50 -0700 internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line > Internet-Drafts directories. This draft is a work item of the > ART Area General Applications Working Group of the IETF. > > Title : Message Disposition Notification > Authors : Tony Hansen > Alexey Melnikov > Filename : draft-ietf-appsawg-mdn-3798bis-07.txt > Pages : 33 > Date : 2016-05-01 > > Abstract: > This memo defines a MIME content-type that may be used by a > mail user agent (MUA) or electronic mail gateway to report > the disposition of a message after it has been successfully > delivered to a recipient. This content-type is intended to > be machine-processable. Additional message header fields > are also defined to permit Message Disposition > Notifications (MDNs) to be requested by the sender of a > message. The purpose is to extend Internet Mail to support > functionality often found in other messaging systems, such > as X.400 and the proprietary "LAN-based" systems, and often > referred to as "read receipts," "acknowledgements", or > "receipt notifications." The intention is to do this while > respecting privacy concerns, which have often been > expressed when such functions have been discussed in the past. > > Because many messages are sent between the Internet and > other messaging systems (such as X.400 or the proprietary > "LAN-based" systems), the MDN protocol is designed to be > useful in a multi- protocol messaging environment. To this > end, the protocol described in this memo provides for the > carriage of "foreign" addresses, in addition to those > normally used in Internet Mail. Additional attributes may > also be defined to support "tunneling" of foreign > notifications through Internet Mail. Two comments: (1) Editorial: A 20 or 21 line Abstract, even through it was copied from 3798, is obnoxious. In addition to violating historical RFC Editor rules, it violates the principles behind an abstract and may not even fit on a single screen of a smaller device. (2) Substantive: As the authors of this document well know, RFC 6533 is heavily (and normatively dependent) on RFC 3798. Its MDN format is defined as using fields from 3798 that this I-D alters to make more more restrictive. If the result of approving this document is to obsolete 3798, the status of 6533 becomes unclear. Even if one hand-waves around the formal status relationships, if the changes to fields that 6533 includes by reference are important enough to include in this I-D, then they should be applied to 6533. That does not seem acceptable either substantively or procedurally. I see two possible remedies and prefer the second: (2.1) Assuming that the changes in this I-D from 3798 do not actually add value to the understanding of 6533, modify this draft to update 6533 to reference this document instead, in the process substituting the updated definitions of assorted fields, obviously including the ua-* fields, removed fields, etc., discussed in Appendix A of the present I-D. (2.2) Use this document to replace and obsolete 6533 as well, creating a single, internationalized, MDN standard with appropriate restrictions on the contexts for the use of non-ASCII characters. It is now 18 years since RFC 2277 was published; especially given the IETF's increasingly international participation and focus, it is no longer seemly to publish Internet Standards that come in "ASCII-only" and "this is the i18n version of that" pairs (no matter what is done in developing those Standards with, e.g., Proposed Standard, documents). Unifying the two documents would also eliminate a good deal of the actual and potential confusion between ASCII-only and i18n notifications and would eliminate the need to navigate among documents that is necessary with 6533 but would become even more complex with the suggestion above (and worse yet, left to the reader's imagination if the I-D is unchanged). The obvious procedural objections to the second approach are that no one has done implementation reports on 6533 or, for that matter, on 6530, 6531, and 6532 (which 6533 normatively references). However, the dependency relationships between 6533 and this I-D (and 3798 for that matter) are such that, if 6533 is not sufficiently implemented to demonstrate that all of the pieces work together, then this document is not ready for prime time (specifically Internet Standard) and should wait unless it proposes to deprecate 6533 in favor of some other strategy. I'd like to see 6530-6532 brought to Internet Standard sometimes soon, but, if that is not feasible, it seems to me that references to them from 3798bis would be one of the better examples of why we now allow that by exception. There is, in principle, also an editorial process objection, which is that it would be highly desirable for the authors of 3798bis to collaborate actively with at least a majority of the authors of 6533. It does not appear to pose a serious problem in this case :-) best, john ---------- End Forwarded Message ----------
- [EAI] FWD: Re: I-D Action: draft-ietf-appsawg-mdn… John C Klensin