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; Thu, 06 Jan 2005 04:37:55 +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 7A5EC61B8D; Thu, 6 Jan 2005 04:37:55 +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 17520-03; Thu, 6 Jan 2005 04:37:55 +0100 (CET) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id ED40461BE5; Thu, 6 Jan 2005 04:37:49 +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 03CC961BB6 for ; Thu, 6 Jan 2005 04:37:48 +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 17429-05 for ; Thu, 6 Jan 2005 04:37:44 +0100 (CET) Received: from pechora.icann.org (pechora.icann.org [192.0.34.35]) by eikenes.alvestrand.no (Postfix) with ESMTP id DE0B661B8D for ; Thu, 6 Jan 2005 04:37:43 +0100 (CET) Received: from montage.altserver.com (montage.altserver.com [63.247.74.122]) by pechora.icann.org (8.11.6/8.11.6) with ESMTP id j063bb419820 for ; Wed, 5 Jan 2005 19:37:37 -0800 Received: from lns-p19-19-idf-82-249-7-129.adsl.proxad.net ([82.249.7.129] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.43) id 1CmOSe-00082l-SG; Wed, 05 Jan 2005 19:37:21 -0800 Message-Id: <6.1.2.0.2.20050106015428.07935030@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 06 Jan 2005 02:47:03 +0100 To: Michael Everson , ietf-languages@iana.org From: "JFC (Jefsey) Morfin" In-Reply-To: References: <0469B304BE16955F822E4FA8@scan.jck.com> <6.1.2.0.2.20050105025712.0e267460@mail.jefsey.com> <20050105121625.GD16300@skunk.reutershealth.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-2A30128B 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 - iana.org 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: draft-phillips-langtags-08, process, specifications, and extensions 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 At 14:29 05/01/2005, Michael Everson wrote: >Dear colleagues, >I can see that I have not been wrong deleting this thread unread. I don't >know what Mr Morfin's problem is, and John's responses suggest to me that >I oughtn't care. Please publish the new RFC soon so we can Get On With It. >Try to get it a number that ends in -66. Dear Michael, May be this one should be worth a second "Bulldog" prize :-) You are fully entitled not to want to consider/ignore the needs and questions I expressed (a very elegant and efficient example of the "particular care" of this caucus as required by the Internet standard process [RFC 2026]). But I am surprised you endorse such repeated "this": >At 07:16 -0500 2005-01-05, John Cowan wrote: >>The intent is that the draft become a BCP replacing RFC 3066 (also a >>BCP),not an Internet Standard. while BCP009 "The Internet Standards Process -- Revision 3" says in "5. BEST CURRENT PRACTICE (BCP) RFCs", says: "The BCP subseries of the RFC series is designed to be a way to _standardize_ practices and the results of community deliberations. A BCP document is subject to the same basic set of procedures as _standards_ track documents and thus is a vehicle by which the IETF community can define and ratify the community's best current thinking on a statement of principle or on what is believed to be the best way to perform some operations or IETF process function. "Historically Internet _standards_ have generally been concerned with the technical specifications for hardware and software required for computer communication across interconnected networks. However, since the Internet itself is composed of networks operated by a great variety of organizations, with diverse goals and rules, good user service requires that the operators and administrators of the Internet follow some common guidelines for policies and operations. while these guidelines are generally different in scope and style from protocol _standards_, their establishment needs a similar process for _consensus_ building. "While it is recognized that entities such as the IAB and IESG are composed of individuals who may participate, as individuals, in the technical work of the IETF, it is also recognized that the entities themselves have an existence as leaders in the community. As leaders in the Internet technical community, these entities should have an outlet to propose ideas to stimulate work in a particular area, to raise the community's sensitivity to a certain issue, to make a statement of architectural principle, or to communicate their thoughts on other matters. The BCP subseries creates a smoothly structured way for these management entities to insert proposals into the consensus-building machinery of the IETF while gauging the community's view of that issue. "The BCP process is similar to that for proposed _standards_. The BCP is submitted to the IESG for review, (see section 6.1.1) and the existing review process applies, including a Last-Call on the IETF Announce mailing list. However, once the IESG has approved the document, the process ends and the document is published. The resulting document is viewed as having the technical _approval_ of the IETF. "Specifically, a document to be considered for the status of BCP must undergo the procedures outlined in sections 6.1, and 6.4 of this document. The BCP process may be appealed according to the procedures in section 6.5. "Because BCPs are meant to express community consensus but are arrived at more quickly than _standards_, BCPs require particular care. Specifically, BCPs should not be viewed simply as stronger Informational RFCs, but rather should be viewed as documents suitable for a _content_different_from_Informational_RFCs_." I also note the importance of the "entities" given by the Internet standard process in BCPs. I would be interested in knowing which entities are participating as such (or nearly as such - I see the W3C, which other entity?) to this proposition. All the best. jfc jfc _______________________________________________ Ietf-languages mailing list Ietf-languages@alvestrand.no http://www.alvestrand.no/mailman/listinfo/ietf-languages