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

["JFC (Jefsey) Morfin" <[e-mail]>]

At 14:42 25/08/2005, Scott Hollenbeck wrote:
> > -----Original Message-----
> > From: JFC (Jefsey) Morfin [mailto:[e-mail]]
> > Sent: Wednesday, August 24, 2005 11:29 PM
> > To: Scott Hollenbeck; [e-mail]
> > Cc: [e-mail]; [e-mail]
> > 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 [e-mail] 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 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf