Subject: RE: [Ltru] Too many ABNF issues (was: Proposal for -matching: "sc oredfiltering" > "scoring")

From: "McDonald, Ira" <[email-masked]>
Date: Wed, 22 Feb 2006 11:33:07 -0800

> -----Original Message-----
> From: Addison Phillips [mailto:[email-masked]]
>
> (snip)
>
> > We _really_ need closure, so that RFC3066bis can be published
> > one of these years - mere mortals don't get fast turnaround in
> > the RFC Editor queue these days.
> 
> The RFC Editor queue is a moot point--we are in the 3066bis 
> era *now*--but I
> agree that it would be *very* nice to get the document published
> once-and-for-all (ease of reference, if nothing else). OTOH, it is my
> observation that we "go faster" when we concentrate on doing 
> the right thing
> in favor of supporting whatever text happens to be in the 
> current draft.
> Fewer sour grapes that way too.

No, we are NOT in the RFC3066bis era now, even if the IANA Subtag
Registry was apparently functioning.  

I can't speak for W3C policies and procedures.

But I can authoritatively say that FSG (Free Standards Group)
and IEEE-ISTO PWG (Printer Working Groups) standards CANNOT
normatively reference unpublished RFCs, even if IESG-approved.
I know this from repeated personal experience in those bodies.

We need this RFC to published.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: John Cowan <[email-masked]>
Date: Wed, 22 Feb 2006 14:43:26 -0500

> Registry was apparently functioning.  

We are and we aren't.  Language (sub)tag approvals are in the RFC3066bis
regime.  For example, [email-masked] cannot now approve a tag
like en-thud, permitted by 3066 but forbidden by 3066bis.

Other specs, however, can't cite RFC3066bis until it gets a real RFC
number.  Consequently, 3066bis-valid tags like de-Latf can't be used in
XML or HTTP or other such contexts yet.

> We need this RFC to published.

Yes.  Which means we need to remove controversial bits (scoring) and 
find and fix editorial problems as fast as possible.

Is it still true that the two RFCs will be joint referents of the BCP
number 47?

-- 
                Si hoc legere scis, nimium eruditionis habes.

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Wed, 22 Feb 2006 16:06:03 -0500

> From: John Cowan [mailto:[email-masked]] 
> Sent: Wednesday, February 22, 2006 2:43 PM
> To: McDonald, Ira
> Cc: [email-masked]
> Subject: Re: [Ltru] Too many ABNF issues (was: Proposal for 
> -matching: "scoredfiltering" > "scoring")

[snip]

> Is it still true that the two RFCs will be joint referents of 
> the BCP number 47?

That's still my understanding of the chartered work.

-Scott-

---

From: Felix Sasaki <[email-masked]>
Date: Thu, 23 Feb 2006 15:12:36 +0900

> I can't speak for W3C policies and procedures.

I am working in the W3C Internationalization Activity, where we have
recommended in the past to other working groups the usage of
formulations like "RFC 3066 or its successor", if they want to cite an
RFC for language tags. Based on Addisons input we have started proposing
[BCP 47] instead, to avoid the reference to the "3066" number. (With
[BCP 47], no specs have to be updated.)
Unfortunately, the willingness to follow the new proposal depends on the
working group we are approaching. It will be *much easier* as the
matching draft is done ...

Regards,

Feli

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 23 Feb 2006 08:05:44 +0100

Scott Hollenbeck wrote:

>> Is it still true that the two RFCs will be joint referents
>> of the BCP number 47?

> That's still my understanding of the chartered work.

Same procedure as last time:  The set of folks wanting PS and
a clear split isn't empty.
                             Bye, Frank

---

From: "Tex Texin" <[email-masked]>
Date: Thu, 23 Feb 2006 00:31:55 -0800

Felix, do you have any feedback from the WGs you have approached that you
can share?

Is the "willingness to follow" mostly being influenced by the lack of the
matching draft or are there other concerns?

Tex

> From: Felix Sasaki
> I am working in the W3C Internationalization Activity, where 
> we have recommended in the past to other working groups the 
> usage of formulations like "RFC 3066 or its successor", if 
> they want to cite an RFC for language tags. Based on Addisons 
> input we have started proposing [BCP 47] instead, to avoid 
> the reference to the "3066" number. (With [BCP 47], no specs 
> have to be updated.) Unfortunately, the willingness to follow 
> the new proposal depends on the working group we are 
> approaching. It will be *much easier* as the matching draft 
> is done ...
> 
> Regards,
> 
> Feli

---

From: Felix Sasaki <[email-masked]>
Date: Thu, 23 Feb 2006 18:44:54 +0900

> Felix, do you have any feedback from the WGs you have approached that you

these were my personal impressions, so: no, I don't have feedback.

> matching draft or are there other concerns?

again this is my personal impression, but it seems that the problems
concerning normative references to RFC 3066bis hinder a discussion on
other concerns.

Felix

---

From: "Tex Texin" <[email-masked]>
Date: Thu, 23 Feb 2006 03:41:18 -0800

thanks Felix.

Tex Texin
Internationalization Architect,   Yahoo! Inc.

> From: Felix Sasaki [mailto:[email-masked]] 
> Sent: Thursday, February 23, 2006 1:45 AM
> To: Tex Texin
> Cc: [email-masked]
> > Felix, do you have any feedback from the WGs you have 
> approached that 
> > you can share?
> 
> > Is the "willingness to follow" mostly being influenced by 
> the lack of 
> > the matching draft or are there other concerns?
> 
> again this is my personal impression, but it seems that the 
> problems concerning normative references to RFC 3066bis 
> hinder a discussion on other concerns.
> 
> Felix
> 
> > 
> > Tex
> >

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Thu, 23 Feb 2006 07:12:34 -0500

> From: Frank Ellermann [mailto:[email-masked]] 
> Sent: Thursday, February 23, 2006 2:06 AM
> To: [email-masked]
> Subject: [Ltru] BCP vs. PS (was: Too many ABNF issues)
> 
> Scott Hollenbeck wrote:
> 

Then those folks should build consensus to update the charter appropriately.

-Scott-

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 23 Feb 2006 15:03:00 +0100

>> Same procedure as last time:  The set of folks wanting PS
>> and a clear split isn't empty.
 
> Then those folks should build consensus to update the charter

The charter doesn't mention BCP.  It only says that the first
document will likely update the structure of the 3066 registry
and its generative mechanisms.  As it did.

The charter also doesn't mention that the second (now third)
document has to be a BCP, it says:  "The first is a successor
to RFC 3066", not the second.

Ignoring formalities, "matching" appears to be over-the-wire,
interoperabilty and all, so why shouldn't it be on standards
track ?
                         Bye, Frank

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Thu, 23 Feb 2006 09:35:20 -0500

> Sent: Thursday, February 23, 2006 9:03 AM
> To: [email-masked]
> Subject: [Ltru] Re: BCP vs. PS
> 
> Scott Hollenbeck wrote:
> 

The IESG evaluation of the registry document, including evaluation of last
call comments received from outside the LTRU working group, concluded that
the words "successor to RFC 3066" meant "BCP replacement".  The matching
document got caught up in that because it is replacing existing text from
3066.

None of this should be news since I know we've talked about it before.  What
I'm suggesting in picking up this conversation (though I know think it's way
too late to be practical) is that any disagreement with the IESG's
interpretation of the charter could be cleared up by revising the charter.
If the group's intention was to produce something other than a two-document
replacement for BCP 47, that should have been articulated clearly when the
charter was first written and approved.  In the absence of such text
interpretation is left to the IESG when the IESG is asked to evaluate
documents for publication.  Of course, the IESG also has the right to change
suggested status even if the charter is clear, but it's much harder for the
IESG to do something counter to a charter that the IESG itself approved.

I agree that this isn't an optimal situation for getting the registry
document through the RFC Editor's queue.  However, the solution is simple:
get the matching document finished.  Your charter says that should have
happened 4 months ago.

-Scott-

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 23 Feb 2006 16:31:40 +0100

Scott Hollenbeck wrote:

> The IESG evaluation of the registry document, including
> evaluation of last call comments received from outside the
> LTRU working group, concluded that the words "successor to
> RFC 3066" meant "BCP replacement".

Yes, that's clear, and as there was no clear indication which
status the WG wants you were forced to pick either BCP or PS,
because there's no "dunno" series.  That sticked, and 3066bis,
the first document and sucessor to 3066, is or will be BCP 47.

> The matching document got caught up in that because it is
> replacing existing text from 3066.

Why should it be caught ?  The BCP vs. PS issue was seriously
discussed for the first document, apparently it's possible to
update / obsolete a BCP by a PS.

For the first part you decided BCP.  But I don't see why you
should be _forced_ to use BCP also for "matching".  Of course
the IESG is _free_ to do this, but not forced.  And the WG is
_free_ to propose PS without updating the charter.

> it's much harder for the IESG to do something counter to a
> charter that the IESG itself approved.

Not my plan to make it harder.  If the IESG insists on a BCP 47
with two documents let them.  I just don't like the concept of
one BCP with two documents, especially if the second document
is much more like normal "standards track" texts.

> I agree that this isn't an optimal situation for getting the
> registry document through the RFC Editor's queue.

Yes, that's too late, you said (quasi-) normative, although it
will be only informative, so now it blocks 3066bis.  Probably
it couldn't have been published faster with all those appeals.

My BCP vs. PS question is unrelated to the blocked 3066bis -
the approval was months ago, I missed the (quasi-) "normative"
in its text, sh*t happens.  Maybe the authors also missed it -
and if not, what could they do ?  Withdraw the approved text
under this condition is not very attractive.

> get the matching document finished.  Your charter says that
> should have happened 4 months ago.

Not "my" charter, I didn't see it before the WG existed.  I'd
pick less aggressive milestones, and I'd avoid dependencies
whereever possible - fortunately there's no "normative" USEAGE
anywhere in USEFOR - I'll try to get it removed from USEPRO ;-)

                          Bye, Frank

---

From: "Addison Phillips" <[email-masked]>
Date: Thu, 23 Feb 2006 08:31:02 -0800

I thought we had consensus in the WG for STD track. This is the first time
I've seen a claim that we'd actually have to change the charter to do that.
In the past, Randy and others have said we could make a consensus decision
to recommend STD and that this should do the trick.

Some of us argued that the linkage was wrong at draft-registry time. The
IESG didn't buy my (or other folk's) arguments and we find ourselves in this
nether world of waiting for draft-matching to be published as an RFC in
order to get 3066bis published. Which means that delaying draft-matching is
as good as blocking 3066bis.

I think the solution is quite simple:

1. Let's finish draft-matching. This removes the argument that we haven't
provided it. If we focus, we could do a last call soon (since the extraneous
junk is now Gone).
2. Let's petition as a WG for the IESG to make the document on the STD
track. 

Either way both documents get published. 

Addison

Addison Phillips
Internationalization Architect - Yahoo! Inc.

Internationalization is an architecture.
It is not a feature. 
> Sent: 2006?2?23? 7:32

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Thu, 23 Feb 2006 12:40:19 -0500

> Sent: Thursday, February 23, 2006 11:31 AM
> To: 'Frank Ellermann'; [email-masked]
> Subject: RE: [Ltru] Re: BCP vs. PS
> 

I just suggested the charter change thing in light of my other comments that
the ultimate decision about status rests with the IESG.  A working group can
make a recommendation, but the decision belonds to the IESG.  You can force
the issue by getting the IESG to agree to something at charter
creation/update time instead of waiting until document approval time.

> 2. Let's petition as a WG for the IESG to make the document on the STD

You can do that.  In fact, the status issue discussion can start now, and if
it gets resolved "soon" the block could be removed.

-Scott-

---

From: "Addison Phillips" <[email-masked]>
Date: Thu, 23 Feb 2006 10:07:48 -0800

> I just suggested the charter change thing in light of my other comments
> that the ultimate decision about status rests with the IESG.  A working
group
> can make a recommendation, but the decision belonds to the IESG.  You can
> force

Thanks for this clarification.

> You can do that.  In fact, the status issue discussion can start now, and
> if it gets resolved "soon" the block could be removed.

Then I, for one, am annoyed. 3066bis went into the Editor's queue last
November. We could be DONE with this discussion of document status by now
and even potentially holding our RFC number, instead of starting the
discussion now.

Look, I'm sick of waiting for the matching draft to finish too, so let's
just get it done... but this issue of BCP vs. PS is not at all novel and
I'm...er, surprised... by this particular option for unsticking the
machinery.

Co-chairs: if consensus exists for draft-matching to be a PS, could you
please initiate this discussion on behalf of the WG?

List members: I intend to submit my current -var3 today as draft-10. I would
like very much if we could do any necessary tweaking next week so as to get
to a WG Last Call. Finishing draft-matching will, among other things,
greatly improve our position in a discussion with the IESG, since they will
have something to look at. 

Addison

Addison Phillips

> From: Scott Hollenbeck [mailto:[email-masked]]
> Sent: 2006?2?23? 9:40
> To: 'Addison Phillips'; [email-masked]

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Thu, 23 Feb 2006 13:30:35 -0500

> Sent: Thursday, February 23, 2006 1:08 PM
> To: [email-masked]

[snip]

> please initiate this discussion on behalf of the WG?

You'll need more than just consensus.  You're also going to need to present
a compelling argument that introduces new information that wasn't available
when the IESG originally evaluated the document.  If all you do is come back
and say "we're asking again", you won't change any minds.

Keep in mind that this is the sticking point from the IESG's perspective:

3066 includes both registry practices AND normative text describing language
ranges.  Remember, the lack of 2119 imperatives does not mean that the text
in section 2.5 of 3066 is informative.

draft-ietf-ltru-registry obsoletes the bulk of 3066.
draft-ietf-ltru-matching is supposed to obsolete the rest (right?).  We
don't have a "partially obsoletes" concept in the RFC Series, so which rules
are to be used in between the time when draft-ietf-ltru-registry has been
approved and draft-ietf-ltru-matching is still being developed?  Has 3066
been completely obsoleted or not during this interim period?

Those are the kinds of issues you'll need to address.

-Scott-

---

From: "Addison Phillips" <[email-masked]>
Date: Thu, 23 Feb 2006 10:48:33 -0800

Thanks Scott. I know that's the case.

I would spend the time if I wanted to invest the time in preparing
arguments, which I don't. Hence, I'm asking them to do it. Frankly, I don't
care what form the matching draft takes, although I wish the IESG had okayed
the split "back when". *I* think the arguments are compelling, but I'm not
going to waste any more time or email on it. I'm going to finish matching.
Maybe even next week.

Addison

Addison Phillips

> Sent: 2006?2?23? 10:31

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Thu, 23 Feb 2006 13:51:07 -0500

> Sent: Thursday, February 23, 2006 1:49 PM
> To: 'Scott Hollenbeck'; [email-masked]

Finishing the matching draft is definitely the fastest way to make progress.
;-)

-Scott-

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 23 Feb 2006 11:21:57 -0800

Hi -

As a technical contributor, I'm not persuaded that the matching
document would make sense as a PS.  Here are my reasons:

  1) It's not a protocol.

      It doesn't specify how things would be required to look on
      the wire.  It only gives algorithms for matching, independent
      of how the language tags traveled over the wire.  Any details
      of how things travel on the wire, or how a negotiation procedes,
      or what happens if something does or does not match something
      else, belong in the specification citing the matching document,
      not in the matching document itself.
 
  2) Having it at the PS grade would create "downlevel" references.

      (Mature) Documents currently referencing the BCP would be put
      through procedural hoops to reference the PS.

  3) It's evolving, and it's not clear that the way in which it will evolve
       after implementation experience is compatibile with the kinds of
       changes permitted on a PS-DS-FS track; if it kept cycling at PS,
       see (2) above.  I hope it's stabler than recent discussion makes
       it look.  If we can't nail it down, then we should split it into the
       minimal match algorithms we know are already used, and publish
       that as part of the BCP.  Work on a generalization could then be
       done as informational, experimental, or update document.

Randy

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 23 Feb 2006 21:16:41 +0100

Scott Hollenbeck wrote:
 
> draft-ietf-ltru-matching is supposed to obsolete the rest
> (right?).

Yes, rest = 2.5, essentially one line of ABNF for the star,
and the prose for prefix matching.

> We don't have a "partially obsoletes" concept in the RFC
> Series

There's "updates" followed by "obsoletes" to finish off any
rest.  That would have resulted in a new BCP number for 3066bis
and later a dead BCP 47 when it's obsoleted by "matching".  Not
pretty.  As I was in the "PS for both" camp I didn't consider
this possibility.

> Those are the kinds of issues you'll need to address.

Sometimes standards pull this stunt, e.g. RfC 2821 contains
a "normative" reference to 821 _and_ proposes to obsolete 821.

For the "normative" detail (SEND, SAML, and SOML) it offers
"read RfC 821 if you like (and then forget it)" or similar.

But we didn't try this in 3066bis, so this point is moot.

                       Bye, Frank

---

From: John Cowan <[email-masked]>
Date: Thu, 23 Feb 2006 16:46:39 -0500

Randy Presuhn scripsit:
> document would make sense as a PS.  Here are my [three] reasons:

+1; +1; +1

-- 
Values of beeta will give rise to dom!          John Cowan
(5th/6th edition 'mv' said this if you tried    http://www.ccil.org/~cowan
to rename '.' or '..' entries; see              [email-masked]
http://cm.bell-labs.com/cm/cs/who/dmr/odd.html)

---

From: Mark Davis <[email-masked]>
Date: Thu, 23 Feb 2006 14:16:04 -0800

I agree with the two-pronged approach.

mark