[Ltru] Re: Review of 4646bis-10, sections 3.5 to App. B

John Cowan wrote:

>>| IANA MUST
>> I consider a "MUST" while talking with IANA as rude.

> What, after they just botched updating the File-Date
> record?  Give me a break.

<br class="for-john" clear="all" />  Do you think they
will be more careful when we're rude in 4646bis ?

Don't try this approach with me, it would backfire ;-)

>> Can we please at least consider that neither IANA 
>> nor expert are idiots ?

> Idiots, no; prone to careless mistakes, definitely.
> People are not protocol engines.

Full metal jacket, they're also not Marines following orders.

>>> /There is always a choice/, which is much nearer the truth.
>> It's "almost always" then.  

> Can you think of a counterexample?  (Hint: It requires a
> language with no language distinctions, script distinctions,
> or variant distinctions.)

Yes, I had i-default in mind, but noting why I think that
there is no choice by definition would be an essay.  And
I was too lazy to check if any other i-whatever is left
(= not deprecated).

>> BTW, I vaguely recall that we didn't want chains:
> You didn't want them, you mean.  Everyone else had no
> trouble with them.

Maybe.  It's a plausible source of unnecessary trouble,
see "prone to careless mistakes" above, that also hits
implementors and other registry users.

>> Is that an attempt to kill the 4( ALPHA ) reservation ?
> Of course not.  It means that under *this* (future) RFC
> there won't be any.  BCP 47 can always be revised by 
> issuing a new RFC.

Good.  A pointless statement apparently, of course it's
not possible to modify a published RFC 4646bis, why do we
tell IANA this ?  IANA is familiar with the concept "RFC".

 Frank

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