Re: [EAI] Results of the IESG telechat with respect to the four EAI documents

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

Barry,

Thanks.  A few comments inline below.

--On Thursday, September 27, 2012 20:15 -0400 Barry Leiba
<[e-mail]> wrote:

> The IESG discussed the four EAI documents on today's telechat
> (Thursday, 27 Sept 2012).  All will likely soon be approved,
> pending some updates.
> 
> Three of the documents (5738bis and the two downgrade docs)
> have DISCUSS positions held by Russ and Benoit, related to the
> normative nature of the downgrade docs and their Standards
> Track status.  We believe that the following edits will clear
> those discusses, and that these edits retain the working
> group's consensus for these documents. I recommend that the
> chairs look these over and ask the document editors to make
> them forthwith.
> 
> --------------------------------------------------------------
> -- draft-ietf-eai-5738bis, Section 7
> 
> OLD
>    Choices available to the server when a message that
> requires SMTPUTF8    is encountered and the client doesn't
> enable UTF-8 capability include    hiding the problematic
> message(s), creating in band or out of band    notifications
> or error messages, or somehow trying to create a    variation
> on the message with the intention of providing useful
> information to that client about what has occurred.  Such
> variant    messages cannot be actual substitutes for the
> original message:
> 
> NEW
>    Choices available to the server when a message that
> requires SMTPUTF8    is encountered and the client doesn't
> enable UTF-8 capability include    hiding the problematic
> message(s), creating in band or out of band    notifications
> or error messages, or somehow trying to create a    variation
> on the message with the intention of providing useful
> information to that client about what has occurred.
> 
>    In creating a variant message, it is important to use an
> algorithm    that has been carefully engineered to present
> useful information to    the user, while not creating security
> or operational problems in the    mail system.  For this
> reason, implementations that choose this    option MUST use a
> standard algorithm.  Two such standard algorithms    are
> introduced in the next paragraph.
> 
>    Such variant messages cannot be actual substitutes for the
> original    message: [...etc...]

As Pete and I discussed briefly on Jabber during the telechat, I
think "MUST use a standard algorithm" is inappropriate for at
least two reasons:

(i) It does not meet the 2026 criterion of being necessary to
assure interoperability.  Note in particular that 2026 Section 6
says "For    example, they must not be used to try to impose a
particular method on implementors where the method is not
required for interoperability."  While the intent is a little
different, that is precisely what a MUST does in this case.
Yes, the argument in the previous paragraph is, IMO, correct and
important (and one I helped make).  But someone who understands
both models could easily design and implement a hybrid (applying
the information-retaining features of popimap-downgrade to one
or two header fields but otherwise following the simpledowngrade
rules.  That might or might not be wise and/or even sensible,
but it would not be any more of an interoperability problem than
either of the two specs alone would be.

(ii) Putting in a MUST on this subject invites people to ignore
us.  Some will ignore us and get things right, others will
ignore us and get them wrong.  We would, IMO, actually be in a
stronger position if we said something like "SHOULD use a
standard algorithm.  An exception might be justified if the
algorithm chosen is either a combination of the standard models
that does not introduce any new issues or if the implementer is
confident that the select different procedure has achieved at
least the same quality of community review that went into the
standard algorithms."

WG, consider this a call for comments and consensus: If others
don't see this issue as significant, I'll drop my concerns and
encourage the authors to use the language Barry proposes.  If
there are a significant number of people who share one or both
of my concerns, I'm prepared to push back with an appeal if that
is necessary.

> --------------------------------------------------------------
> -- draft-ietf-eai-popimap-downgrade, Section 1.2
> 
> OLD
>    2.  The message may be downgraded by the POP or IMAP
> server, in a way        that preserves maximum information at
> the expense of some        complexity.
> NEW
>    2.  The message may be downgraded by the POP or IMAP
> server, in a        standard way that preserves maximum
> information at the expense of        some complexity, and does
> not create security or operational        problems in the mail
> system.

This actually doesn't seem to add anything non-obvious to the
document, but I don't see it as harmful.   That said, I believe
that "does not create security or operational problems..." is a
much stronger assertion than can be justified.   By any measure,
replacing a message that the sender intended to be delivered as
sent, without loss of information, with all integrity checks
intact, and that can be replied to with a surrogate that may
lack all of those properties is an "operational problem".  

Again, if others are comfortable with the new language, I can
live with it.  But, if not, we will need to figure out how to
proceed.

> --------------------------------------------------------------
> -- draft-ietf-eai-simpledowngrade, Section 1
> 
> OLD
>    This document specifies a way to present such messages to
> the client.    It values simplicity of implementation over
> fidelity of    representation, since implementing a
> high-fidelity downgrade    algorithm is likely more work than
> implementing proper support for    [RFC5721] and/or [RFC5738].
> 
> NEW
>    This document specifies a standard way to present such
> messages to    the client -- a way that does not create
> security or operational    problems in the mail system.  It
> values simplicity of implementation    over fidelity of
> representation, since implementing a high-fidelity
> downgrade algorithm is likely more work than implementing
> proper    support for [RFC5721] and/or [RFC5738].

Cosmetic.  If it amuses the IETF to insert the word "standard"
in this or other places, I don't see why we should worry about
it.
 
> --------------------------------------------------------------
> 
> I'll note that these edits will still allow the references to
> the downgrade docs from 5738bis to be informative -- they do
> NOT need to be changed to normative.  With these edits, Russ
> (and, we believe, Benoit) will accept the downgrade docs as
> Standards Track.  (It's possible that the edits to the
> downgrade docs might not be absolutely necessary, but I think
> it's good to emphasize that the engineering behind them had a
> reason, and that it's an important aspect.)

> In addition, all editors should please check the non-blocking
> AD comments that have not been addressed yet, and work with
> the chairs to do a good-faith effort at addressing them.  Some
> might merit text changes, while others might just need a
> response to the AD.

> http://datatracker.ietf.org/doc/draft-ietf-eai-rfc5721bis/ball
> ot/       Comments by Pete, Sean, and Stephen.

Authors should have received copies of most or all of those
comments when they were made and should have seen responses from
me to several of them.  If you believe those responses are
adequate, just say so -- you are not obligated to respond again
unless Barry or Pete really want additional conformation.

> http://datatracker.ietf.org/doc/draft-ietf-eai-5738bis/ballot/
>       Comments by Adrian, Robert, Sean, and Stephen.
> 
> 
> http://datatracker.ietf.org/doc/draft-ietf-eai-popimap-downgra
> de/ballot/       Comments by Robert and Stephen.
> 
> 
> http://datatracker.ietf.org/doc/draft-ietf-eai-simpledowngrade
> /ballot/       Comments by Robert and Stephen.
 
> The 5738bis editors should also take care to address the
> comments made by Timo and Alexey -- I will not be approving
> that document until that's been cleared up.  Pete, you were
> going to try to work on this with Sean, I believe.
> 
> I think 5738bis will definitely need a revised I-D.  Changes
> to the others might be done with an RFC Editor note, depending
> upon what other changes (besides what's above) are needed.
> Pete can decide that, as the responsible AD for the other
> three documents.

Let me express a strong preference for new drafts of any
document that requires more than a very small number of trivial
and obvious changes (I think that means all of them, but haven't
checked back over my list of the comments).   The cleaner we can
make the documents that go to the RFC Editor, the less likely
they are to make errors, the more rapidly they can get the
documents out, and the less time-consuming hassle we will have
at AUTH48.   It remains reasonable to insert a note into a
document that a particular sentence or paragraph needs an
editorial re-working if it is hard to follow and you aren't sure
how to fix it: pointing out something to which the RFC Editor
should pay extra attention is appropriate and they are good at
their work.

    best,
    john

> 
> Barry
> _______________________________________________
> IMA mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ima