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

[Alexey Melnikov <[e-mail]>]

Hi John,

On 01/05/2016 14:14, John C Klensin wrote:
> --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.
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