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

John C Klensin <john-ietf@jck.com> Wed, 20 March 2024 19:45 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: art@ietfa.amsl.com
Delivered-To: art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09546C14F6FA for <art@ietfa.amsl.com>; Wed, 20 Mar 2024 12:45:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qeV723jqam6 for <art@ietfa.amsl.com>; Wed, 20 Mar 2024 12:45:38 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65840C14F616 for <art@ietf.org>; Wed, 20 Mar 2024 12:45:38 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1rn1sT-0004fL-V4; Wed, 20 Mar 2024 15:45:33 -0400
Date: Wed, 20 Mar 2024 15:45:28 -0400
From: John C Klensin <john-ietf@jck.com>
To: John Levine <johnl@taugh.com>, art@ietf.org
cc: mt@lowentropy.net
Message-ID: <10B8BA5F26A5C1DBBB823B08@PSB>
In-Reply-To: <20240320163345.3D88C85CC546@ary.qy>
References: <20240320163345.3D88C85CC546@ary.qy>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/G_f2VZFpHspYaDTQKGivkK_BBdE>
Subject: Re: [art] Unichars / Modern Network Unicode / PRECIS
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Mar 2024 19:45:39 -0000


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

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.

best,
   john