Subject: RE: [Ltru] Re: [psg.com #1135] IETF/LC something other than BCP?

From: "Addison Phillips" <[email-masked]>
Date: Wed, 21 Sep 2005 08:54:37 -0700

+1 in general, but...

I'm.... confused.

Are you recommending that draft-registry be published as a BCP but not "Obsoletes: 3066" until the matching draft is in some advanced state? Or are you recommending that draft-registry be published as BCP and immediately Obsoletes: 3066, with the matching draft to follow?

If the former, wouldn't we have a potentially long interregnum period where both registries are operated (to the confusion of everyone)? If so, I again note the example I cited in the Last Call of RFC 3282 (both it and RFC 3066 obsolete 1766, but on different days and for different purposes).

Addison

Addison P. Phillips
Globalization Architect, Quest Software
Chair, W3C Internationalization Core Working Group

Internationalization is not a feature.
It is an architecture. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Randy Presuhn
> Sent: Wednesday, September 21, 2005 12:07 AM
> To: LTRU Working Group
> Subject: [Ltru] Re: [psg.com #1135] IETF/LC something other than BCP?
> 
> Hi -
> 
> After carefully reviewing the extensive postings on the question
> of how to procede with the registry draft and the initial registry,
> here is how I'd like to procede, followed by a brief rationale for
> this recommendation.
> 
> Modulo the edits already agreed:
> 
> On the initial registry, I think there is rough consensus to:
>    1) recommend publication as an Informational RFC
>    2) add a note to the RFC editor at the beginning of
>       section 3, requesting that the rest of that section
>       be deleted, and replaced with a note saying where the
>       current registry is to be found (or a pointer to
>       the registry RFC, which in turn says where the registry is)
> 
> On the registry document, I do not see a clear consensus, so my own
> judgment colors this proposed recommendation to the IESG:
>    1) recommend publication as BCP
>    2) obsoletes 3066.  The pain with splitting out the matching
>       stuff is similar with what we've gone through with RFC 1213
>       being exploded into a zillion pieces.  If it's necessary
>       to hold publication until the matching document is ready, I think
>       that's a worthwhile tradeoff to avoid any ambiguity that
>       would result from an "Updates 3066".
> 
> Looking ahead, I believe we are where we always were with respect
> to the matching document:
>    1) recommending Proposed Standard when it is ready.
>    2) obsoletes 3066.  (see above)
> 
> Brief rationale:
> Several alternatives were presented, each with pros and cons.
> Ultimately, I found the arguments unpersuasive that this document
> could, at least in part, be considered a protocol specification.
> Though the BCP designation is a bit of a catch-all, it still
> appears to be the best fit, is in keeping with what we were
> instructed to produce, and would result in the least disruption
> when specifications that currently reference 3066 or 1766 are updated,
> particularly in view of the pains the WG has taken to maintain
> syntactic compatibility.
> 
> When one looks at the specifications that reference 1766 and 3066,
> for example RFC 2640 or 2070, they often provide their own
> ABNF or other description of language tag syntax in that protocol.
> We've already decided to move matching into a separate, standards-track
> document.  Negotiation is clearly application protocol specific, and
> is not covered by either the registry or matching drafts.  Consequently,
> when I look at the references to the predecessor specifications,
> I'm left with a clear sense that what's being referenced is not a
> protocol specification, but rather the registry description, which,in
> order to describe registry operation, had to spell out some syntactic
> constraints.  Now I'm not claiming that I've been able to review every
> reference everywhere, but I've seen enough to be reasonably confident
> of a pattern.  I conclude that the document is a registry document, and
> that the syntax specification is for the operation of the registry,
> and does not constitute a protocol specification any more than any other
> formal registry specification would.
> 
> Now, I'm not going to ask whether we're all happy with this recommendation,
> but is this at least something we can live with, recognizing that the IESG
> will probably have its own views as well?
> 
> Randy, ltru co-chair
> 
> 
> 
> 
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ltru

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 21 Sep 2005 10:17:00 -0700

Hi -

> From: "Addison Phillips" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>; "LTRU Working Group" <[email-masked]>
> Sent: Wednesday, September 21, 2005 8:54 AM
> Subject: RE: [Ltru] Re: [psg.com #1135] IETF/LC something other than BCP?
>

> +1 in general, but...
>
> I'm.... confused.
>
> Are you recommending that draft-registry be published as a BCP but not
> "Obsoletes: 3066" until the matching draft is in some advanced state?

No.

> Or are you recommending that draft-registry be published as BCP and
> immediately Obsoletes: 3066, with the matching draft to follow?

Not exactly.
If the IESG would accept this, this would be my preference.

Otherwise, I believe it would be acceptable to defer publication
of the BCP until the matching draft was a Proposed Standard.
It's slated to be done in October, and there is currently only one
open issue on that document.  If folks think there is more work
to be done there (and I suspect there is) they'd better start working
on it.  (In a different thread.)

> If the former, wouldn't we have a potentially long interregnum period
> where both registries are operated (to the confusion of everyone)?

That's why I would NOT make such a recommendation.
That is why I consider it important to make it totally clear that
3066 is Obsoleted, and not merely Updated.

> If so, I again note the example I cited in the Last Call of RFC 3282
> (both it and RFC 3066 obsolete 1766, but on different days and for
> different purposes).
...

This supports my preference for "Obsoletes: 3066" on publication.
This is issue #1134 in https://rt.psg.com/ (user/password "ietf")

Randy