At 17:34 24/08/2005, David Hopwood wrote:
JFC (Jefsey) Morfin wrote:
I would like to understand why
http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-12.txt
claims to be a BCP: it introduces a standard track proposition,
conflicting with current practices and development projects under way?
I've read this draft and see nothing wrong with it. Having a fixed,
unambiguous way to parse the elements of a language tag is certainly
a good idea. What specific current practices do you think it conflicts
with?
Dear David,
Before parsing the language tags many issues are to be considered
which have important consequences often out of the IETF scope (L8/9).
I could tell you I work on brain to brain interintelligibilty related
tools and projects for 25 years: the inadequation, the scarcity, the
centalised control of the proposed solution directly oppose the work
of my own R&D organisation. But you could object "too bad for you"
(we are used to that).
So, I will tell you something different. 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 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.
The Draft relates language tags to a centraly controled and managed
registry. This is a deprecating concept as the Internet distributed
nature becomes more and more a reality. This is fully documented by
the RFC on URI tags. That RFC proposes some examples, using standard
Internet schemes. It would be great if you could show me how the
Draft can support 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 is why I would be more than gratefull if you could
show me how the ABNF is "already flexible enough" to support them.
Deep thanks.
jfc
--
David Hopwood <david.nospam.hopwood@xxxxxxxxxxxxxxxx>
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf