suppress-script values for fil, mi, pes, prs, qu members

[Phillips, Addison]

This seems a difficult distinction to really maintain. Anything related to keyboards, fonts, and locale data is, to some degree, related to languages and linguistic content. Certainly some have sought to (and actually) registered subtags specifically for purposes like that. But, unless it is related purely to national requirements, such as legal standards, it is difficult to wholly separate the presentation, input, or formatting of text from the language itself. Those requirements are often valid, even by the criteria you prefer.

Still, Peter's requests seem motivated purely on linguistic grounds, are supported by actual linguistic data, and do not betray any such ulterior motives. Peter is offering to submit the forms, but asking first if it makes sense to do so, so it isn't as if there is "special" clerical work for you. While I share John Cowan's feelings about adding further Suppress-Scripts, I find the reaction of this list--and particularly of the stewards of the process--to be objectionable because it focuses on the "motives" of the requester (such as you perceive them) rather than the merits of the request. 

Since RFC 5646 clearly and unambiguously provides for additional Suppress-Script registration for cases such as this and since there is apparently no data to suggest that such an S-S field would be in error--and in spite of my misgivings personally about Suppress-Script--I feel that these should be registered if they are formally requested.

Addison Phillips
Globalization Architect (Lab126)
Chair (W3C I18N, IETF IRI WGs)

Internationalization is not a feature.
It is an architecture.

> -----Original Message-----
> From: ietf-languages-bounces at alvestrand.no [mailto:ietf-languages-
> bounces at alvestrand.no] On Behalf Of Doug Ewell
> Sent: Wednesday, October 20, 2010 8:56 PM
> To: ietf-languages at iana.org
> Subject: Re: suppress-script values for fil, mi, pes, prs, qu
> members
> 
> Peter Constable <petercon at microsoft dot com> wrote:
> 
> > How have I not shown actual need?
> >
> > I've identified a set of languages without s-s fields for which
> ll-CC
> > (e.g. quz-PE) tags _are_ in use in _real_ implementations, hence
> > setting up exactly the same conditions for these languages that
> made
> > the compelling case to create all the existing s-s fields.
> >
> > I've pointed out that we are working on _real_ implementations
> that
> > need to be able to compare tags of the form ll with tags of the
> form
> > ll-Ssss (e.g. quz and quz-Latn), or tags of the form ll-CC and
> tags of
> > the form ll-Ssss-CC or ll-Ssss (e.g. quz-PE and quz-Latn-PE or
> > quz-Latn).
> 
> If these "real implementations" are for identifying and searching
> linguistic content, then I think the proposed S-S values are
> probably a
> good idea and "support" them (for whatever that's worth).  If they
> are
> for determining keyboard layouts and font assignments and "binding
> to
> locale data" — none of which is what the Registry is for, IMHO —
> then I
> think they are probably not.
> 
> Either way, I will do whatever clerk work is needed, though
> strictly
> speaking, Section 3.5 tends to imply that the requester should bear
> much
> of the brunt.
> 
> --
> Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org
> RFC 5645, 4645, UTN #14 | ietf-languages @ is dot gd slash 2kf0s ­
> 
> _______________________________________________
> Ietf-languages mailing list
> Ietf-languages at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/ietf-languages