Timetable for action: May 31 is suggested

[Martin Duerst]

Hello Michael, others,

At 01:29 03/05/28 +0100, Michael Everson wrote:

>Well gosh, John, I can't decide about these because there aren't clear 
>guidelines about them or the implications of them.

There are clear guidelines:

 >>>>
    When the two week period has passed, the language tag reviewer, who
    is appointed by the IETF Applications Area Director, either forwards
    the request to IANA at IANA.ORG, or rejects it because of significant
    objections raised on the list.  Note that the reviewer can raise
    objections on the list himself, if he so desires.  The important
    thing is that the objection must be made publicly.
 >>>>

If you think you need to reject any of the proposed registrations,
please do so by clearly pointing to the objections that you think
are significant. If you don't think there are significant objections
for a particular tag, please go ahead and approve it. If you
are unclear whether a particular objection you have seen should
be considered significant or not, please ask us to help you
in discussing it, pointing very clearly to the objection
you are thinking about.


>Do I have to add yi-Hebr now? Somebody says yes.

You don't. Nobody has asked for it. If somebody asks for it,
that will be discussed separately. Last time, there were
strong opinions against it, but that may or may not be
the case next time.


>Do people want to parse the tags? They do.

RFC 3066 defines exactly what people and computers can do with
these tags and what not.


>Can country elements interact with the script tags? Evidently.

Yes. But none of the proposed tags contain country codes.
The question of whether country or script should come first
is therefore completely irrelevant to the current requests.
I do not see any way that you can claim that the fact that the
question of whether country or script should come first is
unresolved is a significant objection to the current requests.


>What format should the parsing have? I don't know, and it is NOT my job to 
>decide arbitrarily. Or is it?

It is not your job as a language reviewer to worry about parsing
of arbitrary potential future registrations. It is very clear how
parsing/matching of language tags and language ranges will work
for the requests at hand, and I have not seen any objections to this.


>Those would work perfectly in a script= tag, in library database fields, 
>and so on.

Sean Burke has shown how having two separate headers,
Accept-Language and Accept-Script, would fail miserably
in negotiation.

Also, getting new HTTP headers defined and widely implemented
would take a lot more time than updating RFC 3066 (which we
already have heard won't be that quick either).

Adding something like xml:script to XML is even more difficult,
if not impossible. [but it is also not necessary, because
the content is mostly self-descriptive]


>No it doesn't. The yi-Latn "precdent" seems to have raised all sorts of 
>new questions. Is there a default script for languages?

This question was asked, and in the context of the requests
at hand, was answered, to the extent it needed to be answered.
For one language in question, there were at one point quite
split opinions, but more research and evidence clearly tipped
the balance.


>Will yi-Hebr have to be added now, as one person suggested?

If the person who suggested that (or somebody else) really thinks
they have a need, they can submit another registration. Whether it
will get registered will depend on how that discussion goes. We should
neither try to predict this discussion nor try to hold it
before there is an actual request, nor should it affect the
requests before us.


>What about yi-US-Latn vs yi-Latn-US -- which should it be?

Again, there is no request, so this is an irrelevant question.
And even if there were a request, the other requests would
not be affected by this.


>-- isn't one structure implied by de-DE-1909? Is that the structure we 
>want for zh-Hant and zh-Hans?

For zh-Hant and zh-Hans, the agreement is that these are highly
preferable to Hant-zh and Hans-zh. [And the later would be illegal
in RFC 3066 anyway.] Whether it could be zh-Hant-cn or zh-cn-Hant is
obviously irrelevant for registering zh-Hant. And there is only
a request for the later.


>The interaction with country codes has not been addressed, has it? EVEN IF 
>THESE PARTICULAR PROPOSALS DON'T HAVE COUNTRY CODES IN THEM THE PROBLEM 
>STILL EXISTS.

Yes, that problem exists, in theory. There are many other
problems that exist. Do we have to solve the problem of
world peace in order to be able to register zh-Hans?
Obviously no. Do we have to solve the question of whether
it would be zh-cn-Hans or zh-Hans-cn in order to be able
to register zh-Hans? Obviously no. If you know of any
potential interaction between the zh-Hans registration
and the above question, please explain it clearly.


>As tag reviewer, I think it best that we decide what we want to do 
>*before* certain tags are added.

Yes, we decide whether we want to add zh-Hans before we register
zh-Hans.


>What do we do with Chinese? We have tags for a number of Chinese 
>languages. None of these have script tags attached. What shall we do with 
>the syntax of these regarding script tags?

If somebody has a need to distinguish some of these languages
based on which script they are written in, they will send in
a registration request. At that point in time, we will
discuss the request, and some people may propose a different
tag structure. For the moment, the only tags requested have
been zh-Hans and zh-Hant. There is no interaction between
these and the potential tags that you mention above.


>I would rather have the issues regarding interaction between language, 
>script, and country codes in these language tags be SETTLED before I do that.
>
>James Seng: What is best? zh-Hans-SG? zh-SG-Hans? zh-guoyu-Hant-SG? Etc. 
>etc. etc. I want this question answered before I approve the kinds of tags 
>proposed. I think I am RIGHT to insist on this.

I think you are wrong on this point. If somebody proposed a tag to
label "Chinese in Singapore written with simplified Han", then
this would be a very important question to discuss. But nobody
has asked for such a registration.


>I myself don't see a need to wait for a complete revision, which will take 
>a long time. We could set policy on the PROBLEM raised without waiting for 
>a formal revision. But *I* don't want to set such a policy by fiat.

That, in and by itself, is a good idea and much appreciated.


>>  > We *DO* need to have a policy on these matters. We *DO* need to have
>>>  a consensus decision on syntax. Is it to be zh-Hans-SG or zh-SG-Hans?
>>>  Do you know? Do you care? Does it matter?
>>
>>Those weren't requested. This merely appears to be another delaying tactic.
>
>Mark's proposals have implications regarding other tag structures, and 
>that is why I am not accepting them at present. Is this in any way unclear?

Yes, this is way unclear. Can you explain why we need to even
discuss whether it might be zh-Hans-cn or zh-cn-Hans in order
to be able to approve zh-Hans ? I agree that Mark's proposals
may have some implications, but if we agree with zh-Hans, and
you approve zh-Hans, that means just that. It does not have
any implications on accepting other registrations. We still
can decide that zh-Hans-cn is best, or that zh-cn-Hans is
best, or that for some obscure reason, we need both, or that
we don't want any such registration and therefore reject it,
if and when such a request comes in. The decision about
zh-Hans does not prejudice either of these outcomes.


Regards,    Martin.