Re: [Uri-review] Proposed scheme registration: sdns (DNS stamps)

Frank Denis <> Thu, 25 October 2018 14:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3DA3C130E6D for <>; Thu, 25 Oct 2018 07:00:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id n_0Zn3AQNrnF for <>; Thu, 25 Oct 2018 07:00:48 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 92363130E99 for <>; Thu, 25 Oct 2018 07:00:45 -0700 (PDT)
Received: from (localhost []) by (OpenSMTPD) with ESMTP id 20f29b7f; Thu, 25 Oct 2018 16:00:43 +0200 (CEST)
Received: from [] ( []) by (OpenSMTPD) with ESMTPSA id ac9a21ab (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO); Thu, 25 Oct 2018 16:00:43 +0200 (CEST)
From: Frank Denis <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_40B66E6D-B2CF-4596-AF1D-52D4F28E30DB"
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
Date: Thu, 25 Oct 2018 16:00:42 +0200
In-Reply-To: <>
To: Eric Johnson <>
References: <> <> <> <>
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: <>
Subject: Re: [Uri-review] Proposed scheme registration: sdns (DNS stamps)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proposed URI Schemes <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 25 Oct 2018 14:00:54 -0000

  Hi Eric,

> On 25 Oct 2018, at 02:49, Eric Johnson <> wrote:
> The previous comment about the "//" is correct. This is *not* a hierarchical scheme, so it should not have a "//". That is, "../foobar" is a meaningless relative URI to apply to the proposed sdns scheme.

  The `//` can be removed, then. Clients and libraries can be updated to handle both cases until all published sources are updated to the new format.

> Maybe I don't understand all the design parameters behind the original proposal?

  The main motivation behind the current scheme is to avoid requiring different encoding rules for individual parameters. This makes implementations easier, less bug-prone, and more secure.

  Having some components URL-encoded, other components hex-encoded, and other being binary flags, and characters such as `:` and `-` in your example acting both as separators and as valid characters within names/IP addresses can lead to broken parsers.

  The current scheme has only one way to encode parameters, no matter what their type is, can deal with binary data such as keys and signatures, is trivial to implement, and doesn’t require nested encoding systems.

  It also makes it more obvious to users about what exactly has to be copied/pasted from a list (where sdns URLs are mixed with human-readable descriptions) to a configuration file.

> If compatibility with existing tools is required, then there are multiple paths:
> - check for hierarchy use in existing implementions (sdns:// parsed differently from sdns:...)
> - register a under a new scheme, and phase out support for the existing sdns:// uses

  There will be a transition period, but `sdns://` <sdns://%60> and `sdns:` can be parsed differently.

  Thanks for your comments,