Subject: [Ltru] review of the day.

From: r&d afrac <[email-masked]>
Date: Sat, 18 Jun 2005 11:03:20 +0200

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 to 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. If that debate was not to occur I 
would have to start a private WG on the issue and to inform the IESG of the 
reasons why. I would prefer not.

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 targets 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, which is a non ISO conformant (I quote the positions 
over OSI 11179) and non scalable solution (quotes a plenty)
- to fully permit (and even extend) that solution in its own area 
(XML/HTML/CLDR classification) through a dedicated RFC based upon the two 
current draft specialised parts. To fulfill 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 (ISO 639-3-4-5-6) and registry extensibility doctrine (ISO 11179) as 
per ISO 639-6 (as indicated by Debbie Garside).

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 [email-masked], 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 [email-masked] 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 [email-masked] 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 I say that [email-masked] is not 
the mailing list documented by RFC 3066, is not operated by the IANA, does 
not benefit from the exposure of a IANA list, does not respect the RFC 3066 
procedures, is an ad hominems (*) and foul language place. At the occasion 
of a specific problem and of the legitimate debate on its implications 
(relation of the registry with other industry/ISO/MPEG registry) denied by 
the IESG designated Examiner, he saw that my support was gaining momentum. 
To stop this his only solution was to confirm my evaluation. He 
acknowledged 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 (a private list is a privae list) but I will 
use this published (and list members' accepted, cf. above) position to 
document near tha IESG, IAB and IANA that:

1. the [email-masked] 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.
But anyone in this position must be in the same position as the ISO MA. His 
name and address must be indicated. Appeals procedures documented. Process 
must be go by the rules not by fear of "pissing off" a collaborator.

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.

I would suggest not: 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 we are discussing at AFRAC.

- 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 name for 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 18 Jun 2005 23:42:18 +0200

r&d afrac wrote: [...]

See <http://article.gmane.org/gmane.ietf.ltru:2313:raw> for
the timestamp lines of your original article.  This dupe is
2312, so it arrived before 2313.  The "megatron" server is
an odd beast at weekends, not the first time that I saw it.

> there must be the debate on the WG-ltru Charter

The charter is TTBOMK debated before the creation of a WG,
then there's a "BoF" or a similar ritual (maybe they also
"hum" or drum or whistle or sing), and an IETF WG pops up,
complete with charter and chair(s).

 From there it's love it or leave it, excl. "re-charter" or
"disband" for the moment.  Better check the details, but
I'm almost sure that you confuse something important here.

> I recall that I committed to produce my own Draft within
> 2 weeks after the end of that debate.

IIRC you said something about April.  If you've submitted
your draft I missed it, in that case please post a pointer.

> I removed myself from the WG-ltru

That does not exactly match my recollection, you used to
call it "enjoying my vacation".

> start a private WG on the issue and to inform the IESG of
> the reasons why. I would prefer not.

IMHO that's strictly your business.  You're of course free
to invite the IESG to any private WG.  OTOH they are forced
to watch many official WGs, so I don't see your point here.

> No. This situation is ruled by RFC 2860.

Okay, that makes sense.  So your proposal is to keep RfC 2860
as normative reference, let Addison hit me because I proposed
to remove it, and be done with it ?

> 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

That "private person", as you put it, is among other things the
list owner, the author of RfC 1766, the author of 3066, and the
former Chair until a few weeks ago.  And he used the RfC 3934
rules in this case exactly for the reason you quoted:

>> On any IETF list, actually. It's best all round if people
>> remain professional and polite, however strong the
>> disagreement.

You could test the RfC 3934 and 2860 procedure for this case.

> conform to the old experimental RFC 1776

Typo, s/1776/1766/
1766 was a normal standards track RfC, obsoleted by RfC 3066
(BCP 47) later, check out <http://purl.net/net/rfc/1766>

                           Bye, Frank

---

From: r&d afrac <[email-masked]>
Date: Sun, 19 Jun 2005 01:04:40 +0200

>an odd beast at weekends, not the first time that I saw it.

This is because I mailed it as Jefsey. And remailed it as rd@afrac. When I 
wanted to delete the first one Moderator had already approved it. Apologies.

>I'm almost sure that you confuse something important here.

You confuse two debates. The IESG debate I contributed to positively. The 
first thing a WG should do, in common opinion (see debate on ietf@ietf on 
the matter) is first to have a common understanding of the Charter. This WG 
has not done this yet and there is no consensus on the reading of the 
Charter. Randy promised this debate once the Draft would be completed.

Disagreeing on the way to properly address the Charter, and having observed 
that the difference are fundamental, I have no real interest in this WG 
until it discusses what the Charter means.

>your draft I missed it, in that case please post a pointer.

I said "mid-April" because a WG usually starts in discussing what it is 
going to do. When I saw that this WG was not proceeding by the usual book, 
I said I would produce a Draft 15 days after the end of the debate over the 
Charter (if there still was a difference of vision between Addison/Mark and 
me). I see no reason why that debate would not lead to a consensus. Randy 
leads the show. We can only comment his ways from the quality of the final 
deliverable. Not yet.

>call it "enjoying my vacation".

Yes. These imposed vacations shown me there were low chances that the 
current trend would correct itself and that my pushing, outside of an open 
debate to understand what the Charter means, could not help. So I decided 
to wait that debate.

>to watch many official WGs, so I don't see your point here.

The point is that if there are two supported conflicting Drafts on the same 
matter, this will only delay both.

I do not mind the delay since I am interested in an ISO 11179 consistent 
approach that ISO 639-6 will provide, and that ISO 639-4 will determine a 
few things about ISO 639-3 and -6. The proper sequence is to get ISO 639-3 
as SIL's list accepted (in removing from the project the parts which 
belongs to ISO 639-4). So W3C and Unicode people can have their 
classification now.

Then to have the Draft 3066 tuned to match this situation, in removing its 
desire to replace BCP 47. To have IS0 639-4 finalised and including the 
responses we need. To have  ISO 639-6 finalised as ISO 11179 consistent 
(this what Debbie Garside, says). To check that consistency and to write a 
BCP 47 Internet framework fully compliant with all the ISO 639 parts, with 
all the issues concerning ISO 15924 and ISO 3166 being addressed (they are 
built in ISO 639-4).

I think everyone here would agree that it is a correct scenario, consistent 
with the ISO plan (and therefore with my reading of the Charter?).

Obviously we can go faster in simplifying RFC 3066, trusting the ISO 
process (with some warranties if they are too slow). This will address most 
of the concerns of IESG in the way IESG want: consistency with ISO. If the 
Draft, which rebuilds the world instead of patching an XML need,is 
advanced, I will probably do that.

>to remove it, and be done with it ?

I am not sure what you mean by "let Addison hit me". I just submit that 
IANA mailing lists are managed by the IANA under RFC 2860 and that if there 
are lacks in RFC 2860 they have to be addressed in RFC 2860 bis. I have 
suggested some points to Brian Carpenter, based upon the experience of the 
application of RFC 3066 and others, he said he retained them (main ietf 
list). I suggest you ask him to add our concerns to his wish list. These 
points (RFC 3934 and removal of Chair and Examiners) seem important enough. 
I think that there should be a Committee, gathering people (4 or 5) from 
various origins (geogr. area, entities), selected by the NomCom for a 
period of one year.

>former Chair until a few weeks ago.

Good for him, but I do not see what has to do. Anyway IETF goes by the 
rule, not by the persons.

The flaw is that he is the list owner. This only means a CIO when he was 
IESG Chair. I hope he did not initially accept the Draft as an AD?
All I see is that he was embarrassed to the point of wanting to claim being 
the owner of a "IANA list".

>  And he used the RfC 3934 rules in this case exactly for the reason you 
> quoted.

(a) he did not respect RFC 3934 and this is why he had to claim the list is 
private. I think I understand some of his reasons.
(b) I am not sure which reason I quoted you refer to. In claiming the list 
private he only confirmed my reasons against the way the list is organised.

>You could test the RfC 3934 and 2860 procedure for this case.

I have nothing to "test". The fact that RFC 3934 and 2860 are not enforced 
show the list is private. Harald confirmed it.
(a) RFC 3934 and 2860 do not apply
(b) there is no RFC 3066 [email-masked] list in operation as per 
RFC 3066. The Draft must make sure this situation is corrected. RFC 2860 
bis is to set up rules to make sure this kind of private holding of a IANA 
list and related privileges cannot happen again.

I have nothing more to add to this.
jfc

PS. you claimed you filtered a mail of mine. This is too bad: I suggested 
you to contact the people of the DIN over ISO 639, 3166, 15924 issues. I am 
sure they could provide you with information and be interested in your 
inputs and in your reading of Peter's text and Addison's and Mark's draft 
which are quoted in the ISO propositions.

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 19 Jun 2005 04:30:54 +0200

r&d afrac wrote:

> This is because I mailed it as Jefsey. And remailed it as
> rd@afrac. When I wanted to delete the first one Moderator
> had already approved it.

I'm not sure that it's "moderation" (Usenet-style), it could
be one of these obscure "megatron" glitches.  Or it's related
to your "vacation".  Randy's job is more like (Fidonet-style)
"retro-moderation", send a private or public warning, and if
that doesn't work block.  I'm guessing here, but "moderating"
individual articles would be a strange way to do it.

Unless it's about false-positive-spam or accepting articles
from unsubscribed sources.  I watch this because I expected
problems, that's why GMaNe has LTRU as a non-public list only
for subscribed members.

> Apologies.

No problem, so far I avoided any "vacation", but I certainly
caught some warnings over the years.  It's difficult for all
parties, and it gets fast out of hand if Murphy or "megatron"
add their random contributions.

> The first thing a WG should do, in common opinion (see
> debate on ietf@ietf on the matter) is first to have a common
> understanding of the Charter. This WG has not done this yet

That's your position.  You said it more than once, and now I
looked at the charter again...

<http://www.ietf.org/html.charters/ltru-charter.html>

...and I still think we're on track. 3066 has several problems
and we fixed them.  We're supposed to add scripts, and we did.

We're not forced to like the idea, and in fact I'm no big fan
of it, but we carefully avoided havoc with the Suppress-Script
concept, solved the problem of too many 693-3 extlangs, and got
it in a shape where Bruce cannot fault us for ignoring MIME.

And we checked especially the most perverse tag under the most
perverse condition, RfC 2231/2047 for pc-multilingual-850+euro.
It's my local charset, I was interested to get it right.

Finally we also found a solution for the funny region codes,
we go with the source standards a far as possible, or in other
words until ISO 3166-1 reycles alpha-2 country codes.  And for
that case we have an emergency exit.

It's _much_ better than the old draft-10.  Minus one round of
final nitpicking it's ready.  Run it through the "idnits" tool,
the W3C spell checker, Bill's XML validator (after adding the
important <?rfc strict="yes" ?>), maybe the ABNF checker again,
and mark the third milestone as "done" on the WG charter page.

> there is no consensus on the reading of the Charter.

That's your position.  For my reading of the charter see above.

> Randy promised this debate once the Draft would be completed.

Discussing the work plan after the work is done would be odd.

> I have no real interest in this WG until it discusses what
> the Charter means.

Yes, as I said, love it or leave it.  I was more interested to
avoid the havoc of the old draft-10, and IMHO the result is now
presentable.  I'm even confident that I could answer each and
every question about MIME-compatibility.  I've forwarded one
technical question to USEFOR, and they can certainly solve it:
<http://mid.gmane.org/[email-masked]>

  [private WG]
>> I don't see your point here.
> The point is that if there are two supported conflicting
> Drafts on the same matter, this will only delay both.

With the IESG you never know, some days ago somebody announced
to publish technically incompatible drafts simultaneously.  If
it wouldn't be both unethical and unprofessional it would be
ridiculous.

But your idea to block a draft by publishing your own does not
fly:  First you'd have to submit it a.s.a.p., and then LTRU is
a WG, so they'd tell you to discuss it here (if it's about the
language tag registry).

> I am interested in an ISO 11179 consistent approach that ISO
> 639-6 will provide, and that ISO 639-4 will determine a few
> things about ISO 639-3 and -6.

ISO 639-6 and 639-4 don't exist yet, I'm not sure what 11179
is, we prepared anything as far as possible for ISO 639-3, and
waiting for vaporware is not "engineering".

> So W3C and Unicode people can have their classification now.

The Unicode consortium is interested in funny 3066bis language
tags ?  Sometimes when you talk about UN, OECD, ITU-T, and what
else I think you overestimate the relevance of the IETF and its
language tags.  It will be more than one decade until the last
3066-application dies, billions of documents will never use a
language tag, other billions use 3066 tags, and it will take
some time before 3066bis is more relevant than say DC.

> removing its desire to replace BCP 47

That's something you should really discuss with Brian, I never
got an answer when I asked here why 3066bis can't return to
the normal standards track.  [ But I forwarded an info from
Carl Malamud to Addison how "intended status BCP" could be
done with xml2rfc. ]

This "BCP" and "experimental" stuff is apparently an easy way
to bypass community review.  But Brian proposed "two-step", so
you might run into a wall there.

> (this what Debbie Garside, says)

I've never heard her say "wait for 639-6".  IIRC Randy asked
whether waiting for 639-3 could be a good idea, but a majority
didn't want to wait.  We have reserved 4ALPHA for ISO 639-6.

> trusting the ISO process

When I have my doubts about the IETF process it doesn't mean
that I trust ISO more.  Only the IETF can fix RfC 3066 / BCP 47
- it's their (= in theory "our") document.

> which rebuilds the world instead of patching an XML need

See ?  There's no "rebuilding the world" here, we're talking
about simple language tags and a somewhat inadequate RfC 3066.

> I am not sure what you mean by "let Addison hit me".

It was a joke, because I wanted to get rid of this obscure Mou
with IANA in the normative references, 2860 is "informational".

 [Brian]
> I suggest you ask him to add our concerns to his wish list.

Thanks, but if I'd discuss anything with him it would be about
publishing conflicting "experimental" drafts, and it would be
because the 2026 "process failure" clause wants me to try this.

> Anyway IETF goes by the rule, not by the persons.

In theory.  In practice the best you'll get is that they try
it, and the worst is that they pretend it.  Everywhere.

> (b) I am not sure which reason I quoted you refer to.

Brian's opinion about "ad hominem", you quoted it as (*) note.

> PS. you claimed you filtered a mail of mine.

-v please, I've no idea what you're talking about.

> I suggested you to contact the people of the DIN over ISO
> 639, 3166, 15924 issues.

Yeah, I still have it, if that's what you mean (2005-03-21):
<[email-masked]>

I only filter "courtesy copies", i.e. mails also sent to the
list don't hit my folder "inbox" but "devnull".  That doesn't
stop me to read it there, but I read the list as a newsgroup
on GMaNe, and that's also where I post replies.    Bye, Frank