Message-Id: <6.1.2.0.2.20050118101416.04e47460@mail.jefsey.com>
Date: Tue, 18 Jan 2005 18:57:39 +0100
To: "Randy Presuhn" <randy_presuhn@mindspring.com>,
	<ietf-languages@alvestrand.no>
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
In-Reply-To: <002001c4fd1b$5cff5c40$7f1afea9@oemcomputer>
References: <20050117110003.38F6461BE5@eikenes.alvestrand.no>
	<00a901c4fcdf$0442a6c0$030aa8c0@DEWELL>
	<6.1.2.0.2.20050117235155.07ab6750@mail.jefsey.com>
	<001001c4fd05$961d8f80$7f1afea9@oemcomputer>
	<6.1.2.0.2.20050118033330.04710eb0@mail.jefsey.com>
	<002001c4fd1b$5cff5c40$7f1afea9@oemcomputer>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed;
	x-avg-checked=avg-ok-57B58F5
Cc: 
Subject: Re: language tag structure
Precedence: list
Sender: ietf-languages-bounces@alvestrand.no
Errors-To: ietf-languages-bounces@alvestrand.no

Dear Randy,
thank you for your answers and questions. I will try to go through them 
seriously again. I case this may help.

At 06:05 18/01/2005, Randy Presuhn wrote:
>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.

No one in this mailing list has to conform to a Charter, to follow 
milestones, to relate with an AD.

I am not participating in the IETF for much more than three or four years. 
But I am involved in international packet switch networking for 27 years 
(in communications for 33) and chaired network oriented meetings with ARPA 
or Internet attendees 20 years ago, before IETF was created.

I do not share the IAB/IETF 2nd generation network architecture vision (I 
explained I had very early to analyze 3rd generation which is now 
emerging). But I am very respectful of the experience accumulated by the 
IETF and the Internet standard process. The key of any network architecture 
is consistency and that it scales. RFC 1958 is an extremely well thought 
document in that regard. This consistency (that every similar problem - and 
similar has no limit here - is resolved in a similar way) and this scaling 
(good English? that every retained solution can be used consistently 
whatever the considered problem) can only be obtained in thinking "network 
first", never "application first". Like when you develop an operating 
system. There can be iterative thinking, but network is to come first.

This list unfortunately thinks application first, and is even focused on 
making one heterogeneous document succeed. I fully accept that this is a 
normal behavior when specialists of an application meet. I also fully 
accept that they can hardly do it otherwise due to the too large scope of 
the RFC 3066 legacy. But these are points which should be corrected, not 
used as the basis of a proposition.

Too much care is given to _replace_ RFC 3066, instead of addressing each 
point in a today network perspective.

> > 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.

Certainly. But their deliverables are different. I accept that ISO may 
focus on delivering a document. I accept that W3C may decide of a way they 
want to organize an application. IETF tries to document consistent building 
blocks that will scale and work and to maintain a real life system. What I 
mean is that if the purpose in life of this mailing list was to make sure 
that languages are properly and consistently supported in a way acceptable 
to every network protocol and fruitful to most of the applications, I don't 
think I would have needed to do anything else than to print its documents 
and to use them.

I am not a standardizer. I am a user. I only speak-up and propose a 
solution when what is proposed does not work.

> > This is why a
> > WG IETF seems necessary.
>
>This doesn't follow, and still doesn't explain your use of "private."

It follows. This mailing list is private because it is not an IETF WG.
It follows. Because IETF WG(s) would be chartered by the IESG in a 
consistent vision of the network architecture reviewed by the IAB.

I think I need to clarify here something. I do not say, as you seem to have 
understood it, that a WG should replace this list. I say that today the 
networking architecture meets at least two major needs which are confused 
in here due to the RFC 3066 legacy which experimented them first.

1st is tagging. All over the network architecture there is a need for 
token, tagging, naming, locale, context, etc. to be consistently addressed 
from a networking point of view. This is a complex issue as it is a key 
part of the transition from 2nd generation (one single network centric 
system) to 3rd generation (an infinity of user centric systems). I am not 
sure the IETF may follows on this real life move because, as Harald 
Alvestrand documented it, IETF is better at maintaining than at innovating. 
But I think that approaching that problem through the need of a consistent 
semantic, and under the pressure of real world's competition, something 
worth can be achieved.

2nd is multilingualism. IMHO this is a so large issue that no WG can 
address it as such: it must be addressed as a culture. As this is the case 
for Security. We have in the Internet standard process the roots of that 
culture in RFC 1591, RFC 2277, RFC 3066 and several others. But we have to 
be very careful at not balkanizing the Internet in knowing better than 
others, one IDN experience is enough.

>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.

Excellent analysis!

Totally true. And this is the very mixed feeling I have about the Draft. 
Because it was "good enough" RFC 3066 was accepted as a BCP. This is an 
uncertain situation which works. Now, to address the needs of one single 
application, this list wants to make the situation "better" for that 
application, detrimentally to all the other users of that "good enough".

Totally true. And you are currently forcing me as user of the "good enough" 
to go elsewhere.

Totally true. And this is because I do think that this refusal to add two 
fields in the langtag (that you can default to null) can render the whole 
IETF irrelevant in the current 2/3rd generation starting transition, in the 
current WSIS trend, in the NGN starting debate, etc. that I am keeping 
trying. I have already shared in the emergence of three leading network 
technologies, I have no problem with a new forum to take over. I only now 
that if this is not done in a concerted way we will lose another 20 years. 
I doubt this is what we want.

>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 explained it above. Is that clear enough or not?
(if you arleady rushed a comment saying I am wrong, please think about it 
carefully in your own words, and try to generalize the concept 
"mathematically", i.e. as much as possible independently from any 
vocabulary indigen to a given culture).

In the case of this draft it means that a solution which fully satisfies 
the current applications (W3C tagging, IDN tables description, etc.) does 
not satisfies web services interinteligibility, OPES operations, CRC 
management/access needs, etc.

There are two ways to make it scale as this is required by its status of 
BCP (an RFC for information would not have this problem).

1. to declare it of limited application. This makes it universally 
applicable in its restricted application scope. This should be acceptable 
to all as it permits to satisfy the immediate needs, to prevent conflicts 
and to permit to work on the final solution. Addison has refused.

2. to enlarge the capabilities so it may scale. For the very reasons you 
gave and because extensive thinking and a comprehensive out-reach to other 
areas should probably necessary to do a good job, I would be very reluctant 
to this right now. This is why I support the first way, on condition that 
we would work on the second one.

But:
(0) Addison refused.
(a) I have another group's 18 months++ thinking on this [this is just 
another private group like this one, with no IETF framework and with a 
different target, with different backgrounds, with a different 
organization, but the same needs]
(b) I was writing a Draft on the IETF ability to document a "Multilingual 
Internet" in spite of its very important changes. It is clear to me that 
should the IESG approve the Draft the way it is today, while the IAB has 
published RFC 3869 which totally ignores multilingual issues, the 
IAB/IESG/IETF would become a simple maintainer of the IPv4 technology (as 
documented by Harald), the focus shifting somewhere else. (my concern is 
not in the shift, but in the unpreparedness of that somewhere else: we 
already have an Internat, I do not wish an Interkaza nor an Itutnet).
(c) we are already working applications/projects using the lang5tag and 
with public presentations in April and June.

>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.

This is a reasonable fear. And I will not hide I expect some results from 
it however I do not consider it the way you do!

Let be candid, there are two ways to present the things.

1. ietf-languages@alvestrand.no has risen a tagging issue of utmost 
importance (everyone agrees on this). Yet it was not able to consensually 
address it because it did not considered the need of other applications 
areas. A WG Tags will help it and others in proposing consensual solutions.

2. ietf-languages@iana.org has open a very important issue and shown that 
it was possible to come to consensual interapplication solutions. The 
maintenance and the consistence of their first proposition should be 
assumed by a WG Tags which will benefit from this experience, will protect 
and assist its possible additional needs and will extend its semantic, 
support, filtering solutions, etc. in a consistent way to all the domains 
requiring it and to all the protocols, procedures.

I favor the second one, but I need at least the first one.

> > 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.

What I mean is that this list has started to think in its private way (not 
along to an IESG Charter reviewed by the IAB) that an RFC 3066bis was 
necessary, then that it was to be made its own way (has an IAB guidance 
been requested?), then that its Draft was actually de facto approved to the 
points that the word "RFC 3066bis" is used on external sites as if was an 
Internet document. You perfectly know that this is contrary to the Internet 
standard process. The Draft name must be used.

> > 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?

I do not know what you mean by "anemones" ?
But I resent the word "frond", because this is exactly what we feel about 
you and I try to smooth it. Spending - certainly clumsily, sorry - much non 
compensated time to this. To stop the petty competition we feel you impose 
on all your brothers at arms.

> > 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.

No problem. But according to the Internet standard process.

- the Draft was in Last Call, while we/many had never heard of it before. 
Comments were requested. Comments were sent and propositions made. Response 
was blunt. Now it is to the IESG to take a position.

- once the IESG has made its position known there will be several cases:
   - either it is refused and we will have the opportunity to represent it 
or to address its concerns differently
   - either there is a new round, and we will propose after having 
carefully considered the IESG comments
   - or it is accepted. Then an immediate appeal would be probably the best 
turn to do instead of a slow confuising deprecation creep. But it calls for 
additional time and I do not like to fight "against", I like to fight "for" 
and to build. We will then probably submit specialized Drafts for information.

In the meanwhile I wanted to make sure I had correctly understood the 
requirement of this list, so its demands would be correctly supported in 
our propositions.

> > 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 problem is not the future. The problem is the conflict right now. 
Lang5tag is becoming operational now. I could present a Draft for 
information. But this list has taken me enough time :-) I also prefer it to 
be documented by a few months of operations.

> > 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.

True. And this is why I hope they will not create a WG Languages. The 
objections and concerns risen by any debate over languages, IDN, etc. are 
too important.

> > 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.

You right. The word is partly ill chosen. What I mean is that I will 
document why what I still believe possible (a consensus on a good extended 
approach) is refused in spite of my time and efforts.

But it will also mean that I will stop lobbying for politics not to step 
in, at the GAC and WSIS.

> > 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.

This is why I say that this is not ...

> > 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.

This is why I use the word consensus.

When I say we have to decide if we are ISO, W3C or IETF, this is precisely 
to avoid this kind of debate.
BTW can you tell me who is the AD for this Draft?

[snip]

> > 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.

I pray for that. But not to point to be beheaded in the process.
I made clear to IESG that should I not be beheaded I supported it.

Now, I would just like to make a remark:
I sent a mail to know if my extended support of the requirements of this 
mailing list was or not correct. The responses discussed my extensions 
(i.e; what they said they were not interested in). They also discussed the 
Draft no one should discuss right now.

I however tried to respond as positively as I could, but I am not able to 
know if was worth the investment. My feeling from all this is it shows the 
current positions are not stabilized yet when it comes to face external 
requirements. An IESG/IAB Charter would have helped this.

jfc

_______________________________________________
Ietf-languages mailing list
Ietf-languages@alvestrand.no
http://www.alvestrand.no/mailman/listinfo/ietf-languages