sgn-MT [et al.]: new RFC 3066 tag[s]

[Addison Phillips [wM]]

> > I do not relish explaining the proposed changes to the user 
> > community, which helped develop this scheme. I would very much like 
> > the scheme there to be adopted as a special case for "sgn" in RFC 
> > 3066bis.
> 
> The cost of doing so is relatively low, and I agree that we should.

Mark and I will discuss this before we submit draft-07 (containing a fix related to the busted-ness of the ABNF validator on the web and various errata related to Peter Constable's comments). I think it should be possible to include an exception of this kind. At least we would be well-and-truly done with the sgn-* tags (we would know how they were formed, registered, and handled) and not have them come back and haunt us with exceptions later. As John Cowan notes, the cost of doing this is very low.

Now: the question is what form the exception takes in 3066bis. If we define the sgn-* tags to be a special case, do we require that they be registered as whole tags before use? Or do we allow the generative mechanism to define the tags and permit special registrations of an informative nature? IOW, is sgn-AQ a "valid" tag?

Addison

Addison P. Phillips
Director, Globalization Architecture
webMethods | Delivering Global Business Visibility
http://www.webMethods.com
Chair, W3C Internationalization (I18N) Working Group
Chair, W3C-I18N-WG, Web Services Task Force
http://www.w3.org/International

Internationalization is an architecture. 
It is not a feature.

> -----Original Message-----
> From: ietf-languages-bounces at alvestrand.no 
> [mailto:ietf-languages-bounces at alvestrand.no]On Behalf Of John Cowan
> Sent: 2004年10月3日 9:12
> To: Michael Everson
> Cc: ietf-languages at iana.org
> Subject: Re: sgn-MT [et al.]: new RFC 3066 tag[s]
> 
> 
> Michael Everson scripsit:
> 
> > I think the problem is that "sgn" does not refer to a language AT 
> > ALL, and (as I suggested once a long time a go) I think the RFC 
> > should define as SPECIAL syntax for what happens wit the prefix "sgn".
> 
> I tend to agree with this, for two reasons: because sign languages are
> a special case, and because I don't want to upset the existing agreement.
> 
> > Then you would want to deprecate "sgn-IE" in favour of "sgn-isg", and 
> > I guess you will later want to deprecate that in favour of "isg"?
> 
> This is the sticky wicket for 639-3, and unless we solve it, we shall
> get no forwarder.
> 
> > And what about Signed Spoken Languages? Those also MUST have country 
> > codes. "sgn-eng-IE" is different from "sgn-eng-US" and *very* 
> > different from "sgn-eng-GB". All of those are representations of 
> > spoken English.
> 
> Indeed.
> 
> > I do not relish explaining the proposed changes to the user 
> > community, which helped develop this scheme. I would very much like 
> > the scheme there to be adopted as a special case for "sgn" in RFC 
> > 3066bis.
> 
> The cost of doing so is relatively low, and I agree that we should.
> 
> -- 
> [W]hen I wrote it I was more than a little              John Cowan
> febrile with foodpoisoning from an antique carrot       cowan at ccil.org
> that I foolishly ate out of an illjudged faith          
www.ccil.org/~cowan
in the benignancy of vegetables.  --And Rosta           www.reutershealth.com
_______________________________________________
Ietf-languages mailing list
Ietf-languages at alvestrand.no
http://www.alvestrand.no/mailman/listinfo/ietf-languages