[apps-discuss] draft-ietf-appsawg-mdn-3798bis-12 and draft-melnikov-mdn-3798bis-eai-00

[John C Klensin <[e-mail]>]

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