Subject: [Ltru] Re: [psg.com #1135] IETF/LC something other than BCP?

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 21 Sep 2005 00:06:57 -0700

Hi -

After carefully reviewing the extensive postings on the question
of how to procede with the registry draft and the initial registry,
here is how I'd like to procede, followed by a brief rationale for
this recommendation.

Modulo the edits already agreed:

On the initial registry, I think there is rough consensus to:
   1) recommend publication as an Informational RFC
   2) add a note to the RFC editor at the beginning of
      section 3, requesting that the rest of that section
      be deleted, and replaced with a note saying where the
      current registry is to be found (or a pointer to
      the registry RFC, which in turn says where the registry is)

On the registry document, I do not see a clear consensus, so my own
judgment colors this proposed recommendation to the IESG:
   1) recommend publication as BCP
   2) obsoletes 3066.  The pain with splitting out the matching
      stuff is similar with what we've gone through with RFC 1213
      being exploded into a zillion pieces.  If it's necessary
      to hold publication until the matching document is ready, I think
      that's a worthwhile tradeoff to avoid any ambiguity that
      would result from an "Updates 3066".

Looking ahead, I believe we are where we always were with respect
to the matching document:
   1) recommending Proposed Standard when it is ready.
   2) obsoletes 3066.  (see above)

Brief rationale:
Several alternatives were presented, each with pros and cons.
Ultimately, I found the arguments unpersuasive that this document
could, at least in part, be considered a protocol specification.
Though the BCP designation is a bit of a catch-all, it still
appears to be the best fit, is in keeping with what we were
instructed to produce, and would result in the least disruption
when specifications that currently reference 3066 or 1766 are updated,
particularly in view of the pains the WG has taken to maintain
syntactic compatibility.

When one looks at the specifications that reference 1766 and 3066,
for example RFC 2640 or 2070, they often provide their own
ABNF or other description of language tag syntax in that protocol.
We've already decided to move matching into a separate, standards-track
document.  Negotiation is clearly application protocol specific, and
is not covered by either the registry or matching drafts.  Consequently,
when I look at the references to the predecessor specifications,
I'm left with a clear sense that what's being referenced is not a
protocol specification, but rather the registry description, which,in
order to describe registry operation, had to spell out some syntactic
constraints.  Now I'm not claiming that I've been able to review every
reference everywhere, but I've seen enough to be reasonably confident
of a pattern.  I conclude that the document is a registry document, and
that the syntax specification is for the operation of the registry,
and does not constitute a protocol specification any more than any other
formal registry specification would.

Now, I'm not going to ask whether we're all happy with this recommendation,
but is this at least something we can live with, recognizing that the IESG
will probably have its own views as well?

Randy, ltru co-chair

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

---

From: Martin Duerst <[email-masked]>
Date: Wed, 21 Sep 2005 19:01:18 +0900

>will probably have its own views as well?

[personal opinion]

I can not only live with this recommendation, I believe
it's the best proposal we can make, for many reasons.

Regards,    Martin.

---

From: "John.Cowan" <[email-masked]>
Date: Wed, 21 Sep 2005 07:58:17 -0400

> here is how I'd like to procede, followed by a brief rationale for

[snip]

> particularly in view of the pains the WG has taken to maintain

And semantic compatibility as well: the interpretation of every existing
tag remains the same.

-- 
Take two turkeys, one goose, four               John Cowan
cabbages, but no duck, and mix them             http://www.ccil.org/~cowan
together. After one taste, you'll duck          [email-masked]
soup the rest of your life.                     http://www.reutershealth.com
        --Groucho

---

From: "John.Cowan" <[email-masked]>
Date: Wed, 21 Sep 2005 08:03:47 -0400

> > here is how I'd like to procede, followed by a brief rationale for

Arrgh.  I meant to insert "+1" somewhere in there.

-- 
The Imperials are decadent, 300 pound   John Cowan <[email-masked]>
free-range chickens (except they have   http://www.reutershealth.com
teeth, arms instead of wings, and       http://www.ccil.org/~cowan
dinosaurlike tails).                        --Elyse Grasso

---

From: D�l�gu� G�n�ral <[email-masked]>
Date: Wed, 21 Sep 2005 16:01:03 +0200

At 09:06 21/09/2005, Randy Presuhn wrote:
>Now, I'm not going to ask whether we're all happy with this 
>recommendation, but is this at least something we can live with, 
>recognizing that the IESG will probably have its own views as well?

Dear Randy (and Martin),
I appreciate the thinking effort, but I am afraid this is not a 
solution we all can live with. But not for the reasons you discuss.

RFC 1766, 3066 etc. express a constant and consistent policy 
documented by Harald Alvestrand which is referred to as 
"internationalisation". As such it acceptable to say that 
"internationalisation" is a part of the Internet standard process and 
can be described by a BCP.

But the WG-ltru charter identifies that the usage of RFC 3066 is 
inadequate, calls corrections and gives some hints. Let consider BCP 
47. It identifies a need (language identification), a way to address 
it (tagging), a lose description of how to do it (protocol), how to 
support it (registry), how to use it (filtering). There are three 
possible problem diagnosis I think of:

1. RFC 3066 only proposes a limited support of internationalisation 
(less than 92 registrations in 10.5 years). Let expand it.
2. RFC 3066 is correct but it is incomplete so we have to better work on it.
3. RFC 3066 addresses internationalisation but if 
internationalisation participates into it it is not what the user 
eventually need, so let comprehend and address the whole problem.

The problem is that commercial/strategic interests/inclinations made 
you decide diagnosis 2 exclusive. The prescription should therefore 
be exclusive and final. The wording/ABNF takes care of the exclusive, 
the BCP nature of the immediate standard.

I think the three diagnosis are true.

1. RFC 3066 does not address all the Internet language related needs. 
A simple proof is the ".cat" lgTLD.

2. in extending the documentation of the RFC 3066 different aspects, 
one breaks the BCP nature and equilibrium. The same as filtering is 
PS, the same the ABNF is a PS protocol: it carries registry supported 
information to be used to manage an interchange (and to be used by a 
PS filtering). That it can also be used in document classification 
and in search engines (creating security risks for the users),does 
not change that language tags are male plugs to fit female plugs 
which are filters. Their purpose is to carry network information: 
aside of SMTP From, To; Subject, there are Language: Script: Region:.

There is no problem in removing the ABNF - and possibly the registry 
management, or adding ways the Internet standard process is to 
consider the language aspects, the way IAB guidance is necessary for 
a few points, etc... . This keeps defining the Multilingual Internet as BCP 47.

3. where we really oppose is that the constrained RFC 3066 approach 
does not scale. Real world analysis shows there are three demanded 
architectural layers. Question is probably to understand which ones 
are part of the IETF scope. But they must not be denied services.

- (1) end to end interoperability. This is internationalisation (or 
localisation). CLDR assumes it is based upon language/script/country. 
I am not convinced: there are many other localisation needs. But we 
agree it concerns the computer end and infrastructure.

- (2) brain to brain interintelligibility. This is what we call 
multilingualisation. This means to address networked languages as 
spoken, written, sung, signed, etc. languages are considered (however 
it is probably much more complex). As brain to brain information 
exchange protocols. It considers a person knowing external rules 
(referent) exchanging with another one knowing (not necessarily 
sharing) the same referent.

- (3) mind to mind inculturation (culture sharing). This is what we 
can call vernacularisation. This means to support the networked 
exchanges of people sharing a same context.

The WG-ltru proposed is a layer violation. As every layer violation 
it is not easily perceived when at default. The layer 1 refers to 
locales (what the systems MUST share to interoperate). Layer 2 calls 
for a referent to be documented (what two unknown persons are to use 
to understand each others). Layer 3 calls for a context to be 
documented (what the other person MUST understand to be in full empathy).

The internet default is "manufacturers English-Latn-US 
legal/technical usage". The proposition adds the "locale". In a 
nutshell: what Unicode wants to document. This means that the 
resulting system is adequate to support legal/technical applications 
in any language. Legal here includes: contracts, e-commerce forms, 
etc.. Technical here includes classifications, programming, e-mail, etc.

This is why the proposed WG-ltru Draft:

1. is adequate for the legal/technical area in the limited XML 
perspective. This is why the first thing I asked was to define the 
area of application and let discuss how to enlarge it.

2. can be made adequate though the "0-" extension which is an 
existing solution able to address all the other needs even if not 
always in an elegant manner.

This is why - seeing that we have wasted enough time in not 
identifying diagnosis 3 (Harald's strategy is correct at its level, 
support of the upper layers is to be organised) - the Versailles 
meeting has engaged in an entirely different approach which consists 
in documenting an ISO 11179 compliant logical model, able to accept 
the current propositions as its value domains. The problem will be to 
relate them through a metamodel (we named the "langroot" but which 
might extend to the whole Internet ontology). The problem is not 
simple as ISO 11179 only considers a "flat" model (metadata/data) 
while a decentralised system like the Internet necessarily calls on 
the notion of "paradata" and of information addresses. It also calls 
on a management insuring the unicity of datas in a given context. 
Something we know well with the DNS pollution. It also calls in the 
way to register and disseminate the information.

At this stage the langroot refers around 7800 items, bridges the DNS. 
But its structure is not stabilised at all. We should however publish 
a copy soon and deploy a documentation site, in line with the time 
schedule I announced in May.

Once we see how it stabilises, withinSO and other SSDOs we will issue 
a Draft. May be in November.
Good luck with your position. Unless you add the "0-" half-line and 
permit Martin to live in peace, it will be appealed and challenged 
everywhere. I do not think it is your target.

jfc

---

From: Mark Davis <[email-masked]>
Date: Wed, 21 Sep 2005 10:08:39 -0700

I assume Martin is speaking to Randy's text below. And I agree with Martin.

Martin Duerst wrote:
> recommendation,

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 21 Sep 2005 20:25:57 +0200

>       the registry RFC, which in turn says where the registry

Apparently there's a new language tag "rup", and so the state
"waiting for AD go-ahead" substate "revised ID needed" could
be used to 1) add "rup", 2) move chapter 3 to appendix A, 3)
fix ToC reflecting this, 4) add a dummy link to the registry,
5) add a RfC-editor note to remove appendix A and to fix this
   dummy link as soon as the real IANA registry is available.

John also proposed to get rid of the [record-jar] reference
in this informational RfC.

>    2) obsoletes 3066.
[...]
>    2) obsoletes 3066.  (see above)

Above all "obsoletes 3066"...

> I'm not going to ask whether we're all happy with this
> recommendation,

...the form apparently forces the AD to recommend a status.

                       Bye, Frank

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 21 Sep 2005 11:39:28 -0700

Hi -

(Note new subject.)

> From: "Frank Ellermann" <[email-masked]>
> To: <[email-masked]>
> Sent: Wednesday, September 21, 2005 11:25 AM
> Subject: [Ltru] Re: [psg.com #1135] IETF/LC something other than BCP?
...
> be used to 1) add "rup"
...

Yes.  Doug is already aware of this.

Randy, ltru co-chair

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 21 Sep 2005 11:43:03 -0700

Hi -

...
>  and so the state
> be used to
...
> 2) move chapter 3 to appendix A, 3)
> fix ToC reflecting this,
...

As a technical contributor, I'd strongly suggest that we not
engage in reorganization at this time, and that we limit the
change to the absolute minimum needed to accomodate
the comment.  Let's avoid complicating things for ourselves
and our editors.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 21 Sep 2005 11:45:51 -0700

Hi -

...
...
> 4) add a dummy link to the registry,
...

Let's see what Doug proposes for the note.  I'd personally prefer
a reference to the registry draft, rather than putting an URL into
the note in the initial registry draft.  That would leave fewer
opportunities for error in AUTH48.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 21 Sep 2005 11:52:20 -0700

Hi -

By the way, John Klensin proposed that the note be something like

"3.  The initial contents of the registry as specified
in this document are those entries in the IANA registry
[IANA-registry] with a field-name of "Added" and a value
of "2005-07-10".  Note that [ltru-registry, Section 3.1]
requires that an "Added" field appear in each
registration record and that its Section 3.3(1)
specifies that field must not be changed after
registration."

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 21 Sep 2005 11:59:09 -0700

Hi -

...
...

Well, the discussion as I read it lead to John saying (about the registry
document):

| I would recommend that, as an editorial matter, use of phrases
| like "inspired by" or "derived from" would clear up a lot of
| confusion before it starts, making it clear that the book is not
| needed.  For example, the beginning of the second paragraph of
| 3.1 might read
|
| 'The registry will be in a text file format that is
| fully specified below.  This format was inspired by the
| "record-jar" format [record-jar].'

I think analogous editorial tweaks in the two places where the format
is mentioned in the initial registry draft are less drastic than the
changes needed if we eliminated the reference entirely.  As I read
your posts on the topic, it seemed you were arguing that giving
credit to the originators of the format that inspired this one
was the right thing to do.

Randy

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 21 Sep 2005 21:35:47 +0200

Randy Presuhn wrote:

>> 1) add "rup"
 
> Yes.  Doug is already aware of this.

Sure, but I guess that Doug prefers to know that "we" (TINW)
are also aware of this, with these mad IETFers - one constantly
changing his name, others seriously debating BCP vs. STD, the
IETF Chair trying to clean his list from everything he's not
really interested in, an AD proposing to upper-case all "may"
and "must", a WG Chair screaming about his "subjects", the IANA
allegedly unable to add 2+2 as long as the result is 5, strange
conspiracies of typesetters (time to admit it, my father was a
typesetter), somebody checking ISO and UN Web pages for obscure
entities like "830" or the colour of GG, despite of a WG Chair
saying that it's the name of a cow, a dangerous period of about
six weeks where numerous zh-cmn pages missed the opportunity to
stick to zh-guoyu, a mysterious invasion of BU by NH - so yes,
I fear for this author it's more like a mad ETF than an IETF,
and he's happy if "we" explicitly agree on something.   </joke>

                       Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 21 Sep 2005 21:58:27 +0200

> [IANA-registry]
  ^^^^^^^^^^^^^^^
That beast in the references is what I called "URL".  In the
"registry draft" it's only given in prose, not as a reference:

| All approved registration forms are available online in the
| directory http://www.iana.org/numbers.html under "languages".

| The new registry MUST be listed under "Language Tags" at
| <http://www.iana.org/numbers.html>, replacing the existing
| registrations defined by [RFC3066].

In the "initial draft" [IANA registry] would be a reference,
with the complete URL given in the references.  Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 21 Sep 2005 22:10:54 +0200

Randy Presuhn wrote:
 
> I think analogous editorial tweaks in the two places where
> the format is mentioned in the initial registry draft are
> less drastic

Yes, that's also ok.  At the moment the "editor's copy" of
draft 13 still doesn't have a proper reference with ISBN
and publisher (seriesInfo) for [record-jar].

                           Bye, Frank

See <http://mid.gmane.org/[email-masked]>

---

From: r&d afrac <[email-masked]>
Date: Thu, 22 Sep 2005 00:45:12 +0200

[this mail was sent using a non approve mailbox to the list, iesg and 
randy - I send it back to the list]

Dear Randy (and Martin),

jfc