Re: [Ltru] draft-davis-t-langtag-ext

["Phillips, Addison" <[e-mail]>]

There is no such thing as a "private extension". The whole point of the extension mechanism is public use.

We provide private use subtags for private use.

Addison

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Debbie Garside
> Sent: Friday, July 08, 2011 9:09 AM
> To: 'Doug Ewell'; [e-mail]
> Subject: Re: [Ltru] draft-davis-t-langtag-ext
> 
> Also, if my memory serves me correct, the responsibility for maintaining
> extension data was designed for private extensions not this type of extension
> where there is a more public use.
> 
> Debbie
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Debbie Garside
> Sent: 08 July 2011 16:14
> To: 'Doug Ewell'; [e-mail]
> Subject: Re: [Ltru] draft-davis-t-langtag-ext
> 
> Thanks for the explanations Doug
> 
> Yes, it all seems terribly fractured which is another reason for keeping it within
> IETF.
> 
> Best wishes
> 
> Debbie
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Doug
> Ewell
> Sent: 08 July 2011 15:55
> To: [e-mail]
> Subject: Re: [Ltru] draft-davis-t-langtag-ext
> 
> Debbie Garside <debbie at ictmarketing dot co dot uk> wrote:
> 
> > But I still don't see why it needs to be taken out of IETF.  Where is
> > the added value?  Where are discussions held?  Why create another list
> > when we already have IETF-languages?
> > ...
> > I really need to be shown the added value of outsourcing this work. I
> > am open to being persuaded.
> 
> Actually, the responsibility for maintaining extension data has always been
> delegated, ever since RFC 4646 introduced the extension mechanism.
> 
> A draft that proposes a new extension, such as the one under discussion,
> defines the maintaining or registering authority for that extension.  In theory
> this could be the ietf-languages list itself, but the membership of that list, taken
> as a whole, has historically been less than eager to embrace the extension
> concept.  Usually, proposing an extension implies that one is assuming
> responsibility for its maintenance, including setting up a mailing list for
> discussion.
> 
> The CLDR folks were ultimately responsible for proposing both RFC 6067 (the -
> u- extension) and the present draft, and it is natural that they assume
> responsibility for maintaining it.  I'm not worried about that.
> I do have concerns that we neglected, in 4646 and 5646, to require that the
> maintaining authority be open or have a transparent process, or that the
> "registry" of extension data (paragraph 3) not be spread out across multiple
> documents in different formats, including algorithms and prose descriptions,
> omissions which are exploited (both IMHO) by 6067 and by the present draft.
> 
> --
> Doug Ewell | Thornton, Colorado, USA | RFC 5645, 4645, UTN #14
> www.ewellic.org | www.facebook.com/doug.ewell | @DougEwell ­
> 
> 
> _______________________________________________
> Ltru mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ltru
> 
> 
> _______________________________________________
> Ltru mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ltru
> 
> 
> _______________________________________________
> Ltru mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ltru