Re: UTF8

[der Mouse <mouse%Rodents.Montreal.QC.CA@localhost>]

>   3.1.  What charset to use

>      All protocols MUST identify, for all character data, which
>      charset is in use.

> You would need to present a strong argument to the IESG why that
> doesn't apply to you.

But it does apply-- vacuously.  Because the whole problem is what to do
when you *don't* have "character data", just an opaque octet string.
(It probably is character data at some conceptual level, in a human
mind somewhere, but even assuming that that's always so, that level is
totally inaccessible to software.)

Of course, this is my take on it.  Niels seems to think that a right
answer is to just impose a character set on the octet string by fiat,
and given how alone I am in holding up my end of this question, that's
probably about what the WG position is going to end up being.  (And in
that case there is no question of violating the snippet you describe.)

I find it somewhat odd that the IESG considers it so impossible for
these things to be octet strings rather than character strings that
they're willing to not only approve a protocol that makes no provision
for octet strings, but, you say, to actively block a protocol that goes
out of its way to make octet strings possible.  But apparently I'm
alone in wanting to be able to use protocol fields that are
fundamentally octet strings to represent octet strings rather than
character strings; I can only infer that nobody else cares about
traditional Unices any longer.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse%rodents.montreal.qc.ca@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B