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 apps-discuss(_at_)ietf(_dot_)org. 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 <john-ietf(_at_)jck(_dot_)com>
To: "Murray S. Kucherawy" <superuser(_at_)gmail(_dot_)com>, IETF Apps
Discuss <apps-discuss(_at_)ietf(_dot_)org>
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" <superuser(_at_)gmail(_dot_)com> 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: <internet-drafts(_at_)ietf(_dot_)org>
Date: Sun, Jul 31, 2016 at 10:23 AM
Subject: I-D Action: draft-ietf-appsawg-mdn-3798bis-09.txt
To: i-d-announce(_at_)ietf(_dot_)org
Cc: apps-discuss(_at_)ietf(_dot_)org
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 ----------
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp