On 16.03.2010 00:37, Masataka Ohta wrote:
Julian Reschke wrote:
People can read/edit their local characters.
People can't read/edit local characters of other people.
A conservative approach would be:
1) allow non-ASCII contact information *in addition* to the ASCII version
2) allow non-ASCII in I18N example
No. The conservative approach currently deployed is to have ASCII
contact information only, which is enough.
*A* conservative approach != The *most* conservative approach.
for 1), it really doesn't matter whether everybody can read it;
just stick with the ASCII version
for 2), we should be able to identify a few non-ASCII characters that
are suitable for use in I18N examples which *do* work widely (a few
Greek capital letter 'A', which is identical to Latin chapital
letter 'A', is already tooooo much.
I don't see your point. If it's identical it makes a poor choice for
demonstrating I18N. It *would* be a good choice for demonstrating
HTML is already too complex and unstable that there is no hope that
The current version is 4.01, and it has been stable since 1999. The next
version, 5, is approaching Last Call, and is unlikely to break anything
that is actually in use.
With more than 40 years of history of RFC, HTML is unstable.
HTML is *relatively* unstable compared to text/plain (we're comparing
formats, not character sets, right?).
Anyway, it's clear that you're not going to convince me, and I'm not
going to convince you.
Even compatible ones? Just asking...
Tools does not support restricted profile very well, as was
demonstrated by a circled 'R' character in a
I don't think anything was demonstrated at all. If we wanted to test an
HTML profile, we'd first have to agree on it, and then put the checks in
place. This hasn't happened yet, so, by definition, nothing was
demonstrated proving or disproving it can be done.
Best regards, Julian
Ietf mailing list