language tag structure

[JFC (Jefsey) Morfin]

Dear Randy,
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 
>completion
>of 3066bis.

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

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.

jfc