Re: I-D ACTION:draft-hoffman-utf8headers-00.txt

Keith Moore <[email protected]> wrote:

> > UTF-8 header fields are likely to fall unexpectedly into the hands
> > of software that doesn't know how to handle them.  If UTF-8 header
> > fields use the same field names as the corresponding ASCII header
> > fields, there's no telling what will happen.
>
> but using new field names for utf-8 versions of existing fields has
> other pitfalls - e.g. that the utf-8 and ascii versions can get out of
> sync,

That is indeed a concern that does not arise if UTF-8 header fields use
the same field names as ASCII header fields.

> that the utf-8 fields will get converted to 2047 or bit-stripped, etc.

That concern applies equally regardless of whether UTF-8 header fields
use the same field-names as ASCII header fields.

Charles Lindsey <[email protected]> wrote:

> > There seems to be assumption here that existing "8-bit clean"
> > software will automagically understand "UTF-8 header fields" that
> > use the same field-names as existing ASCII header fields.
>
> Eh? Of course they will, because those ASCII header fields are already
> correct UTF-8.  Nothing automagic needed there.

Non-ASCII field contents are invalid according to the spec that was
in force when all existing implementations were written.  Therefore
feeding non-ASCII field contents to those implementations is asking for
unpredictable behavior.  Some implementations will say "sorry, can't
parse that", but others will think they can parse it, and what are the
chances that they parse it correctly, and do the correct thing with
whatever protocol elements they find, according to a spec that didn't
exist when the implementation was created?

> > But "UTF-8 header fields" have not even been defined yet, and there
> > are plenty of important details to work out.
>
> Right, these are issues not discussed in Pete's present draft, but
> they need to be.  So here is a stab at it:
>
> [[ many suggestions for new rules and new implementations ]]

You suggest several things that new implementations will need to do to
properly handle UTF-8 headers.  As long as they're going to be doing all
that, it would be a negligible additional burden to handle a prefix like
"8:".  In exchange for that tiny burden, we would get the benefit that
old software, which knows nothing of the new rules, will be much less
likely to blindly charge ahead and try to process data that it was never
designed to handle properly.

AMC