Message-Id: <6.1.2.0.2.20050412213834.0556d7f0@pop.online.fr>
Date: Tue, 12 Apr 2005 21:38:49 +0200
To: "ltru Working Group" <ltru@ietf.org>
From: Jefsey Morfin <jefsey@online.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: 
Subject: [Ltru] IANA update trough RFC
Precedence: list
Sender: ltru-bounces@lists.ietf.org
Errors-To: ltru-bounces@lists.ietf.org

from a recent qui pro quo with Michael Everson resulted in an idea which 
may have some worth. I suggested Michael to come in here to jointly support 
the idea, also with his experience. I regret he refused because I think the 
idea interesting.

We are discussing of first version of the "registry" to be loaded by the 
IANA and we experiment delays up to 6 months by the IANA. We also need to 
find a dissemination way which does not drain to much on the Internet 
public common resources. We have not discussed some of the Charter 
questions the idea, IMHO, could make easier to address.

The idea use the present IETF WG and to transfer it under the Chairmanship 
of Michael (IESG assigned reviewer(s)) once the RFC published.

- the WG-LTRU would be permanent
- it would issue a yearly RFC which would be the language registry (the 
format to discuss)
- this RFC would follow a Draft which would be updated every month by the WG.
- the reference to the RFC would give the yearly reference.
- the standard IETF (AD, Chairs, Charter, Last Calls,etc) Internet standard 
process would apply.

A Draft is valid for 6 months. Drafts have a well established track. This 
would both match the IANA delay (6 months) and is acceptable as a normative 
document because this is a BCP (which describes a de facto practice). This 
would leave full control of the IESG over the evolution of the registry 
through the yearly review of the WG Charter and would permit to keep the 
format updated to the various applications demands. It would permit a 
permanent cooperation with other Application Area propositions/WGs (like OPES).

The interest is also that an RFC includes the Security, IANA, etc 
consideration parts, permitting to easily document/maintain these aspects 
and is covered by the ISOC/IETF Intellectual Property Rights. Another 
advantage is that this would make langtags a standard IETF process without 
special procedures. The Internet standard process considers the case of 
lack of network expertise in a specialized WG and the assistance to provide 
to its Chairs.

The load on IANA should be very reduced, due to the permitted stability of 
the RFC process, numerous replication servers, habit of developers, etc. 
This would certainly encourage the proposition of value added services on 
top of the yearly RFC/Draft publication. The addition of language names in 
different languages could then easily result from additional BPC.

jfc




_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru