[apps-discuss] draft-ietf-appsawg-mdn-3798bis-12 and draft-melnikov-mdn-3798bis-eai-00
John C Klensin <john-ietf@jck.com> Fri, 12 August 2016 15:37 UTC
Return-Path: <john-ietf@jck.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFEBC12D13B for <apps-discuss@ietfa.amsl.com>; Fri, 12 Aug 2016 08:37:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level:
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgGiCOuuuKfy for <apps-discuss@ietfa.amsl.com>; Fri, 12 Aug 2016 08:37:01 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9196512D603 for <apps-discuss@ietf.org>; Fri, 12 Aug 2016 08:37:00 -0700 (PDT)
Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1bYEW3-0005Qa-BD; Fri, 12 Aug 2016 11:36:59 -0400
Date: Fri, 12 Aug 2016 11:36:54 -0400
From: John C Klensin <john-ietf@jck.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>
Message-ID: <54A0127BF1E106F08CE6CF58@JcK-HP8200>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/apps-discuss/y71aD44y-r8TiY4eUO15NZ-WmhI>
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] draft-ietf-appsawg-mdn-3798bis-12 and draft-melnikov-mdn-3798bis-eai-00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Aug 2016 15:37:03 -0000
Hi. Ok, I'm confused. Just in case I'm not the only one, I notice that these two drafts have been posted within the last 24 hours and that draft-melnikov-mdn-3798bis-eai-00.txt seems to be identical to draft-ietf-appsawg-mdn-3798bis-12.txt except that the former adds a new Section 3.4 titled "UTF-8 Message Disposition Notifications" which appears to replace most of RFC 6533. Some questions: (1) Is the intent to have draft-melnikov-mdn-3798bis-eai replace draft-ietf-appsawg-mdn-3798bis? If so, why not say so in the drafts and tracker? (2) If the intent is to progress draft-ietf-appsawg-mdn-3798bis to Internet Standard and then use draft-melnikov-mdn-3798bis-eai to "update" it, doesn't that get us tangled up with the forking problems discussed in previous postings? In addition, because, AFAICT, that sequence of actions would result in a Proposed Standard updating or replacing an Internet Standard, doesn't it open that can of worms and the resulting confusion about just what is "the standard"? (3) draft-melnikov-mdn-3798bis-eai indicates that it updates RFC 6533, but contains no indication of just what it updates and what it leaves in place. Some of the material in Section 3.4 seems to make reference to 6533 text, but the relationship is not clear. At least an explanation of what is changed/replaced and what remains seems necessary to proper review and consideration of this document as well as to allowing implementers to figure out what we expect them to do. For all of the reasons in the "fork" thread/discussions, it would be far preferable, IMO, to copy what is needed and simply obsolete 6533. (4) The historical RFC Editor nominal upper limit for an abstract is 13 lines, a limit that (deliberately) approximately the rules in the style guides of other technical publishers. Significantly longer discussions are usually seen as executive summaries, not abstracts, or as very exceptional cases. The abstract in these documents seems to be about 23 lines long (a few less if one does not count the blank lines between paragraphs, one more if "RFC 6533" is added to the last sentence of the one in the "eai" version, which seems necessary for consistency). Can this be trimmed back? Or are there exception circumstances of which I'm not aware? Recommendations: (i) Unless there is a compelling reason for advancing MDNs to Internet Standard now, drop draft-ietf-appsawg-mdn-3798bis and focus on the "eai" specification so that we don't have two documents that apply to the same subject matter and that are nearly identical except in one section in the pipe at the same time. If there is such a compelling reason, it should be made explicit for the community. (ii) Improve the "eai" specification to explain its relationship to 6533, include additional 6533 materials as needed, and obsolete 6533. Once that is done and published, track implementations of that spec closely and move the whole business to Internet Standard as soon as possible (ideally by reclassification rather than yet another document). (iii) If it is not feasible or desired by the community to set draft-ietf-appsawg-mdn-3798bis aside, it should incorporate a clear A/S discussing its applicability relative to 6533 and possible replacements for 6533. Assuming good sense is still a stronger principle in the IETF than the many rules we keep inventing, there should be no problem with either incorporating such a statement and explanation in an Internet Standard or a separate, normatively-reference document. Just my opinion, but I remain concerned about causing confusion about what should be implemented, creating real or apparent forks, and impeding development and deployment of the SMTPUTF8 collection. I don't think reviewing progressing these two, nearly-identical, drafts helps with any of those issues. best, john
- [apps-discuss] draft-ietf-appsawg-mdn-3798bis-12 … John C Klensin