draft-phillips-langtags-08, process, specifications, and extensions

[Peter Constable]

> From: ietf-languages-bounces at alvestrand.no [mailto:ietf-languages-
> bounces at alvestrand.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