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

[Alexey Melnikov <[e-mail]>]

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:
> 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)
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
> 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,
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.

> 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.
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.
> 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.
Thank you.

Alexey


> --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.
>
>
>
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss