sgn-MT [et al.]: new RFC 3066 tag[s]
dewell at adelphia.net
Mon Oct 4 04:49:18 CEST 2004
Georg Schweizer <gschweizer at gmx dot at> wrote:
> I still think that we should retain the possibility to register
> generic extensions (e.g., ISO 3166 codes as sub-tags of ISO 639
> ... for instance if one wishes to make publicly available a
> reference to the definition for a language such as sgn-US
> (American Sign Language). [Sec. 3, RFC 3066]
This passage seems to have been included *specifically* to allow the
registration of sgn-* tags, which were already permitted by the
generative mechanism, to narrow them down so that each tag specifies a
single language, instead of the set of sign languages that might be used
in a given country.
If a special syntax is added to RFC 3066bis to support this special use
of sgn-* tags, the passage is not necessary. There doesn't seem to be a
pressing need to provide additional references for non-sign languages or
variants whose tags can already be generated.
> In fact the choice of "sgn-US" for any sign language other than ASL
> would not be valid anyway, because tags will have to be chosen "as
> precise as possible, but no more specific than is justified" [Sec.
> 2.3, RFC 3066bis draft-06].
> Thus it appears that (under RFC 3066bis) the registration of such a
> generic language tag would not contravene earlier semantics.
It is not true that, even if a special registration did not exist,
"sgn-US" could only mean American Sign Language. We know that American
Sign Language is not the same as Martha's Vineyard Sign Language
(encoded as sgn-US-MA) or Hawai'i Pidgin Sign Language (encoded as
sgn-US-HI). Both of these are sign languages used in the United States,
which is the literal meaning of "sgn-US" according to the generative
mechanism. (Whether that constitutes a legitimate language tag is
> The only thing I'm afraid of is that this could lead to a long list of
> unnecessarily registered codes. I suggest to add another criteria than
> the desire for "publicly available reference", one that could also be
> applied to "sgn" extensions.
If we just add a special syntax for sgn-* codes, we won't need such a
generic mechanism that opens the door for everyone to register their
favorite dictionary of CB trucker lingo.
More information about the Ietf-languages