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
- Re: [art] Unichars / Modern Network Unicode / PRE… Rob Sayre
- [art] Unichars / Modern Network Unicode / PRECIS Rob Sayre
- Re: [art] Unichars / Modern Network Unicode / PRE… Peter Saint-Andre
- Re: [art] Unichars / Modern Network Unicode / PRE… John Levine
- Re: [art] Unichars / Modern Network Unicode / PRE… Steffen Nurpmeso
- Re: [art] Unichars / Modern Network Unicode / PRE… Paul Kyzivat
- Re: [art] Unichars / Modern Network Unicode / PRE… Martin Thomson
- Re: [art] Unichars / Modern Network Unicode / PRE… Rob Sayre
- Re: [art] Unichars / Modern Network Unicode / PRE… Rob Sayre
- Re: [art] Unichars / Modern Network Unicode / PRE… Martin Thomson
- Re: [art] Unichars / Modern Network Unicode / PRE… John C Klensin
- Re: [art] Unichars / Modern Network Unicode / PRE… Marc Petit-Huguenin
- Re: [art] Unichars / Modern Network Unicode / PRE… Claudio Allocchio