Subject: RE: [Ltru] RE: [newsml-2] japanese scripts (was: person/name given and family elements)

From: Misha Wolf <[email-masked]>
Date: Fri, 10 Feb 2006 19:23:07 +0000

Hi Addison,
 
The problem is that we don't need a new subtag.  We need, rather, to be able to use the script subtags which exist in the new registry (in particular Hani, Kana and Hrkt).  As the new RFC isn't yet fully baked, we're assuming that we must not do that.  And as the old registry has been closed, I'm assuming that it's too late to request ja-Hani, ja-Kana and ja-Hrkt under the old regime.
 
Misha

________________________________

From: Addison Phillips [mailto:[email-masked]] 
Sent: 10 February 2006 19:18
To: Misha Wolf; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [Ltru] RE: [newsml-2] japanese scripts (was: person/name given and family elements)

Just because 3066bis is not published with an RFC number yet doesn't mean that it isn't BCP 47, does it? That isn't how the process was presented to me. I've been told repeatedly that once the RFC-to-be has passed through the process to IESG approval, we're done. (And the appearance of the new registry is evidence of this.) If you need a subtag, submit a 3066bis request and let's testdrive the system...

Addison

Addison Phillips
Internationalization Architect - Yahoo! Inc.

Internationalization is an architecture.
It is not a feature. 

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of Misha Wolf
Sent: Friday, February 10, 2006 11:05 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [Ltru] RE: [newsml-2] japanese scripts (was: person/name given and family elements)

Unfortunately, this page:

    http://www.iana.org/numbers.html#L

says:

    "No further registrations in this registry."

in relation to the RFC 3066 language tags registry.

I suppose that if the IETF takes much longer to move RFC 3066 bis to RFC status, we may have to lobby for the RFC 3066 registry to be re-opened.  We're now stuck between one system which has closed and another which has not yet opened.

Misha

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of Rob Warner
Sent: 10 February 2006 18:53
To: [email-masked]
Subject: Re: [newsml-2] japanese scripts (was: person/name given and family elements)

It's worth noting that the XML 1.0 specification does explicitly allow for values in a form defined by RFC 3066's successor to be used in xml:lang attributes: http://www.w3.org/TR/2004/REC-xml-20040204/#sec-lang-tag

The danger of course is that existing consumers may not fully understand the new syntax.  Since there are really no NewsML 2 consumers yet, that's probably not an issue for us. 

If RFC 3066 bis is too far in the future, we might look at registering jp-Hani & friends, the same way zh-Hans & zh-Hant were done.

cheers,

Rob

On 10/02/06, Misha Wolf <[email-masked]> wrote: 

Yes.  I imagine that the new RFC will be approved before NewsML 2 is finalised.

Misha

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of Laurent Le Meur
Sent: 10 February 2006 17:37
To: [email-masked]
Cc: [email-masked] 

Subject: RE: [newsml-2] japanese scripts (was: person/name given and family elements)

Therefore your proposal is to explicitly and provisionally allow for xml:lang="jp-Hani", isn't it? 

Laurent 

________________________________

De : [email-masked] [mailto: [email-masked] <mailto:[email-masked]> ] De la part de Misha Wolf
Envoyé : vendredi 10 février 2006 18:21
À : [email-masked]
Cc : [email-masked]
Objet : RE: [newsml-2] japanese scripts (was: person/name given and family elements)

It would be a bad idea to introduce a "script" attribute now, just before draft-ietf-ltru-registry [1] becomes an RFC, replacing RFC 3066.

[1] http://ietfreport.isoc.org/idref/draft-ietf-ltru-registry/ 

Misha

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of Laurent Le Meur
Sent: 10 February 2006 11:33
To: [email-masked]
Subject: RE: [newsml-2] japanese scripts (was: person/name given and family elements)

Takahiro, 

The xml:lang attribute can take values indicating a script: it is the case for zh-Hans and zh-Hant (Traditional vs. Simplified Chinese), isn't it?

I see that it is not currently used for Japanese scripts (kanji, katagana, hiragana).

I spotted:

http://www.w3.org/International/articles/language-tags/ 

" There is a need, sometimes, to distinguish the script used, in addition to the language. For example, Mongolian might be written in Mongolian script or Cyrillic; Croatian might be written in Latin or Cyrillic; ..."

Then http://www.inter-locale.com/ID/draft-ietf-ltru-registry-13.html#script 

"Script subtags are used to indicate the script or writing system variations that distinguish the written forms of a language or its dialects. The following rules apply to the script subtags: "

Then http://www.unicode.org/iso15924/iso15924-codes.html 

And found the tokens found in HR-ML samples 

- Hani (for Kanji)

- Kana (Katakana)

- Hrkt (alias for Hiragana + Katakana)

My question: Can't we already express script with xml:lang="jp-Hani" ?

(I imagine that it would not be RFC3066 compliant any more).

If not, should we then create a specific attribute, as a sibling of xml:lang, in all elements supporting strings, that will be deprecated when the replacement of RFC3066 is standardized? If so, why are we the only group looking at this problem?

Laurent 

________________________________

De : [email-masked] [mailto: [email-masked] <mailto:[email-masked]> ] De la part de Takahiro FUJIWARA
Envoyé : lundi 16 janvier 2006 01:20
À : [email-masked]
Objet : Re: [newsml-2] FW: person/name given and family elements

I would explain from the view of Japanese people.

> With Japanese comes another factor: two scripts for one language.

Yes! this is the thing what I want to say.

   We always need two scripts in the application form such as resident registration, curriculum vitae(résumé), application form when the online shopping...

   One is for the formal printable name.  The other one is for the pronunciation.  There is many ways to write a pronunciation such as Hiragana, Katakana, multiple-romanisations.  But there is needed only one pronunciation in one application form because we can convert to another.  This pronunciation is also used for the name list with order by pronunciation.  Japanese people do not use order by Alphabetical nor order by Kanji.

Takahiro Fujiwara

________________________________

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 

This e-mail, and any file transmitted with it, is confidential and intended solely for the use of the individ ual or entity to whom it is addressed. If you have received this email in error, please contact the sende r and delete the email from your system. If you are not the named addressee you should not disseminate, distr ibute or copy this email. 

For more information on Agence France-Presse, please visit our web site at http://www.afp.com 

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 

To find out more about Reuters visit www.about.reuters.com

Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 

This e-mail, and any file transmitted with it, is confidential and intended solely for the use of the individ ual or entity to whom it is addressed. If you have received this email in error, please contact the sende r and delete the email from your system. If you are not the named addressee you should not disseminate, distr ibute or copy this email. 

For more information on Agence France-Presse, please visit our web site at http://www.afp.com 

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 

To find out more about Reuters visit www.about.reuters.com

Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.

SPONSORED LINKS 

Computer security <http://groups.yahoo.com/gads?t=ms&k=Computer+security&w1=Computer+security&w2=Large+format&w3=Computer+training&w4=Cover+letter+formats&c=4&s=90&.sig=NXlGxZwPdSovwYGB_QxPfg>  

Large format <http://groups.yahoo.com/gads?t=ms&k=Large+format&w1=Computer+security&w2=Large+format&w3=Computer+training&w4=Cover+letter+formats&c=4&s=90&.sig=Xgv39LCLBufY68C7Cn591Q>  

Computer training <http://groups.yahoo.com/gads?t=ms&k=Computer+training&w1=Computer+security&w2=Large+format&w3=Computer+training&w4=Cover+letter+formats&c=4&s=90&.sig=AITXDmxE-xPOb2PMRGopaA>  

Cover letter formats <http://groups.yahoo.com/gads?t=ms&k=Cover+letter+formats&w1=Computer+security&w2=Large+format&w3=Computer+training&w4=Cover+letter+formats&c=4&s=90&.sig=hdKoTXIuKmdrxQCTebJkRA>  

________________________________

YAHOO! GROUPS LINKS 

*	 Visit your group "newsml-2 <http://groups.yahoo.com/group/newsml-2> " on the web.
	  
*	 To unsubscribe from this group, send an email to:
	  [email-masked] <mailto:[email-masked]?subject=Unsubscribe> 
	  
*	 Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/>  . 

________________________________

SPONSORED LINKS 

Computer training <http://groups.yahoo.com/gads?t=ms&k=Computer+training&w1=Computer+training&w2=Computer+security&w3=Large+format&w4=Cover+letter+formats&c=4&s=90&.sig=wNk3N1pL6jKj7rQtAo6_Bg>  

Computer security <http://groups.yahoo.com/gads?t=ms&k=Computer+security&w1=Computer+training&w2=Computer+security&w3=Large+format&w4=Cover+letter+formats&c=4&s=90&.sig=P4cBpLcQ_APNQBncv4s5Kw>  

Large format <http://groups.yahoo.com/gads?t=ms&k=Large+format&w1=Computer+training&w2=Computer+security&w3=Large+format&w4=Cover+letter+formats&c=4&s=90&.sig=qTXrDc3eP0NoTfnkNtPBHQ>  

Cover letter formats <http://groups.yahoo.com/gads?t=ms&k=Cover+letter+formats&w1=Computer+training&w2=Computer+security&w3=Large+format&w4=Cover+letter+formats&c=4&s=90&.sig=9SdRM48GwBoPiwisRRoRAg>  

________________________________

YAHOO! GROUPS LINKS 

*	 Visit your group "newsml-2 <http://groups.yahoo.com/group/newsml-2> " on the web.
	  
*	 To unsubscribe from this group, send an email to:
	 [email-masked] <mailto:[email-masked]?subject=Unsubscribe> 
	  
*	 Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> . 

________________________________

To find out more about Reuters visit www.about.reuters.com

Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.

To find out more about Reuters visit www.about.reuters.com

Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sat, 11 Feb 2006 16:02:10 +0100

--On fredag, februar 10, 2006 19:23:07 +0000 Misha Wolf 
<[email-masked]> wrote:

> Hi Addison,
>
> The problem is that we don't need a new subtag.  We need, rather, to be
> able to use the script subtags which exist in the new registry (in
> particular Hani, Kana and Hrkt).  As the new RFC isn't yet fully baked,
> we're assuming that we must not do that.  And as the old registry has
> been closed, I'm assuming that it's too late to request ja-Hani, ja-Kana
> and ja-Hrkt under the old regime.

my advice would be to use them - and let the bureaucracies of the IETF take 
their own sweet time.

The only thing we can do to help them along is to finish the comparator 
draft (and - shame on me - I need to review it again :-( )

                 Harald

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 11 Feb 2006 19:25:03 +0100

Luc Pardon wrote:

> I submitted a request for registration of el-Latn (Greek with
> Latin script) in September last year, under the then current
> RFC 3066 rules. The registration was approved on 28 Sept 2005.

That was before "date B" 2005-10-16 in the 3066bis registry...

> It is my understanding that it should have been added to the
> then-current registry

...yes.

> but it was not.

Some case of Murphy between you, the tag reviewer, and IANA.

> The registry is now closed

If some approved registrations before it was closed are MIA
they could just add them.  Not too exciting in your case, the
new registry allows el-Latn.

> FWIW, it is unclear to me when, by whom and on what formal
> grounds

When:  About 2006-01-04 3066bis left state "IANA", see also
http://rtg.ietf.org/~fenner/ietf/rfc/hist.cgi?draft=draft-ietf-ltru-registry

Who:  IANA of course.

What formal grounds:  After IESG approval anything IANA has to
do is done first, here create two new registries and close the
old registry as specified in 3066bis.

> RFC 3066 is still BCP and BCP47 still points to RFC3066

That's just another case of Murphy, the IESG added a normative
reference to [RFCTBD] (= matching) in their approval, thereby
screwing up the smooth transition more than necessary:

A delay of some months just allowing IANA, RfC-editor, authors,
and potential appeals to get it right is necessary, but waiting
for a not yet finished RfC is less desirable.

3066bis is already a RfC, it only didn't get its number yet.
Simply use the old RfC and registry if you don't believe it.

> draft-ietf-ltru-registry-14.txt) is still in draft, has been
> so since 14 October 2005 and will expire on 17 April 2006,
> i.e. in about two months.

Approved drafts don't "expire", they wait it in the RfC-editor
queue until its their turn for some final editorial fixes, then
they get a number, and that's it.  They can't "vanish" from the
RfC-editor queue without severe reasons (e.g. if authors refuse
to approve modifications of 3rd parties like the IESG).

> I suppose the advice would be the same: just go ahead and use
> it to your hearts desire. Which, in my book, translates to:
> just ignore IETF standards and do as you please.

You can do that anyway,  You could also ask IANA and/or the tag
reviewer what went wrong, but I guess that's what you're just
doing.

> Which leaves me wondering why I bothered. It has been a waste
> of time. Silly me.

Obviously one reason why you bothered - "who knows how long it
takes until RfC 3066bis gets its number" - made sense, but then
your registration met its own Murphy.  One Murphy too many here.

> If IETF/IANA wants to make itself irrelevant, it only has to
> keep the various registrations proces(ses) as "efficient and
> smooth" as they apparently are and stand by as people do what
> they need to do to fulfill real needs they have in real life.

At the moment there's zero _real_ delay with 3066bis, after all
the appeal has to be resolved, and RfC editor state "IESG" is
not better than "missing REF".

If el-Latn is added now we'd also need it in the new registry
as "redundant".  The redundant entries are what the word says.

                               Bye, Frank

---

From: Martin Duerst <[email-masked]>
Date: Sat, 11 Feb 2006 15:56:50 +0900

[cutting out most of the old thread history; please, everybody,
reduce your postings to what is really necessary to understand
each posting.]

I fully agree with Addison here. RFC3066bis has been approved by the IESG,
and the IANA has carried out all the necessary preparations. The only thing
that's still missing is the RFC number, but that's only a problem when you
want to cite the new spec, not when you want to use the tags.
The whole thing is very clear from the IANA page, it says:

Language Subtag Registry        RFC-ietf-ltru-registry-14.txt   Expert 
Review (Michael Everson)

which means that registrations to the Language Subtag Registry are open
and will be done according to registry-14.txt, with Michael as the
expert reviewer.

It may look strange that a 'law' goes into effect before it has been
formally published, but that's how the IETF works :-).

Regarding a script subtag for the Japanese Kanji/Kana mixture, my personal
oppinion would be to just leave the script subtag out. If a tag "Japn"
existed, the only real purpose for it would be to change

%%
Type: language
Subtag: ja
Description: Japanese
Added: 2005-10-16
%%

to

%%
Type: language
Subtag: ja
Description: Japanese
Added: 2005-10-16
Suppress-Script: Japn
%%

So there is really absolutely no point to add such a tag to actual data,
and only a limited benefit (formal completeness and consistency of the
registry) for introducing such a script tag (at least from the point of
view of RFC3066bis; there may be other needs for "Japn").

Given that, we could actually add "Japn" as a script all by our own,
just for that specific purpose (or at least we could propose to do so
in case another attempt to add it to the ISO script standard fails).

Regards,    Martin.

At 04:23 06/02/11, Misha Wolf wrote:
>we're assuming that we must not do that.  And as the old registry has been 
>closed, I'm assuming that it's too late to request ja-Hani, ja-Kana and 
>ja-Hrkt under the old regime.
>
>Misha

---

From: r&d afrac <[email-masked]>
Date: Sun, 12 Feb 2006 13:55:12 +0100

Dear Martin,
I suppose this is said with your co-Chair hat since there is no 
special mention. Worrying: had you said it hat-off it would have been 
a confusion I asked the Chairs and AD to start clarifying. With your 
hat on, it looks like seditious.

At 07:56 11/02/2006, Martin Duerst wrote:
>want to cite the new spec,

Incorrect. The RFC 3066 Bis Draft is under Internet standard process 
appeal. Right now at IESG level.

>not when you want to use the tags.

This really look like a coup:
- as mentioned above, the "law" you refer to is not approved yet
- the "law" you want to use is not the consensus you yourself 
declared and the IESG approved.

>Language Subtag 
>Registry        RFC-ietf-ltru-registry-14.txt   Expert Review (Michael Everson)
>

We all know this is what affinity groups wants to change the law 
into. The current IANA entry (text and presence at this date) as is 
wrong and you must make it corrected. If you say it is right this is 
pressure on IESG and IAB, this is to be appealed.

>formally published, but that's how the IETF works :-).

No. This is not strange. This is wrong.

The way the IETF works is the Internet standard process. The way the 
IANA works is in respecting the Internet standard process. Under the 
IESG management and IAB guidance. In the case it is not, it MUST be 
corrected, NOT encouraged.

I do hope you agree with me.

jfc

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 12 Feb 2006 21:53:28 +0100

r&d afrac wrote:

> I suppose this is said with your co-Chair hat since there
> is no special mention.

Ex falso quodlibet.

> the "law" you refer to is not approved yet

This is untrue, the approval was sent to the announce list.

> The current IANA entry (text and presence at this date)
> as is wrong and you must make it corrected.

It reflects precisely the approved initial registry draft,
and so far it's correct.  Modulo one redundant el-Latn MIA.

> If you say it is right this is pressure on IESG and IAB,
> this is to be appealed.

Nonsense.  Like everybody else Martin is entitled to post
his opinion.  You can't "appeal" opinions.  At this time
only IESG members could post any "official" info here wrt
3066bis.

>> It may look strange that a 'law' goes into effect
>> before it has been formally published, but that's how
>> the IETF works :-).

> No. This is not strange. This is wrong.

It was "formally published".  AFAICT both authors accepted
the RfC-editor note adding a new "informative" reference
to [RFCTBD] as de facto "normative".  That was good enough
to create the new IANA registry as specified.

> The way the IANA works is in respecting the Internet
> standard process.

That's what IANA did, IESG approval => create registry.

Anything else is between you and the IESG.  They will
inform IANA, RfC editor, and the authors if necessary.

                         Bye, Frank

---

From: Luc Pardon <[email-masked]>
Date: Sat, 11 Feb 2006 17:57:06 +0100

Harald Tveit Alvestrand wrote:
> 
> 
> my advice would be to use them - and let the bureaucracies of the IETF 
> take their own sweet time.
> 

    And what should I do ?

    As some of you may recall, I submitted a request for registration of 
el-Latn (Greek with Latin script) in September last year, under the then 
current RFC 3066 rules. The registration was approved on 28 Sept 2005. 
It is my understanding that it should have been added to the 
then-current registry but it was not.

    The registry is now closed (FWIW, it is unclear to me when, by whom 
and on what formal grounds, since RFC 3066 is still BCP and BCP47 still 
points to RFC3066), the current version of "the successor to RFC 3066" 
(from my layman's reading of 
http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-14.txt) is 
still in draft, has been so since 14 October 2005 and will expire on 17 
April 2006, i.e. in about two months.

    I suppose the advice would be the same: just go ahead and use it to 
your hearts desire. Which, in my book, translates to: just ignore IETF 
standards and do as you please.

    Which leaves me wondering why I bothered. It has been a waste of 
time. Silly me.

    Extrapolating, I wonder why anyone would bother to submit anything 
for registration at all, if the outcome is "just go ahead and use it" 
anyway.

    If IETF/IANA wants to make itself irrelevant, it only has to keep 
the various registrations proces(ses) as "efficient and smooth" as they 
apparently are and stand by as people do what they need to do to fulfill 
real needs they have in real life.

    Just a view from the outside ...

    Best regards,

    Luc Pardon
    Skopos Consulting
    Belgium

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 14 Feb 2006 09:31:27 +0100

On Sat, Feb 11, 2006 at 05:57:06PM +0100,
 Luc Pardon <[email-masked]> wrote 

> April 2006, i.e. in about two months.
...
> real needs they have in real life.

People who are more knowledgeable than I am will fix me if I'm wrong
but I believe that the status of this work at IETF is clear:

The two LTRU drafts have been approved by IESG on Tue, 15 Nov 2005
(announcement attached). From there, the IETF work on these two drafts
is *done*.

Now, the RFC is not yet issued, true, but this is a RFC-editor issue
(http://www.rfc-editor.org/), which has nothing to do with IETF, it is
a completely separated organization. The RFC editor pub queue
(http://www.rfc-editor.org/queue.html) show them in the state "REF =
Holding for normative reference (followed by ID string of referenced
document)". Apparently, they are waiting for draft-ietf-ltru-matching
(currently in 09). 

(Same thing for the IANA, which is not an IETF organization.)