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

[John C Klensin <[e-mail]>]

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