Subject: [apps-discuss] Moving ahead with draft-ietf-appsawg-mdn-3798bis

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 3 Aug 2016 19:58:09 -0700

Colleagues,

The authors, ADs, and I have discussed this newest version and feel there
have not been enough material changes to the draft since Working Group Last
Call completed to warrant a second WGLC.  Accordingly, this will progress
shortly toward IETF Last Call and IESG evaluation.  A diff to the version
that was WGLC'd:

https://www.ietf.org/rfcdiff?url1=draft-ietf-appsawg-mdn-3798bis-02&url2=draft-ietf-appsawg-mdn-3798bis-10

If you have any final comments please provide them to the list, the chair,
or the authors ASAP.

-MSK

---------- Forwarded message ----------
From: <[email-masked]>
Date: Sun, Jul 31, 2016 at 10:23 AM
Subject: I-D Action: draft-ietf-appsawg-mdn-3798bis-09.txt
To: [email-masked]
Cc: [email-masked]

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-09.txt
        Pages           : 35
        Date            : 2016-07-31

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-09

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

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/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft
<https://www.ietf.org/mailman/listinfo/i-d-announce%0AInternet-Draft>
directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: John C Klensin <[email-masked]>
Date: Thu, 04 Aug 2016 10:14:10 -0400

Murray, Tony, and Alexey,

I don't know how to think about this draft in context, but my
problem is not with the specific changes to 3798.

We've got Proposed Standards for internationalized headers and
addresses from the EAI WG (RFC 6530ff) that include an i18n MDN
specification (RFC 6533).  One of the arguments against doing or
standardizing that work at all was that it basically created a
fork in the email environment with mutually-incompatible
ASCII-only (including encoded words, etc.) and i18n-native
environments.  When the WG and IETF adopted the SMPTUTF8 ("EAI")
specifications as Proposed Standards, most of those who were
actively involved knew that the only basis on which the
situation they created would be viable long-term was if it was
transitional to fully-internationalized mail and that
advertisement and use of the SMTP Extension SMTPUTF8 gradually
became as ubiquitous as 8BITMIME.

It would seem to me to be completely appropriate to update the
MDN specification.  However, dealing with the i18n work by
saying 

	"Application that need to convey non ASCII text in these
	fields should consider implementing
	message/global-disposition-notification media type
	specified in [RFC6533] instead of this specification."

(ignoring the grammatical errors in that sentence) seems to me
to be completely contradictory to that transition theory and
very confusing to implementers and operators of email systems as
to what they should be doing.  Asking them to implement and
support two separate specifications for the same thing long-term
--except possibly with different "generate" and "accept" models
as pioneered for email by RFC 2822/5322-- is, at best, unwise on
the part of the IETF.

The relationship between this draft and RFC 6533 raises at least
two other issues.  First, RFC 6533 is heavily dependent on RFC
3798.  it appears to me that several of the changes made in this
document interact with 6533 as well and that either it needs to
be updated to reflect them (and presumably to reference this
document rather than 3798) or or it needs to be made very clear
that the dependencies on 3798 from 6533 do not shift to this
document (and how inconsistencies in registry instructions,
etc., are to be resolved).  Otherwise, we get back into the
unresolved argument about what it means to have normative
references to a document that has been obsoleted.   Second,
questions have been raised in separate discussions about the
complexity and implementability of 6533, some of which questions
reflect on 3798.  The latter are not addressed by this document.

It seems to me that it is inappropriate to advance this document
before those relationship issues are carefully and openly
explored and discussed.  While the two sets of documents
(EAI-produced and this AppsAWG work) all lie within the same
Area and, for MDNs, even have overlapping authorship,
coordination among the various pieces of work so far makes it
seem much closer to a cross-area situation, so I think it is up
to the leadership of the present group and the AD(s) to decide
whether it is best to hold that discussion now or on IETF LC.

best,
   john

p.s. I will forward a copy of this note to the EAI list for
information, but hope we can keep the discussion here on
apps-discuss.

--On Wednesday, August 03, 2016 19:58 -0700 "Murray S.
Kucherawy" <[email-masked]> wrote:

> https://www.ietf.org/rfcdiff?url1=draft-ietf-appsawg-mdn-3798b
> is-02&url2=draft-ietf-appsawg-mdn-3798bis-10
> 
> If you have any final comments please provide them to the
> list, the chair, or the authors ASAP.
> 
> -MSK
> 
> 
> 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

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 4 Aug 2016 16:12:51 +0100

Hi John,

I am still thinking on some of the issues that you've raised. Quick 
answers below.

On 04/08/2016 15:14, John C Klensin wrote:
> document rather than 3798)
Yes, good point. I will work on initial rfc6533-bis that addresses 
similar concerns. I am likely to delegate further editing of this future 
draft to another willing person.
> or or it needs to be made very clear
> complexity and implementability of 6533,
Yes. I am still trying to figure out what is the best way forward on 
this. I will reread Arnt's proposal and will reply.
> some of which questions
> reflect on 3798.
I am not sure about this, just yet. There might be no changes.
>   The latter are not addressed by this document.

> whether it is best to hold that discussion now or on IETF LC.
Will you be Ok with having rfc6533-bis draft and some broad agreement 
between authors about the possible way forward with it? My preference is 
to get draft-ietf-appsawg-mdn-3798bis done (I would like to free up my 
time to do other IETF things) and proceed with rfc6533-bis in parallel.
> information, but hope we can keep the discussion here on
Thank you.

Alexey

> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: John C Klensin <[email-masked]>
Date: Thu, 04 Aug 2016 12:11:07 -0400

Alexey,

Some quick responses below (I'm on a call and about to head to a
meeting... might change my mind with more thought)...

--On Thursday, August 04, 2016 16:12 +0100 Alexey Melnikov
<[email-masked]> wrote:

>...
>> It seems to me that it is inappropriate to advance this
>> document before those relationship issues are carefully and
>> openly explored and discussed.  While the two sets of
>> documents (EAI-produced and this AppsAWG work) all lie within
>> the same Area and, for MDNs, even have overlapping authorship,
>> seem much closer to a cross-area situation, so I think it is
>> up to the leadership of the present group and the AD(s) to
>> decide whether it is best to hold that discussion now or on
>> IETF LC.

> Will you be Ok with having rfc6533-bis draft and some broad
> agreement between authors about the possible way forward with
> it? My preference is to get draft-ietf-appsawg-mdn-3798bis
> done (I would like to free up my time to do other IETF things)
> and proceed with rfc6533-bis in parallel.

Makes me _very_ nervous, especially against the background of
some things being handled on the basis of such agreements and
then having the revised document stall for nearly forever.  I
really do see a threat to SMTPUTF8 deployment and adoption in
this work and way of handling things.  Questions of how serious
that threat is and whether it is acceptable really should be
matters of community consensus (including the EAI community),
not just an agreement among authors.

If your goal is simply to get this out of your queue (something
with which I'm very sympathetic), then post rfc6533-bis, if
necessary even with placeholder content, put a normative
reference to it in 3798bis, process the latter and then let it
sit in the RFC Editor queue until we have actually addressed the
issues.  The is noot my favorite approach, but is certainly a
possibility.

best,
   john

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 5 Aug 2016 10:15:09 +0100

Hi John,

On 04/08/2016 17:11, John C Klensin wrote:
> with which I'm very sympathetic), then post rfc6533-bis,
Pretty much. There is no point in posting rfc6533-bis-00 if there is no 
tentative agreement between authors how to proceed (at the moment there 
isn't), but the intent is to let normal IETF process apply after that. 
Maybe even do this in a new WG.
> if necessary even with placeholder content, put a normative
This is not my preferred approach, considering that RFC 6533 is not as 
widely deployed as RFC 3798 (and its predecessors).

Best Regards,
Alexey

---

From: John C Klensin <[email-masked]>
Date: Fri, 05 Aug 2016 09:57:39 -0400

Alexey,

(explicitly copying a few important/relevant people who may not
be actively following this list)

--On Friday, August 05, 2016 10:15 +0100 Alexey Melnikov
<[email-masked]> wrote:

>>> done (I would like to free up my time to do other IETF
>>> things) and proceed with rfc6533-bis in parallel.

>> this work and way of handling things.  Questions of how
>> serious that threat is and whether it is acceptable really
>> should be matters of community consensus (including the EAI
>> community), not just an agreement among authors.

>> If your goal is simply to get this out of your queue
>> (something with which I'm very sympathetic), then post
>> rfc6533-bis,

> Pretty much. There is no point in posting rfc6533-bis-00 if
> there is no tentative agreement between authors how to proceed
> (at the moment there isn't), but the intent is to let normal
> IETF process apply after that. Maybe even do this in a new WG.

If you think you can get sufficient leadership and engagement, I
think the community would benefit from a sort of YAM-bis to draw
things back together.   Especially if/when the discussion gets
really technical, it would also move the work off this list,
which I see as an advantage. However, for reasons very similar
to Shawn's, I think the "EAI" work needs to be part of the
drawing-together process.  That applies not only to DSNs, but to
questions such as whether we are ready to start aggressively
pushing SMTPUTF8 and potentially discouraging the use of
encoded-words (while still requiring that they be accepted and
understood).  If we are not, we are getting to be in desperate
need of an Applicability Statement that is clear about what
implementers and operators actually should do. See below.
 
>> sit in the RFC Editor queue until we have actually addressed
>> the issues.  The is noot my favorite approach, but is
>> certainly a possibility.

> This is not my preferred approach, considering that RFC 6533
> is not as widely deployed as RFC 3798 (and its predecessors).

Not mine either but see Shawn's note, Arnt's comments, and so
on.  Creating a real or apparent long-term fork is in no one's
interest.  There is also the question of what one counts in the
SMTPUTF8 space -- Joseph is more likely than I am to have
details, but I believe we are above two independent
interoperable implementation on all components, even though some
of those implementations may not be fully conformant to the spec
and whose experience may argue for dropping some requirements or
features (again, see Arnt's notes, most of which have not been
posted to this list).  I don't know how to sort those issues out
without considering everything in the same context... and it
doesn't seem to me that advancing potentially-forking documents
piecemeal is consistent with that.

best,
   john

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 5 Aug 2016 15:29:46 +0100

John C Klensin writes:
> (again, see Arnt's notes, most of which have not been
> posted to this list).

I can sum up on the list, or perhaps restate.

RFC 6533 is not a very long RFC, but it is bothersomely complicated, most 
of the complexity is not central to its purpose, and it's not being 
implemented as much as the neighbouring RFCs. The parts of that sentence 
are causally related, I think.

I am proposing to replate 6533 with a simpler version. I want to simplify 
section 3 (about ORCPT) so that only the first two productions in the 
formal syntax are needed. (This affects what happens when the message path 
includes a standards violation. There is no change as long as the MTAs 
follows the RFCs.) I also want to simplify section 4.5 (DSN generation) so 
that it's possible to generate a DSN without reference to the DSN's 
recipient's SMTP server's SMTP extensions. If possible perhaps simplify a 
few other bits of section 4.

I have volunteered to do the editing. I probably add an example or two 
while editing.

IMO, 3798bis should incorporate what it needs from 6533(bis). Reading and 
implementing partly related documents is harder than it needs to. Separate 
documents is convenient for us, that's IMO less important than having 
implementers be able to read and understand.

Arnt