On 10/17/2012 2:32 PM, Ned Freed wrote: > Channeling my inner Maslow, I see the present text as best, an additional > sentence or two as next best, a sentence and a cite to the downgrade doc next > in line, and including actual EAI examples in this doc as the worst choice.
The problem I have with the current text is that it says 'what' motivated the change, but not how it is useful for the intended class of uses. The reader is left entirely to guess.
Self-actualization among the inadequately-informed invites fantasy more than it invites utility.
That depends on both the utility and the desirability of repeating the existing use case, doesn't it? The EAI use case of downgraded messages is one that only exists because of a nasty confluence of restrictions and which we absolutely do not want to see repeated in any other context. If you really think this is important to explain why we're making this change against the overall context of RFC 5322 - and I most certainly do not agree that it is important to do so - then the best "use case" to add is the negative one: The elimination of an unnecessary restriction that isn't followed in practice. I see no way to explain the narrow EAI use case in this context without either dragging in a whole bunch of EAI that has no business being here or leaving various things dangling. Either way the average reader looking at general message usage isn't going to get it, and the more you try and waltz around this the more likely you are to get exactly the outcome you fear: Someone is going to see some sort of parallel with some problem they are trying to solve (some sort of deliberate form of address obfuscation scheme immediately comes to mind) and proceeds to make a mess of things. Ned P.S. It really would be best if this could wait until there was an update to RFC 5322. But that's not how the timing has worked out, so this is the best alternative available.