[Suit] URIs, IRIs and CRIs in SUIT manifests

Christian Amsüss <christian@amsuess.com> Thu, 21 March 2024 00:36 UTC

Return-Path: <christian@amsuess.com>
X-Original-To: suit@ietfa.amsl.com
Delivered-To: suit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 725B0C14F60F for <suit@ietfa.amsl.com>; Wed, 20 Mar 2024 17:36:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.606
X-Spam-Level:
X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 AmlAPyOKfmjb for <suit@ietfa.amsl.com>; Wed, 20 Mar 2024 17:36:24 -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 6FFF9C14F6F0 for <suit@ietf.org>; Wed, 20 Mar 2024 17:36:21 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by smtp.akis.at (8.17.2/8.17.2) with ESMTPS id 42L0aJaG033507 (version=TLSv1.2 cipher=ECDHE-ECDSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <suit@ietf.org>; Thu, 21 Mar 2024 01:36:19 +0100 (CET) (envelope-from christian@amsuess.com)
X-Authentication-Warning: smtp.akis.at: Host 095129206250.cust.akis.net [95.129.206.250] claimed to be poseidon-mailhub.amsuess.com
Received: from poseidon-mailbox.amsuess.com (hermes.lan [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 359A435F65 for <suit@ietf.org>; Thu, 21 Mar 2024 01:36:19 +0100 (CET)
Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:f25a:3064:ea03:bc4d]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 4FFBF3260E for <suit@ietf.org>; Thu, 21 Mar 2024 01:36:18 +0100 (CET)
Received: (nullmailer pid 10629 invoked by uid 1000); Thu, 21 Mar 2024 00:36:17 -0000
Date: Thu, 21 Mar 2024 10:36:17 +1000
From: Christian Amsüss <christian@amsuess.com>
To: suit@ietf.org
Message-ID: <ZfuBASaA95MKAMm2@hephaistos.amsuess.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="rsGADakyZlhSuDR6"
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.86
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/VcG90MbJuus71TFU531AiHgbfuA>
Subject: [Suit] URIs, IRIs and CRIs in SUIT manifests
X-BeenThere: suit@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Software Updates for Internet of Things <suit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/suit>, <mailto:suit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/suit/>
List-Post: <mailto:suit@ietf.org>
List-Help: <mailto:suit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/suit>, <mailto:suit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Mar 2024 00:36:28 -0000

Hello Brendan, SUIT,

todays's meeting had the question of URI references vs. IRI references
in the manifest.

(and now Dave has chimed in advocating for URIs on the protocol level
due to specification trouble with IRIs, and his point is valid, so maybe
it is better to just stick with URIs).


From a specification PoV, I'm OK with either. URIs are a bit easier to
use in a deterministic form, but references are not expected to be
compared anyway, only resolved.

From an internationalization PoV, both URIs and IRIs allow non-ASCII URI
components -- it's just that the IRI form is human readable (and more
compact by a factor of 3 for the non-ASCII parts).

From an implementation PoV, frankly I can't tell what is supported
better: the URI processors I have encountered in embedded space are
often so limited that I'd expect handling errors in non-ASCII URIs no
matter whether they are encoded as URIs or IRIs.

The easiest to process on an embedded device would be CRIs[1] -- but
that so far has little implementation base, and is only due for
completion in May. It has advantages on the compactness side, and UTF-8
is transported without any percent encoding.

BR
Christian

[1]: https://datatracker.ietf.org/doc/html/draft-ietf-core-href

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