Re: [core] [Cbor] CBOR Tag 38 (in draft-ietf-core-problem-details)

Christian Amsüss <christian@amsuess.com> Thu, 19 May 2022 11:26 UTC

Return-Path: <christian@amsuess.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A31A8C15E3E1; Thu, 19 May 2022 04:26:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 zM_BlXPDr-yh; Thu, 19 May 2022 04:26:02 -0700 (PDT)
Received: from smtp.akis.at (smtp.akis.at [IPv6:2a02:b18:500:a515::f455]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44AC9C159492; Thu, 19 May 2022 04:25:59 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com ([IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by smtp.akis.at (8.17.1/8.17.1) with ESMTPS id 24JBPsAk010805 (version=TLSv1.2 cipher=ECDHE-ECDSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 May 2022 13:25:55 +0200 (CEST) (envelope-from christian@amsuess.com)
X-Authentication-Warning: smtp.akis.at: Host [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd] claimed to be poseidon-mailhub.amsuess.com
Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 508FE6294; Thu, 19 May 2022 13:25:54 +0200 (CEST)
Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:6af7:d8f9:ffcb:a3ef]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 0D584A13B; Thu, 19 May 2022 13:25:54 +0200 (CEST)
Received: (nullmailer pid 3630114 invoked by uid 1000); Thu, 19 May 2022 11:25:53 -0000
Date: Thu, 19 May 2022 13:25:53 +0200
From: Christian Amsüss <christian@amsuess.com>
To: Carsten Bormann <cabo@tzi.org>
Cc: cbor@ietf.org, core@ietf.org
Message-ID: <YoYpQQPkH0T+1kls@hephaistos.amsuess.com>
References: <E7B9C8A6-81CC-452E-98CE-421CC37B98DD@tzi.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="1atGbw+h2iuzVMyC"
Content-Disposition: inline
In-Reply-To: <E7B9C8A6-81CC-452E-98CE-421CC37B98DD@tzi.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/t8qdzyjD90jQvxYHEGnhfKdtKeQ>
Subject: Re: [core] [Cbor] CBOR Tag 38 (in draft-ietf-core-problem-details)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 May 2022 11:26:04 -0000

Hello Carsten,

picking up points from the interim meeting:

On Wed, May 11, 2022 at 02:17:15PM +0200, Carsten Bormann wrote:
> Oh, and while you read the W3C documents, please note that neither the
> existing tag 38 nor the various proposals to fix/complement it solve
> delimiting embedded runs; this would be getting a bit closer to
> creating a little markup language though.

Not doing anything markup-language-ish could guide our choice on
explicit vs. implicit null: As long as we don't have context, there's
nowhere to "inherit" the direction from yet, so true/false/null should
suffice as options.

The question of "do we need more extensibility" also came up:

I don't think we have to set up a registry here; when anyone defines how
boustrophedon or top-to-bottom-then-right-to-left interact with what is
now still called *bi*directional rendering, there'd just be a new
document that updates problem-details and thus has IANA change the
reference again. My heuristic here is that I wouldn't know what to check
for as an expert, let alone give guidance to the reviewing expert, so it
can be done in a document update just as well.

By the way, I know now how I erred when I noted that Hebrew did not
usually need a direction tag; I confused the direction with the script
type of the language (sub)tags, where the Hebr script is suppressed for
he (and explicit script), and only languages such as Azerbaijani
commonly get one.

BR
c

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom