[EAI] Heads-up - SMTPUTF8/EAI interactons with draft-ietf-appsawg-mdn-3798bis

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

Hi.

This is a heads-up about draft-ietf-appsawg-mdn-3798bis, an
update to the base Message Delivery Notification spec that
appears to me to have some interactions with the i18n version of
MDNs (RFC 6533) and to potentially be disruptive and/or an
impediment to SMTPUTF8 deployment.  The message below explains
my perspective on the situation.   Anyone on these lists who
feels a need or desire to comment on the situation should direct
their comments to [e-mail].  Please do not add to
the confusion by commenting on the EAi/ima or ietf-smtp lists.

    thanks,
       john



---------- Forwarded Message ----------
Date: Thursday, August 04, 2016 10:14 -0400
From: John C Klensin <[e-mail]>
To: "Murray S. Kucherawy" <[e-mail]>, IETF Apps
Discuss <[e-mail]>
Subject: Re: [apps-discuss] Moving ahead with
draft-ietf-appsawg-mdn-3798bis

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" <[e-mail]> 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
> 
> 
> ---------- Forwarded message ----------
> From: <[e-mail]>
> Date: Sun, Jul 31, 2016 at 10:23 AM
> Subject: I-D Action: draft-ietf-appsawg-mdn-3798bis-09.txt
> To: [e-mail]
> Cc: [e-mail]
> 
> 
> 
> 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.
>...


---------- End Forwarded Message ----------