Return-Path: Received: from murder ([unix socket]) by eikenes.alvestrand.no (Cyrus v2.2.8-Mandrake-RPM-2.2.8-4.2.101mdk) with LMTPA; Wed, 24 Aug 2005 17:18:45 +0200 X-Sieve: CMU Sieve 2.2 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 97419320096 for ; Wed, 24 Aug 2005 17:18:45 +0200 (CEST) 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 06105-07 for ; Wed, 24 Aug 2005 17:18:37 +0200 (CEST) X-Greylist: domain auto-whitelisted by SQLgrey-1.4.8 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by eikenes.alvestrand.no (Postfix) with ESMTP id E9CA8320095 for ; Wed, 24 Aug 2005 17:18:26 +0200 (CEST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7wur-0008H6-TX; Wed, 24 Aug 2005 11:11:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7wuo-0008Gn-US for ietf@megatron.ietf.org; Wed, 24 Aug 2005 11:11:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26954 for ; Wed, 24 Aug 2005 11:11:44 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7wv9-0003YG-8b for ietf@ietf.org; Wed, 24 Aug 2005 11:12:07 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E7wud-0002jY-6p; Wed, 24 Aug 2005 08:11:36 -0700 Message-Id: <6.2.3.4.2.20050824145147.04d9cc20@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Wed, 24 Aug 2005 15:02:36 +0200 To: "Scott Hollenbeck" From: "JFC (Jefsey) Morfin" In-Reply-To: References: <6.2.3.4.2.20050824104625.051a4ab0@mail.jefsey.com> Mime-Version: 1.0 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 - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: iesg@iesg.org, ietf@ietf.org Subject: RE: Last Call: 'Tags for Identifying Languages' to BCP X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0021783552==" Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org X-Virus-Scanned: by amavisd-new at alvestrand.no --===============0021783552== Content-Type: multipart/alternative; boundary="=====================_144875149==.ALT" --=====================_144875149==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed On 13:24 24/08/2005, Scott Hollenbeck said: > > -----Original Message----- > > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On > > Behalf Of JFC (Jefsey) Morfin > > Sent: Wednesday, August 24, 2005 5:03 AM > > To: iesg@ietf.org; ietf@ietf.org > > Subject: Re: Last Call: 'Tags for Identifying Languages' to BCP > > > > I would like to understand why > > http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-12.txt > > claims to be a BCP: it introduces a standard track proposition, > > conflicting with current practices and development projects under way? > > > > I support it as a transition standard track RFC needed by some, as > > long as it does not exclude more specific/advanced language > > identification formats, processes or future IANA or ISO 11179 > > conformant registries. In order to avoid conflicts, its ABNF should > > be completed in dedicating a singleton to the general tag > > URI > > > (http://www.ietf.org/internet-drafts/draft-kindberg-tag-uri-07.txt > > > accepted RFC). > >Jefsey, >First, let's agree that you've asked this question [1], made this suggestion >[2], and engaged in discussion of these topics on the LTRU working group >mailing list. I know you haven't been happy with the way the discussion >went, but these are not new topics. Agreed? Dear Scot This an IESG last call. The IESG solicited final comments on its intent to take a decision on the document - not on the WG methods. I am honored to be involved in an internal discussion to the IESG by the AD in charge, but if the IESG has already set-up its mind, what is the use of a Last Call period? The considered Draft does not describe a practice. It is a standard track proposition among many others, existing or possible, including better ones (according to his author), in an area where expertise is scarce. >Why a BCP? Production of this document is a direct requirement of the group >charter: "This working group will address these issues by developing >two documents. >The first is a successor to RFC 3066." 3066 is BCP 47. The >introduction and list of changes included in the >document describe why and how it is obsoleting 3066. A successor is not necessarily a replacement. This question marred the two last previous Last Calls of this proposition. Time has come to address this in deprecating RFC 3066/BCP 47 and in considering this Draft as what it is: a standard track RFC. >The ABNF suggestion has been discussed, partially accepted, and partially >rejected by the working group. If you have new information to describe why >you think the working group decision was a mistake, please describe it. The IESG is to determine is if there is a consensus or not about the Draft. It is not new the sun is not blue. It is not new that commercial interests are in conflict with open sources. There are on this list - and this is the purpose of a LC - all the IETF competences to evaluate if the partial acceptance of my suggestions went far enough or not. A technical conflict remains a conflict. One may dislike it, but one has to address it. We have two contradicting propositions, one accepted as an RFC, one here under discussion. Both use W3C needs as a motive, but both authors claim (one by disclaimer in his text, the other in the WG debate) they do not represent the W3C positions. May be a LC is the proper time, and this list the best place, for W3C to tell us officially the tags, the private use tags or the other tag formats they (also) want. And the same for all the other concerned SDOs. All the best. jfc --=====================_144875149==.ALT Content-Type: text/html; charset="us-ascii" On 13:24 24/08/2005, Scott Hollenbeck said:
> -----Original Message-----
> From: ietf-bounces@ietf.org [ mailto:ietf-bounces@ietf.org] On
> Behalf Of JFC (Jefsey) Morfin
> Sent: Wednesday, August 24, 2005 5:03 AM
> To: iesg@ietf.org; ietf@ietf.org
> Subject: Re: Last Call: 'Tags for Identifying Languages' to BCP
>
> I would like to understand why
> http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-12.txt
> claims to be a BCP: it introduces a standard track proposition,
> conflicting with current practices and development projects under way?
>
> I support it as a transition standard track RFC needed by some, as
> long as it does not exclude more specific/advanced language
> identification formats, processes or future IANA or ISO 11179
> conformant registries. In order to avoid conflicts, its ABNF should
> be completed in dedicating a singleton to the general tag
> URI
> ( http://www.ietf.org/internet-drafts/draft-kindberg-tag-uri-07.txt
> accepted RFC
).

Jefsey,
First, let's agree that you've asked this question [1], made this suggestion
[2], and engaged in discussion of these topics on the LTRU working group
mailing list.  I know you haven't been happy with the way the discussion
went, but these are not new topics.  Agreed?

Dear Scot
This an IESG last call. The IESG solicited final comments on its intent to take a decision on the document - not on the WG methods. I am honored to be involved in an internal discussion to the IESG by the AD in charge, but if the IESG has already set-up its mind, what is the use of a Last Call period?

The considered Draft does not describe a practice. It is a standard track proposition among many others, existing or possible, including better ones (according to his author), in an area where expertise is scarce.

Why a BCP?  Production of this document is a direct requirement of the group
charter: "This working group will address these issues by developing two documents.
The first is a successor to RFC 3066." 3066 is BCP 47.  The introduction and list of changes included in the
document describe why and how it is obsoleting 3066.

A successor is not necessarily a replacement. This question marred the two last previous Last Calls of this proposition. Time has come to address this in deprecating RFC 3066/BCP 47 and in considering this Draft as what it is: a standard track RFC.

The ABNF suggestion has been discussed, partially accepted, and partially
rejected by the working group.  If you have new information to describe why
you think the working group decision was a mistake, please describe it.

The IESG is to determine is if there is a consensus or not about the Draft. It is not new the sun is not blue. It is not new that commercial interests are in conflict with open sources. There are on this list - and this is the purpose of a LC - all the IETF competences to evaluate if the partial acceptance of my suggestions went far enough or not.

A technical conflict remains a conflict. One may dislike it, but one has to address it. We have two contradicting propositions, one accepted as an RFC, one here under discussion. Both use W3C needs as a motive, but both authors claim (one by disclaimer in his text, the other in the WG debate) they do not represent the W3C positions. May be a LC is the proper time, and this list the best place, for W3C to tell us officially the tags, the private use tags or the other tag formats they (also) want. And the same for all the other concerned SDOs.

All the best.
jfc

--=====================_144875149==.ALT-- --===============0021783552== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============0021783552==--