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: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of Debbie Garside
Sent: 08 July 2011 16:14
To: 'Doug Ewell'; ltru@ietf.org
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: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of Doug Ewell
Sent: 08 July 2011 15:55
To: ltru@ietf.org
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
Ltru@ietf.org
https://www.ietf.org/mailman/listinfo/ltru

_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www.ietf.org/mailman/listinfo/ltru