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

From: [email-masked]
Date: Sun, 01 May 2016 04:50:46 -0700

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.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-mdn-3798bis/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-appsawg-mdn-3798bis-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-mdn-3798bis-07

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: John C Klensin <[email-masked]>
Date: Sun, 01 May 2016 09:14:56 -0400

--On Sunday, May 01, 2016 04:50 -0700 [email-masked]
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.
> 
>    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
>    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

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

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 5 May 2016 15:24:52 +0100

Hi John,

> an abstract and may not even fit on a single screen of a smaller
I can work on shortening. Suggestions are welcome.
> approving this document is to obsolete 3798,
Yes.
> the status of 6533
> 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
> proposes to deprecate 6533 in favor of some other strategy.
I am not sure this follows!
> I'd
Indeed :-).

Best Regards,
Alexey