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

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

Alexey,

(explicitly copying a few important/relevant people who may not
be actively following this list)

--On Friday, August 05, 2016 10:15 +0100 Alexey Melnikov
<[e-mail]> wrote:

>>> 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 you think you can get sufficient leadership and engagement, I
think the community would benefit from a sort of YAM-bis to draw
things back together.   Especially if/when the discussion gets
really technical, it would also move the work off this list,
which I see as an advantage. However, for reasons very similar
to Shawn's, I think the "EAI" work needs to be part of the
drawing-together process.  That applies not only to DSNs, but to
questions such as whether we are ready to start aggressively
pushing SMTPUTF8 and potentially discouraging the use of
encoded-words (while still requiring that they be accepted and
understood).  If we are not, we are getting to be in desperate
need of an Applicability Statement that is clear about what
implementers and operators actually should do. See below.
 
>> 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).

Not mine either but see Shawn's note, Arnt's comments, and so
on.  Creating a real or apparent long-term fork is in no one's
interest.  There is also the question of what one counts in the
SMTPUTF8 space -- Joseph is more likely than I am to have
details, but I believe we are above two independent
interoperable implementation on all components, even though some
of those implementations may not be fully conformant to the spec
and whose experience may argue for dropping some requirements or
features (again, see Arnt's notes, most of which have not been
posted to this list).  I don't know how to sort those issues out
without considering everything in the same context... and it
doesn't seem to me that advancing potentially-forking documents
piecemeal is consistent with that.

best,
   john