Doug wrote: > Debbie Garside <debbie at ictmarketing dot co dot uk> wrote: > > >> Similarly, it is possible to imagine software looking > fruitlessly for > >> a language subtag 'True' that is the macrolanguage of 'ar' > instead of > >> remembering that 'True' is a special case. > > > > Not if it is programmed correctly :-) > > Check the ISO 639-6 data (I can't). Is there any 4-letter > code element with value 'true'? Can you guarantee there > won't be one in the future? > Can you guarantee that Registry consumers who read this in > draft-4646bis, Section 2.1: I have to admit it took me a while to figure out the ref to 639-6 but you are absolutely right, there is no saying that an alpha4 won't be used within a Macrolangauge field in the future. Good catch! > > I would sack them without hesitation ;-) > > I'm pretty sure you're kidding, but we've seen Michael get > attacked on this list and ietf-languages for human errors > such as this. I am :-) But perhaps in bad taste... forgetting the history. > > Now come, come, this is not the GNSO GA forum you know! > > One LTRU member, who has since left the WG, used the term > "process failure" to describe the addition of new region > subtags AC, CP, DG, and so forth. While the IESG might not > take this seriously, the objections can become pretty > disconcerting. The "removal or replacement" bit is from RFC > 4646 and the current draft. I see your point... being quite reasonable people ourselves we sometimes forget that there are unreasonable people out there :-) Best Debbie > -----Original Message----- > From: Doug Ewell [mailto:doug at ewellic.org] > Sent: 11 May 2008 03:04 > To: LTRU Working Group > Cc: Debbie Garside > Subject: Re: [Ltru] I'm really confused by chinese in 3066bis > > Debbie Garside <debbie at ictmarketing dot co dot uk> wrote: > > >> Similarly, it is possible to imagine software looking > fruitlessly for > >> a language subtag 'True' that is the macrolanguage of 'ar' > instead of > >> remembering that 'True' is a special case. > > > > Not if it is programmed correctly :-) > > Check the ISO 639-6 data (I can't). Is there any 4-letter > code element with value 'true'? Can you guarantee there > won't be one in the future? > Can you guarantee that Registry consumers who read this in > draft-4646bis, Section 2.1: > > "At all times, the tags and their subtags, including private > use and extensions, are to be treated as case insensitive: > there exist conventions for the capitalization of some of the > subtags, but these MUST NOT be taken to carry meaning." > > will still be careful to distinguish 'true' from 'True'? > > >> Suppose your friendly team of Designated Experts, presented with a > >> new batch of several dozen ISO 639-3 changes including a new > >> classification of macrolanguage 'qma' with encompassed languages > >> 'qea' and 'qeb', remembers to put "Macrolanguage: qma" on > the records > >> for 'qea' and 'qeb' but forgets to put "Macrolanguage: > True" on the > >> record for 'qma'. > > > > I would sack them without hesitation ;-) > > I'm pretty sure you're kidding, but we've seen Michael get > attacked on this list and ietf-languages for human errors > such as this. > > >> Suppose further that the ietf-languages list didn't catch > this during > >> the 1-week review. We would end up with an internal inconsistency > >> within the Registry. Gosh, your friendly Experts would hate that. > >> They would also hate the inevitable e-mail flames about "process > >> failure" and the possibility of removal or replacement at > the IESG's > >> discretion. > > > > Now come, come, this is not the GNSO GA forum you know! > > One LTRU member, who has since left the WG, used the term > "process failure" to describe the addition of new region > subtags AC, CP, DG, and so forth. While the IESG might not > take this seriously, the objections can become pretty > disconcerting. The "removal or replacement" bit is from RFC > 4646 and the current draft. > > -- > Doug Ewell * Arvada, Colorado, USA * RFC 4645 * UTN #14 > http://www.ewellic.org > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages ^ > > > > > _______________________________________________ Ltru mailing list Ltru at ietf.org https://www.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.