--On Thursday, September 20, 2012 15:03 -0500 Ben Campbell <ben@xxxxxxxxxxx> 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