Subject: [Ltru] RE: Update ltru-initial-05 (was RE: Draft-14 ready...)

From: "Addison Phillips" <[email-masked]>
Date: Fri, 14 Oct 2005 15:40:44 -0700

I'd support including it. The comment makes sense to me.

Addison

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

Internationalization is not a feature.
It is an architecture. 

> -----Original Message-----
> From: Scott Hollenbeck [mailto:[email-masked]]
> Sent: Friday, October 14, 2005 3:23 PM
> To: Addison Phillips; 'Randy Presuhn'; [email-masked]
> Subject: Update ltru-initial-05 (was RE: Draft-14 ready...)
> 
> > -----Original Message-----
> > From: Addison Phillips [mailto:[email-masked]]
> > Sent: Friday, October 14, 2005 4:56 PM
> > To: Addison Phillips; Randy Presuhn; Scott Hollenbeck; [email-masked]
> > Subject: Draft-14 ready...
> >
> > All:
> >
> > Draft-14 is posted in all three formats on the inter-locale site:
> >
> > http://www.inter-locale.com/ID/draft-ietf-ltru-registry-14.xml
> > http://www.inter-locale.com/ID/draft-ietf-ltru-registry-14.html
> > http://www.inter-locale.com/ID/draft-ietf-ltru-registry-14.txt
> >
> > IDnits ran clean.
> > ABNF checker ran clean.
> >
> > A diff is posted here:
> >
> > http://www.inter-locale.com/ID/draft-registry-13-14-diff.html
> >
> > The list of changes (edits performed by me) incorporated into
> > draft 14 is:
> >
> > 1. Updated XML2RFC tool to version 1.30. This caused every
> > header number to pick up a trailing dot (i.e. "2.1.1."
> > instead of "2.1.1"). It also caused the artwork titles to be
> > left aligned instead of centered and the authors addressed to
> > be moved to the bottom just before the IPR statement.
> >
> > 2. Changed, per Kent's comment, "then" to "than" in Section 5.1.
> >
> > 3. Changed, per Elwyn's comment, the title of Figure 2
> > (Section 3.1) from "record-jar ABNF" to "registry format ABNF"
> >
> > 4. Changed the reference from RFC 2234bis to RFC 4234.
> 
> All reasonable.
> 
> Related topic, other document: what do you all think about Russ Housley's
> comment?:
> 
> "Russ Housley:
> Comment:
> [2005-10-12]
>   In section 3 of draft-ietf-ltru-initial-05, it might be useful for the
>   document to include the URL of the IANA registry.  It seems to me that
>   anyone interested in this document will want to locate the IANA
>   registry too."
> 
> -Scott-

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

---

From: Mark Davis <[email-masked]>
Date: Fri, 14 Oct 2005 15:50:12 -0700

+1

---

From: Ted Hardie <[email-masked]>
Date: Fri, 14 Oct 2005 15:54:48 -0700

At 3:40 PM -0700 10/14/05, Addison Phillips wrote:
>Scott, quoting Russ:

Historically, IANA has moved registries around their site as needed.  If
you include a URI, you force them to maintain that URI or redirects to
an appropriate URI.  I would suggest a pointer to the IANA site instead,
since that is likely more stable.

My two cents,
			regards,
				Ted Hardie

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 14 Oct 2005 18:22:44 -0700

Hi -

> From: "Ted Hardie" <[email-masked]>
> To: "Addison Phillips" <[email-masked]>; "Scott Hollenbeck" <[email-masked]>; "Randy Presuhn"
<[email-masked]>; <[email-masked]>
> Sent: Friday, October 14, 2005 3:54 PM
> Subject: [Ltru] RE: Update ltru-initial-05 (was RE: Draft-14 ready...)
>

> since that is likely more stable.
...

As a contributor...
I prefer this alternative, particularly since the document is only informational.

Randy

---

From: "Jukka K. Korpela" <[email-masked]>
Date: Sat, 15 Oct 2005 10:06:16 +0300 (EEST)

On Fri, 14 Oct 2005, Ted Hardie wrote:

> Historically, IANA has moved registries around their site as needed.

Unfortunately, yes. That works against the purposes (the very
raison d'etre) of IANA and the registries.

> If you include a URI, you force them to maintain that URI or redirects to
> an appropriate URI.

If only we could force them! But despite some problems in the past, I 
think we need to expect IANA to maintain such stability. The other option 
is to find another registration authority.

As Tim Berners-Lee puts it, "Cool URIs don't change",
http://www.w3.org/Provider/Style/URI

> I would suggest a pointer to the IANA site instead,

A URL _is_ a pointer - a specific, exact pointer. Referring generically to 
a site (with a domain name, if we can expect that to be stable) is not 
user-friendly at all. Saying things like "go to http://www.iana.org/,
then click on 'bar', then on 'foo', and select 'zap' from the dropdown 
menu" would look foolish and would not be stable at all but bind us to a 
particular site design, as opposite to a specific URL, which _can_ be kept 
working if a site is reorganized.

A stable URL is also essential for the ability to link to a document
in hypertext.

-- 
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/

---

From: Marion Gunn <[email-masked]>
Date: Sat, 15 Oct 2005 13:17:11 +0100

Ted's is the only sensible approach.
mg

-- 

Marion Gunn * EGTeo (Estab.1991)
27 Páirc an Fhéithlinn, Baile an 
Bhóthair, Co. Átha Cliath, Éire.
* [email-masked] * [email-masked] *

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 15 Oct 2005 23:40:31 +0200

Jukka K. Korpela wrote:

> If only we could force them

Let's say "convince", and an absolute URL to the real registry
could do the trick.  Ira posted some examples like RfC 3806:

<http://permalink.gmane.org/gmane.ietf.ltru/3737>

> we need to expect IANA to maintain such stability. The other
> option is to find another registration authority.

The latter option would require a lot of work:  Update several
RfCs so that registries could be hosted elsewhere.  Or appoint
somebody to maintain PURLs for the IETF if you trust that PURL
lives longer than the direct URL.

 From that POV organizations like W3C or PURL are still "new"
(OTOH OCLC was founded 1967, that's good enough for the IETF).

> As Tim Berners-Lee puts it, "Cool URIs don't change"

ACK.  But IMHO it's not the main issue here.  I'd gues that
less than 1000 persons worldwide have ever heard of "3066bis".

The relevant reality is defined by "Googlebot finds it" plus
"Google shows it among the first 10 hits".  An absolute URL
in an RfC is a guarantee to spread the news, even in the worst
case (= IANA picks a new URL for the new registry).

Without that guarantee we can still hope that IANA picks the
old URL for the new registry, because then links on existing
pages continue to work for what we want.  E.g. I have a link
<http://www.iana.org/assignments/lang-tags/>

Okay, I'd update it when necessary, but numerous other folks
won't, unless they check links and get a 404.  Standards and
regitries are among other things wishful thinking, if nobody
knows them or everybody ignores them they are dead.

"Search Engine Optimization" is very important.  That's why I
proposed to add <http://www.inter-locale.com> to the <author>
section:  It will sky rocket Addison's page rank, this page
will have an URL to the new registry, Googlebot will find it,
and that's how "shaping reality" works today (AFAIK + IMHO).

                        Bye, Frank

---

From: r&d afrac <[email-masked]>
Date: Sun, 16 Oct 2005 01:48:01 +0200

>lives longer than the direct URL.

I thought the idea was to eventualy merge width CLDR?
So the whole thing would be supported on the same machines by the same people?
Every time I asked about the dissemination system and its size, 
usage, etc. I was responded "like Unicode"?

>less than 1000 persons worldwide have ever heard of "3066bis".

Please do not say that after an IESG 3066bis LC.
Since I would say that at least 500 knows it through my team ....
and most of these people are concerned by the impact not much by the 
technical hosting details.

Now, you would also imply that may be less than 100 ever read it?
So that IETF would go by minority consensus?

><http://www.iana.org/assignments/lang-tags/>

This seems an odd discussion because "lang-tags" is a directory of 92 
files. Not a registry of hundredth and then thousands of entries?

>and that's how "shaping reality" works today (AFAIK + IMHO).

I am not sure of the interest of the inter-locale.com site in this? A 
better IANA site design would be more suitable. You seem to consider 
the langtags will not really be used and known? Surprising.
jfc

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 16 Oct 2005 03:13:19 +0200

> I thought the idea was to eventualy merge width CLDR?

Why do you think that ?  I'm just curious.  It's less than
a week that I pulled another public en-UK stunt instead of
en-GB in a Usenet newsgroup... <sigh />

> Every time I asked about the dissemination system and its
> size, usage, etc. I was responded "like Unicode"?

http://www.unicode.org/Public/UNIDATA/NamesList.txt  768 KB

Yes, that's about twice (?) the size I'd expect for a 3066ter
registry,  For 3066bis it's less than 80 KB.  If you still
don't believe it let's wait until it's created, you can then
verify that it's really hosted by IANA and less than 80 KB.

>> I'd gues that less than 1000 persons worldwide have ever
>> heard of "3066bis".
 
> Please do not say that after an IESG 3066bis LC.

=> John reviewed the drafts.  Bruce explained why he didn't.
Probably some others also looked at it, but didn't bother
to comment.

> I would say that at least 500 knows it through my team

Those folks also didn't bother to comment it (assuming that
they exist, I don't share that opinion)

> Now, you would also imply that may be less than 100 ever

Yes.

> So that IETF would go by minority consensus?

No.  But those are TAObis / PECSI / general topics.  I'm still
trying to find out how it's supposed to work - especially if
there are conflicts, or if somebody only claims that there's
a problem.
  
>> E.g. I have a link <http://www.iana.org/assignments/lang-tags/>
 
> This seems an odd discussion because "lang-tags" is a
> directory of 92 files. Not a registry of hundredth and then
> thousands of entries?

It was only an _example_ for a public link to the relevant part
(my personal POV) of the old registry = "stuff I won't find in
the source standards".  I could as well link to a single file
<http://www.iana.org/assignments/language-tags> or to the HTML
view <http://www.iana.org/assignments/lang-tag-apps.htm> of
this directory.

For a fun effect try:
http://purl.net/xyzzy/-AWFID/inlinktext:%2522language%2520tags%2522

> You seem to consider the langtags will not really be used
> and known?

What I consider is that it may take years until the last user
of language tags will note that RfC 3066 has been replaced.

                           Bye, Frank

---

From: r&d afrac <[email-masked]>
Date: Sun, 16 Oct 2005 06:42:12 +0200

Dear Frank,
Interesting points, we would have discussed and hopefully addressed 
had we studied in common our Charter and made a clean sheet work.

>en-GB in a Usenet newsgroup... <sigh />

I just read the charter, looked at who are the authors, read the list 
of the Unicode officers and members, joined Unicode, discussed with 
people from their organisations, been contacted by some. Been 
inquired by industry people who are no members. By concerned Govs. 
Discussions inside ISO and other SSDOs. Exposure after the second LC helped.

The point is not what people plan. But what the problems are and what 
are the possible solutions and budgets.

>http://www.unicode.org/Public/UNIDATA/NamesList.txt 768 KB

I am afraid you missed the point. Please access the CLDR project.

- http://www.unicode.org/cldr/
- Directed by Mark Davis
- quoted in our charter
- none of the simple questions asked on this list about their IPRs 
was responded
- the determination to exclusive - any IETF only project would have 
rejoiced at "0-".

>verify that it's really hosted by IANA and less than 80 KB.

RFC 3066bis is of low interest irt. size. The size and use for "IANA" 
management is what they call RFC 3066 ter, quater, etc. A realistic 
forecast is between Unicode or the like and the DRS (an ISO 11179 
conformant Distributed Registry System).

>Probably some others also looked at it, but didn't bother

Thank you for this testimony. I agree. I suppose that a few tried but 
find it quite obscure (no definition, etc.) and abandonned.

>they exist, I don't share that opinion)

I am not sure what "assuming that they exist, I don't share that 
opinion" may mean? Which opinion.

I am not interested in commenting on RFC 306 bis, just in being able 
to use it. To remind our need was my job. You are the experts. We are 
the users. I am interested in sharing only if I see you do not 
deliver what I need.

I will recall two chanels I quoted (but I run/share in some others):

- AFRAC which works on the way to make every common information 
avalaible to users - so is interested in the technical quality of the 
deliverables; AFRAC is a small French R&D team with connections to 
various lists such as ISOC, Eurolinc, etc.

- NICSO which is a users / govs / small ccTLDs / community oriented 
think-tank. It broadcast specialised notes. Obviously they are not 
read by all the destinees.

I think a global awareness of 500 (people knowing there is a major 
problem, where and I will keep them posted) is conservative. But this 
people are not interested in a "possible". Now the document is 
approved, it enters into their field as a political move or as a 
legal violation. Politics are now interested. Lawyers will be 
interested when it starts being enacted.

> > Now, you would also imply that may be less than 100 ever

Thank you for this evaluation.

>there are conflicts, or if somebody only claims that there's

This is a good question. I was enrolled in the principle of a WG in 
giving conditions which were not respected. A charter came which was 
not respected. There is no way to really block the work of a WG even 
if you think it detrimental to the IETF. This is IMHO the main problem.

The only way left is I think the one I was able to follow:
- to make sure the document is the least harming one in the case it 
would be enforced. But you saw what it means.
- to try to work out an external consensus on a least confusing maket solution
- to prepare and engage the legal, market, political mechanic to 
block the error to try to enforce a practical consensus.

The problem is, if there is only one person, there may be an error, 
but at least there will not be confusion over a debate. The problem - 
as I experimented it - is when because there is only one (or a very 
limited kernel of) person who think paying attention to the IETF is 
worth the effort. If the problem is not that important for external 
people, we have a standardisation confusion. If there is a conflict 
and if it is vital to the external people or if they are no 
interested in other IETF issues, their only solution they have is to 
kill the IETF.

I hope that now the IESG has approved the document that danger is 
over. But it has been more than real. I never hidden it. And this is 
very easy now. This is why PECSI is important.

>http://purl.net/xyzzy/-AWFID/inlinktext:%2522language%2520tags%2522

This is good. But this is a searcher page (good idea). What we need 
is an operational registry supporting real applications/usages.

>of language tags will note that RfC 3066 has been replaced.

I am not as pessimitic as you are. The work achieved is of interest 
for the "globalization" (end to end ASCII English 
internationalization + localisation). I understand that CLDR is 
progressing well. Let assume it is in line with their Q2.2006. 
Globalization will then have most of its tools since they keep the libraries.

I suppose the WSIS, meetings like Berlin, the UNICODE meeting will 
give it some momentum. Then the meta-spam issue will make it known. 
So a solution will have to be proposed by mid-next year. That 
solution is the "0-/1-" userspaces and ISO 11179 conformance. ISO 
639-3/6 will have been published. This gives a good schedule and 
permits to work.

The point now is for us to publish the langroot, to work on the DRS 
servers logic and better document and support "globalisation". For 
the WG-ltru it is to finish the work over filtering. But it has to do 
it seriously in caring about the legal implications. The hope is the 
Internet Governance obliges the IETF solution to be the default of 
the common one the soonest to reduce costs, confusion and 
balkanisation as in IDNA.

The WG-ltru also has to do it in avoiding mad threads like the "route 
66" one. The approval of the IESG protects now the IETF against DoS 
(I hope) but will put more focus on this mailing list by more people.

Take care.
jfc