Message-Id: <6.2.1.2.2.20050618010305.041e2690@pop.online.fr>
Date: Sat, 18 Jun 2005 02:57:31 +0200
To: 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] review of the day.
Precedence: list
Sender: ltru-bounces@lists.ietf.org
Errors-To: ltru-bounces@lists.ietf.org

At 20:21 17/06/2005, Addison Phillips wrote:
>Oh Mighty Co-Chairs: dare I broach the subject of a Last Call and how we 
>reach that?

Before that there must be the debate on the WG-ltru Charter. I recall that 
I committed to produce my own Draft within 2 weeks after the end of that 
debate. I removed myself from the WG-ltru seeing that its would lead 
nowhere but to contention (as a remark of Addison on another list shown it) 
as long as we would not have discussed and agreed on a common and involved 
reading of the Charter.

NB. I submit from several face to face meetings and  from a substantial 
number of mail exchanges with members of this list and people waiting for 
the debate on the "thorny points of the Charter", there is _no_ observed 
consensus of the target of this WG. I submit that there is however the 
possibility to find an agreement between the two prevailing positions which 
are:

- to impose to the whole internet as BCP 47, the complex increase of rules 
of Draft 3066 bis, non ISO conformant (I quote positions over OSI 11179) 
non scalable solution (quotes a plenty)
- to fully permit that solution in its own area (XML/HTML/CLDR 
classification) through a dedicated RFC in line with fulfillment of the 
Charter requirements through a scalable simplification of RFC 3066, based 
upon the acquired experience, RFC 1958 guidelines and a correlation with 
the ISO equivalent works and registry extensibility doctrine.

At 01:56 16/06/2005, Randy Presuhn wrote
   RFC 3934 is clearly in terms of giving authority to working group chairs.
>In the case of ietf-languages@iana.org, there isn't a working group chair
>per se.  Thus RFC 3934 wouldn't be applicable unless we were to
>add language saying we wanted it to apply.  To make it work, we'd need
>to identify who, for purposes of that process, would fulfill the role normally
>taken on by a WG chair.

And by the AD.

At 15:49 17/06/2005, Doug Ewell wrote:
>Randy Presuhn <randy underscore presuhn at mindspring dot com> wrote:
> > As an observer of the ietf-languages@iana.org mailing list, it seems
> > to me that the registry draft might benefit from an explicit statement
> > about the applicability of RFC 3683 or some other means of maintaining
> > order on that mailing list.  Using RFC 3683 itself seems too
> > heavyweight, but RFC 3934 is formulated in terms of working groups.
> >
> > Separate from the language tag reviewer, would it make sense to
> > appoint the administrator of the ietf-languages@iana.org mailing list,
> > and to empower the administrator to fulfil the role of "WG chair"
> > *solely* for the purpose of carrying out the procedures of RFC 3934
> > for that mailing list?
> >
> > Would it make more sense to lift the appropriate paragraphs from 3934,
> > substituting phrases to fit the ietf-languages situation?
> >
> > Or should we just leave things as they are?
>
>The current administrator of that list has, of course, just exercised
>something comparable to RFC 3934, while acknowledging that it was a
>personal list-owner's right and not provided in RFC 3934.

The problem Harald faced was that I say that ietf-languages@alvestrand.no 
is not the mailing list documented by RFC 3066, is not operated by IANA, 
does not benefit from the exposure of a IANA list, does not respect the RFC 
3066 procedure, a place full of ad hominems (*) and foul language. At the 
occasion of a specific problem and of its implications, he saw that my 
support was gaining momentum. To stop me his only solution was to confirm 
my position; acknowledging that this list was a personal list, where the 
RFC 3934 procedure is not respected, and appeals ignored.

I will not appeal to IESG/IAB but I will use this to document that:
1. the ietf-languages@iana.org isto be a IANA organized and chaired list to 
help the Examiner(s) chosen by IESG
2. the rules of the IANA/IETF/ICANN MoU apply to it - including appeal to 
the IESG and IAB
3. reach out of that list benefits from the adequate exposure on the IANA site.

(*) ad hominems show that this list is not an IETF list:
On 14:52 17/06/2005, Brian E Carpenter said:
>>I thought that ad hominem attacks were considered unacceptable on this list?
>On any IETF list, actually. It's best all round if people remain
>professional and polite, however strong the disagreement.


>It might not be a bad idea to include a short statement to the effect
>that the list administrator has authority to maintain order, and lift an
>appropriate passage, or maybe a reference to RFC 3934 together with a
>clarification that it is expressly being applied to a non-WG list.

Its administrator is the IANA. The IANA is to decide the rules.

At 22:01 17/06/2005, Frank Ellermann wrote:
>No problem if the list owner wants it, but it's tricky:  Who
>appoints the moderator, what if the list owner doesn't agree,
>where's the appeal and recall procedure, can the tag reviewer
>also be the moderator, etc. ad nauseam.

ad nauseam seems to be a true characterisation.
The capacity to remove the Chair must also be granted.

<quote MoU>
4.5. ... For protocols within the IETF scope (i.e., registries created by 
IETF action), appeals against such denials may be made to the IESG and 
subsequently to the IAB as provided in 4.2 above.
</quote>

I take this occasion to recall to the Chair  of this WG the subsequent part 
of the agreement:

<quote>
4.6. The IANA shall have non-voting liaison seats on appropriate IETF 
committees as determined by the IETF, and may participate in all IETF 
discussions concerning technical requirements for protocol parameter 
assignment through such liaisons.
4.7. The IANA shall review all documents in IETF Last Call to identify any 
issues of concern to the IANA, and shall raise these issues with the IESG.
</quote>
At the end of the day this means Doug Barton participating to the work of 
this WG. I suggested several time it was the role of the Chairs to discuss 
with him if we could not speed up the process in inviting him.
,
>Maybe it's simpler to solve these problems generally for all
>review lists, add them to the general area and let the Chair
>pro forma appoint the list owner as listmom.

No. This situation is ruled by RFC 2860.

>Randy's plan B "Or should we just leave things as they are?" is attractive.

No. Because I am going to use my "banning from a IANA list exercised by a 
private person without the protection of RFC 3934 rules nor the appeal 
capacity of RFC 2860" to oppose the Draft 3066 bis.

The propositions I made above are probably good enough.

>There can be conflict only for old libraries using new applications. But 
>the old libraries do not support the new features. So if I want to use the 
>new features I need the new libaries.
>
>I have another way to address the need: to register in the applications 
>registry one tag per language and per comment: 7500 * comment nr. With ISO 
>639-6 20.000 * comment nr. This may quickly make billions of entries. All 
>this just to stay compatible with a non used experimental format?
>F. Charles.

You do not necessarily need to do that. I suggest you use the x-tags format 
x-6aaaabbb.

- x-6 is a prefix for ISO 639-6 codes.
- aaaa is an ISO 639-6 cod
- bbb is a comment code. You can register nearly 40000 of them (that anyone 
car read in his own langage)
- aaaa being a concept, you can use bbb as container of the associate 
values by a referent following an ISO 11179 logic: this way you can link 
many many things, while keeping your page crispy.

This way you stay conform to the old experimental RFC 1776 they want to 
respect - even if this Draft passed you are all correct.

jfc




_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru