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

Alexey Melnikov <> Thu, 04 August 2016 15:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 56C1A12D0A5 for <>; Thu, 4 Aug 2016 08:13:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.288
X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c9pvwKJEdcMo for <>; Thu, 4 Aug 2016 08:13:16 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BCCC212B013 for <>; Thu, 4 Aug 2016 08:13:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1470323593;; s=june2016;; bh=xmmE3VQ4/ASzF/34zyoqfY7s/ykyEPTQjuWkHxtQgT8=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=ci/x4NO2qAljLpzzaTropuTRYn9ly8qggABzTHVc9CfZCGAgxOZkhw45PhDnl8J2wQm1TR Mzgx7bArdkxtc1Yt5X71Zl+ZlF2jeMriSgVXXjbrjq404ld9VOSb3xQCB3XGk465TehQ4t GVrnlikiGXZoI3bWGIR3tq4TpDOdCT8=;
Received: from [] ( []) by (submission channel) via TCP with ESMTPSA id <>; Thu, 4 Aug 2016 16:13:13 +0100
To: John C Klensin <>, "Murray S. Kucherawy" <>, IETF Apps Discuss <>
References: <> <E4AA7EB24E12F5FAE7D4C50B@JcK-HP8200>
From: Alexey Melnikov <>
Message-ID: <>
Date: Thu, 4 Aug 2016 16:12:51 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
In-Reply-To: <E4AA7EB24E12F5FAE7D4C50B@JcK-HP8200>
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [apps-discuss] Moving ahead with draft-ietf-appsawg-mdn-3798bis
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 04 Aug 2016 15:13:18 -0000

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.


> --On Wednesday, August 03, 2016 19:58 -0700 "Murray S.
> Kucherawy" <> wrote:
>> 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: <>
>> Date: Sun, Jul 31, 2016 at 10:23 AM
>> Subject: I-D Action: draft-ietf-appsawg-mdn-3798bis-09.txt
>> To:
>> Cc:
>> 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