Re: [EAI] [eai] #11: Capture the scenario of "SHOULD not use UTF-8 in Message-ID" for future advice draft

[[e-mail]]

> On 9/19/2011 7:58 AM, [e-mail] wrote:
> >>   "Implementers of message-id generation algorithms may prefer to restrain
> >>   their output to ASCII since that has a few minor advantages, such as when
> >>   constructing References fields in mailing-list threads where some senders
> >>   use EAI and others not."


> I looked over the draft, and this language made me very uncomfortable.

I don't see why. It's a fact that using 8-bit utf-8 in message-ids (1) isn't
really necessary and (2) creates a situation where replies are forced to be EAI
messages when otherwise they may not have needed to be. Saying that  generators
of such fields need to be aware of the consequences seems completely reasonable
to me, and it also aligns quite well with the nearby sections on line limits,
encoded words, and encoding restrictions, all of which have very much the same
overall character as this.

> The reason is that -- once again -- it has this draft trying to juggle a hybrid
> (UTF-8/ASCII-only) world, rather than a much simpler UTF-8 only world.  Indeed,
> the language that results looks awkward.

No, it really isn't doing that.

> A simple question is why this juggling is appropriate here but not in the rest
> of the core drafts, including this one?

Since the juggling you refer to is in fact nonexistent, this question is 
unanswerable.

> For the situations that need this special treatment, why do they /not/ also need
> it for all other occurrences of UTF-8.

Because they aren't comparable cases. Again, there is no real need to generate
utf-8 message-ids - these are fields for automatic processing, not presentation
to the user. The same cannot be said for addresses, subject fields, etc. etc.
And yes, there are other automatically processed fields where we're now
allowing 8-bit utf-8, but AFAIK none of them have the additional cascading
effect message-ids have. (And if someone can identify additional cases they
should also be noted in this specification.)

In short, this is a special case, one that arises from a combination of
factors, and for that reason it's worth noting.

> And in answering that question, consider
> whether those are edge conditions or likely to be typical.

The message-id issue is most certainly going to create issues for clients.

				Ned