Pinyin

[Randy Presuhn]

Hi -

> From: "Peter Constable" <petercon at microsoft.com>
> To: "Randy Presuhn" <randy_presuhn at mindspring.com>; <ietf-languages at iana.org>
> Sent: Thursday, September 25, 2008 8:35 AM
> Subject: RE: Pinyin
...
> > And the use case for lumping these together as a single variant
> > is.... ???
> 
> Here's my take from what I've heard: There *isn't* a use case to lump these together,
> but rather that the motivation is (a) that, if we have a subtag "pinyin", then there will
> be users that use that for various PRC romanizations whether we define it as being
> for that or not; and (b) that people are thinking there are probably needs to tag
> content in those other romanizations, so we may as well kill two (or three...) birds
> with one stone.

I agree that no use case (not even an implausible one) has been presented so far.
I find the motivations unconvincing, but recognize that folks may want to consider
addressing more than the original registration request in order to avoid future
registration requests.

> Our options:
> 
> A. Register "pinyin" with a broader scope, and everything gets tagged the same
> undifferentiated way wrt written variation.

This would be a Very Bad Thing, in that it fails to distinguish the variant
described in the registration request from other variants.
 
> B. Register "pinyin" with a broader scope, and register one or more variants to
> support differentiating the various orthographies.

I can see how this could be made to work, but do not see any value to
doing it this way.  Our job is not to provide a hierarchical taxonomy of
orthographies.  WHAT IS THE USE CASE???
 
> C. Register "pinyin" with a narrow scope -- Hanyu Pinyin only -- and expect
> implementers to actually read and observe what the registry has to say about the subtag.

I think fears of "pinyin" being misapplied are overblown, so
approach "C" would be fine with me.
 
> D. Register "hpinyin" (or some other subtag) to mean specifically Hanyu Pinyin;
> others may register subtags for other Romanizations if they wish.

This would be fine with me, and if it brings an end to what should have been
a very quick approval cycle, so much the better.

> From what I can tell, only C or D fits the original request; B may satisfy the
> requester's needs, though I'm guessing Mark might be less satisfied with that.

I have the same reaction.

Randy