Re: [Gen-art] Gen-ART LC Review of draft-ietf-eai-popimap-downgrade-07

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

--On Thursday, September 20, 2012 15:03 -0500 Ben Campbell
<[e-mail]> wrote:

> Hi,
> 
> Email discussion about the simple downgrade draft made me
> think of a concern that I think I failed to mention in my
> review. In particular, the "tunneling" mechanism allows the
> creation of several new "Downgraded-*" header fields
> containing encoded content from the original message. Given
> that downgraded messages are primarily to be consumed by
> legacy clients, which we can assume do not know anything about
> this draft, why would we expect the clients to present those
> headers to the user, or otherwise notify the user of their
> existence?

Ben,

Many participants in the WG agree with you that the relatively
complex effort to preserve information represented by
popimap-downgrade isn't worth the trouble.  That is one of the
reasons the simple downgrade doc exists and why some
participants prefer "forklift or no message" strategies.

But I think you are missing an important part of the puzzle,
which is that the audience for those downgraded messages isn't a
client but a user.  A user who gets an obviously-bogus message
(weird headers, can't reply, etc.) will presumably do something.
If that "something" is to discard the message as trash, then
that user is no worse (or better) off than if the message had
been blocked or discarded earlier in the works.   If a server
operator can predict that behavior, then she is probably better
off configuring a "no downgrade" strategy.  But, if the user
enlists the help of other resources (organized help desks,
well-written FAQs, helpful relatives,...) having that resource
able to differentiate between these two downgrade models and
something random and then say for this case "better retrieve and
examine the full set of headers" actually is useful.   

That also means that having a relatively small number of
well-documented downgrade mechanisms is useful and maybe
important.  That, in turn, does raise the character of those
downgrade specs to "if you want to do this, do it this way"
standards rather than "this is how we think it could be done,
but do as you like" informational specs.  From my point of view,
that _is_ an interoperability issue, albeit interoperable with
users and their support structures not (merely) between server
and client.  

There are also some server-> legacy client (yes, one that
doesn't have a clue that UTF-8 headers might be
encountered/valid) interoperability issues on which the WG spent
a lot of energy because it would be pretty easy for a server to
send something to a legacy client that would break it, rather
than just creating a surrogate message that contains different
information (or differently-organized information) than the
original.  There was a lengthy discussion about alternative ways
to represent backward-pointing UTF-8 addresses that concluded
with the use of encoded words and group syntax because of just
that sort of interoperability consideration and the WG's
conviction that some other strategies would create much greater
risks.

YMMD, but I think the above fairly accurately represents the
rough consensus of the WG after lengthy discussion of the issues
involved, including good approximations to the ones you have
raised.  Unless you have something new to add (ideally after
reviewing the archives), I think we should put the topic to rest.

best.
   john