Return-Path: Received: from eikenes.alvestrand.no ([unix socket]) by eikenes.alvestrand.no (Cyrus v2.1.11-Mandrake-RPM-2.1.11-1mdk) with LMTP; Tue, 18 Jan 2005 04:53:25 +0100 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8C91E61BAE; Tue, 18 Jan 2005 04:53:25 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23083-05; Tue, 18 Jan 2005 04:53:25 +0100 (CET) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1ACD761BFD; Tue, 18 Jan 2005 04:53:20 +0100 (CET) X-Original-To: ietf-languages@alvestrand.no Delivered-To: ietf-languages@alvestrand.no Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3C0AE61BAE for ; Tue, 18 Jan 2005 04:53:14 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23083-03 for ; Tue, 18 Jan 2005 04:53:11 +0100 (CET) Received: from montage.altserver.com (montage.altserver.com [63.247.74.122]) by eikenes.alvestrand.no (Postfix) with ESMTP id 13DA061B9C for ; Tue, 18 Jan 2005 04:53:11 +0100 (CET) Received: from lns-p19-1-idf-82-251-91-4.adsl.proxad.net ([82.251.91.4] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.43) id 1CqkQW-00064k-J4; Mon, 17 Jan 2005 19:53:09 -0800 Message-Id: <6.1.2.0.2.20050118033330.04710eb0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 18 Jan 2005 04:53:02 +0100 To: "Randy Presuhn" , From: "JFC (Jefsey) Morfin" In-Reply-To: <001001c4fd05$961d8f80$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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-3D417088 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - alvestrand.no X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Virus-Scanned: by amavisd-new at alvestrand.no Cc: Subject: Re: language tag structure X-BeenThere: ietf-languages@alvestrand.no X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Language tag discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-languages-bounces@alvestrand.no Errors-To: ietf-languages-bounces@alvestrand.no X-Virus-Scanned: by amavisd-new at alvestrand.no 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@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 _______________________________________________ Ietf-languages mailing list Ietf-languages@alvestrand.no http://www.alvestrand.no/mailman/listinfo/ietf-languages