[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Ltru] Re: [psg.com #938] should introduction allude to intendedbcp status?



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.