Registered sgn-* tags
dewell at adelphia.net
Mon Jul 12 22:18:11 CEST 2004
Michael Everson <everson at evertype dot com> wrote:
>> This is a good point, Michael. 3066bis does allow for tags in the
>> future that would cover your requirements. The only problem is the
>> syntax, not the semantics. sgn-BR works fine, since it is <lang>-
>> <region>, but sgn-BE-fr doesn't, since it is <lang>-<region>-<lang>.
>> So it is grandfathered in.
> Well, it means "Belgian French Sign Language", and this productive
> mechanism should be available for extension.
> That is, it should NOT be proscribed by 3066bis.
One problem is that the third subtag in this "productive mechanism"
isn't necessarily an ISO 639 language code. In the three registered
tags, it is, but in all but two of the 21 three-part tags in Michael's
Table B, it is an ISO 3166-2 sub-region code.
For example, Catalonian Sign Language is proposed to be sgn-ES-CT, where
CT is the ISO 3166-2 code for the Cataluña region of Spain.
As much as I love ISO 3166-2 codes, they do have the problem, as far as
creating a productive mechanism is concerned, that they can vary from
one to three alphanumeric characters in length, and thus collide with
codes in other systems. So the third subtag in sgn-BE-fr means
"French," or perhaps "sign language based on the French spoken
language," but the same subtag in sgn-US-HI (if registered) would mean
"Hawaii." There is no way to tell, just by looking at the subtags and
their length and position (as set out in 3066bis), that sgn-US-HI
doesn't mean, roughly, "sign language based on Hindi, as used in the
Additionally, Michael proposes to encode signed spoken languages (as
opposed to sign languages per se) using ISO 639-2 (alpha-3) codes as the
second subtag. But all of the languages in question have an ISO 639-1
(alpha-2) code, so this isn't permitted even under RFC 3066.
>> So let's consider what we would do with a new tag such as "Spanish
>> Sign Language as used in Canada".
> That's not a credible tag.
A productive mechanism has to allow silly combinations as well as
practical ones. RFC 1766 allowed eu-CN.
What we need here is a way to register -- not necessarily generate --
tags for the sign languages, and signed spoken languages, that Michael
wants to represent.
> See http://www.evertype.com/standards/iso639/sgn.html for a complete
> specification which outlines the scheme.
> A simple fix to 3066bis, if it is going to proscribe this kind of
> thing, is to specifially allow the syntax as described in that
> document as permitted following, specifically, the 3-letter code
There are three related but different syntaxes exemplified in sgn.html:
>> 1. Register a language subtag 'sgnes' (registered language subtags
>> can be 4 or more letters). It would then automatically allow for the
>> generative use of sgnes-CA or sgnes-US, etc.
> This doesn't relate the the requirement.
Specifically, it wouldn't work for cases 2 and 3 above.
> The requirement has to do with identifying "Place-name's Sign
> Language" and also "Signed Spoken-Language". This is complex, but if
> you let what was developed in 2001 continue to work for tags
> following "sgn" then there won't be any disruption and the system can
> work as it does today.
The tags in Table A are all registered under RFC 3066, and would all
become generative or would be grandfathered under RFC 3066bis.
Most of the tags in Table B would be automatically valid under RFC
3066bis as well -- sgn-DZ for "Algerian Sign Language" seems pretty
self-evident under the generative scheme. But are the 21 three-part
tags currently valid? They wouldn't be under RFC 3066 unless they were
registered. And I don't think the Table C tags would be valid at all
under RFC 3066, based on Section 2.3, bullet 2.
So I don't know if it's a question of letting the strategy described in
Tables B and C "continue to work" under RFC 3066bis. It's not fully
More information about the Ietf-languages