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.