Re: [art] Unichars / Modern Network Unicode / PRECIS

On Wed, 20 Mar 2024, John C Klensin wrote:

> --On Wednesday, March 20, 2024 12:33 -0400 John Levine
> <johnl@taugh.com> wrote:
>
>> It appears that Martin Thomson  <mt@lowentropy.net> said:
>>> On Wed, Mar 20, 2024, at 11:17, Paul Kyzivat wrote:
>>>> Postel's law is often the wise thing to do.
>>>
>>> Consider me successfully invoked: RFC 9413 says all that
>>> needs to be said on this topic.  But to summarize: the
>>> robustness principle is not wise, merely expedient.
>>
>> My understanding is that Postel said you should be liberal
>> *when the spec is ambiguous.* He didn't say you should work
>> around broken implementations, although a lot of people seem
>> to believe that he did.
>
> FWIW, that ("in case of ambiguity" and not "tolerate brokenness
> and stupidity") is certainly what I heard in multiple
> conversations with him on the subject.

Broken implementations are broken implementations and are not because of 
"ambiguity in the specification", they are just wrong.

The issue is that it happens de facto that when a broken implementaion 
goes out in the real world, it starts to make damages. I asked myself many 
time "can we do technically something so that we can 'block', 'impede the 
broken implementation to work', so that the ones who put it out there 
(nowadays very often commencial vendors) have to fix it because it just 
does not work itself?". It applies the same for imp[ementations not 
following openess, interoperability etc.; can we block them from hijacking 
protocols, but vuolating other principles? Unluckily not easy, maybe 
impossible... but never forget this as a principle. We cannot stop 
stupidity (or just ignorance in reading a specification) but trying to 
limit damages to all the rest... yes. But... how?

> He also invoked a variation on the principle as an argument
> against our getting bogged down in our work by deciding we
> needed to consider every possible unlikely and obscure case and
> then overspecifying what should be done were they to ever arise.
> That was obviously a delicate balance a quarter-century ago and
> remains so.  Given how long it seems to take the IETF these days
> to get specifications from rough agreement about all the
> important issues, including text that is recognized as close to
> done, to deciding we are actually finished and ready to publish,
> it is not clear to me that we have the balance right... and,
> whether it is blamed on Jon or not, perhaps we should be more
> explicitly revisiting that set of tradeoffs rather than, e.g.,
> attacking slogans.

+1

>
> best,
>   john
>
> _______________________________________________
> art mailing list
> art@ietf.org
> https://www.ietf.org/mailman/listinfo/art
>

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          Claudio.Allocchio@garr.it
                        Senior Manager and Advisor
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

      PGP Key: https://www.cert.garr.it/servizi/informazioni-su-pgp-keys