|
RE: Last Call: 'Tags for Identifying Languages' to BCP
2005-08-25 14:46:05
At 14:42 25/08/2005, Scott Hollenbeck wrote:
> -----Original Message-----
> From: JFC (Jefsey) Morfin [mailto:jefsey(_at_)jefsey(_dot_)com]
> Sent: Wednesday, August 24, 2005 11:29 PM
> To: Scott Hollenbeck; ietf(_at_)ietf(_dot_)org
> Cc: iesg(_at_)iesg(_dot_)org; ietf(_at_)ietf(_dot_)org
> 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(_at_)alvestrand(_dot_)no 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
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
|
|