Re: [apps-discuss] I-D Action: draft-ietf-appsawg-mdn-3798bis-07.txt

Alexey Melnikov <alexey.melnikov@isode.com> Thu, 05 May 2016 14:33 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91D8B12DB03 for <apps-discuss@ietfa.amsl.com>; Thu, 5 May 2016 07:33:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.997
X-Spam-Level:
X-Spam-Status: No, score=-2.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 dem3WWjknUYe for <apps-discuss@ietfa.amsl.com>; Thu, 5 May 2016 07:33:07 -0700 (PDT)
Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id B4FB612DB19 for <apps-discuss@ietf.org>; Thu, 5 May 2016 07:25:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1462458314; d=isode.com; s=selector; i=@isode.com; bh=9Z7JRvyxtu014qHbPlbWTh0kbP/oCJeCM1/uW0dTtPQ=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=vcIWTPnFg4HgMWwup5MxfkdMk7n4F7T1Z1uziuX5gqFYpzouwg/Q5n5iDms5Pp7yNG3da7 ddmzhaex/p8lcA/Asi5gvIJ9ZGOI3VFILiTFPgjyhozG0+e+jfV71El1eh4sN8ERHj2Ybf 4JSPMyz3erk9il4IZgYpmAT1UTYK5y0=;
Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id <VytXyQB-mxhx@statler.isode.com>; Thu, 5 May 2016 15:25:13 +0100
To: John C Klensin <john-ietf@jck.com>, apps-discuss@ietf.org
References: <20160501115046.14230.42722.idtracker@ietfa.amsl.com> <9626E3570CB632119010C433@JcK-HP8200.jck.com>
From: Alexey Melnikov <alexey.melnikov@isode.com>
Message-ID: <572B57B4.5000104@isode.com>
Date: Thu, 5 May 2016 15:24:52 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
In-Reply-To: <9626E3570CB632119010C433@JcK-HP8200.jck.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/apps-discuss/9rBBkAxFl3_6NsTl0HQqWOybxxg>
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-mdn-3798bis-07.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 May 2016 14:33:11 -0000

Hi John,

On 01/05/2016 14:14, John C Klensin wrote:
> --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.
I can work on shortening. Suggestions are welcome.
> (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,
Yes.
> 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.
I think I prefer revising RFC 6533 as a separate draft. Firstly, 3798bis 
is intended to be Internet Standard and merging the documents will reset 
that, because as far as I know it is not deployed enough. Secondly, 
merging is quite a bit of work and I would rather get 3798bis be done 
now, before I get more involved in IESG :-).

I can help with 6553bis, but I would rather somebody new and eager steps 
up and drives the process.

I can also entertain your option 2.1, but I need to investigate what 
exactly needs to change in RFC 6553, before forming my opinion. But 
again, this might reset 3798bis back to Proposed Standard.
> 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 am not sure this follows!
> 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 :-)
Indeed :-).

Best Regards,
Alexey