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

Alexey Melnikov <> Fri, 05 August 2016 09:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9ED9112D80B for <>; Fri, 5 Aug 2016 02:15:40 -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 U8tqlYU8KNl7 for <>; Fri, 5 Aug 2016 02:15:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 909EE12D68F for <>; Fri, 5 Aug 2016 02:15:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1470388537;; s=june2016;; bh=cIvPq7LVzNT6XaOLhZWU90860osMBhXLYnSs7HlmrPU=; 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=T/bd2O/1xP40eRvkT1L9dwbvJl1CQn2nvml+pGo1n2QCHlWlsNEiRY8ZZ3ZfFo9JjDFzPL DP+H7NKR7Hh8v1Q0+kur7+1GPFlzjHfpSYq0KLhTOyrL1Cf1udjSu+B5PUrz9tWRWRbFTM xe0fdhnLcpaPMrAzDoLdSjFCMCrLoGU=;
Received: from [] ( []) by (submission channel) via TCP with ESMTPSA id <>; Fri, 5 Aug 2016 10:15:37 +0100
To: John C Klensin <>
References: <> <E4AA7EB24E12F5FAE7D4C50B@JcK-HP8200> <> <47872C0B5B5198E8126F5469@JcK-HP8200>
From: Alexey Melnikov <>
Message-ID: <>
Date: Fri, 05 Aug 2016 10:15:09 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
In-Reply-To: <47872C0B5B5198E8126F5469@JcK-HP8200>
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc: IETF Apps Discuss <>
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: Fri, 05 Aug 2016 09:15:41 -0000

Hi John,

On 04/08/2016 17:11, John C Klensin wrote:
> 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
> <> 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,
>>> 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.
> 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,
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
> 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.
This is not my preferred approach, considering that RFC 6533 is not as 
widely deployed as RFC 3798 (and its predecessors).

Best Regards,