headers
John Cowan | 12 May 01:00
Favicon

Re: Re: [psg.com #951] extensibility via codes not maintained by ISO

JFC (Jefsey) Morfin scripsit:

> Frank documented what you can do with this mental twist. Scripts are named 
> in ISO 15924 ane are collections of characters documented in ISO 10646 with 
> their digital value. 

Many ISO 15924 scripts are not presently encoded, and ISO 15924
in no way depends on ISO 10646.

> UTF-8 global script.

UTF-8 is not a script.

> Anyway, non of them gives me a correct French keyboard :-)

Keyboards are neither scripts nor encodings.

> BTW , I always wander (and nobody answered) what is going to be the use for 
> your browser to know the name of the Script? Will it tell you "Hi! John, 
> you entered Mongolian script", or will it call a collection of digital 
> records to do someting with them? Or is it just for statistics?

A browser could look for a Mongolian font, or could replace the document
with a note that it is in a script you don't understand, or transliterate
it into a script you do understand.  But of course language tags are not
confined to browsers: they can also be used, for example, to catalogue
resources.

--

-- 
Babies are born as a result of the              John Cowan
(Continue reading)

Permalink | Reply | 1 comment |
headers
Frank Ellermann | 12 May 01:11
Picon
Picon

Re: [psg.com #954] all aliases must be equally supported

Addison Phillips wrote:

>> ACK.
> I take that as the converse of NACK, that is, U+0006?

ACK  NAK NACK ;-)

> I read rule (4) to mean that VU would not be added, which is
> one thing you have objected to.

Oops, I was counting bullets, and the 4th bullet discusses the
Recommended-Prefix.  And the IM example is not the 9th bullet
but the 10th:

| Codes assigned by ISO 639, ISO 15924, or ISO 3166 that do not
| conflict with existing subtags of the associated type but
| which represent the same meaning as an existing subtag of
| that type are entered into the IANA registry as new records.
| The field 'canonical value' for that record MUST contain the 
| existing subtag of the same meaning

For some obscure reasons I thought that that's the "no problem"
rule.  But you see "new tag for an already registered entity"
as conflict / problem.  Therefore you skip the 10th bullet and
arrive at number 11, the "conflict" rule.  Maybe you should
define "conflict", I thought that it's only about collisions.

Yes, and 3.3.11.4 says "don't register if it's unnecessary".

> The phrase "no new entry is created" seems to forbid the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Addison Phillips | 12 May 01:22
Picon
Favicon

RE: Re: [psg.com #954] all aliases must be equally supported

> Mark,
> I am sorry, Frank is right. You cannot be cannonical with tables you do
> not
> control. This is precisely the problem the charter wants us to address.
> Stability is not in the ID but in the documented object.  You have two
> possibilities: to attach a date to the ID or to define your own canonical
> table and relate it to the ID.
> jfc

Uh... The items in the registry all have dates attached to them. And they are in their own canonical table
over which the registry draft has ironclad control. We are discussing rules for the maintenance of
canonical values and stability of those values in that registry. The use of ISO 3166 to provide some of the
values in that table does not mean that the registry cedes control to the ISO 3166 MA. Defining rules for how
the registry tracks ISO 3166 is what we are about here, since creating separate standards for these things
is unappealing.

Addison

Addison P. Phillips
Globalization Architect, Quest Software
Chair, W3C Internationalization Core Working Group

Internationalization is not a feature.
It is an architecture.
Permalink | Reply | 0 comments |
headers
Frank Ellermann | 12 May 01:36
Picon
Picon

Re: xml2rfc category (was RE: Re: [psg.com #938] should introduction alludetointendedbcp status?)

Scott Hollenbeck wrote:

> Are you using the most recent version of xml2rfc?

I use the Web interface (1.29) http://xml.resource.org/ and for
the validation http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/

> I'm pretty sure I've used this before without any trouble.

Maybe you prepared an RfC for the in-queue with number="XXXX"
and say seriesNo="100" for BCP 100, that has visible effects,

Or you used <note>, that's something I've not tested.  More
than one <workgroup> isn't the trick to add text below the WG.

                           Bye, Frank
Permalink | Reply | 0 comments |
headers
Randy Presuhn | 12 May 01:41
Picon

Re: [psg.com #952] how to determine whether an ISO 639 registration request has been processed?

Hi -

> From: "JFC (Jefsey) Morfin" <jefsey <at> jefsey.com>
> To: "Randy Presuhn" <randy_presuhn <at> mindspring.com>
> Cc: <ltru <at> ietf.org>
> Sent: Wednesday, May 11, 2005 1:30 PM
> Subject: Re: [Ltru] [psg.com #952] how to determine whether an ISO 639 registration request has been processed?
>
> On 21:30 11/05/2005, Randy Presuhn said:
> >New Flash:  Participation in the IETF is by *individuals*.
> >
> >Everyone:  *please* stop wasting time and energy on the non-technical
> >cr*p that some insist on injecting into the mailing list, in the hope of
> >derailing our work.
>
> I am not sure this is a call of order in reference to the insults I must
> accept.
...

It is, though it is primarily a call to order in reference to the counterproductive
material present in many of Jefsey's postings.  I call upon Jefsey to stick to the
technical problems at hand, and I call upon the rest of the WG to do likewise.

Doug's response about "treachery and skulduggery" was unhelpful, but understandable
in light of Jefsey's patently offensive initial comment. (number 23 in
http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html )

Randy, ltru co-chair
(Continue reading)

Permalink | Reply | 1 comment |
headers
Randy Presuhn | 12 May 02:07
Picon

Re: Interim and Paris?

Hi -

> From: "JFC (Jefsey) Morfin" <jefsey <at> jefsey.com>
> To: <ltru <at> ietf.org>
> Sent: Wednesday, May 11, 2005 3:48 PM
> Subject: Re: [Ltru] Interim and Paris?
>

> On 21:09 11/05/2005, Randy Presuhn said:
> >I am intrigued by the statement "I note that I am the only non-English
> >speaker at the WG-ltru".  Grammar aside, it can be read several ways:
> >   (1) All members except Jefsey are proficient in English.
>
> Please stop this non-technical ....
>
> It seems that as you document it with your "Grammar aside": (1) is the only
> correct solution
> jfc
>
>
> BTW, thank you to tell me what is grammatically wrong in my sentence, since
> it was not intended.
...

The word "at" should have been "in", and "WG-ltru" should have been "ltru WG".
Even with those corrections, the sentence is still odd, as "non-English speaker"
would normally be understood as someone with far less command of the language
than you.

The noun-like "non-English speaker" itself seems odd, though the adjective-like
(Continue reading)

Permalink | Reply | 0 comments |
headers
JFC (Jefsey) Morfin | 12 May 02:22

Re: [psg.com #952] how to determine whether an ISO 639 registration request has been processed?

On 01:41 12/05/2005, Randy Presuhn said:
>Doug's response about "treachery and skulduggery" was unhelpful, but 
>understandable in light of Jefsey's patently offensive initial comment. 
>(number 23 in http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html )

The comment is correct. It may be Franglishly awkward, but itis not 
offensive. It says that the MUST is inadequate because its procedure of 
application is not documented. It then say how the MUST and the lack of 
procedure will be understood (because this is the way it was understood by 
_every_ of the five reviewers I called upon. It was also a point which 
really upset them).

Anyway, I am sure that if that comment was patently offensive, the Chairs 
would have clarified the issue with me before broadcasting it as 
#952.  This point is obviously out of a Draft non replacing RFC 3066 and 
does not prevent consens on that case. This point is an absolute blocking 
factor as is language treatment disparity.
jfc
Permalink | Reply | 0 comments |
headers
JFC (Jefsey) Morfin | 12 May 04:22

Re: [psg.com #960] use ITU E.164 calling codes instead of ISO 3166 country codes

At 00:57 12/05/2005, Randy Presuhn wrote:
> > From: "JFC (Jefsey) Morfin" <jefsey <at> jefsey.com>
> > To: "Randy Presuhn" <randy_presuhn <at> mindspring.com>; "LTRU Working 
> Group" <ltru <at> ietf.org>
> > Sent: Wednesday, May 11, 2005 12:00 PM
> > Subject: Re: [Ltru] [psg.com #960] use ITU E.164 calling codes instead 
> of ISO 3166 country codes
> >
>
> >
> > At 20:28 11/05/2005, Randy Presuhn wrote:
> > >Hi -
> > > > In message
> > > > http://www1.ietf.org/mail-archive/web/ltru/current/msg01643.html
> > > > it was proposed to use ITU E.164 calling codes instead of ISO 3166
> > > > country codes.
> > >
> > >I haven't seen much support for this proposal, and some rather compelling
> > >arguments against it, so unless I see a groundswell of support, I plan to
> > >mark this one "rejected".
> >
> > Where did you read _instead_??
>...
>
>Please, then, state just what your proposal is.  Showing what the changes 
>to the
>ABNF would be might help.
>
>In the meantime, pending discussion of your proposal, I've re-opened the 
>issue.
(Continue reading)

Permalink | Reply | 1 comment |
headers
JFC (Jefsey) Morfin | 12 May 01:43

Re: Re: [psg.com #951] extensibility via codes not maintained by ISO

On 01:00 12/05/2005, John Cowan said:
>they can also be used, for example, to catalogue
>resources.

Such as keyboard's keys?
jfc
Permalink | Reply | 0 comments |
headers
JFC (Jefsey) Morfin | 12 May 01:55

RE: Re: [psg.com #954] all aliases must be equally supported

On 01:22 12/05/2005, Addison Phillips said:
>Uh... The items in the registry all have dates attached to them. And they 
>are in their own canonical table over which the registry draft has 
>ironclad control. We are discussing rules for the maintenance of canonical 
>values and stability of those values in that registry. The use of ISO 3166 
>to provide some of the values in that table does not mean that the 
>registry cedes control to the ISO 3166 MA. Defining rules for how the 
>registry tracks ISO 3166 is what we are about here, since creating 
>separate standards for these things is unappealing.

Can you document the interest of a canonical table over which you want to 
have ironclad control? You create there your own standard. What for? Your 
job is not to maintain a canonical base but to tell users what a code used 
at a given date meant in the ISO table. It could change every year, you do 
not mind. Not your concern. Your concern (look at the charter) is to make 
sure the users know what is each subtag in the format and reach the proper 
version value. The registry does not cede control to the ISO 3166 MA, the 
ISO 3166 MA _HAS_ control, the registry just copy it in a readable form for 
your usage. Otherwise it conflicts.
jfc
Permalink | Reply | 0 comments |

Gmane