Message-Id: <6.2.1.2.2.20050423135722.0379e590@mail.jefsey.com>
Date: Sat, 23 Apr 2005 14:42:59 +0200
To: Frank Ellermann <nobody@xyzzy.claranet.de>, ltru@ietf.org
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
Subject: Re: [Ltru] BCP 47 
In-Reply-To: <42699FA6.CA7@xyzzy.claranet.de>
References: <634978A7DF025A40BFEF33EB191E13BC0B209B3C@irvmbxw01.quest.com>
	<634978A7DF025A40BFEF33EB191E13BC0B209B3C@irvmbxw01.quest.c om>
	<6.2.1.2.2.20050423010354.02bc35a0@mail.jefsey.com>
	<42699FA6.CA7@xyzzy.claranet.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: 
Precedence: list
Sender: ltru-bounces@lists.ietf.org
Errors-To: ltru-bounces@lists.ietf.org

At 03:06 23/04/2005, Frank Ellermann wrote:
>JFC (Jefsey) Morfin wrote:
>
> > there is no RFC 3066 standard since RFC 3066 is only a BCP
> > and not a standard
>Finally I'd bet that my idea to go back to standards track
>instead of a BCP is "dubious" or worse, but I'd really like
>to know why.  Are BCPs a dead end, is it impossible to get
>rid of them and to return to standards track ?

This idea is correct and does not contradict the RFC 3066 bis project. My 
only opposition to the current Draft is precisely that it does not respect 
the spirit of the Standard Internet process. Let review this main and first 
thorny question risen by the Charter.

There are three problems discussed by the charter.

- the identification of the languages in the Internet standard process 
(first sentences).
- the difficulties of applying RFC 3066 as it is, and the ways to remedy to 
that.
- the filtering solutions.

I say that they should be resolved in the following way

1. in having an language identification framework applicable to _every_ 
Internet Standard Process needs, past and future. This should be 
accompanied by a letter to the IESG or a part in the Draft to provide 
further guidance on the Charter revisions. It should document why this 
brings consistency, stability, security and capacity for Internet standards 
scalability. This general framework should succeed to RFC 3066 as RFC 047.

IMHO as a BCP it should stabilize a WG-TAGS as the maintainer of the subtag 
registry, the current status would be provided in annex. Being a BCP (which 
should be a description of real common practices) it can be easily updated 
by RFC (I suggest every year - as there are RFCs describing the historic 
status of RFCs); using monthly drafts to keep an accurate status of the 
subtags (a BCP is not normative but descriptive, so a Draft can be a 
snapshot of an evolving situation - with a 6 month validity).

The advantage is this corresponds to a well defined, stable and 
acknowledged process. That there are mirrors of RFC everywhere. That an RFC 
annex is not necessarily the place a browser will parse.

Another important advantage is that the WG-TAGS charter is revised every 
year by the IESG under IAB guidance/review. This permits to adapt to the 
Internet standard process and to ISO evolution without problem.

Another advantage is that each yearly RFC is timestamped (I would say every 
January 1st). This gives a good historic spine to leave totally open to 
imaginative thinking the way to address standard evolution question on a 
per application basis (if a new system starts on today document, they will 
not care about the past, while the common BCP 047 will keep them consistent 
with every other application).

2. to evaluate, from the RFC 3066 four years experience, what belongs to 
the general needs of the Internet standard process, which should go to the 
general framework and what is specific to which applications. From this to 
provision in the framework the links to specialised RFCs, to describe the 
requirement an RFC must match to adequately describe an application 
language tag, etc.

I submit that problems difficult to address in the current Draft way, 
result from a lack of underlaying framework, and oblige to the "SHOULD", 
"MUST", etc debate which should only be cases of a framework.

3. to discuss in detail the filtering solution, starting from the 
objective/target for each application (to the light of the framework and of 
possible legacies of _that_ application and of its own standardisers 
evolution strategy) to write the BPC 047 compliant RFC 3066 nth, for each 
application. Please remember RFC 1958 basic principle: but that principle 
everything in the Internet may change and solutions must keep this as 
normal possibility.

In the status of the current debate this means two (or more) documents, as 
described by the charter.

1. a BCP 047 replacement providing a language description framework, also 
supporting the much needed tag names and including the registry present 
yearly status.

2. an RFC 3066 bis documenting most of the areas of use of the present RFC 
3066 bis (HTML, XML, CLDR, etc.): tags, filters, use of the implicits,

3. on demand additional RFCs by members of this group or others groups 
documenting the use of language related information in LDAP, Java, MPEG, 
DNS, OPES, CRC, Internet Architecture, etc.

jfc




_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru