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

Re: [Ltru] I'm really confused by chinese in 3066bis



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.