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

Re: [Ltru] Re: [psg.com #1026] what to do about Guernsey and Jersey



Hi -

Instead of a bunch of rhetorical questions, how about fleshing
out a specific counter-proposal, if you think the current proposal
is so intolerably bad?

> From: "Frank Ellermann" <nobody at xyzzy.claranet.de>
> To: <ltru at ietf.org>
> Sent: Saturday, June 11, 2005 9:12 PM
> Subject: [Ltru] Re: [psg.com #1026] what to do about Guernsey and Jersey
>

> Randy Presuhn wrote:
>
> > Let's finish this thing.
>
> What do you _expect_ if the 831 + 832 problem showed up after
> date-B ?  Or the hypothetical new 888 ?  Wait for ISO 3166-1
> codes how long, forever ?  That's what the draft -04 says now.
>
> Or just list 831 + 832 because they came before date-B, and in
> the case of 833 we're absolutely sure that it's old.  Does it
> block a possible future GG + JE ?  Does it also block a future
> IM ?  Apparently that's what the draft -04 says.
>
> We really should get this right, and IMHO we can get it right
> today (2005-06-12 GMT).  And I really like to hear what you'd
> _expect_ in these cases.

As long as the algorithms and registry data produce a single
result for the question "how do I tag language X in its Jersey
variety", I really don't care whether the resulting string
contains dashes and digits or letters and in what proportion.

> On the new (private) "IETF golden rules" list they have it as
> the principle of the least surprise.  I know it as "is there a
> high astonishment factor ?" plus "then don't implement it".

Prior to this WG I thought Guernsey was a kind of cow, and
Jersey was near New York City.  I'd still be astonished
if my web browsey offered either for a language preference.  :-)
Seriously, if it did, I still wouldn't care whether the resulting tags
were alpha, numeric, or mixed.

Randy




_______________________________________________
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.