Subject: Re: Last Call: 'Tags for Identifying Languages' to BCP

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Wed, 24 Aug 2005 11:03:06 +0200

I would like to understand why 
http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-12.txt 
claims to be a BCP: it introduces a standard track proposition, 
conflicting with current practices and development projects under way?

I support it as a transition standard track RFC needed by some, as 
long as it does not exclude more specific/advanced language 
identification formats, processes or future IANA or ISO 11179 
conformant registries. In order to avoid conflicts, its ABNF should 
be completed in dedicating a singleton to the general tag 
URI 
(http://www.ietf.org/internet-drafts/draft-kindberg-tag-uri-07.txt 
accepted RFC).

jfc

At 18:45 23/08/2005, The IESG wrote:
>The IESG has received a request from the Language Tag Registry Update WG to
>consider the following documents:
>
>- 'Initial Language Subtag Registry '
>    <draft-ietf-ltru-initial-04.txt> as an Informational RFC
>- 'Tags for Identifying Languages '
>    <draft-ietf-ltru-registry-12.txt> as a BCP
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action.  Please send any comments to the
>[email-masked] or [email-masked] mailing lists by 2005-09-06.
>
>The file can be obtained via
>http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-04.txt
>http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-12.txt

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

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Wed, 24 Aug 2005 07:24:02 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of JFC (Jefsey) Morfin
> Sent: Wednesday, August 24, 2005 5:03 AM
> To: [email-masked]; [email-masked]
> Subject: Re: Last Call: 'Tags for Identifying Languages' to BCP 
> 

Jefsey,

First, let's agree that you've asked this question [1], made this suggestion
[2], and engaged in discussion of these topics on the LTRU working group
mailing list.  I know you haven't been happy with the way the discussion
went, but these are not new topics.  Agreed?

Why a BCP?  Production of this document is a direct requirement of the group
charter:

"This working group will address these issues by developing two documents.
The first is a successor to RFC 3066."

3066 is BCP 47.  The introduction and list of changes included in the
document describe why and how it is obsoleting 3066.

The ABNF suggestion has been discussed, partially accepted, and partially
rejected by the working group.  If you have new information to describe why
you think the working group decision was a mistake, please describe it.

-Scott-
LTRU Area Advisor

[1]
http://www1.ietf.org/mail-archive/web/ltru/current/msg03360.html

[2]
http://www1.ietf.org/mail-archive/web/ltru/current/msg03196.html

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Wed, 24 Aug 2005 15:02:36 +0200

On 13:24 24/08/2005, Scott Hollenbeck said:
> (<http://www.ietf.org/internet-drafts/draft-kindberg-tag-uri-07.txt>http://www.ietf.org/internet-drafts/draft-kindberg-tag-uri-07.txt 
>
> > accepted RFC).
>
>Jefsey,

Dear Scot
This an IESG last call. The IESG solicited final comments on its 
intent to take a decision on the document - not on the WG methods. I 
am honored to be involved in an internal discussion to the IESG by 
the AD in charge, but if the IESG has already set-up its mind, what 
is the use of a Last Call period?

The considered Draft does not describe a practice. It is a standard 
track proposition among many others, existing or possible, including 
better ones (according to his author), in an area where expertise is scarce.

>charter: "This working group will address these issues by developing 
>two documents.
>The first is a successor to RFC 3066." 3066 is BCP 47.  The 
>introduction and list of changes included in the

A successor is not necessarily a replacement. This question marred 
the two last previous Last Calls of this proposition. Time has come 
to address this in deprecating RFC 3066/BCP 47 and in considering 
this Draft as what it is: a standard track RFC.

>you think the working group decision was a mistake, please describe it.

The IESG is to determine is if there is a consensus or not about the 
Draft. It is not new the sun is not blue. It is not new that 
commercial interests are in conflict with open sources. There are on 
this list - and this is the purpose of a LC - all the IETF 
competences to evaluate if the partial acceptance of my suggestions 
went far enough or not.

A technical conflict remains a conflict. One may dislike it, but one 
has to address it. We have two contradicting propositions, one 
accepted as an RFC, one here under discussion. Both use W3C needs as 
a motive, but both authors claim (one by disclaimer in his text, the 
other in the WG debate) they do not represent the W3C positions. May 
be a LC is the proper time, and this list the best place, for W3C to 
tell us officially the tags, the private use tags or the other tag 
formats they (also) want. And the same for all the other concerned SDOs.

All the best.
jfc

---

From: David Hopwood <[email-masked]>
Date: Wed, 24 Aug 2005 16:34:22 +0100

> conflicting with current practices and development projects under way?

I've read this draft and see nothing wrong with it. Having a fixed,
unambiguous way to parse the elements of a language tag is certainly
a good idea. What specific current practices do you think it conflicts
with?

> I support it as a transition standard track RFC needed by some, as long 
> as it does not exclude more specific/advanced language identification 
> formats, processes or future IANA or ISO 11179 conformant registries.

The grammar defined in the draft is already flexible enough.

-- 
David Hopwood <[email-masked]>

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Wed, 24 Aug 2005 12:25:08 -0400

On Wed, August 24, 2005 9:02 am, JFC (Jefsey) Morfin said:
>> (<http://www.ietf.org/internet-drafts/draft-kindberg-tag-uri-07.txt>
>>
>> > accepted RFC).
>>
>>Jefsey,

This is not an internal discussion.  You sent a question to both the IESG
mailing list and the IETF discussion list.  The people on these lists are
not necessarily familiar with the discussion that took place on the LTRU
working group mailing list.  I believe it is necessary to help those readers
understand your questions and comments by putting them in context.

The IESG has not made up it's mind about anything.  We do, however, need to
understand what transpired during the course of working group deliberations
as we attempt to understand your questions and comments.

> better ones (according to his author), in an area where expertise is

Thank you for that comment.  It will be considered by the IESG.

> this Draft as what it is: a standard track RFC.

The working group was chartered to produce a document that replaces RFC 3066
according to my reading of the charter.  The registry draft notes this
status in the Introduction.  Yesterday the working group received an AD
evaluation comment that this status also needs to be more explicitly noted
in the first page document header.  I consider this an editorial issue that
can be resolved in the context of any other edits required as a result of
last call review.

If you are suggesting that this document does not meet the requirements of
the working group charter, then that is a valid comment that must be
considered by the IESG.

> formats they (also) want. And the same for all the other concerned SDOs.

I provided a link to your working group comment to help readers of this
exchange (including the IESG) review both your suggestion and the working
group response to your suggestion.  Thank you for this clarifying
information.

-Scott-

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Thu, 25 Aug 2005 05:29:17 +0200

On 18:25 24/08/2005, Scott Hollenbeck said:
   The people on these lists are
>understand your questions and comments by putting them in context.

Dear Scott,
what is surprising is that a Draft dealing with standard track 
issues, replacing an RFC dealing with the same issues, itself 
replacing a standard track RFC 1766 considering the same issues, can 
become a BCP.

As you now know it is because RFC 3066 became BCP 47. Alluding to 
WG-ltru is then confusing: the need is for someone with good memory 
to tells us how the content of the Standard Track RFC 3066 has been 
granted a BCP status, while deprecating a Standard Track RFC?

And to discuss how to correct that situation.

>as we attempt to understand your questions and comments.

If you say so. FYI never discussed the RFC 1766 origin because the 
point was out of the WG-ltru scope.

>according to my reading of the charter.

I think it is slightly more complex. The Charter says:
"RFC 3066 [a BCP] and its predecessor, RFC 1766 [a Standard Track], 
defined language tags for use on the Internet.".

It then says:
"This working group will address these issues by developing two 
documents. The first is a successor to RFC 3066."

Then, deep in the Charter, it says:
"The current registry contains pairs like uz-Cyrl/uz-Latn and 
sr-Cyrl/sr-Latn, but RFC 3066 contains no general mechanism or 
guidance for how scripts should be incorporated into language tags; 
this replacement document is expected to provide such a mechanism."

You know the lack of Charter analysis by the WG I often complained 
about. This is the reason why the WG has not been in a position to 
elucidate that "thorny" point. I consider legitimate and reasonable to say:

1. we have a need: to better address the language identification in 
Internet protocols
2. this is a standard track issue introduced by RFC 1766 and we need 
to correct the difficulty met by its successor RFC 3066
3. one of these difficulties is that such an Internet core issue to 
the Multilingual Internet is addressed by a closed BCP instead of  an 
open Standard. Let make the successor document a Standard Track 
document replacing a centralised control by a distributed solution.

>The registry draft notes this

I consider this document meets _some_ but _not_all_ the requirements 
of the working group charter (I could provide a long list if this was 
necessary). I submit this because 25 years of applied R&D, operations 
and survey in this area shown me no one on earth has today the 
expertise to stabilise any standard or practice in the brain to brain 
language interoperability area. This why _any_ proposition can only 
be "ad experimendam".

We met a very similar, however limited, situation in the IDN case. We 
all know the result. I suggest we do not repeat the same approach and 
that we deliver something stable the Internet community can rely on, 
live and develop with.

To do that there are three options.

1. to replace the BCP 47 (RFC 3066) by an Internet standard process 
framework dealing with the Multilingual Internet support. I started 
working on such a Draft one year ago. This was delayed by the 
WG-ltru: it has been a tough but fruitful experience I am now able to 
use in a preliminary  proposition. I hope to be able to publish a 
preliminary draft very soon, with reasonable international support 
expectations. This will probably be a long process.

2. to mend the closed format proposed by the Draft. For the reasons 
above I submit this is not feasible now, because no one has the 
expertise, the vision, the experience and the necessary universal 
support to do it today. I expect however that the community process I 
will propose will help doing it, based upon the experience. I would 
not be surprised if the R&D involved lead to a work of a magnitude 
comparable to IPv6 but calling on many sub-expertises the IETF has 
not right now.

3. to make the proposed Draft a default language identification 
system, supporting any other identification schemes in using one 
singleton as an introduction sequence. I note that during the WG-ltru 
process I have documented the support of my organisation to an ABNF 
included in the URI tags RFC. Some refinements are being discussed. I 
am ready to document such an extension through a WG-ltru specialised draft.

Everyone knows that people from large stakeholders, consortia and 
standardisation entities are involved in the proposition. They may 
find some commercial motivation in the use of the Draft current 
closed format. I submit this would be a mistake because they would 
block their own R&D (which will most probably agree with the results 
of our own experimentation when they have done their own home work). 
They would also run into the risk to attach a poor image to their 
name, if Governments and users are dissatisfied as they will  most 
probably be.

This is why I think my "default" proposition meets the requirements 
and the interests of everyone:

- large stakeholders benefit from a stable solution and lead (rather 
than a controverted IANA)
- their own R&D can develop
- competitive specific propositions and innovation can develop 
without harming anything, comforting the common approach
- community R&D and grassroots projects can develop and boost the 
Multilingual Internet - what we missed in the IPv6 case.

>group response to your suggestion.  Thank you for this clarifying

I have repeatedly indicated that I would appeal from a positive 
decision of IESG concerning the current status of the Draft. Because 
it would harm and delay the Internet community, for the global reason 
I give above and for many non-detailed "sub-reasons". This lead the 
Shepherding Chair to send you and through you the IESG a summary of 
my objections. I have no copy of this mail.

jfc

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Thu, 25 Aug 2005 03:39:03 +0200

>a good idea. What specific current practices do you think it conflicts

Dear David,
Before parsing the language tags many issues are to be considered 
which have important consequences often out of the IETF scope (L8/9).

I could tell you I work on brain to brain interintelligibilty related 
tools and projects for 25 years: the inadequation, the scarcity, the 
centalised control of the proposed solution directly oppose the work 
of my own R&D organisation. But you could object "too bad for you" 
(we are used to that).

So, I will tell you something different. Today, the common practice 
of nearly one billion of Internet users is to be able to turn off 
cookies to protect their anonymous free usage of the web. Once the 
Draft enters into action they will be imposed a conflicting privacy 
violation: "tell me what you read, I will tell you who you are": any 
OPES can monitor the exchange, extact these unambigous ASCII tags, 
and know (or block) what you read. You can call these tags in google 
and learn a lot about people. There is no proposed way to turn that 
personal tagging off, nor to encode it.

>>conformant registries.

(I suppose you mean more than just grammar. Talking of the ABNF is 
probably clearer?).

I am certainly eager to learn how I can support modal information 
(type of voice, accent, signs, icons, feelings, fount, etc.), medium 
information, language references (for example is it plain, basic, 
popular English? used dictionary, used software publisher), nor the 
context (style, relation, etc.), nor the nature of the text (mono, 
multilingual, human or machine oriented - for example what is the tag 
to use for a multilingual file [printed in a language of choice]), 
the date of the langtag version being used, etc.

The Draft relates language tags to a centraly controled and managed 
registry. This is a deprecating concept as the Internet distributed 
nature becomes more and more a reality. This is fully documented by 
the RFC on URI tags. That RFC proposes some examples, using standard 
Internet schemes. It would be great if you could show me how the 
Draft can support them.

The Draft has introduced the "script" subtag in addition to RFC 3066 
(what is an obvious change). However in order to stay "compatible" 
with RFC 3066, author says it cannot introduce a specific support of 
URI tags. This is why I would be more than gratefull if you could 
show me how the ABNF is "already flexible enough" to support them.

Deep thanks.
jfc

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Thu, 25 Aug 2005 08:42:25 -0400

> From: JFC (Jefsey) Morfin [mailto:[email-masked]] 
> Sent: Wednesday, August 24, 2005 11:29 PM
> To: Scott Hollenbeck; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: Last Call: 'Tags for Identifying Languages' to BCP 

[snip]

Jefsey,

You seem to be misunderstanding the distinction between BCPs and standards
track documents.  There's nothing "closed" about BCPs.  They are subject to
the exact same community review, approval, and appeal processes that are
used for standards track documents.

If I've misunderstood what you mean by "closed", please feel free to clarify
so that I and others can better understand your comment.

-Scott-

---

From: Bill Fenner <[email-masked]>
Date: Thu, 25 Aug 2005 09:23:12 -0400

JFC,

  In March, 1995, when RFC 1766 was published, the BCP track did not exist.
The Standards Track was being used for things that were not protocols
and did not fit well into the 3-stage process.  Since BCPs are subject to
the same consensus judging and scrutiny as standards-track documents, it's
been common practice to obsolete old standards-track documents with BCPs
when it's reasonable to think that the original document would have been
a BCP if BCPs had existed at the time.

  Bill

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Thu, 25 Aug 2005 17:35:04 +0200

>so that I and others can better understand your comment.

Dear Scott,
you ask two totally separate questions here: the BCP nature of the 
Draft, and the open/closed ABNF issue.
I will try to explain each of them in detail. I apologise being long, 
but we face a complex new Internet phase (brain to brain 
interintelligibility), most probably more complex than the whole 
today Internet. We need to be careful at not committing a mistake on 
its very root.

1. RFC 2026 says that
"The BCP subseries of the RFC series is designed to be a way to 
standardize practices and the results of community deliberations.".

A BCP is to describe and stabilise existing practices, present best 
community and IESG/IAB leadership thinking and to document the 
Internet standard process itself. One of the practical consequences is that:
- an appeal does not prevent a BCP to be enforced, since it 
should  describe and stabilise something which already exists.
- no successful implementations are required before it being confirmed.
- IESG will not accept a document for information or for 
experimentation contradicting it, since it is a community best practice.
- error are not easy to correct: every RFC does not make a standard, 
but every BCP is supposed to document a reality to stay compatible 
with. If the initial orientation is incorrect this will stay for ever.

While a standard track RFC is enforced only when published and 
confirmed after starting being successfully used, using a BCP vehicle 
permits a "fait accompli" strategy, all the more when a IANA registry 
has been implemented. This may be extremely costly to the Internet 
and the users, in money and delay. In this case, an error would be 
dramatic as we all know that multilingualism and the engaged 
balkanisation risk are key issue for the Internet. Can we foot 
another IDNA (which fortunately are Standard Track and informational?).

The target of the authors (this was still discussed at the WG-ltru 
yesterday) is to immediately enforce the ABNF in the IANA registry. 
This is not normal since the Draft introduces a new standard track 
proposition. This proposition imposes the IANA langtag registry a 
strict format and is said to be needed in a much larger number of new 
occasions (XML) while the danger to the user and the privacy legal 
aspects have not been investigated. This format conflicts with other 
formats resulting from the lose application of the out-dated RFC 
3066, or waiting for the corrections needed of RFC 3066, or 
respecting the URI tag RFC (from those I know). Actually this Draft 
opposes other existing or projected practices and projects. This was 
documented by the Draft's author: he begged a competitive Draft from 
me, so the "best" could "win". He acknowledged  better formats could 
be devised, such as an alternative project he had in the past.

IMHO the "winner" of an IETF document is to be the user community. A 
standard track document must define the best solution, a BCP must 
inclusively report on a community consensus or respect every serious 
or dedicated practice and R&D. This is all the more true in an area 
where the IETF community knows it has no particular experience, and 
no one in the world as final expertise. My own organisation's R&D 
"bad practices" are to respect the URI tag RFC and to disrespect the 
Draft proposition. This only shows that we are in a standard track 
case and that (even if we are wrong) we must be able to appeal 
_before_ what we consider as a deadly error is imposed on the Internet.

Another situation where a BCP could be acceptable, would be a 
community consensus that a current mix of practices would be a real 
disorder. Then the Draft constraints could be understandable. However 
not if it creates a greater disorder. The rigidity of the Draft will 
create such a disorder at some stage at ruling in a 
human/culture/political area. This rigidity is acceptable in a 
federating proposed standard but is opposed to the very concept of a 
BCP.  I documented some areas it does not address and the security 
problems it creates. I note that I obtained no indication from the 
WG-ltru on the use and the ways of use of the Registry, what is the 
basic of a practice description and what will affect the practical 
feasibility of the proposed standard. The load on the IANA servers 
may be tremendous if XML libraries start calling the IANA servers or 
even if the locale want to cache the registry. This would represent a 
technical and financial bottleneck - as a ccTLD Registry I am 
directly interested as we contribute to the cost of the IANA service. 
This is still terra quasi incognita.

On 15:23 25/08/2005, Bill Fenner said:
>In March, 1995, when RFC 1766 was published, the BCP track did not 
>exist. The Standards Track was being used for things that were not 
>protocols and did not fit well into the 3-stage process.  Since BCPs 
>are subject to the same consensus judging and scrutiny as 
>standards-track documents, it's been common practice to obsolete old 
>standards-track documents with BCPs when it's reasonable to think 
>that the original document would have been a BCP if BCPs had existed 
>at the time.

I thank Bill for this input. This clarifies the historical origin and 
demonstrates the misunderstanding. The RFC 1766, 3066 and the Draft 
addresses two different issues: a registry and a protocol issue. I 
suppose that a registry management issue can be documented by a BCP. 
But the proposition defines the exclusive management of a community 
property (the langtag IANA registry) it can be only be finalised by a 
serious positive community consensus. I submit that the IETF 
community has not yet the common expertise and the multilingual 
culture to uncover such a consensus. I note that all the participants 
to this debate, but me, have a perfect command of the English 
language and the majority has not the equivalent command of another 
language: this may not be the best experience to address and 
establish non-English language management rules?

But it seems odd to document the option to use a registry (the 
langtags do not necessitate a central directory in the URI tag 
practice) and the core of the complex interintelligibility layer 
protocol architecture to develop by a BCP (unless an IAB BCP?) , 
while there is:
- not even a community global awareness,
- no consensus on the nature of what we discuss
- a need of a Draft because the RFC 3066 use is limited by its lacks

The BCP nature could be accepted should the Draft intend to 
complement RFC 2026 and be dedicated to the support of Multilingual 
Internet specifics. This was the intent of the Draft I started 
working on. Such a BCP would for example introduce a "multilingual 
support" section in every Internet standard process document. This is 
not the case.

RFC 3066 can also be accepted as a BCP as written by an IESG Member 
outside of any WG, documenting the still existing private mailing 
list [email-masked] as the reviewer of the IANA langtag 
registry. In such a case RFC 3066 is an "IESG incitation". But the 
Charter obsoletes that incitation, obsoleting it. This should return 
the Draft to the RFC 1766 standard track not-a-standard-yet status.

Another possibility (the one I would have favored by far) would be a 
new "IESG/IAB incitation" in the area: an IESG or IAB documentation 
of the multilingual internet framework I call for.

I do not think the Draft standardises a common practice. I do not 
think the Draft is the result of a community wide delibarated consensus.

2. the open/closed nature of the proposition.

The difference between an open and a closed proposition is that a 
closed proposition is built to cover every possible issue and 
prevents possible additions then considered as a confusion, except 
through a revision. An open proposition is built to (be able) to 
welcome and support additional possibilities without revision. The 
current Draft is a closed proposition: yesterday the WG-ltru list 
still discussed ways to forbid usages they did not think about.

My "default proposition" makes it an open proposition, in considering 
the Draft proposition as a strictly defined default approach and in 
using a reserved mechanism as an organised hook for other 
possibilities, R&D, experimentation, innovation, user protection 
through encryption, multilingualism etc.

I would say that "closed" means that additions are to be made inside 
the proposition through revisions (the WG-ltru has already planned an 
RFC 3066 ter, RFC 3066 tetra, etc) An "open" proposition permits any 
addition to be build on top. Usually an appliance is a closed system, 
while a computer is an open one.

If you want to compare with OS, you will have Windows, Linux, QNX 
from closed to open systems. In networking the same graduation will 
be from centralised, decentralised, to distributed (no need to say 
that my vision of the Internet is more user-centric than 
central-registry centric: my work is over the granular distribution 
of personalised but consistent registries. This is in-line with 
TC32/ISO 11179 the WG-ltru refused to consider, an area where IETF 
starts having a real experience (ISO lacks) with the URI (IRI, MRI) tags.

I hope this is clearer.
jfc

---

From: David Hopwood <[email-masked]>
Date: Thu, 25 Aug 2005 23:40:56 +0100

JFC (Jefsey) Morfin wrote:
> [...] Today, the common practice of 
> nearly one billion of Internet users is to be able to turn off cookies 
> to protect their anonymous free usage of the web. Once the Draft enters 
> into action they will be imposed a conflicting privacy violation: "tell 
> me what you read, I will tell you who you are": any OPES can monitor the 
> exchange, extact these unambigous ASCII tags, and know (or block) what 
> you read. You can call these tags in google and learn a lot about 
> people. There is no proposed way to turn that personal tagging off, nor 
> to encode it.

I don't know which browser you use, but in Firefox, I can configure exactly
which language tags it sends. If it were sending other information using
language tags as a covert channel (which it *could* do regardless of the
draft under discussion), I'd expect that to be treated as at least a bug,
and if it were a deliberate privacy violation, I'd expect that to cause a
big scandal.

> I am certainly eager to learn how I can support modal information (type 
> of voice, accent, signs, icons, feelings, fount, etc.), medium 
> multilingual, human or machine oriented - for example what is the tag to 
> use for a multilingual file [printed in a language of choice]), the date 
> of the langtag version being used, etc.

I mean that the grammar is flexible enough to encode any of the above
attributes (not that it would be useful or a good idea to encode most
of them).

> (what is an obvious change). However in order to stay "compatible" with 
> RFC 3066, author says it cannot introduce a specific support of URI 
> tags.

This objection seems to be correct: URI tags include characters not
allowed by RFC 3066. But you could easily encode the equivalent information
to an URI tag, if you wanted to.