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

From: Barry Leiba <[email-masked]>
Date: Thu, 27 Sep 2012 20:15:46 -0400

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...]

----------------------------------------------------------------
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.

----------------------------------------------------------------
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].

----------------------------------------------------------------

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/ballot/
      Comments by Pete, Sean, and Stephen.

   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-downgrade/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.

Barry

---

From: John C Klensin <[email-masked]>
Date: Thu, 27 Sep 2012 23:49:27 -0400

Barry,

Thanks.  A few comments inline below.

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

> (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
>    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-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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ima

---

From: Barry Leiba <[email-masked]>
Date: Fri, 28 Sep 2012 00:48:09 -0400

> think "MUST use a standard algorithm" is inappropriate for at

I understand your reasons.  I don't know if a "SHOULD use a standard
algorithm" would satisfy Russ and Benoit.  You could ask, and try
engaging them further on the question.

> That said, I believe

Well, certainly feel free to change that phrase in all three places.
It's what I came up with; that doesn't make it right.  I think you
know what I'm trying to say, so if you (or the WG) comes up with
different language that gets the point across I think it will be fine.

> in this or other places, I don't see why we should worry about

As I said, I don't know that that's necessary.  The key part is the
change to Section 7 of the IMAP spec.

> unless Barry or Pete really want additional conformation.

I just listed the ones that are there and that I don't explicitly
remember seeing addressed.  It's possible that they all have been, in
which case this is an easy step.  Just making sure we have it covered.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Fri, 28 Sep 2012 01:17:34 -0400

> engaging them further on the question.

On re-thinking this, I'll say two things:

1. 2119 also allows MUST "to limit behavior which has potential for
causing harm."  One thing we're saying is that if you don't do this
right, it's likely to cause harm in some significant way -- having a
(wrong) replyable address, otherwise misleading the user, whatever.  I
think MUST is justified on those grounds.

2. If the WG really *are* saying that these two algorithms are just
examples, and you can roll your own, taking this from this and that
from that, and making things up on your own (like Franck's idea of
just reserving a bogus local-part and leaving the domain alone)...
then I think I *agree* with Russ that there's no reason to make these
two Standards Track.

But I don't think that's what the WG are saying.  We spent a lot of
time engineering these quite carefully, and there's a reason we had to
do that.  The message is (and should be), "Don't try this at home."

Barry

---

From: "John Levine" <[email-masked]>
Date: 28 Sep 2012 05:45:38 -0000

>engaging them further on the question.

I prefer SHOULD, but not enough to get into a fight with Russ and
Benoit.  Since SHOULD roughly means "MUST unless you're sure you
know what you're doing", that seems appropropriate.

It is true that we spent a long time thinking about this, and there
are plenty of superficially plausible approaches that turn out to have
serious problems, so they're right that you shouldn't make up
something at random.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Fri, 28 Sep 2012 02:49:08 -0400

--On Friday, September 28, 2012 01:17 -0400 Barry Leiba
<[email-masked]> wrote:

>>> 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 understand your reasons.  I don't know if a "SHOULD use a
>> standard algorithm" would satisfy Russ and Benoit.  You could
>> ask, and try engaging them further on the question.
> 
> 1. 2119 also allows MUST "to limit behavior which has
> potential for causing harm."  One thing we're saying is that
> if you don't do this right, it's likely to cause harm in some
> significant way -- having a (wrong) replyable address,
> otherwise misleading the user, whatever.  I think MUST is
> justified on those grounds.

Sure.  "MUST be careful", "MUST not screw up", "MUST protect the
client from receiving anything that does not conform to the base
POP or IMAP specs at least as far as headers are concerned"
would all be appropriate statements to "limit behavior... harm".
"MUST run only protocols that have received the IETF seal of
approval" is nonsense unless you believe that the IETF have a
inherent monopoly on quality specifications in this area.  It
also requires you to believe that, e.g., popimap-downgrade will
be safer two months from now (or whenever it is approved and
then published) than it is today despite absolutely no change in
the specification itself.  The latter possibly takes us out of
the "stamp of approval" regime and into a regime in which one
believes that the IETF anoints protocols and that the anointment
process gives them extra magical powers (or at least safety
properties). 

> 2. If the WG really *are* saying that these two algorithms are
> just examples, and you can roll your own, taking this from
> this and that from that, and making things up on your own
> (like Franck's idea of just reserving a bogus local-part and
> leaving the domain alone)... then I think I *agree* with Russ
> that there's no reason to make these two Standards Track.

But I didn't say a word about "making things up on your own".
Franck's idea isn't present in ether spec, so using it would not
be conformant in the synthesis model I am suggesting.

Backing up a step, there is a protocol the WG did not decide to
write up.  Let's call it "flexible downgrade" to contrast it
with "simple downgrade" and "maximum information preservation
downgrade" (aka popimap-downgrade).  From a 10,000 foot level,
it soul contain a collection of operations, just like
popimap-downgrade does today but also including the operations
that appear in/for simpledowngrade.  Then, much like
popimap-downgrade, it would have a case for each relevant header
fields (or group of them).  The case would say "for this header
field, either do <the simple thing> or perform <whatever the
current applicable popimap-downgrade operation is>... as in "you
MUST do one or the other for that header field type".  

There are several reasons why such a spec would be a bad idea,
but let's ignore them for the present.  Suppose that spec had
been written.  We could then either lose the standalone
simpledowngrade and popimap-downgrade specs entirely or convert
them into profiles (e.g., "simpledowngrade" would be defined as
"always pick column A" and popimap-downgrade would be defined as
"always pick column B".   One spec, no competing standards, two
profiles but not bar on creating more.   We wouldn't be having
this conversation because there wouldn't be competing specs and,
while I wouldn't be happy with it, I could tolerate a MUST for
the spec because it would generate all of the surrogate message
cases we have evaluated and have reason to believe  are ok.

> But I don't think that's what the WG are saying.  We spent a
> lot of time engineering these quite carefully, and there's a
> reason we had to do that.  The message is (and should be),
> "Don't try this at home."

Agreed.  What we are quibbling about is the meaning of "this".
And a SHOULD allows for the difference between "if anyone tries
this, ever, the IETF deity will strike you with its
thunderbolts" and "you shouldn't try this unless you are a
professional driver and 'home' is a closed track".

   john

---

From: Dave Crocker <[email-masked]>
Date: Fri, 28 Sep 2012 10:50:36 -0700

...
>     Such variant messages cannot be actual substitutes for the original

The haggling over must vs. should is not irrelevant, but there's a 
deeper problem with the proposed solution:  It uses the word 'standard' 
as a kind of magic handwave, rather than a precise, technical (or 
process) term: "implementations that choose this option MUST use a 
standard algorithm".  What does that mean?

So, the text defines a criterion ("present useful information to the 
user, while not creating security or operational problems") but no basis 
for determining what algorithms satisfy it and what don't AND no 
on-going process for registering algorithms deemed worthy.  Hence, it is 
not possible to know whether the normative condition has been satisfied.

> draft-ietf-eai-popimap-downgrade, Section 1.2
...
>        problems in the mail system.

same problem

My suggestion is to drop the word standard, define a registry and make 
adding entries to it carry the Specification Required condition.  (Feel 
free to argue for any of the more-stringent conditions; I'm merely 
suggesting the lowest process bar that makes sense to replace the word 
'standard'.)

d/
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net