From: ietf-languages-bounces(_at_)alvestrand(_dot_)no [mailto:ietf-languages-
bounces(_at_)alvestrand(_dot_)no] On Behalf Of Bruce Lilly
There is nothing in RFC 3066 that says a registered tag must have 3 to 8
characters in the second subtag. It simply requires that any tag in which
the second subtag is 3 to 8 letters must be registered.
The following rules apply to the second subtag...
That does not permit tags with two-letter second subtags to be registered
in the IANA registry; it permits that only for "Tags with second subtags
of 3 to 8 letters". Granted, it could be clearer.
Are you familiar with the term "eisegesis"? You are "putting words in the
mouth" of the RFC. It does not say what you claim. You are very clearly
mis-interpreting it, as evidenced by the registry and by the text of the RFC
itself:
<quote source = RFC 3066, section 3>
This procedure MAY also be used to register information with the IANA
about a tag defined by this document, for instance if one wishes to
make publicly available a reference to the definition for a language
such as sgn-US (American Sign Language).
</quote>
You are, quite simply, mistaken on this point.
There is no reason to create a separate mechanism. When identifying
textual content,
Language is not exclusively associated with text. It is also a
characteristic of spoken (sung, etc.) material (but script is
not).
True, though at present, the vast majority of linguistic content on the
Internet is in the form of text. But this draft easily accommodates non-text
content: don't put in a script ID when it's not an appropriate thing to declare
about the content.
the identity of the writing system
Writing doesn't apply to spoken material, etc. There is nothing
in RFC 3282 or MIME that requires that Content-Language and/or
Accept-Language fields be used exclusively with written text.
And there's nothing in the draft that would require a language tag to have a
script ID.
In an inappropriate way. Without consideration for backwards
compatibility. In violation of the BCP that specified the syntax
and registration procedure.
Not inappropriate at all.
Specifying script for audio material is as inappropriate as
specifying charset. In Internet protocols, we do not burden
protocols with having to interpret charset information for
non-text material; we should not do so for script information.
This is silly. It's like arguing that xml:lang is a bad idea in the XML spec
because it can be used as an attribute on any kind of element, including
elements that happen not to contain linguistic content. So the draft would make
it possible for someone to tag audio material with a tag containing a script
ID; that doesn't mean people are going to be foolish enough to do so.
And all your repeated comments about lack of consideration for backwards
compatibility and violation of syntax and procedures of BCP47 have been
shown to be invalid.
Sorry -- saying so doesn't make it so. I have explained in
detail that an RFC 1766/3066 parser cannot be expected to
make sense of unregistered "sr-Latn-CS" etc. I have pointed
to specific second subtag length requirements in RFC 3066 for
registration.
You have misread RFC 3066 (see above), and that has already been pointed out in
earlier messages. I've been willing to be corrected when you have shown me to
be wrong; it's a bit frustrating that you don't seem willing to acknowledge
such a clear mistake.
Any your misreading of RFC 3066 has misled you regarding what an RFC 3066
parser should or should not be able to do with "sr-Latn-CS".
Peter Constable
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf