+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: ltru-bounces at ietf.org [mailto:ltru-bounces at ietf.org] 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 > Ltru at ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru at ietf.org https://www1.ietf.org/mailman/listinfo/ltru
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.