Re: [Uri-review] URI scheme for postal addresses?

Christian Amsüss <christian@amsuess.com> Wed, 26 July 2023 21:38 UTC

Return-Path: <christian@amsuess.com>
X-Original-To: uri-review@ietfa.amsl.com
Delivered-To: uri-review@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13925C169528 for <uri-review@ietfa.amsl.com>; Wed, 26 Jul 2023 14:38:09 -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 N9HZ_NYAy0Hr for <uri-review@ietfa.amsl.com>; Wed, 26 Jul 2023 14:38:04 -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 8E89EC14CEF9 for <uri-review@ietf.org>; Wed, 26 Jul 2023 14:38:03 -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 36QLc1lK078391 (version=TLSv1.2 cipher=ECDHE-ECDSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 26 Jul 2023 23:38:01 +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.lan [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id ED9A525F6E; Wed, 26 Jul 2023 23:38:00 +0200 (CEST)
Received: from hephaistos.amsuess.com (hephaistos.lan [IPv6:2a02:b18:c13b:8010::32b]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id A3E7426758; Wed, 26 Jul 2023 23:38:00 +0200 (CEST)
Received: (nullmailer pid 12914 invoked by uid 1000); Wed, 26 Jul 2023 21:38:00 -0000
Date: Wed, 26 Jul 2023 23:38:00 +0200
From: Christian Amsüss <christian@amsuess.com>
To: Nicholas Humfrey <nicholas.humfrey@bbc.co.uk>
Cc: "uri-review@ietf.org" <uri-review@ietf.org>
Message-ID: <ZMGSOBxd406ER+hm@hephaistos.amsuess.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="3yrRr6hfPY0aw7rd"
Content-Disposition: inline
In-Reply-To: <DU2PR01MB8112C169AA2A3412F6E0F3FEC000A@DU2PR01MB8112.eurprd01.prod.exchangelabs.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/uri-review/G2e6JNgTzZXfszGwagz_xxSws3o>
Subject: Re: [Uri-review] URI scheme for postal addresses?
X-BeenThere: uri-review@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Proposed URI Schemes <uri-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uri-review>, <mailto:uri-review-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uri-review/>
List-Post: <mailto:uri-review@ietf.org>
List-Help: <mailto:uri-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Jul 2023 21:38:09 -0000

Hello Nicholas,

(hoping this is not in conflict with the liaison manegement topic Eliot
has started)

While the format is URI compliant in the sense that its ABNF describes a
subset of the strings the URI ABNF allows (unless I missed something),
it will behave quite weirdly when used as a URI. In particular, URI
normalization will turn upper case letters in the third segment into
lower case letters if the first two segments are empty. (I'm also told
that common but non-conformant implementations of URI processors will
turn integers in the third segment into IPv4 addresses if the first two
segments are empty, but I personally don't care about those).

The case normalizations would be highly unexpected by users (to whom the
third segment has no special meaning). To avoid such issues, I'd suggest
that an empty first segment should be disallowed; the corresponding ABNF
would be:

    addressdata = segment-nz *("/" segment)
    segment-nz = 1*urlchar

Best Regards
Christian

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