language tag structure

[Randy Presuhn]

Hi -

> From: "JFC (Jefsey) Morfin" <jefsey at jefsey.com>
> To: "Randy Presuhn" <randy_presuhn at mindspring.com>; <ietf-languages at alvestrand.no>
> Sent: Monday, January 17, 2005 7:53 PM
> Subject: Re: language tag structure
>

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

I've participated in the IETF for many years.   The conduct of this
list has been remarkably similar to what one would expect of a WG
mailing list.  Most of the participants on this list appear to be well-versed
in IETF culture; I know several of them have been active in the IETF
for many years.  Most of the participants have used terminology
consistently with the way those terms are used in the IETF.  The
exceptions to this are notably few.

> Just decide if this is IETF, ISO or W3C. It can only be one.

It is common for IETF work, and for work submitted to the IETF, to consider
other bodies' work.  It is a charter requirement for some working groups.

> This is why a
> WG IETF seems necessary.

This doesn't follow, and still doesn't explain your use of "private."

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

I've been involved in standards processes for many years in various organizations.
Too many times I've seen something that was probably "good enough" be
delayed by the possibility of somehow making it incrementally "better",
sometimes to the point of forcing potential users of the technology to
go elsewhere.  Sometimes this can even render a standards organization
irrelevant in a field it had once dominated.

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

Could you explain what you mean by "scale"?  It sounds like you're using
the term in a very different sense from how it is used in the IETF.

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

I have not called you a troll.  But I am quite serious in being concerned that
instigating a WG might cause further delay for 3066bis, and you have done
nothing to allay those concerns.

> There is not such a thing as RFC 3066bis.

Please take the time to learn a little about IETF culture.
This is the normal shorthand way of labeling an internet-draft
that is intended to supercede a published RFC.  This list
has been discussing RFC 3066bis for quite some time.

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

With fronds like these, who needs anemones?

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

As we WG chairs and document editors like to say: send text.

> I do not block anything. I keep proposing and documenting how we can best
> and fastest proceed.

I'm sorry, but the proposals have frequently had the same gestalt as
classic delaying tactics that some of us have seen in other fora.  Forgive
me for being sceptical, both as a linguist and as an engineer, about the
probability that some of your proposals could come to fruition in a timely
manner.

> > > 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 don't speak for the IESG, but I've observed over the years that if there are
significant objections about the proposed scope of work from the
likely set of contributors, formation of a working group is not likely.

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

"Lobbying" is not an accepted part of IETF culture.  Though it sometimes
happens, the lobbyist's impact on the outcome may be the opposite of
what was intended.

> The question is not to know if people will vote for it, but if there is a

"Voting" is not an accepted part of IETF culture.

> consensus that it could work and it is worth trying it. There is not such a
> consensus.

In the IETF "consensus" means "rough consensus", which does NOT mean
"everyone has veto power" (true consensus).  If this were a WG mailing list,
it would be the WG chair's job to determine whether there was a rough consensus
on this document, before handing to an AD to take to the IESG.

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

All the more reason to get 3066bis finished and into the RFC editor's queue,
so those who need it can get on with life while the proposed WG effort proceeds in
parallel.

Randy