RE: Last Call: 'Tags for Identifying Languages' to BCP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



At 14:42 25/08/2005, Scott Hollenbeck wrote:
> -----Original Message-----
> From: JFC (Jefsey) Morfin [mailto:jefsey@xxxxxxxxxx]
> Sent: Wednesday, August 24, 2005 11:29 PM
> To: Scott Hollenbeck; ietf@xxxxxxxx
> Cc: iesg@xxxxxxxx; ietf@xxxxxxxx
> Subject: RE: Last Call: 'Tags for Identifying Languages' to BCP

[snip]

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

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.

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 ietf-languages@xxxxxxxxxxxxx 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


_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]