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

[David Hopwood <[e-mail]>]

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 <[e-mail]>


_______________________________________________
Ietf mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf