Subject: [Ltru] Last call comments on LTRU registry and initialization documents

From: John C Klensin <[email-masked]>
Date: Tue, 06 Sep 2005 06:43:59 -0400

Comments on draft-ietf-ltru-registry and
draft-ietf-ltru-initial and, secondarily, on
draft-ietf-ltru-matching...

Summary: These documents represent good work, and the community
should be grateful to have them.  However, I believe they, and
the still-incomplete "matching" one, have conclusively
demonstrated that the expectations of the WG Charter were
unreasonable and inappropriate.  When the documents are
examined as an IETF product, rather than on the assumption that
the charter represents perfect foresight, it is clear that the
documents should not be handled as BCPs but as Proposed
Standards, with an applicability statement and/or profile to
follow.  The reasoning behind this conclusion is explained
below.

---------------

These specifications are a nice piece of work and the model
specified is quite elegant.  It appears to me to meet the goals
of permitting a high degree of specificity when needed while
providing a plausible mechanism for preserving stability across
changes in underlying documents.  Having tried, mostly
unsuccessfully, to track the WG's work, I believe that the IETF
community owes those who have actively participated and
contributed great thanks.  However, the documents that they
have produced should not be approved as one or more BCPs, nor,
in their present form, as replacements for RFC 3066 / BCP 47.
An alternate suggestion that does not require significant work
beyond that specified in the charter is outlined below.

(1) BCPs or Proposed Standards

The WG Charter calls for the production of BCPs.   Like all
provisions of WG Charters, the requirements that the community
specifies and agrees to must be treated as tentative: if the
best work the WG can produce, consistent with the general goals
of the charter, are not acceptable as the charter specifies,
the community must have the ability to change categories or, in
the worst cases, refer the WG products back to the WG for
further work under a new set of charter specifications.
Fortunately, I do not believe that worst case applies here: the
documents that were last-called appear to be quite appropriate;
it is only how they are classified and applied that appears to
be at issue.

RFC 3066 (and 1766) were arguably just a mechanism for tying a
few existing (and tested) specs together, using a review and
registration procedure.  As such, they were at least marginally
inside the category and usage for which BCPs are appropriate.
LTRU-registration, by contrast, is designed to operate without
registration of full tags: the role of the reviewer, and of
IANA, is to register subtag entitites from which tags can be
constructed.  It also provides for a highly distributed
registry, with different maintainers for different subtags or
groups of subtags.  Neither the IETF community, nor the IANA,
has any experience with doing things that way.  Given the
importance of this registry, and the dependencies upon the
preceeding 3066 registry, that combination of conditions -- a
more complex architecture, registration of components rather
than full tags, and lack of community experience with the
approach -- adds up to an extremely strong argument for
treating these documents as Proposed Standards, and then
letting them advance along the standards track as experience
accumulates, rather than approving them as a single-stage BCP.

(2) Matching rules and the replacement of RFC3066/ BCP47

RFC 3066 essentially specifies its own set of matching rules:
for matching purposes, tags are treated as atomic and two tags
match or they do not.  Both the "registry" document and some of
the discussion leading up to it pointed out the flaws in that
approach, particularly tags that are equivalent but do not
match because extra information is supplied.  However, the
material in Sections 4.1 and 4.2 of the LTRU specification does
not provide an adequate replaceent for Section 2.3 of RFC 3066.
The latter is considerably more normative and specific (even if
naive in retrospect).  By contrast, the material in the LTRU
registry document gives much more general guidance, but not the
level of specific instructions needed to promote
interoperability.  Hence, a _replacement_ for RFC 3066 as BCP
47 requires not only the registry specification but a set of
matching rules (perhaps those to be specified in
draft-ietf-ltru-matching, but see below).

(3) Interoperability issues

Until and unless a protocol or specification is tested in
practice, interoperability is no better than an hypothesis.
That is one reason, perhaps the major reason, why we have a
multiple-stage standards process.  It is also much of the
reason why the IETF has traditionally tried to avoid complex
protocols with many options.  As Marshall Rose elegantly wrote
in RFC 1425, 

   Experience with many protocols has shown that:

       protocols with few options tend towards ubiquity, whilst
	   protocols with many options tend towards obscurity.

Viewed as a protocol the LTRU model is option-laden.  Much as I
dislike going down the path of profiles, it appears to me that,
if we are going to keep interoperability paramount, the general
guidance about choices of tags in Section 4 of the registry
document must be supplemented by application-specific profiles,
developed from use cases, that include both tagging and
matching rules if we are going to support interoperability and
avoid many of the operational problems with 3066 that
stimulated the LTRU work.

(4) What should be done.

I have become convinced that, rather than approving these
documents as a BCP, we should...

	(i) put the registry document on the standards track, as
	a proposed standard.  While this step, and the next one,
	should not be done without agreement from the WG, they do
	not require any additional work on the WG's part.  While
	changes from would-be standards track to informational or
	experimental are more common, such changes of designation
	after Last Call are clearly within the IESG's scope.

	(ii) either put the initialization draft on the
	standards track with it or publish it as informational and
	use the downref procedure,  
	
	(iii) define a profiling mechanism for what should
	actually be done to effectively and interoperably use this
	registry.  This step, and the one that follows, is an
	additional task for the WG.  But the WG's work is, IMO, not
	complete until it is done: mechanisms for how to put
	something into a registry are always much easier than
	determinations of how entities, once registered, are to be
	used in an effective and interoperable way.  For the IETF,
	the latter has always been key... to the point that it is
	implicit in every WG charter.

	(iv) acknowledge that only a profile, and not the
	registry doc, can replace 3066, and that such a profile
	must combine rules for registry use and specific matching
	rules.  Such a profile is inherently dependent on the
	matching rules and only a document (or set of documents)
	that specifies both registration and matching can
	appropriately become a new version of BCP 47.
	
	(v) put the matching doc on the standards track when it
	is considered ready, with only the profiles (if that)
	showing up as BCPs.  As with (i) and (ii), this does not
	intrinsically require more work from the WG.

--------------------------

Some nit-picking (easily fixed):

The documents make reference to the "record-jar" format.  I
believe the text in ltru-registry is sufficient to define the
portion of that spec that is relevant, justifying the editor's
choice to list [record-jar] an an information reference.  If
that is correct, the fact that the format specification is
self-contained in this spec should be made _very_ explicit in
both the "registry" and the "initial" document.  Indeed, the
"record-jar" reference might best be eliminated from the latter
document as a distraction.  If it were not, I believe that we
should obtain permission from Eric Raymond and if necessary
Addison-Wesley, to reproduce the relevant material in an RFC: a
dependency on a moderately expensive book that could go out of
print as part of the definition for an IANA registry should be
acceptable to neither the IETF nor to the IANA.  And,
incidentally, the reference given is incomplete.

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

---

From: John C Klensin <[email-masked]>
Date: Tue, 06 Sep 2005 16:19:47 -0400

--On Tuesday, 06 September, 2005 15:14 -0400 Sam Hartman
<[email-masked]> wrote:

> John, what does it mean to put a registry document on the
> standards track?  In particular, how do you get multiple
> implementations of a registry?

One is reminded of the story of Eeyore's birthday party.
Registering things --putting them into a registry so that they
can be retrieved and examined using whatever key was used to put
them there-- is always easy and, as you point out, untestable.
But it is also almost never the point: the point is whether the
right information is being placed in the registry to support the
relevant applications and whether those applications can use the
information in a way that promotes interoperability.  

With regard to that driving issue, it is certainly possible to
have multiple implementations of matching rules.  It is
certainly possible to examine, in practice, different uses of
the tagging system to determine whether its mechanisms are
sufficient and, if sufficient, whether they meet some "minimum
necessary" criteria or represent serious overkill and/or
redundancy.

With apologies to Spencer, let me turn your question around and
ask how something can be identified as a "Best Common Practice"
when 

	* when it has not been practiced at all, 
	
	* when there is no evidence that it is "best" (even if
	one agrees that no better options are on the table or
	even that none are likely to be searched out and found
	unless, someone, this approach is shown to fail as RFC
	3066 was shown to fail), and 
	
	* it certainly isn't "common" in the "widely
	disseminated and used" sense of that term.

Things would be better if we had "PP" (proposed practice), "AGI"
(apparently good idea), or "WTOSITD" (well thought-out shot in
the dark), or "NRtBTWNW" (no reason to believe this will not
work) categories.  But we don't.  And the model and mechanisms
associated with Proposed Standard, when applied to the use cases
rather than the registry itself, much more nearly meet
application needs and community expectations than identifying a
document like that as a BCP.

    john

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 06 Sep 2005 16:42:19 -0400

This document defines structure and meaning for labels, as well as the 
procedure for registering parts of that structure.
As such, the structure is "bits on the wire" and is subject to 
interoperability concerns.

Yours,
Joel M. Halpern

At 03:14 PM 9/6/2005, Sam Hartman wrote:
>John, what does it mean to put a registry document on the standards
>track?  In particular, how do you get multiple implementations of a
>registry?
>
>--Sam
>
>
>Ietf mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ietf

---

From: Sam Hartman <[email-masked]>
Date: Tue, 06 Sep 2005 15:14:09 -0400

--Sam

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 07 Sep 2005 01:10:49 +0200

John C Klensin wrote:

> (ii) either put the initialization draft on the standards
> track with it or publish it as informational and use the
> downref procedure,

That's a formal point:  The initial registry is too long to
put it in the IANA considerations of the main document, and
it will be soon obsolete.  Therefore it had to be a separate
document.

Because the WG wanted a proper last call also for this part
it was published as I-D.  Same idea as for e.g. RfC 4021 - a
part of the header field registry defined in RfC 3864.

Apparently RfC 4021 is "standards track", but "informational"
for the initial registry is also possible.  I don't get the
need for "downref" in this case, the reference to the initial
registry in the main document _is_ only informational.

Do "informational" RfCs created by a WG get a "last call" ?
I'm not sure what the last paragraph in 2026 4.2.3 means.

Something's odd with the procedures here, I'd be surprised
if RfC 4021 would be promoted on stadards track, it's only
a (now already obsolete) snapshot of a part of a registry.

> believe the text in ltru-registry is sufficient to define
> the portion of that spec that is relevant

Yes, the defined format is "inspired by" record-jar, it does
not claim to be the real thing.  E.g. it doesn't have arbitrary
comment lines, OTOH it defines a way to encode Unicode by the
known &#x????; sequences for u+????.

> a dependency on a moderately expensive book that could go out
> of print as part of the definition for an IANA registry

No, it's also only informational for those interested in "the
real thing" instead of what's used for the registry and future
extension registries. 

> incidentally, the reference given is incomplete.

Yes, the draft author knows already how to add the proper ISBN
with xml2rfc, "easily fixed" as you said.  Not referencing the
original idea at all would be wrong.  But the reference in the
initial registry draft is in fact unnecessary.  Think of it as
some kind of "informational credits" in the main document.

We also considered a pure 2822-like format with CRLF CRLF as a
record separator, but the WG preferred CRLF "%%" CRLF, that's
all - no copyright traps and no necessity to buy the book (e.g.
I don't have it).
                             Bye, Frank

---

From: John C Klensin <[email-masked]>
Date: Wed, 07 Sep 2005 02:42:40 -0400

> registry in the main document _is_ only informational.

That wasn't clear from the text, but I may not have read closely
enough.    See below.

> I'm not sure what the last paragraph in 2026 4.2.3 means.

Independent of what that paragraph means, it is common for
anything that is presented by the WG to IESG for comment to get
a last call within the WG; I can't imagine a WG chair doing
otherwise.  Whether WG informational documents are then Last
Called to the IETF is up to the IESG and relevant ADs.  There is
no requirement that it be done, but it generally is done if the
AD concludes that the document is likely to be either
consequential or controversial.

> a (now already obsolete) snapshot of a part of a registry.

Personal opinion: What should be done in cases like this is to
structure the I-D so that it clearly differentiates between:

	(i) The specification, rationale, and other contextual
	information for the initial registry contents, and 
	
	(ii) The actual listing of the registry initialization

and that the specification provide for some way of
distinguishing between initial registry entries and subsequent
ones by examining the registry (this could be as simple as the
specification of a particular date.

Then an instruction to the RFC Editor could be included in the
I-D asking that they not publish the initialization document
until the entries have been made in the IANA registry and then
that the list of entries be dropped and replaced with a pointer
paragraph and reference.  That would lead to an RFC that was
clearly informational and fairly short, saving everyone
long-term problems.

For draft-ietf-ltru-initial, that would mean retention of
sections 1, 2, and 4-7 into the RFC but the replacement of
section three with, e.g.,

	"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."

Then you are done.  Presto, clearly informational document,
historical information retained in the registry (which is where,
IMO, it belongs), no chance of anyone ignoring the instructions
in the third paragraph of Section 1 that the initialization list
in the RFC is not the registry, and an RFC that runs around ten
pages rather than 118.  

I think that would be a win all around.  But, again, just my
opinion.

> real thing" instead of what's used for the registry and future

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].'

But, again, this is purely an editorial matter as far as I'm
concerned.

> all - no copyright traps and no necessity to buy the book (e.g.

Not a decision on which I'd ever be inclined to second-guess a
considered WG decision.

    john

---

From: Sam Hartman <[email-masked]>
Date: Tue, 06 Sep 2005 17:22:20 -0400

>>>>> "John" == John C Klensin <[email-masked]> writes:

    John> --On Tuesday, 06 September, 2005 15:14 -0400 Sam Hartman

    >> implementations of a registry?

    John> One is reminded of the story of Eeyore's birthday party.
    John> Registering things --putting them into a registry so that
    John> they can be retrieved and examined using whatever key was
    John> used to put them there-- is always easy and, as you point
    John> out, untestable.  But it is also almost never the point: the
    John> point is whether the right information is being placed in
    John> the registry to support the relevant applications and
    John> whether those applications can use the information in a way
    John> that promotes interoperability.

    John> With regard to that driving issue, it is certainly possible
    John> to have multiple implementations of matching rules.  It is
    John> certainly possible to examine, in practice, different uses
    John> of the tagging system to determine whether its mechanisms
    John> are sufficient and, if sufficient, whether they meet some
    John> "minimum necessary" criteria or represent serious overkill
    John> and/or redundancy.

It is possible to do many things.  I was hoping that I could get you
to make a concrete proposal for how you see this document advancing if
we put it on the standards track.  Personally I think your comments
are valuable even if you don't make such a proposal,but I think they
would be more valuable if you or someone holding the same position
would make it very clear what it would mean for this document to be on
the standards track.  My question is not motivated by a lack of
imagination about what that could mean but rather all too many options
I can think of.

Here are some questions it seems like the IETF community would need to answer in order to implement your proposed categorization:

1) What happens to the existing registry with these documents on the
    standards track but not BCPs?

2) How do we advance these documents on the standards track?

In addition, it might be advisable for the IETF community to consider
the question of what happens if we find this is not the right
approach; that question is not required to implement your proposed
reclassification but it seems advisable to consider.

Let me throw something out to answer the questions I posed.  We could
keep the existing 3066 registry as the BCP registry and create a new
registry for these documents.  We could advance these documents when
any single using protocol advances.  Presumably that would mean that
these documents could not advance until some protocol that normatively
references them advances; that's probably OK.  Clearly these are not
the only answers to the questions I posed--I'm not even sure if they
are good answers.  They are presented only to illustrate that it is
possible to answer the questions without huge effort.  That in turn
suggests to me at least that I'm not establishing an unreasonable
requirement by asking the questions be answered.

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Wed, 07 Sep 2005 15:37:46 +0200

>         3066 was shown to fail), and

John,
you can say that!

There are four propositions. The Draft is the least network oriented, 
but has its place for catalogs, library organisation, related menus, 
and e-commerce contracts. It should have been a WTO, W3C, LDAP, MPEG 
proposition, but it supports a consistent content-database-computer 
management system (HTML, XML, CLDR [some Locale standardisation 
attempt]). The problem is simply that it would constrain human 
relations and cultural life support protocols to its locale 
"internationalisation" conceptual level, and miss key networked 
communication aspects.

A two minutes consideration of the difference between the way 
Shakespeare wrote a page and the way you store, distribute and read 
it today, may give you some hints about the difference between what 
the Draft wants to do and what the IETF needs. The Draft drastically 
extends the basic error of the lose RFC 3066 (rigidifying orthogonal 
language/country information) and wants to see it enforced and made 
universal.

A content container should at least document if the language 
description is from the author, to the reader or for the protocol. It 
should the document seven properties (language, mode, community, 
referent, context, style, media) and the property description 
version. Your own Words program just does that. Each of these 
elements may include many sub-elements.

There are three other propositions than status-quo:

A. the current Draft using of ISO 639-1, 2, 3 and additional ISO 
codes. That proposition is based upon the SIL list of 7500 documented 
languages. It is supported by Peter Constable (on the list), author 
of ISO 639-3.

B. Linguasphere (planned to be ISO 639-6). It identifies 20.000 
community language 4 letters not reusable codes and is built as ISO 
11179 compliant for far more information. They fully replace langtags 
when no legal aspect is involved. They are planned to be discussed 
when an ISO standard. It is supported by Debbie Garside (on the list) 
and Dr. David Dalby.

C. the "grassroots approach". The approach is to accept in a network 
and multilingual way everything existing and to relate it to an "ISO 
11179" compatible system. Still at basic thinking and experimental 
stage. This is part of a generalised DRS (distributed registries 
system) to include every network/local/user registry (including 
langtag). The URI-tags seem to fully support the network aspects, the 
IRI-tags the multilingual concept. It obviously support the two 
systems above which can be its defaults. I accepted to spend time on 
the representation of  industrial, political and users interests in that area.

There is no "better" solution. There are more adequate solutions in 
specific situations (A and B can be defaults of C). Each helping the 
other to better define itself. However the A proponents think their 
proposition must be exclusive. They wanted a counter-proposition of 
mine so the "best" might "win". Their ad-hominems were their way to 
exclude a "competition". Their non-technical mails on the IETF main 
list fully exposed that strategy.

The text proposed in December was not acceptable. The currently 
proposed text still appears as an "industrial and commercial Trojan 
Horse" with risks of commercial, political and technical confusion. 
But its authors have trimmed enough their ABNF "against me" to block 
"C" leaks there and threfore a lot of confusion. Yet, we have still 
have no support of non-script mode and three sources of conflicts:

- charset of a document vs script.
- script of a document in a politically oriented (privacy/racial 
violation) tag.
- lingual community information - what may imply a conflicting 
language, script and charset - may conflict with langtags.

My proposition is:

1. to reduce the charset/script conflicts in defining the Internet 
meaning of a script (equivalent to ccTLD IDN tables). No big deal, 
since the tables are already published by Unicode.

2. to define the relation between ccTLDs and langtags "regions" - 
probably one sentence to be approved by IANA, ICANN and the ccTLD community.

3. to include the IRI-tags into the Draft, through the multilingual 
(numeric) "0-" hook, so we support different but not alternative descriptions.

I was opposed over ISO 11179. It seems this has changed since the 
August ISO meeting. I can only rejoice. IMHO the DRS issue is far 
more complex than ISO 11179 and should be addressed separately (may 
be after some experience has been gained with the IRI-langtags?)

jfc

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 08 Sep 2005 01:11:52 +0200

> anything that is presented by the WG to IESG for comment to
> get a last call within the WG; I can't imagine a WG chair
> doing otherwise.

Yes, we've done this.  The problem with the initial registry
is that it's easy to miss something - it's derived from six
different sources, among others the "old" 3066 registry.  For
some details it's possible to fix potential bugs later (using
the registration / review procedure of the main document).

But generally it's intentionally impossible to get rid of a
registered tag, they are persistent:  "deprecate" is allowed,
but not "removal".  Therefore it's important to find any bug
now in the "IETF last call", later would be too late.

> Whether WG informational documents are then Last Called to
> the IETF is up to the IESG and relevant ADs.  There is no
> requirement that it be done, but it generally is done

Okay, that's the desired effect in this case, the status (PS,
informational, or other ways to send it to IANA) is secondary.

[...]
> that the specification provide for some way of distinguishing
> between initial registry entries and subsequent ones by
> examining the registry

That's possible, there are "Added" / "Deprecated" timestamps.
 
> an instruction to the RFC Editor could be included in the
> until the entries have been made in the IANA registry

That should be also clear, there are "IANA considerations" in
both documents, and it makes no sense to publish them as RfC
without first creating the actual registry (as defined by the
initialization document).

In other words, we artificially squeezed the initial registry
into an I-D to get the desired "IETF last call", and IANA has
to remove these artifacts (intro, boilerplate, page headers)
again resulting in the proper registry.

> section three

1, 2, and 4..7 are only a "content-transfer-encoding" for the
purpose of getting 3 via "IETF last call" to IANA.  And as a
side-effect there will be also a RfC documenting "the making of
the initial registry" - in theory it could be also archived as
"historic RfC" after IANA created the real registry.

> historical information retained in the registry (which is
> where, IMO, it belongs), no chance of anyone ignoring the
> instructions in the third paragraph of Section 1 that the
> initialization list in the RFC is not the registry, and an
> RFC that runs around ten pages rather than 118.

Splitting it is IMHO less convincing - your idea assumes that
chapter 3 already exists as new IANA registry, but that's not
yet the case.  Some hen and egg situation, and if there's an
informal way to create IANA registries on probation (subject
to a future "IETF last call") the WG didn't know it.

The chapters 1, 2, 4..7 are also interesting without 3, but
OTOH the same info is also available in the LTRU list archive,
it's not strictly necessary to keep it as separate RfC apart
from chapter 3 (= the beef, about 100 pages).

 [record-jar]
> For example, the beginning of the second paragraph of 3.1
> might read

> But, again, this is purely an editorial matter as far as I'm

It's fine, I like it, then fix the [record-jar] reference, and
it should be clear that <registry> is fully specified in the
main document, with the book only "for info" and as "credits".

                        Bye, Frank

P.S. for Randy:  Can we get a ticket for this editorial issue ?

It's about 1 - no [record-jar] in "initial", 2 - "inspired by"
in "registry", and 3 - add ISBN + publisher to the reference.

---

From: John C Klensin <[email-masked]>
Date: Wed, 07 Sep 2005 19:58:45 -0400

--On Tuesday, 06 September, 2005 17:22 -0400 Sam Hartman
<[email-masked]> wrote:

> It is possible to do many things.  I was hoping that I could
> get you to make a concrete proposal for how you see this
> document advancing if we put it on the standards track.

Sorry, I may have misunderstood.  Also, to some extent, I
thought I answered this question in my initial note, but may not
have been clear enough about it.  And I deliberately avoided too
much detail as possibly not appropriate to a Last Call comment.

> Personally I think your comments are valuable even if you
> don't make such a proposal,but I think they would be more
> valuable if you or someone holding the same position would
> make it very clear what it would mean for this document to be
> on the standards track.  My question is not motivated by a
> lack of imagination about what that could mean but rather all
> too many options I can think of.

Well, I think that the decisions here should be made, or at
least proposed and supported, by the WG and not by one of us.
I, too, can imagine many options.  Let me suggest answers to
your questions below with the understanding that the WG may have
better answers, and then comment further if that appears to be
needed.

> Here are some questions it seems like the IETF community would
> need to answer in order to implement your proposed
> categorization:
> 
> 1) What happens to the existing registry with these documents
> on the     standards track but not BCPs?

Same thing that happens if they are adopted as BCPs.  Or not.
The current documents propose to obsolete one registry and
replace it with another.  It is at least as appropriate to do
that in a standards-track document as it is with a BCP.  

Alternately, what I have anticipated (and intended my notes to
suggest) is that draft-ltru-registry and draft-ltru-matching
(and maybe some other things) end up on the standards track and
be supplemented by applicability statements that identify the
contexts in which they should be used and with which options.  I
would hope that the number of them would be quite small, but one
could easily imagine an "LTRU matching options for use with MIME
and HTML" and an "LTRU matching options for use with XML in i18n
contexts" that might show some differences.  Or not.  In the
most general of cases, such documents might reference the new
registry and old (bit-identical and handwaving) matching rules
or the old registry and new matching rules.

As Addison points out, the entries permitted by the new registry
concept are sufficiently compatible with the entries in the old
registry that the above fine distinctions would probably not be
necessary.  If so, any and all applicability statements would
apply to the new registry.  One could separately direct IANA to
stop accepting registrations in the old registry.  And that is
the most practical and plausible definition of deprecating/
obsoleting a registry: no protocols or applicability statements
utilize it and IANA does not accept new entries into it.   To
simply say "don't use that one any more, use this one", is an
appeal to authority, not a demonstration that the old one is, in
fact, obsolete and superceded.

My problem with LTRU-registry (and LTRU-matching) in this regard
is that they mix up "specify a better registry and matching
model" with "get rid of 3066".  At present, it is unproven
whether, in practice, the subtag registration model of
LTRU-registry, combined with LTRU-matching, is a sufficient
replacement for all of the uses to which 3066 may be put.  We
need to remember that we have no way to know whether we have an
inclusive list of all of those uses.   It is much safer, in the
environment in which we find ourselves, to write an A/S
("profile" to all intents and purposes) that _replicates_ the
tagging model and matching rules of  3066, excluding all of the
new subtag types that LTRU-registry permits, but that references
the new registry and not the old one, and let _it_ replace 3066.
Then one writes one or more additional A/S documents that
specify different applicability of the new registry with
LTRU-matching and let it complement or update the
3066-compatible A/S as appropriate.

> 2) How do we advance these documents on the standards track?

My apologies, but this is going to be a bit long because I think
we have gotten into a philosophical and procedural tangle
(through no fault of the LTRU WG).

We turn the question around, perhaps taking a trip back to when
BCPs actually represented "common practices" or even before we
had BCPs.  Our colleagues at, e.g., ISO and the ITU, have
sometimes gone into the business of making lists: establishing
registries of things so that numbers or codes could be assigned
to them and standardized, independent of the actual applications
to which those lists might be put.  Such lists can be evaluated
on internal quality (sometimes objectively, sometimes not), but
it is usually assumed to be unfair to evaluate them on their
success in supporting particular applications and types of
applications.  Ultimately, a criticism of the relationship
between the list and some application is rejected on the basis
that the relevant committee or process just assigns code points
-- interpretation of those code points with regard to any
particular real-world problem is is out of the committee's scope.

Those efforts are often extremely worthwhile and extend across
broad classes of work --efforts related to character sets,
scripts, languages, and even country code identifiers are a tiny
fraction of the whole.  Even when I complain about the "we just
assign code points" attitude, I recognize its validity and
importance.

_However_, as far as I can remember, the IETF has never
intentionally gone into that business.  Instead, we create
registries in support of particular protocols or sets of
protocols.    The success or failure of the "foo" registry is
not evaluated on how many foos we can put in to it, or its
comprehensiveness relative to some external foo-list, but on
whether it does the job that the foo-protocol (and maybe foo1,
foo2, etc.), requires.  Normally, we don't even write a "create
the baz registry" document.  Instead, we write a "baz protocol
specification" document and include a more or less long section
that instructs IANA to create the registry, what to put in it,
and how.    We may make those registry/IANA specifications into
separate documents for a long series of good reasons, one of
which is "useful for several protocols, including some we don't
know about", but the evaluation criteria should not change: a
success evaluation is based primarily on the success of the
protocols that use the registry and its contents and the degree
to which the registry supports interoperability among
implementations of those protocols.    Of course, if someone
could demonstrate that the registration and maintenance
procedures, as specified, don't work, that would also be a bar
to advancement on the standards track, just as demonstrated
inability to exercise IPR provisions would be, but it should not
be our primary focus.

That still leaves an issue that, if we have a base registry
specification that is not linked to applications of the registry
by either inclusion in the application specification or by
strict dependency (one application, one registry), but by a
collection of A/S, just how much of the registry needs to be
used and in what way to justify advancing the specification.
That isn't exactly a new issue, nor is it exclusive to registry
specifications.  My personal recommendation is that the WG
should develop a recommendation on the subject -- either as part
of the registry and matching specifications or as part of one or
more of the A/S documents -- that we Last Call those provisions,
and, assuming community support, we accept that definition and
move on.  The only requirement I would, personally, apply would
be that the recommendation include demonstrated utility and
interoperability support for at least one A/S and application.
But other rules are possible and I think such requirements are
best discussed in the WG and at Last Call, not turned into
attempts at developing general rules.
 
> In addition, it might be advisable for the IETF community to
> consider the question of what happens if we find this is not
> the right approach; that question is not required to implement
> your proposed reclassification but it seems advisable to
> consider.

I agree.  See "footnote" below.   But I suggest that it has
already been demonstrated that handling complex non-protocol
documents that have protocol (on the wire) implications by
identifying them as BCPs, even if there is no operational
experience with either the documents or any associated
protocols, is broken and causes other problems.  So I think
that, like it or not, we have sort of a zero-base problem here:
my approach may or may not be the optimal one. But the status
quo has already proven inadequate so the alternative is "third
proposal" not "keep doing what we have been doing".  Also, we do
have experience with the approach I'm suggesting with less
extensive registries: it occurs every time a registry is created
by an "IANA Considerations" section in a standards-track
document.  Unlike the BCP approach, we have some
running-code-like evidence that approach works, at least in
those contexts.

> Let me throw something out to answer the questions I posed.
> We could keep the existing 3066 registry as the BCP registry
> and create a new registry for these documents.  We could
> advance these documents when any single using protocol
> advances.  Presumably that would mean that these documents
> could not advance until some protocol that normatively
> references them advances; that's probably OK.  Clearly these
> are not the only answers to the questions I posed--I'm not
> even sure if they are good answers.  They are presented only
> to illustrate that it is possible to answer the questions
> without huge effort.  That in turn suggests to me at least
> that I'm not establishing an unreasonable requirement by
> asking the questions be answered.

Yes.  And although I deliberately did not address this more
specific possible answer in writing the text above, you will
note that my strawman suggestion, including the suggested
requirement for at least one application to demonstrate
usability and functionality, and yours are consistent and
compatible.

best,
     john

Footnote: those who are reading this and also following newtrk
should probably think about one of the implications of where I,
and possibly Sam, are headed.  If we are going to stay with a
multiple-stage standards process, it might be useful to modify
the "advancement" rules in 2026 to provide that a document being
considered for Proposed Standard (or any other given maturity
level) may optionally include an explicit "conditions for
advancement" section.  That section could be evaluated by the
community on Last Call (and earlier) to replace the more general
conditions (and handwaving) in 2026 for that particular document
or collection of documents.  If approved, it wouldn't quite be
binding on the community in terms of advancement of the document
if those conditions were met: the advancement request would
still need an IETF Last Call and "experience shows that we got
those criteria wrong" could be an argument against automatic
acceptance/ advancement.  But it would give us a much better way
to deal with peculiar and edge cases than saying "whoops, don't
see how the make the 2026 standards track rules apply exactly,
so let's make this a BCP".   And it would mesh nicely with some
of the ideas Larry and others seem to be proposing about
implementation reports.

---

From: John C Klensin <[email-masked]>
Date: Thu, 08 Sep 2005 00:39:15 -0400

Jefsey,

Somewhat against my better judgment, I want to respond to a few
of your remarks in the context of what I said and meant and what
I think the LTRU work, as a collection of IETF documents and an
IETF/IANA registry, sets out to do.

--On Wednesday, 07 September, 2005 15:37 +0200 "JFC (Jefsey)
Morfin" <[email-masked]> wrote:

> There are four propositions. The Draft is the least network
> oriented, but has its place for catalogs, library
> organisation, related menus, and e-commerce contracts. It
> should have been a WTO, W3C, LDAP, MPEG proposition, but it
> supports a consistent content-database-computer management
> system (HTML, XML, CLDR [some Locale standardisation
> "internationalisation" conceptual level, and miss key
> networked communication aspects.

I believe that you are getting several different issues badly
intermixed, confusing your readers and possibly even yourself.

Well, I think there may be more than four "propositions", if I
understand what you intend by that term, but let me return to
that question below.

It seems to me that the draft is nothing more or less than a way
to structure elements of several different base systems into a
very general language/ script/ location identification system.
Those base systems have UN, ISO, and UTC origins.  To the extent
to which you find reasons to disagree with what those bodies
have put in their standards and registries and how they have
structured those registries, it seems to me that you should be
taking it up with them, in their contexts.

A second issue is why those particular base systems have been
chosen rather than others that would accomplish the same
purposes.  While the WG has better reasons (some of which are
identified in the LTRU-registry draft), the bottom line is that
no other systems exist that are global in character, accepted
internationally by recognized bodies, and generally plausible.
You, or for that matter I, might well imagine that a
better-optimized job could be done for one or more of them if an
effort were initiated under different assumptions, but to sit
around waiting for such an effort to materialize or reach
agreement would delay the real work of internationalization that
we both believe are important.   Of course, I, and the WG, could
have missed something: if you sincerely believe that there is a
better alternative to one of those base systems -- an
alternative that exists, is global in scope, is generally
recognized by some appropriate international body, and that is
generally available-- please identify it and the reasons why you
think it is superior.

A third issue relates to the difference between breaking things
into categories in order to make lists and the codes, names, or
labels that are assigned to those categories.  The making of the
lists is what the relevant based standards are all about.  It is
typically a difficult task, but it is one for which IETF cannot
and should not take responsibility (as I hope I have explained
above).  But the assignment of codes/ names/ labels to those
categories is largely arbitrary.  There can be good reasons for
preferring one system over another, especially in the
environment of particular assumed applications (or
"propositions"), and I need to assume that the UN, ISO, and UTC
have made rational choices.  But substituting a different set of
codes doesn't change the semantics of the underlying base
system.  So, if you are looking for a different set of codings/
names --I don't think you are, but I can't be sure-- I think you
need a really clear and compelling argument for why the existing
ones are generally inappropriate and a clear and easily-realized
proposal for generating a substitute list of codes and mappings.

> Shakespeare wrote a page and the way you store, distribute and
> read it today, may give you some hints about the difference
> between what the Draft wants to do and what the IETF needs.
> The Draft drastically extends the basic error of the lose RFC
> 3066 (rigidifying orthogonal language/country information) and
> wants to see it enforced and made universal.

I see no statement in the draft that would justify the claim of
wanting or expecting "enforcement".  What I think I do see is a
wide range of applications that might reasonably take advantage
of some language and/or script and/or locality and/or "other
things" coding and identification system.  I imagine the range
to be broader than the examples you list as "propositions".   I
am quite certain, philosophically rather than analytically and
with examples, that the registration system and matching rules,
as proposed, are too specific or overspecified for some
plausible uses.  I am equally certain that they are
insufficiently specific for some other uses that might be
imagined.

But that is precisely what voluntary standards are all about.
No one I know is really trying to mandate use of the technique
specified in these documents and, if there is someone, he or she
is delusional.  I believe that the IETF should be specific, _for
protocols and other work within IETF's scope_, about whether the
LTRU work should be used and how it should be used.  If you have
other applications that could use this work, and the work is
appropriate, that is great: use it with everyone's blessings.
If you have applications (or propositions) for which this work
is just wrong, then go do something else, I assume again with
everyone's blessings.

> description is from the author, to the reader or for the
> protocol. It should the document seven properties (language,
> mode, community, referent, context, style, media) and the
> property description version. Your own Words program just does
> that. Each of these elements may include many sub-elements.

Ok.  The LTRU group, presumably with some specific IETF
applications in mind, including (correctly or not) those
supported by RFC 3066, concluded either that the level of
specificity you ask for above was not necessary or that it was
impractical.  For the purposes for which you presumably want
this, you have two choices, both of which appear to me, in my
ignorance, to be completely plausible.  The first it to
completely forget about this IETF effort and do your own thing,
building on either the LTRU spec or the base documents that
determine the subtags as you think appropriate.  No one will
stop you and, if anyone tries, I recommend that you ignore them
and get on with your work.   

The second option is to construct an applicability statement of
your own, one that specifies the applications or propositions
that are relevant, the elements of the LTRU registry you want to
use (if any), the sources of other elements and how they are
used, and so on.  Whether you should try to put that
applicability statement through the IETF depends on what the
application area / proposition is all about: if the IETF is not
representative of the community you see yourself serving, or
authoritative about its needs, it seems to me that IETF
involvement would add little value and probably be very
frustrating for all concerned.
 
> A. the current Draft using of ISO 639-1, 2, 3 and additional
> ISO codes. That proposition is based upon the SIL list of 7500
> documented languages. It is supported by Peter Constable (on
> the list), author of ISO 639-3.

Ok.  If this has appropriate applications other than those
covered by the LTRU documents, create an appropriate
applicability statement.  If necessary, propose a standards
track document and appropriate IANA registry, but I would assume
that the ISO 639 registries would be sufficient.
 
> B. Linguasphere (planned to be ISO 639-6). It identifies
> 20.000 community language 4 letters not reusable codes and is
> built as ISO 11179 compliant for far more information. They
> fully replace langtags when no legal aspect is involved. They
> are planned to be discussed when an ISO standard. It is
> supported by Debbie Garside (on the list) and Dr. David Dalby.

See above comments about not-yet-complete proposals.  If this
were to be adopted as an ISO 639 component, the comments above
would apply exactly.  In the interim, unless you are prepared to
argue that 3066 is adequate, without fixing the problems that
LTRU addresses, until the above work is complete and accepted,
and adequate for _all_ IETF-related language-tagging purposes,
it seems to me that you should get out of the way of those
purposes and applications.

> C. the "grassroots approach". The approach is to accept in a
> network and multilingual way everything existing and to relate
> it to an "ISO 11179" compatible system. Still at basic
> thinking and experimental stage. This is part of a generalised
> DRS (distributed registries system) to include every
> network/local/user registry (including langtag). The URI-tags
> seem to fully support the network aspects, the IRI-tags the
> multilingual concept. It obviously support the two systems
> above which can be its defaults. I accepted to spend time on

See above about systems that are not yet complete and, from what
I understand of this work, not yet really started.

> There is no "better" solution. There are more adequate
> solutions in specific situations (A and B can be defaults of
> C). Each helping the other to better define itself. However
> the A proponents think their proposition must be exclusive.
> They wanted a counter-proposition of mine so the "best" might
> "win". Their ad-hominems were their way to exclude a
> "competition". Their non-technical mails on the IETF main list
> fully exposed that strategy.

I don't think so.  While I think they and I disagree about many
things, I have generally found them willing to listen and to
accept constructive input.  There really is a place, in the
engineering context in which we find ourselves, for deciding
that, in the presence of a demonstrated problem, a proposal that
actually exists, and that is structured on top of base documents
that actually exist, must be accepted in preference to work that
has not yet completed and ideas that are still being formulated
-- at least for an identified set of problems and applications
for which it can be demonstrated to be the solution.  My
proposal to recast the registry and matching documents into
Proposed Standards supplemented by one or more Applicability
Statements should make it more clear that other applications,
with their own Applicability Statements and scopes, can be
expected and, if they have different needs, should be able to
utilize approaches designed to meet those needs.  

I believe that approach is structurally and procedurally
correct.  But I also believe it will not help solve the issues
you are trying to raise and the applications you are trying to
accommodate, if only because your message, intentionally or not,
is "just wait until a series of incomplete ideas, some of the
barely germinated, can fully mature and be considered".  That
just is not a reasonable request given a number of activities,
applications, and protocols that need to move forward.

> The text proposed in December was not acceptable. The
> currently proposed text still appears as an "industrial and
> commercial Trojan Horse" with risks of commercial, political
> and technical confusion. But its authors have trimmed enough
> their ABNF "against me" to block "C" leaks there and threfore
> a lot of confusion. Yet, we have still have no support of
> non-script mode and three sources of conflicts:
> 
> - script of a document in a politically oriented
> (privacy/racial violation) tag.

Once again, if you have applications or situations in which
these needs are particularly important and for which the LTRU
documents do not appear responsive, either

* Start work on an applicability statement or profile that will
make the LTRU tagging system meet your needs for those
applications.     But, if you want that applicability statement
discussed in the IETF, please don't waste anyone's time by
discussing it before you have an Internet-Draft posted.

* Ignore LTRU entirely, design your own system, and see if you
can get it into the marketplace well and extensively enough to
drive LTRU out, either generally or in whatever niches you think
are most important.  Remember that, if the LTRU is as inadequate
as you believe, it will disappear on its own, with no need for
you to push it along.

> My proposition is:
> 
> 1. to reduce the charset/script conflicts in defining the
> Internet meaning of a script (equivalent to ccTLD IDN tables).
> No big deal, since the tables are already published by Unicode.

ccTLD IDN tables are, to all intents and purposes, just lists of
characters bound to TLD-registry-specific names or keywords.  If
you really see something important and useful that needs to be
done, generate an applicability statement.  See above about
posting I-Ds, however, and also see below about ccTLDs, ICANN,
etc.

> 2. to define the relation between ccTLDs and langtags
> "regions" - probably one sentence to be approved by IANA,
> ICANN and the ccTLD community.

IANA does not make policy, and hence doesn't approve anything.
If you have a specific proposal to make in this area, please
make it to and at ICANN -- not an IETF problem no matter how
much you might wish otherwise.
> 
> 3. to include the IRI-tags into the Draft, through the
> multilingual (numeric) "0-" hook, so we support different but
> not alternative descriptions.

Applicability statement and profile.  See comments above.  And
note that, as far as I know, you are the only advocate within
the IETF for the "0- hook". That is not what we normally are
referring to when we talk about the evidence of strong community
support needed to produce something as an IETF specification or
standard.

> I was opposed over ISO 11179. It seems this has changed since
> the August ISO meeting. I can only rejoice. IMHO the DRS issue
> is far more complex than ISO 11179 and should be addressed
> separately (may be after some experience has been gained with
> the IRI-langtags?)

Perhaps this is a discussion you should be having with the
relevant ISO TC or SC?

    john

---

From: r&d afrac <[email-masked]>
Date: Thu, 08 Sep 2005 18:13:38 +0200

>IETF/IANA registry, sets out to do.

Dear John,
Since you ask I will respond in detail. With two liminary remarks:

- what should be discussed is not what you or I may _think_ , but 
what this collection of proposed document may lead to or block. 
Technically, operationally, politically, economically, culturally.
- obviously I would drop most of the points I rise here if the 
document became a standard proposition instead of a BCP and/or if the 
"0-" was supported. That position did not change of a iota since 
mid-december, but was improved by the IESG registration of the 
URI-tags RFC and by the Draft ABNF clarifications obtained at the WG-ltru.

>intermixed, confusing your readers and possibly even yourself.

By what they address, by the exclusive they claim, the langtags are a 
key part of an internationalisation of the Internet.

I oppose internationalisation of Internet as inadequate. It consists 
in permitting the use of languages by "end users" (an unknown concept 
to IETF), under constraints such as those described by Addison, as 
optional add-on to the ASCII Internet, with English as a default of 
these options. We technically and politically experimented what this 
vision leads to in the IDNA case.

I support a Multilingual Internet providing a multilateral, 
multimodal, multitechnology convergent networking architecture for 
the world digital ecosystem, on an equal linguistic research, 
standardisation, development and usage basis. By nature that Internet 
is "multi" when the legacy Internet is "mono". The point is simple: 
"internationalisation will NOT address the multilingual demand and 
the further vernacularisation needs".

To cope with multilingualism and with many other necessities we need 
to turn architectural parameters from "mono" to "multi". The single 
TCP/IP protocol suite, the single end to end interoperability, the 
single RIR addressing system, the single ICANN naming system, the 
single IANA clearing house, the single English language, the single 
ASCII set, etc. cannot deliver the expected (or already used) 
answers. All over embryonic "multi" are pouring (NATs, P2P, 
alt-roots, PADs, now mDNS and co, blackboxes, etc.)

I know IAB guidance is missing. I know there is no model. I know the 
changes "intermix" everything. I know opposing pro status quo 
commercial interests are powerful. I know Governments are demanding 
and clumsy. I know the Internet geeks never changed technology yet. I 
know the Internet is nearly a billion people wide. But hiding the 
problem and trying to squeeze a global architectural revamp in the 
narrowing (patching?) of an inadequate RFC, IS confusing.

The urgent need is to think hard, to understand and test in what 
directions a "multi-Internet" may go and to permit, document and 
accompany a smooth transition. Multilingualism is one of the main 
aspects, so it can be used for real life testing at low risk.This is 
what I tried:

- having investigated and tested some of the trends of this 
evolution, in line with ICANN suggestions, and other involved leading entities.
- using the WG-ltru opposition for "mono-Internet" ABNF reducing 
confusion risks (and possibilities) - as well described by Addison.
- introducing a "multi-Internet" approach permitting a smooth 
transition based on a mechanism already accepted as an RFC (URI-tags 
- that should need to be documented as IRI-tags).

>understand what you intend by that term, but let me return to

Great! Why not to introduce them? are they already supported by an RFC?
Anyway, they all are blocked by the Draft ABNF. Unless we use "0-", 
"1-" etc. for each of them?

>very general language/ script/ location identification system.

"seems" is imprecise. It is or it is not.
In fact it is not.

- it does not want to be "a way", but the internet standard practice. 
Here is the blocking point.
- you know better than to say it is a "general 
language/script/location identification system"!. It is a very 
restrictive limited in scope coding system, correlating ISO codes in 
a way ISO has not accepted, impeaching other correlations which might 
be more adequate and complete, competing instead of cooperating, 
supporting no other modal information than an imprecise (*) script 
code and an inadequate "location" (**) identification.

(*) ISO 15924 is only a list of one hundred codes which can be 
associated to a script concept. More indications on the meaning are 
needed. If Charset is Latin and the langtag says "Cyrl" how will the 
page print?

(**) "location" is not the meaning of RFC 1591, the only place in the 
Internet documents where the concerned codes are used up to now. Jon 
Postel considered local internet communities' authority. This 
document not. Other times, other ways.

>taking it up with them, in their contexts.

??? !!!

Had you followed the debate of this WG-ltru you would know I have 
been denied the quote of the very terms and restrictions these 
authorities use when publishing the used data. These data are NOT 
used in the way they are intended to. This does not mean that they 
cannot, but that an appropriate language is to be provided to 
document it. The WG shown that such a language might lead to 
technical conflicts and alight other lacks.

Why not the Editor simply include the appropriate legal mentions? Why 
not to consider the current debate over ISO 639-4 (ISO 639 guide 
lines). Why not to quote and consider ISO 639-4, 5, 6 drafts, the 
same as this Draft is part of the ISO 639 debate and annexes. I am 
surprised by what could be considered as a cross-contribution loop. I 
am also surprised by your suggestion: would IETF documents have to be 
discussed at ISO?

All the more than I made clear enough that I share in common 
interests efforts. And that I accepted to dedicate time to the lack 
of concern of the WG-ltru for language networking issues. I did not 
think appropriate to involve other people in the WG-ltru rough 
waters. One academic friend tried very politely - he is at the origin 
of the "0-" proposition. He was named a "troll". Do not be afraid if 
I am the one to tell the reality in here (you saw competition wants 
to expel me for that), I always said I represent users interests. My 
architectural vision is user-centric, so I cannot do otherwise. But 
this does not mean than I am alone :-) and only involved in here. But 
a job had to be done: to expose a wrong approach. This is now made.

It only means that I am very respectful of the IETF ways and that I 
think that it is still the best entity to document the 
"multi-Internet". But if the IESG/IETF/IAB says "no" at the end of 
the day, this will obviously not stop the multilingual global NGN to 
develop without them. But I would be sad.

>internationally by recognized bodies, and generally plausible.

As I documented it, this comment is out of scope.
1. the problem is not with the use of these code, the problem is with 
the way they are used.
2. this problem would not be a big problem if a PS (an inadequate 
tagging would confuse and cost the world because of its initial 
sponsors, but would  soon fade away). The problem is with the BCP 
nature of the document which leaves no choice: accept or balkanise 
(you document this further on).
3. I leave you the responsibility of your review of existing propositions.

My opposition is only to avoid a general balkanisation. But after 
all, may be I am a fool and there might be some advantages. And you 
seem to advocate it...

>we both believe are important.

What do you mean by "to sit around waiting"?  when our such effort is 
only delayed by the Draft time wasting. This is necessary because 
this is a pure _commercial_ exclusion effort. Do you think that 
financial aspects are not involved? I never hidden I was also 
supported by industrial interests fighting and fought by industrial 
interests. Harald Alvestrand and Peter Constable fully documented 
that central motivation. I will not betray some of my opponents, but 
no one should be fooled: this debate is worth "a lot of money for 
industry". This is something we all agree, we only disagree for who - 
some consider they lost what other consider they saved. I strongly 
_oppose_ this kind of interference in the IETF.

This absurd attempt to commercial exclusive, on "mono-Internet" 
pseudo technical interest grounds, have made us all to lose a full 
year (except getting a cleaner ABNF for that proposition and an RFC 
to support the URI-tags solution).

Our common target is stability, surety, security, innovation 
capability in supported end to end interoperability and serviced 
brain to brain interintelligibility whatever the person, the 
computer, the location, the language. This byte and language oriented 
pervasiveness cannot be supported by what you call 
"internationalisation" (I would call lower layer localisation). You 
say it yourself  when you say that the "real work of 
internationalisation" is ahead. If the Draft is accepted without the 
"0-" hook for IRI-tags that work will be a no-starter.

The proposition is painting on old rust. That we both want the 
painting. But believing we can keep the rust and get a proper 
painting is illusory and a waste of time. But, we may proceed step by 
step. Not remove all the rust and repaint everywhere at the same 
time. Let start with the IRI-langtags. Let get experience (not only 
for multilingualisation) and let build on it.

What is the danger? If I am wrong, it will simply not fly and no 
commercial interest will have been hurt. But if I am right we will 
have protected the Internet unity.

>  Of course, I, and the WG, could

I can only repeat:

1. I sincerely believe there always is a better alternative than exclusion
2. I sincerely believe that inclusiveness is by nature global in scope
3. I submit that the proven experience of a product like Words 
documenting more elements than the tag is to consider
4. I cannot leak IPR but I am sincerely sure that the "mono-Internet" 
exclusive Draft ABNF preventing "0-" is a _major_ mistake.
etc.

and I will always say that NO solution is superior to any others, but 
that specific solutions can be more appropriate in specific cases and 
that is dumb stupid to exclude them on short-sighted commercial 
grounds or technical limitations. Technical limitations are made to 
be addressed.

>above).

I am not sure about what you want to say here. This Draft is about 
IETF taking that kind of responsibility. Unless you intend to say the 
IETF delegates the [email-masked] responsibility of 
feeding the IANA, in an equivalent way it delegated the names and 
numbers responsibility to ICANN?

>  But the assignment of codes/ names/ labels to those
>have made rational choices.

I am not sure about what you wants to say here either, nor why you 
want to keep quoting the UTC?

What are the UN and ISO to do with this? The rational is not with 
them, but with this Draft to use their codes for needs which were no 
part of their rational. Please pick ISO 639-4 draft and tell me among 
the examples of usage of ISO 639 where ISO 639-4 alludes to 
networking. Please tell me in which way the table of codes related to 
the name of countries may be easily correlated with human language 
dissemination? With human language censoring may be ....

???

>  But substituting a different set of

John investigating the same erroneous issues will lead to nowhere.

- this Draft does not respond an IETF Charter but pursues a business strategy
- in so doing it tries to use the IESG and IANA to exclude competition
- this results from reasons well identified by IAB in RFC 3869. With 
the very provisions discussed by IAB that such a motivations do not 
preclude partial good. But must be replaced by non-commercial 
funding. This is exactly what I am: non profit and building public projects.

I happen to know better about the risks involved because that 
business strategy wants to commercially lock a market that (with many 
others of influence, this debate also helped to gather) I want to 
keep free for longer term common and commercial interests. The 
magnitude of the economical, political, technical, legal and societal 
involved interests and the probable consequences on the control of 
the Internet (due to the load on the IANA and the complexity of the 
involved information - and competition) is such that, should the 
Draft be approved without supporting the IRI-langtags space it would 
either be not applied (leading to delays and confusion) or be opposed 
in a way which would probably balkanise and disband the Internet as 
we know it.

I only try to prevent this from happening. I may very poor at that, I 
would then apologise and call for help.
But, opposing me if I am right is burying the Internet or 
transferring its control (what I believe is attempted).

>is delusional.

What are you talking about?
This document is the updated of BCP 47 Internet standardized practice.

>I believe that the IETF should be specific, _for
>other applications that could use this work,

John, many people have applications this work is to prevent the use !!!

I do not understand all this. Or you did not read the ABNF?

No one can de facto introduce a global proposition.
- either it must be part of a future revision of a document which 
wants to be a narrowing of RFC 3066
- or it must use subtags shorter or equal to 8 alphanum, without 
possibility to use "-:=?/" etc. So no URI-tags are permitted.
- or it is a language, script, region it must be accepted by 
[email-masked]
- if it is vocal, style, dictionary, contextual, cultural, etc. etc. 
this is not supported.

>and the work is appropriate, that is great: use it with everyone's 
>blessings. If you have applications (or propositions) for which this work

I am not sure you mean by do something else? Would it be like "If 
someone sleeps with your wife, don't worry go do sleep with someone 
else?" Many do _not_ and will _not_ want to be dependent on this Draft. Period.

There are only two solutions. Either the langtag can adopt formats 
they can tune or they will be blocked.
Just understand that langtags may be more dangerous than spam or 
cookies. So at last users must be entitled to control them and to use 
them far more cleverly than the default way the Draft proposes !!!

Opposing this is certainly being sure to kill a few people. We all know that.
Just to support very very short sighted non realistic commercial dreams.

>impractical.

"presumably": you are incorrect in that assumption.
BTW "some specific application" would justify options.
I wish some IETF applications would have been considered :-)
DNS, OPES, Java, etc. have been denied to me.

>For the purposes for which you presumably want

This is what I want to prevent. This is no problem.
But the name is balkanisation. Do you support it?
It makes a large difference to me if we have a BCP or a PS.

>frustrating for all concerned.

I wish the IESG to decide that. I maintain that common interest is 
that the Internet documentation stays with the IETF. Or at least that 
the IETF stays as a common focal point. Obviously if the IESG decides 
(and IAB confirms) to exclude the "multi-Internet" starting with the 
Multilingual Internet, I will certainly consider your suggestion. But 
still with great care. Rome was not built in one day, but was burnt 
in one night. We should be very careful at that;

The actual issue is the control of the IANA registry. There are three 
possibilities:

1. the IANA is an exclusive source of langtags.
2. the IANA is one of the sources of the langtags as the IRI-langtags 
are added to the Draft ABNF through the "0-" sequence.
3. the IANA is no more the Internet central clearing house because of 
the distribution of registries.

In the first case, the [email-masked] mailing list will 
become unmanageable and the whole process will be blocked. Leading to 
a decision of authoritative transfer. I then support a transfer to 
the GAC if the WSIS has not taken over.

In the second case, things will continue as per today. There will 
most probably a problem of overload of the IANA and legal issues over 
the nature of the langtags. This will only speed up the need to 
transition to the third solution.

The third case is the eventual solution for a distributed network. It 
still calls for a lot of thinking, experience and work. But can be 
implemented rather quickly now on a test basis with multilingual 
priority. This however represents serious dangers due to the 
commercial competition and political aspects it would exacerbate.

>that the ISO 639 registries would be sufficient.

??? This application has the e-commerce, etc. applications it is designed for.
I trust Addison to know what he wants (however he documented he does 
represent W3C positions).

>purposes and applications.

This solution is an open source retained solution. This solution is 
appropriate in part to many needs. I am sorry but your "adequate for 
_all_IETF-related language-tagging purpose" is a "mono-Internet" de 
facto deprecated thinking.

As far as I am concerned the Draft addresses none of the RFC 3066 
lacks. It only prevents more applications to use it: this is very 
positive as it clarifies the situation. ISO 639-6 has as much 
interest for IETF as the Draft has interest for ISO 639-4. Except 
that ISO 639-6 reflects a common practice the Draft does not represent.

SIL and Linguasphere are two widely used universally accepted lists. 
SIL is private and limited to a single list. Linguasphere is much 
more complete and ISO 11179 compliant. But they are 
professionally/marketingly of equivalent excellence. The reason why 
Linguasphere is more appealing in terms of use, is that the Draft 
does not uses SIL (ISO 639-3) but a progressive mix of ISO 639-1 and 
ISO 639-2 (the ISO scheduling of -3 and -6 are only a few months apart).

The current thinking of the WG-ltru, if I understand it correctly is 
a confuse usage of ISO 639-6 in an appropriate way as a complement of 
ISO 639-1, 2, 3 and 5. It is likely that routines supporting ISO 
639-6 codes in an open source manner will be available long before 
the Draft support of ISO 639-3 .....

>I understand of this work, not yet really started.

????
Do not confuse achievement and started. There are millenaries that 
languages have a name. The commercial attempt to standardise the 
printing industry and library classification is not the first, and 
hopefully not the last one.

You probably confuse IRI-langtags which are only a documentation to 
internationally work - probably this falls; and the DRS work which 
has been engaged 2 years ago as an incorporated R&D non-profit effort 
involving various industrial, private, public, etc. French and 
foreign interests. But that work is certainly important (see end).

>for which it can be demonstrated to be the solution.

We fully agree. This is why I am sad at the RFC 3869 documented 
motivations many see there and the RFC 3774 documented problems we 
feel we meet.

There is a very simple way to turn us wrong on this two points: to 
accept the "0-" to show the intent is not a registry exclusive and 
that all existing propositions are considered; and to make the Draft 
an SP, to show there was no to intent of exclusion of other propositions.

>  My
>correct.

I agree. The entire issue is here. Even well commercially supported 
an inadequate proposition will eventually fade away.

>  But I also believe it will not help solve the issues

This is _absolutely_not_ what I have asked for !!!

1) I have documented to the contrary how existing development were 
ready to adapt to avoid confusion with the Draft.
2) we generalised our experience and other commercial applications we 
cannot discuss as not being part of them have agreed to use the 
existing URI-tags approved RFC. This is the end of it. Except that we 
will now extend to IRI-tags and have to document an extension.

>discussing it before you have an Internet-Draft posted.

Once again. This is not what I want.
I want to prevent that all those the draft is designed to prevent to 
do so, do it independently, rising a hell of confusion.
But if you think it is better, I will consider your advise to 
balkanise the Internet.

>as you believe, it will disappear on its own, with no need for

This is true.
But in the meanwhile it will have caused serious harm.
Also, the Draft in a serious number of case is a very interesting 
default, now the ABNFis clean and possible pretensions reduced.
Also, I prefer good compromise now than exclusion.
Love your enemies says the Gospel.

>posting I-Ds, however, and also see below about ccTLDs, ICANN,

Thank you. But, I am sorry, you do not address the technical issue.

>much you might wish otherwise.

Sorry again, you do not address the technical issue.
The IETF understanding of ISO 3166 is documented by RFC 1591.
Not also in the Draft.

>the IETF for the "0- hook?  That is not what we normally are

I do not think you need to be many to support common sense 
propositions. But if this was needed we could. Is that so necessary? 
I respect the IETF enough not to play that game.

But I am sure than if you consider it seriously, you would support it yourself.

>Perhaps this is a discussion you should be having with the

???
I have no objection that the Internet architecture is discussed at 
TC32 (or TC37), but I am surprised that _you_ would suggest it.
Anyway do not be afraid we did not wait for the suggestion.

Take care.
jfc

---

From: "Doug Ewell" <[email-masked]>
Date: Fri, 9 Sep 2005 08:07:25 -0700

John C Klensin <john dash ietf at jck dot com> wrote:

> The success or failure of the "foo" registry is
> and how.

So, do you propose that we withdraw the specification of the initial
registry contents, all 963 tags and subtags, and replace it with a set
of instructions to IAN on how they can duplicate our work?  And cross
our fingers that they get it right, or prepare to go through
item-languages for any correctible errors or omissions they may
introduce, and live with the uncorrectable errors?  Just wondering.

--
Doug Ewell
Fullerton, California
http://users.adelphia.net/~dewell/

---

From: "Doug Ewell" <[email-masked]>
Date: Fri, 9 Sep 2005 08:20:38 -0700

Sorry, Spell Checkers Gone Wild.

> of instructions to IAN on how they can duplicate our work?  And cross

s/IAN/IANA/

> item-languages for any correctible errors or omissions they may

s/Item/ietf/
s/correctible/correctable/

> introduce, and live with the uncorrectable errors?  Just wondering.

I don't know why my spell checker corrected "uncorrectible" to
"uncorrectable" but left "correctible" uncorrected.

---

From: John C Klensin <[email-masked]>
Date: Fri, 09 Sep 2005 11:47:50 -0400

--On Friday, 09 September, 2005 08:07 -0700 Doug Ewell
<[email-masked]> wrote:

>> foo2, etc.), requires.  Normally, we don't even write a
>> "create the baz registry" document.  Instead, we write a "baz
>> protocol specification" document and include a more or less
>> long section that instructs IANA to create the registry, what
>> to put in it, and how.
> 
> So, do you propose that we withdraw the specification of the
> initial registry contents, all 963 tags and subtags, and
> replace it with a set of instructions to IAN on how they can
> duplicate our work?  And cross our fingers that they get it
> right, or prepare to go through item-languages for any
> correctible errors or omissions they may introduce, and live
> with the uncorrectable errors?  Just wondering.

No, no.  And I don't understand how you could read that into
anything I wrote.

But let me try to spell that comment out in different language,
just to be sure that we both understand what I was suggesting:

	(i) Internet-Drafts and RFCs are different creatures.
	It is perfectly acceptable, indeed common, to have text
	in I-Ds that no one intends to see in a final RFC.
	
	(ii) The IESG can instruct IANA to form a registry
	and initialize it with any set of instructions that are
	clear enough for IANA to follow accurately.   Those
	instructions can be in an RFC, in an I-D, in a formal
	IESG note to IANA, or, in principle, written on the
	back of an envelope.  It is usually assumed that
	mechanisms that are public and leave tracks are better
	than those that don't, but even that is not a
	requirement.

So, all I was suggesting wrt the text of the "initial" document
is that, when the IESG concluded that it had reached community
consensus, two things should happen:

	(1) The IESG instructs IANA to create the registry,
	populating it with the elements as instructed in the
	Internet-Draft  and using the formats specified there
	and in the "registry" I-D.  
	
	(2) The document is passed to the RFC Editor for
	publication, but with a note indicating that the 100 or
	so pages of subtags should be dropped and replaced by a
	paragraph that explains how the initial subtags, as
	specified by the WG process, can be identified from the
	registry itself.   I _strongly_ prefer that the relevant
	paragraph be constructed and approved by the WG itself,
	rather than being made up by one or more IESG members; I
	assume the IESG would feel the same way.

For whatever it is worth, this gets you a registry created on
the timeframe of a protocol action, not a wait until an RFC is
about to be published (it is not the only way to accomplish
that, of course).  It gets a RFC that is 100 or so pages shorter
and that eliminates any chance of the contents of the RFC being
confused with the contents of the registry itself (something
that the I-D explicitly warns against).  All other things being
equal, a dozen-page RFC is likely to be finished and posted more
quickly than a 117 page one.  Since the usual practices of the
RFC Editor would not permit the publication of one of these
documents before the other (if you don't know/ understand why,
it is worth your asking), what holds up one document, holds up
both and "faster" is clearly in the interest of the WG and the
community.

How you get from there to "withdraw... replace ...instructions
to duplicate work..." is unfathomable to me, but it certainly
was not what I was suggesting.

That suggestion was just about streamlining with a more
efficient and appropriate way to implement what are, as far as I
can tell, _exactly_ the same set of actions.  Unless I've missed
something, it ought to be problematic only if, somehow, the WG
believes that there is "credit" for an RFC in proportion to its
page count.  That belief would be, AFIK, pretty novel around the
IETF.

    john

---

From: "Doug Ewell" <[email-masked]>
Date: Fri, 9 Sep 2005 09:14:57 -0700

> in I-Ds that no one intends to see in a final RFC.

Understood.  The WG decided that the initial-registry I-D should be an
RFC, for various reasons.

> assume the IESG would feel the same way.

That makes sense to me.  Other members of the WG, and in particular the
chairs, have orders of magnitude more experience with this sort of thing
than I do, and so I can't speak to whether it makes sense to them.

> was not what I was suggesting.

I apparently misread this passage, which you wrote and I quoted:

| Normally, we don't even write a "create
| the baz registry" document.  Instead, we write a "baz protocol
| specification" document and include a more or less long section
| that instructs IANA to create the registry, what to put in it,
| and how.

I am delighted that my interpretation was wrong.

> Unless I've missed

That was definitely not my intent, nor that of anyone else in the WG.
Indeed, I pointed out that if LTRU is ever revised to incorporate
subtags based on ISO 639-3 codes, the additional registry information
would occupy 740 pages, and suggested that this amount of material might
be inappropriate to publish as an RFC or even an I-D.

A 118-page draft consisting almost entirely of a code list certainly
shouldn't impress anyone by its length, any more than a 1,000-page phone
book.

---

From: r&d afrac <[email-masked]>
Date: Fri, 09 Sep 2005 18:31:47 +0200

The problem with your Draft is that you do not include the 3 letters 
version of the 2 letter version as a correlative information between 
ISO 639-2 and ISO 639-3 tables. I do not think should be left to the 
Editor. Otherwise your Draft seems no problem. But I suppose that 
IESG would need a formal OK from Michael Everson since he is charge 
of [email-masked].
jfc

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 09 Sep 2005 21:25:55 +0200

Doug Ewell wrote:

> don't know why my spell checker corrected "uncorrectible"
> to "uncorrectable" but left "correctible" uncorrected.

Did you test en-AQ-1996 ?  <gd&r>

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 09 Sep 2005 22:07:11 +0200

> in I-Ds that no one intends to see in a final RFC.

I-D not intended to be an RFC was clear, but we missed
the critical "text *_in_* an I-D" trick / how-to / option...

> (ii) The IESG can instruct IANA to form a registry

...in conjunction with this shortcut.

> Those instructions can be in an RFC, in an I-D, in a formal
> back of an envelope.

Okay, that's better - at least for the future 3066ter with
several thousands of ISO 639-3 language subtags.

> The document is passed to the RFC Editor for publication,
> but with a note indicating that the 100 or so pages of
> subtags should be dropped and replaced by a paragraph that
> explains how the initial subtags, as specified by the WG
> process, can be identified from the registry itself.

Makes sense, and that text could be "informational".

> I _strongly_ prefer that the relevant paragraph be
> constructed and approved by the WG itself, rather than
> being made up by one or more IESG members; I assume the
> IESG would feel the same way.

You obviously have a working "threat analysis" for these
procedural details, where the threats cover hypothetical
cases like "IESG screws up" or "somebody cries 'appeal'" ;-)

> a RFC that is 100 or so pages shorter and that eliminates
> any chance of the contents of the RFC being confused with
> the contents of the registry itself (something that the
> I-D explicitly warns against).

Okay,  I knew that it's possible to have notes to the RfC-
editor in an I-D (e.g. instructions to remove the document
history), but I didn't know that it's also possible to have
similar notes _to_ the IESG (unlike _from_ the IESG).

> unfathomable to me

Authors feel like fathers, easily upset if you'd propose to
"do" something with their baby that's strictly impossible ;-)

> if, somehow, the WG believes that there is "credit" for an
> RFC in proportion to its page count.  That belief would be,
> AFIK, pretty novel around the IETF.

It's far too short for the Guiness book as the longest RfC,
so that wasn't our intention.  RfC 2801 could be the record.

                           Bye, Frank

---

From: "John.Cowan" <[email-masked]>
Date: Fri, 9 Sep 2005 22:16:16 -0400

> 	and in the "registry" I-D.  

I think that's what we had in mind.

> 	publication, 

It's not clear to me what the point of publishing it as an RFC is,
and in fact if an explicit decision to that effect has been made,
it went past me entirely.

IMHO after initial-registry has served its purpose, it should be
allowed to time out and die.

-- 
So that's the tune they play on                 John Cowan
their fascist banjos, is it?                    [email-masked]
        --Great-Souled Sam                      http://www.ccil.org/~cowan

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 9 Sep 2005 22:38:55 -0700

Hi -

> From: "John.Cowan" <[email-masked]>
> To: "John C Klensin" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
> Sent: Friday, September 09, 2005 7:16 PM
> Subject: Re: [Ltru] Re: Last call comments on LTRU registry and initializationdocuments
>
> John C Klensin scripsit:
>
...

(As ltru co-chair)

Those who follow the ltru WG mailing list closely will recall that
there were two distinct issues recorded in the issue tracker:
(at https://rt.psg.com/ user and password are "ietf")
#875 should initial registry contents be made into an internet-draft?
#878 should the initial registry contents i-d be published as an RFC?

There was a rough consensus in support of #875, but the discussion
of #878 was inconclusive.   We asked our AD whether he had any
preference with respect to #878, and he indicated a preference for
publication as an (informational) RFC.

That is how we got to where we are today.

The decision on #875 (initial registry as i-d) has in retrospect proven
to be a good one, in my personal opinion.

Regarding issue #878, I think we've all looked at it as just a matter of how
to work the process to get the right stuff into the registry.  The working
group has been quite clear in wanting to ensure that the initial registry
is not mistaken for the registry itself, and was never enthusiastic about
publishing it as an RFC.

Consequently, I do not think that it would be a big problem if the
IESG were to tell the ltru WG that we don't need to publish the initial
registry i-d as an RFC, or if the WG, reconsidering issue #878 as a
result of the IETF last call comments were to reach a consensus to
withdraw the publication request, as long as we have some assurance
that the registry will be end up with the right stuff.

Sure, we would have wasted a lot of energy getting the initial registry i-d
RFC-ready, but the important thing is to initialize the registry.  Process
is a tool, not an end in itself, and the result we are interested in is
getting the updated registry going, not publishing a history of its
initialization, as interesting as that might be.

The only problem I see is that the registry draft,
http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-12.txt,
currently references the initial registry i-d in multiple places; we'd need
someone to provide the correct incantation to make the right thing
happen.  I can hardly imagine that a document (whether BCP
or some kind of Standard-to-be) would be permitted to reference
(even informatively) an i-d never intended for publication.
Please send suggested text.

Although my personal preference would be to publish the i-d
http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-04.txt
as an Informational RFC, ideally marked "Historic" from
the first day it appears, I do not object to non-RFC alternatives
that let us accomplish the initialization, as long as we keep the
initialization data out of any container that would cause it to be
mistaken for the registry itself.

Randy, ltru co-chair

---

From: John C Klensin <[email-masked]>
Date: Sat, 10 Sep 2005 20:04:09 -0400

--On Friday, 09 September, 2005 22:38 -0700 Randy Presuhn
<[email-masked]> wrote:

>> It's not clear to me what the point of publishing it as an
>> RFC is, and in fact if an explicit decision to that effect
>> has been made, it went past me entirely.
>> 
>> IMHO after initial-registry has served its purpose, it should
>> be allowed to time out and die.
> ...
> 
> (As ltru co-chair)
> 
> Those who follow the ltru WG mailing list closely will recall
> that there were two distinct issues recorded in the issue
> tracker: (at https://rt.psg.com/ user and password are "ietf")
> #875 should initial registry contents be made into an
> internet-draft? #878 should the initial registry contents i-d
> be published as an RFC?
> 
> There was a rough consensus in support of #875, but the
> discussion of #878 was inconclusive.   We asked our AD whether
> he had any preference with respect to #878, and he indicated a
> preference for publication as an (informational) RFC.
> 
> The decision on #875 (initial registry as i-d) has in
> retrospect proven to be a good one, in my personal opinion.
> 
> Regarding issue #878, I think we've all looked at it as just a
> matter of how to work the process to get the right stuff into
> the registry.  The working group has been quite clear in
> wanting to ensure that the initial registry is not mistaken
> for the registry itself, and was never enthusiastic about
> publishing it as an RFC.
> 
> Consequently, I do not think that it would be a big problem if
> the IESG were to tell the ltru WG that we don't need to
> publish the initial registry i-d as an RFC, or if the WG,
> reconsidering issue #878 as a result of the IETF last call
> comments were to reach a consensus to withdraw the publication
> request, as long as we have some assurance that the registry
> will be end up with the right stuff.
> 
> Sure, we would have wasted a lot of energy getting the initial
> registry i-d RFC-ready, but the important thing is to
> initialize the registry.  Process is a tool, not an end in
> itself, and the result we are interested in is getting the
> updated registry going, not publishing a history of its

Extremely violent agreement.

> http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-1
> 2.txt, currently references the initial registry i-d in
> multiple places; we'd need someone to provide the correct
> incantation to make the right thing happen.  I can hardly
> imagine that a document (whether BCP or some kind of
> Standard-to-be) would be permitted to reference (even
> informatively) an i-d never intended for publication. Please
> send suggested text.
> 
> http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-04
> .txt as an Informational RFC, ideally marked "Historic" from
> the first day it appears, I do not object to non-RFC
> alternatives that let us accomplish the initialization, as
> long as we keep the initialization data out of any container
> that would cause it to be mistaken for the registry itself.

Well, that pair of issues is exactly what I was concerned about
and suggesting fixing, despite Doug's strong reaction to a
suggestion I didn't intend to make.

Specifically: If a document is published in the RFC series that
lists elements of a registry, it will, inevitably, be used as a
reference instead of the registry.  Disclaimers in the document
(as now exist) will help with that a bit.  The word "historic"
in the RFC Index will help with that a bit.  But it will still
be referenced by someone, somewhere, as an "official" RFC and an
easy-to-obtain list.   At the same time, there is useful, albeit
mostly-historical, information in the initialization document
that I would personally prefer not get lost.  And that
referencing issue is a pain in the neck, although not a huge one.

So, very specific suggestion:

	(1) Get the registry created and initialized, exactly as
	specified in the "initial" document at -02.  I think
	that is a no-brainer and we all seem to be agreeing
	about it.
	
	(2) Issue, and send to the RFC Editor for Informational
	publication, a version of draft-ietf-ltru-initial that
	replaces the contents of Section 3 ("Initial Registry
	Contents") with a pointer to the registry itself and, if
	desired, a hint as to how the initial elements can be
	identified, for historical purposes, in the registry.
	Leave the rest of it alone.  It contains useful text and
	some information that should not be lost (such as the
	omitted code element list).  Just to be orderly, remove
	the "don't pretend this is the registry"
	statements/warnings from the abstract and the end of
	Section 1.

This prevents anyone from referencing the RFC form of the
initialization document as the registry far more effectively
than any warnings or labels -- there will be nothing there to
reference.  It saves time patching references to the
initialization document because the initialization document will
exist as an RFC and even have the same section numbering.  It
saves worrying about whether there is important historical
information in the initialization document that would need to be
moved somewhere else if that document were dropped, and where to
move it. 

The WG and IESG should do what they think best, but this really
seems pretty obvious to me.

Of course, none of the above has anything to do, one way or the
other, with my concerns about BCP versus Standards Track,
replacement of 3066 without doing something specific about the
matching rule question, applications-specific profiles, and so
on.  Whatever the right answers to those concerns are, they are
not as obvious, at least to me.

    john

---

From: r&d afrac <[email-masked]>
Date: Sun, 11 Sep 2005 02:34:19 +0200

We eventually reach the mission assigned by the Charter: the real 
IANA registry. And we considering some of the key points:

1. is the directory to be published as an RFC?
2. is it or not to document the subtags ISO aliases?
3. is it to respect the Charter and the IESG authority in being 
reviewed by [email-masked] and approved by its IESG 
designated reviewer?
4. what is its expected growth? Should it be contained in size? Is it 
informative or normative?
5. what is its practical purpose, in term of user applications? How 
is it expected to be used?
6. what is its dissemination system?
7. who is going to insure that this system is sure, secure, stable 
and who will bear the cost of it?

I am opposed that my approach is not in operations (cf. John): 
AFRAC's role is to consider the various propositions and to test the 
most appropriate ones for its own mission of a reference center. From 
this (a) we know the main Draft proposition is very limited and 
dangerous, (b) we know there are others possible propositions, with 
their own con and pros (Addison explained he had one), (c) we observe 
they should be correctly be supported by IRI-tags with  RFC 3066 bis 
as a default with no other change than to add one sentence: "0- 
introduces an URI/IRI tag which conforms RFC [URI-tags]"]).

Going further without first a consensus on the target of the WG 
(addressing user needs like ours vs. imposing on us an unique limited 
solution) would only create confusion. Competition, as begged from us 
by Addison, between standardisers and users is never good.

Now these simple, practical questions are put in front of the IESG. 
IESG will turn me right or wrong. If they can think of a way to 
deliver, with non limited and non constrained internationalisation 
options, along with the proposed registry: no one will be more happy 
than me. Otherwise the Internet standard process still gives chances 
to a thinking maturation process, through IETF/IAB and external appeals.

To help that thinking we may have to stabilise and deploy a 
grassroots project. But I am afraid then to trigger other projects by 
industry leaders and Govs. They will see there a way to block a 
Internet possible control and a way to obtain parts of it. But the 
constant disregard of our needs as a user of the deliverable may 
eventually push us to do that.

1. is it to be published as an RFC?

     As an RFC it is the same base for all the common reference 
centers, existing and to come, IANA or not. It preserves a point of 
consensus. It permits RFC "bis", "ter" etc. to accompany ISO, usage 
and RFC 3066nths evolution.

2. is it or not to document the subtags ISO aliases?

     No to do so would underline the motivation of exclusiveness. 
This would only add to confusion: users will see that registry as an 
hybrid registry, randomly (on their opinion) using variable format 
elements from ISO 639-1,2,3,5,6, from ISO 3166 and UN, from its own, 
with no documented relation with the ISO codes they use in their 
other applications. Search engines and Gov systems will align on ISO 
11179 works and on ISO 639-4 guidelines. In defending for ever the 
RFC 3066 errors, instead of correcting them progressively, what do we 
want to do?

    This is IETF, not a WTO arbitration.

3. is to respect the Charter and the IESG authority in being approved 
by [email-masked] and its reviewer

    I documented the need and the courtesy to have Michael Everson 
and [email-masked] to review and approve the soundness 
and the consistency of the proposed registry content. It also 
underline the script orientation of the Draft.

4. what is its expected growth? Should it be contained in size? Is it 
informative or normative?

    John documented the IETF/RFC's related difficulties if the 
parameter registry goes large (I do not know if there is another 
registry which can expand to 40.000 items?).

5. what is its practical purpose, in term of user applications? How 
is it expected to be used?

    This point is still pending.

6. what is its dissemination system?

    This point is still pending - it will result from the above.The 
only indication I got so far is "like Unicode". I indicated the 
system we advocate.

7. who is going to insure that this system is sustained and who will 
bear the cost if it?

    I know this is not a main IETF concern. I submit it is because 
the IANAI registries are usually not that size and do not risk to be 
accessed by the XML applications by billions?

jfc

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 11 Sep 2005 04:22:25 +0200

John C Klensin wrote:

 [ltru-initial]
> The WG and IESG should do what they think best, but this
> really seems pretty obvious to me.

Yes, it's _now_ obvious, but it wasn't before you started
this thread.  So keeping the rest of "ltru-initial" as an
informational or historic RfC might also help others when
they look for a "how-to".

> none of the above has anything to do, one way or the
> other, with my concerns about BCP versus Standards Track

That puzzle is for the IESG, I hope that they find a better
answer than "toss a coin".  On the technical side I'd like
to see a way to communicate the "intended status" in an I-D
with xml2rfc (not only for Bruce's reviews).  And I hope
that splitting the BCP series into "techno" vs. "meta" (or
similar) shows up in a future carpenter-procdoc-roadmap-01.

 [applications-specific profiles]
> Whatever the right answers to those concerns are, they are

For that part all I found as potential candidates is "never
use script subtags" (e.g. audio) and "always use a script"
(= intentionally violating several SHOULDs in conjunction
with Suppress-Script).  If that's really all it's obvious,
no additional profile-headaches necessary at the moment.

It's possible to add this later if some future extension
registry offers more exciting choices than to script or
not to script.

Maybe we could mention this in a note about the extension
registries.  Also as a hint for the future DS^W3066ter.

                       Bye, Frank

---

From: John C Klensin <[email-masked]>
Date: Sun, 11 Sep 2005 03:27:38 -0400

> they look for a "how-to".

I think so.

> similar) shows up in a future carpenter-procdoc-roadmap-01.

Two observations: (1) In a situation like this, if the community
leaves the IESG to make this sort of decision without
significant community input, then the community deserves
whatever the IESG does, including coin-tossing.   If people
care, they should say so clearly enough that the IESG's role is
to interpret community input, not to make things up because no
one (besides some soreheads like me) is saying anything.

FWIW, that split in the BCP series is already covered in
draft-ietf-newtrk-repurposing-isd.

> no additional profile-headaches necessary at the moment.

Perhaps my imagination is worse than yours, but I can easily
imagine "numeric country codes prohibited" or "alpha-2 country
codes prohibited" (note that matching the two requires large
tables that are not, as far as I know, freely available for free
and that change).  I can also imagine "script required" or
"region, if present, ignored" or a number of other variations
and profiles.

> registries.  Also as a hint for the future DS^W3066ter.

"Add later" is much more plausible, at least formally, with a
Proposed Standard than it is with a BCP.  The notion of
replacing a BCP with a new BCP that says something different is
always going to be dicey unless there has been an actual and
obvious change in common behavior.

    john

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 11 Sep 2005 14:05:01 +0200

John C Klensin wrote:

> In a situation like this, if the community leaves the IESG to
> make this sort of decision without significant community
> input, then the community deserves whatever the IESG does,
> including coin-tossing.   If people care, they should say so
> clearly enough that the IESG's role is to interpret community
> input, not to make things up because no one (besides some
> soreheads like me) is saying anything.

It's not that nobody but you said anything about it, in fact
it's the only case of a potential "rough consensus" not covered
by a half dozen LTRU tickets.

What Addison said is IMHO correct, 3066bis must replace 3066,
they can't coexist.  One of the main design goals was backwards
compatiility.  Any solution designed to exist in parallel with
3066 would be completely different, because it's not forced to
be backwards compatible.  For starters there won't be a kludge
like "Suppress-Script" in that hypothetical solution.

Most probably we agree so far, and then the question of BCP vs.
standards track is among other things a matter of taste.  It's
apparently a "feature" of 2026 that the IESG decides about the
status - in the usual sense of "your feature is my bug (and
v.v.)", so all we can do is offer some opinions.

If you'd press the WG for some kind of consensus about this I'd
bet that you'd get "BCP with an option for the IESG to say PS",
exactly as Scott (= the AD, the Proto-shepherd avoided that
issue) stated it.  With some more or less convincing reasons.

And finally it's not up to the author / WG / Chair / community
to decide about the status.  Unfortunately in the case of some
individual submissions, this "experimental" loophole to bypass
a proper "IETF last call" as seen for SPF and SID was "wrong"
(a 2234bis "wrong", so that's as bad as 32 ordinary wrongs :-)

But for ltru-registry there was a "last call", and I think the
IESG knows that some (not only you) prefer PS instead of BCP
for 3066bis - under the conditions listed by Addison.

> draft-ietf-newtrk-repurposing-isd.

Thanks for info, added to my "I-D collection" - admittedly I'm
lost in this one-step / two-step / add-XML-step netwrk-maze.

> imagine "numeric country codes prohibited" or "alpha-2
> country codes prohibited" (note that matching the two
> requires large tables that are not, as far as I know, freely
> available for free and that change).

In that case your imagination is worse tha mine.  The _actual_
lists are freely available, e.g. the alpha-2 country codes:

http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/iso_3166-1_decoding_table.html?printable=true#AA

It's unnecessary to match these lists.  All details about the
registration of region codes are specified in 3066bis.  Forward,
sideward, backward, 3166 screws up, 3166 out of sync with UN,
everything, we discussed this for months.  It was the reason
why I was interested in this WG.

It makes no sense to exclude all numeric country codes, that's
the "escape hatch" if 3166 is forced to reuse an aplha-2 code
(examples: GE, SK, CS), because 3066bis tags are persistent
(unlike 3066 tags).

Maybe you could exclude the UN "macro-regions" (~ continents),
you could as well exclude some languages or scripts, or all
variants.  If you do so, fine, but that doesn't affect the
registry.

There's one thing where getting _free_ lists could be tricky:
old region codes.  OTOH precisely that issue is addressed by
the registry with its persistent subtags, you don't need any
old UN or 3166-lists to determine what 3066bis subtags mean
(unlike 3066 tags).

> I can also imagine "script required" or "region, if present,
> ignored" or a number of other variations and profiles.

Yes, the first case was also in my shorter list.  If you take
language + script + region as three "dimensions", then the
language is required (using the langtag registry in other
contexts could be a bad plan, it's not designed to be a say
region registry, and for a script registry you can also use
the ISO standard).  That leaves two dimensions where you could
say "ignored" or "required".  Better don't consider "variant"
as an independent fourth dimension, it's not, generally it has
a "Prefix".

All in all you'd get about four potential "profiles":  I-I,
I-R, R-I, and R-R (I = ignored. R = required).  The concept of
regions in 3066 and 3066bis is so clumsy that I can't imagine
any serious case of R.  That reduces the profiles to I-I + R-I
(= my "to script or not to script"), or maybe I-I, R-I, I-?,
and R-I (? = region allowed).

> "Add later" is much more plausible, at least formally, with
> a Proposed Standard than it is with a BCP.

Add Jefsey and we're three. and that's not much, bye, Frank

---

From: r&d afrac <[email-masked]>
Date: Sun, 11 Sep 2005 14:55:26 +0200

At 14:05 11/09/2005, Frank Ellermann wrote:
>Any solution designed to exist in parallel with 3066 would be 
>completely different, because it's not forced to be backwards compatible.

This is uncorrect. There is a total confusion between backward 
compatibility and conformance. Any new format including the RFC 3066 
format will be backward compatible. The Draft demands for ever new 
releases to stay compatible only with RFC 3066, and invents new 
constraints to that end.

I note that this "backward compatibility" which excludes the support 
of most of user needs, includes the introduction of the support of 
"scripts" , interestingly enough a word not even used by RFC 3066.

jfc