language tag structure
JFC (Jefsey) Morfin
jefsey at jefsey.com
Tue Jan 18 04:53:02 CET 2005
I will respond again in good faith in the hope this may help. Who knows?
At 03:29 18/01/2005, Randy Presuhn wrote:
> > This "ietf-language at alvestrand.no" mailing list has made a complex private
> > Internet standard process "BCP" Draft.
>Private? In what sense?
IETF. This list wants to present an IETF draft. It should follow and
respect the IETF Internet Standard Process. It should adopt its
terminology, understand its culture. Otherwise we will never understand
each others and will keep disputing jargon issues. There seems to be a
language negotiation problem.
Just decide if this is IETF, ISO or W3C. It can only be one. This is why a
WG IETF seems necessary.
>The mailing lists and discussions have certainly
>open and publicized. Otherwise I, as an outsider to this work, would not
>have found out about it long ago.
> > It does not address all language
> > related tagging needs.
>Nor should it. "Perfect is the enemy of done."
Even if you comment the Draft's attempt to cover too much, may I ask the
real interest of this comment?
We are not here to defend personnal positions! We are here to build
something that will work and scale and because of that will be accepted by
the users. In taking advantage from everyone's input. The Draft is
certainly good for many things, but does not scale. This would have been
easily fixed for a long in telling that it does not want to scale. Instead
of calling names the people who explain it.
> > I therefore prepare a document for information one
> > the way we will have addressed them all, once they have stabilized and been
> > demonstrated. I will also engage a BCP 025 process for a WG-Tags to be
> > created in order to address the information tagging needs in a
> consistent way.
>But please please please don't allow this research project to hold up
Now, please, be serious about the IESG. You cannot at the same time say
that I am a troll and that I am making the decision. We are here to work
together. The best we can. Thats all.
There is not such a thing as RFC 3066bis. There is a Draft. This Draft was
on a Last Call. The IESG must now decide about it. I supported this Draft
with a line saying that its scope is limited to the present scope of RFC
3066. Addison say "no", it is intended to cover everything. The attitude
of the authors and the confusion created by the announcement of an unknown
corrected -.09.txt have endangered the completion of the process. I must
however be clear: should the draft be accepted as BPC 047 without the
restriction I ask, I would appeal to save the day.
You have to accept that an RFC is not a W3C or an ISO document. It is not
completed when approved by the IESG. It is completed when used. If the
proposed Draft was understood as anything else than a temporary patch to
permit to proceed with IRI, XML documents, etc. the created confusion would
most probably endanger the whole Internet - because sovereignty and
multilingualism are the world's priorities.
Now. I will add please, please, please don't allow your eagerness for a
partial solution, personal political agendas or list selfishness, to hold
up completion of many other works, while adding a paragraph or two would
permit everyone to agree.
I do not block anything. I keep proposing and documenting how we can best
and fastest proceed.
> > The purpose of my mail was to make sure no one saw a problem with the parts
> > which wants to address the needs discussed on this list.
>The responses make it clear that several participants do have problems
>with the proposals in your message. Unfortunately, you don't seem to have
>addressed the objections. I've seen no messages in support of those
Their "objections" concern areas they claim not to be interested in. They
are welcome to come and discuss them on the mailing list dedicated to the
concerned draft. Please let stop confusion.
> > I have no reason
> > to suppose the responses I received were not loyal and genuine. They have
> > discussed parts for being outside of the scope of their draft what was not
> > the question. They have not discussed parts in their own scope.
>This is normal engineering discipline. It goes with the "E" in IETF.
>It is necessary to avoid "creeping featurism".
If this mailing list wants to develop a "blocking featurism" attitude, then
I will certainly change position and will definitely lobby for its Draft
to be rejected, because it does not scale and pretends . It will just not
work, IESG accepted or not.
The question is not to know if people will vote for it, but if there is a
consensus that it could work and it is worth trying it. There is not such a
consensus. If you guys keep saying you know better than everyone there will
be no decision in its favor.
>The lack of support for investigating your areas of concern
???? where did you find this ???? Oh! you mean on a list formed not to
consider them :-)
> suggests that if a tags working group were to be formed, its charter
> would constrain it to a much narrower set of issues than you would like.
I suggest you reread BCP 025. I do not know what you mean by "constrain".
If you mean clearly defined, with milestones, reports, openness, one
document per addressed matter, cooperation with other concerned WGs, etc.
Yes it would be constrained.
If you mean "narrower" as clearly assigned to a specific global task, not
confusing description, definition, usage, principles and examples. Yes it
would be narrower.
In addition you know what? It would be defined by a Charter negotiated with
IESG and reviewed by IAB. To make sure that what will be discussed will be
reviewed, is publicized, can scale, etc. and respects the RFC 1958 guide lines
>If you cannot build a concensus that a real problem exists AND is worth
>fixing AND can be solved AND belongs in the IETF, folks won't waste time
>here solving it.
This is true. Preparing a WG proposition is a serious task which calls for
months of thinking, discussion, examples, reviews, different points of
views. We already have 18 months of work on a generic example, after a two
year experimentation permitting to learn a few problems. Most probably a
few RFC will also share in the documentation of the need and of its
solutions. Nothing would prevent the Draft to do it to. So we would save
time and hassle.
Before we can go through that filtering exercise (which, as you say, may
turn the proposition down) there are a few months to go and much work ahead.
More information about the Ietf-languages