Registered sgn-* tags

[Doug Ewell]

Peter Constable <petercon at microsoft dot com> wrote:

>> Would these not have been valid under the generative grammar of RFC
>> 3066?  We have sgn-BR for Brazilian Sign Language, sgn-CO for
>> Colombian Sign Language, and so forth.  How does this differ from
>> "Sign Languages as used in Brazil," "Sign Languages as used in
>> Colombia," etc. which would be the interpretation according to the
>> generative grammar?
>
> These interpretations are *not* the same. There can be (and in some
> cases are) multiple, distinct signed languages used in a single
> country. The interpretation cannot be "Sign Languages as used in
> [country X]".
> ...
> These are cases in which it cannot simply be assumed that the
> semantics of the whole can be derived by merely registering the
> semantics of the subtag.

Well, then we have another problem.

RFC 3066bis says that if a previously registered tag can be generated
using existing subtags, then the tag MUST be considered to be
"superseded" (I'll ignore the bit about "marked" for now).  That goes
for zh-Hant and en-boont, as the draft points out.

What about sgn-US?  This can be generated, not only under the new RFC
3066bis mechanism, but even under the old RFC 3066 language-country
mechanism.  In either case, the generative meaning of sgn-US would
logically be "Sign Languages as used in the United States."  That's what
you get when you concatenate the meaning of "sgn" and the meaning of
"US".

But Peter says that "Sign Languages as used in the United States," the
combined semantics of the parts, is not an acceptable alias name for
"American Sign Language,"  the semantics of the whole.  If we want to
record the semantics of the whole, we have to register the tag as a
whole, right?  But RFC 3066bis says we can't do this; we have to
supersede the tag and consider it to be the sum of its registered parts.

See, RFC 3066 didn't say this.  Actually, RFC 3066 said you couldn't
register a 2-letter second subtag at all:

"Tags with second subtags of 3 to 8 letters may be registered with IANA,
according to the rules in chapter 5 of this document."  (Section 2.2,
page 3)

but then made a special case for creating a registration to document the
meaning associated with a generated tag:

"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)."  (Section 3, page 8)

(I'm not sure how this makes sgn-BE-nl valid in any case.)

RFC 3066bis doesn't have a special provision like this.  Does it need
one, to allow registrations of already-composable tags for documentation
purposes?  If so, sgn-US "American Sign Language" would take precedence
over sgn "Sign Languages" + US "United States", which according to Peter
is not the same thing.  But if so, such tags wouldn't really be
"superseded" as Appendix C seems to require.

For now, I'm leaving the composable sign-language tags ("sgn-US") where
they are in my registry, in the dungeon of "superseded" comments.  But
this looks like another problem that needs to be solved before the RFC
can go live.

-Doug Ewell
 Fullerton, California
 http://users.adelphia.net/~dewell/