John,
it seems to me that you're really over-stating the risk of UTF-8.
I understand & agree that there may be systems out there which have
trouble displaying UTF-8.
However (!): I would think that it is sufficient that we can reasonably
assume that any *person* who needs to read an RFC does have access to a
Web browser less than 5 years old (picking a somewhat arbitrary number),
which *will* display UTF-8 just fine -- availability of fonts aside
(or is that your point?).
As a matter of fact, the IETF is telling protocol designers that they
*have* to support Unicode -- why can we require it for protocols, but
not for the documents we produce ourselves?
Regarding the other point about transmitting quotes from RFCs: of course
it's wise to phrase the normative parts of RFCs so that they don't
require transmission of non-ASCII characters. And yes, that needs to be
stated, if it isn't already.
On the other hand, it would be extremely useful to have examples that
*do* contain non-ASCII characters; if only to make implementers aware of
the fact they they can *not* rely on ASCII and things are going to work
(I've seen authors not doing I18N examples because they didn't know how
to publish them as RFC...).
BR, Julian
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf