JFC (Jefsey) Morfin wrote:
[...] Today, the common practice of
nearly one billion of Internet users is to be able to turn off cookies
to protect their anonymous free usage of the web. Once the Draft enters
into action they will be imposed a conflicting privacy violation: "tell
me what you read, I will tell you who you are": any OPES can monitor the
exchange, extact these unambigous ASCII tags, and know (or block) what
you read. You can call these tags in google and learn a lot about
people. There is no proposed way to turn that personal tagging off, nor
to encode it.
I don't know which browser you use, but in Firefox, I can configure exactly
which language tags it sends. If it were sending other information using
language tags as a covert channel (which it *could* do regardless of the
draft under discussion), I'd expect that to be treated as at least a bug,
and if it were a deliberate privacy violation, I'd expect that to cause a
big scandal.
I support it as a transition standard track RFC needed by some, as
long as it does not exclude more specific/advanced language
identification formats, processes or future IANA or ISO 11179
conformant registries.
The grammar defined in the draft is already flexible enough.
(I suppose you mean more than just grammar. Talking of the ABNF is
probably clearer?).
I am certainly eager to learn how I can support modal information (type
of voice, accent, signs, icons, feelings, fount, etc.), medium
information, language references (for example is it plain, basic,
popular English? used dictionary, used software publisher), nor the
context (style, relation, etc.), nor the nature of the text (mono,
multilingual, human or machine oriented - for example what is the tag to
use for a multilingual file [printed in a language of choice]), the date
of the langtag version being used, etc.
I mean that the grammar is flexible enough to encode any of the above
attributes (not that it would be useful or a good idea to encode most
of them).
The Draft has introduced the "script" subtag in addition to RFC 3066
(what is an obvious change). However in order to stay "compatible" with
RFC 3066, author says it cannot introduce a specific support of URI
tags.
This objection seems to be correct: URI tags include characters not
allowed by RFC 3066. But you could easily encode the equivalent information
to an URI tag, if you wanted to.
--
David Hopwood
<david(_dot_)nospam(_dot_)hopwood(_at_)blueyonder(_dot_)co(_dot_)uk>
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf