Re: Last Call: 'Tags for Identifying Languages' to BCP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.nospam.hopwood@xxxxxxxxxxxxxxxx>


_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]