I experimented with changing the rfc element's type attribute to 'bcp' with no effect on the content of the I-D xml2rfc generates. So let's skip it. 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 lists.ietf.org [mailto:ltru-bounces at lists.ietf.org] On > Behalf Of Randy Presuhn > Sent: 2005?5?11? 13:59 > To: LTRU Working Group > Subject: Re: [Ltru] Re: [psg.com #938] should introduction allude to > intendedbcp status? > > Hi - > > > From: "Addison Phillips" <addison.phillips at quest.com> > > To: "Randy Presuhn" <randy_presuhn at mindspring.com>; "LTRU Working Group" > <ltru at ietf.org> > > Sent: Wednesday, May 11, 2005 1:35 PM > > Subject: RE: [Ltru] Re: [psg.com #938] should introduction allude to > intendedbcp status? > > > > > There is no way that I know of to insert this value except by editing > the generated document by hand. > > It's not worth the effort. > > > I'm not sure that I would *want* to insert it. We allude only to RFC > status in the document. > > Surely RFC 3066's successor, whatever track the IESG puts it on, will > obsolete the current > > BCP 47 too. Debate about whether to pursue the STD track or not might be > interesting to > > have in this WG, but has no practical effect on the contents of the > document except for > > that one phrase, no? And in practice, the track the document follows has > no impact on > > what we put into it either. > > All true. That's why the comment is marked "rejected". As I wronte > earlier: > > > The abstract already (-01) states "This document obsoletes RFC 3066 > (which > > replaced RFC 1766)." That's the important part, which I believe > satisfies > > the heart of the comment. Whether this ultimately becomes a BCP or not > is > > up to the IESG; we as a WG will only make a recommendation. > > The BCP vs STD debate isn't really ours to have. We can make a > recommendation > when we pass it to the IESG, but the decision is theirs to make. Since > the technical > content is already out there as a BCP, I think we'd need a fairly > compelling argument > to ask for something else. In any case, I'd prefer to defer discussion of > BCP/STD > until all other issues are resolved, since it really doesn't impact the > content of the > document. > > Randy, ltru co-chair > > > > > _______________________________________________ > Ltru mailing list > Ltru at lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru at lists.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.