Re: [Uri-review] Request for review

Timothy Mcsweeney <> Wed, 27 May 2020 23:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 81C143A0DB0 for <>; Wed, 27 May 2020 16:42:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.795
X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id B0Y5ZftMSPCb for <>; Wed, 27 May 2020 16:42:38 -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 720143A0DAE for <>; Wed, 27 May 2020 16:42:38 -0700 (PDT)
Received: from ([]) by (mreueus004 []) with ESMTPSA (Nemesis) id 1MOAS5-1jOsC41rZJ-00OZle for <>; Thu, 28 May 2020 01:42:37 +0200
Date: Wed, 27 May 2020 19:42:35 -0400 (EDT)
From: Timothy Mcsweeney <>
Reply-To: Timothy Mcsweeney <>
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
Importance: Normal
X-Originating-Client: open-xchange-appsuite
X-Mailer: Open-Xchange Mailer v7.10.1-Rev31
X-Provags-ID: V03:K1:qeQVbjxTvpN+XCqooKoo/H3nJS1s+jbYomRJhQrdLccumi9xx/f A6yO+KZyHSunisAgsiVRHAcJ4NQ8tgQyZxWjvMNy/YxtDkbiFzwOsraJpnha7YvMS/Tf52b 3V/CXCi/dfID8Az2mmYNgVEpdHvCdYa+hQKIFeWF0J17Wpi7S9p9SX9vw9ayNL47sYWC3ZE dMwOmAf8bDHJOnuLnzNpA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:J4bxOCdi1MQ=:txGEKDEns3a9PxeOcbewN9 s9RAP4PO8mcrtbAhHjO1u58s2tiuvxktg+RUiryxhovMhq35XI1SwxNJloB1/lhNBJsSFUg1I YTSHQyACgmEEZCNlIA/nrubE8zxaP9Y4t56qh4eXg6Lv5sXHHjfgS21HmOc/ZNt4xKLixTsBQ aPufzG2vScG2x+cNDCDmH5bsi6bbSvPjY4f4dac/kwhcJJzsKotVm63HaqJgu0gkcgR1dgcH4 TIQ3d/K984oI0sIbz4cp7OmihmCUPrLBJCfQ38Xtan8CJXKxQ4gUO7eAjf7SZ89iqG58TCeUm oy6WnfrwYYeidkDKERNXiuYTR7tysQopvc2zduAGQdiNqQ012O/LT8yIpB2rm2XiTEOXp7tgS 8VpfKZDi8lBYADR+qLW3iVcdWf5kYowVLt8O3C32x98DHaMt8y5fCQsxTJxTVOZ3zrsqfSLlQ djuBbD9YJ3PpI+Yt99MhGvZqvHNat3Lv/pBjKxBFgdtPWU7k1zMQ/saAgGwuehUSsXYQCrJH5 be/2F5AFJDgpq2htBgdvL/9KDwwbV0eAnkg9lcRKOYV//qPeIRdK+Qn1YQb4V8kbYk7rxzjvv 6nD46P+oXWdUkqnsdPAWMJ6tzn8xepWGfwBwVVyJ/iYOYDZXnJjfsYXh+uU+cUEebi145UuDI 9XKPgl/9uQOG8MTgsZRM4quYSNga7gv73WYxNIuaiFeqiyrA8ulpzDo/s2me5uLYGKx140Eoa RTDBYuw7DdTPXqa9AJoWhAlCXX3vhw+Qm2tG4fUR3+L3L04B5tU7c25lh/wfSYt2/r4pM574V RcbmXsx7rqNwt1m/50huy6OxSTr/nFXXCt/Z+IlyYcjbcAtejMWfbyNE90Rd/fSD3ZJ9EUW
Archived-At: <>
Subject: Re: [Uri-review] Request for review
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: Wed, 27 May 2020 23:42:41 -0000

Just putting this conversation up here to show that Ted brought up some good points that I have fixed in the second draft.
On May 21, 2020 at 7:18 PM Timothy Mcsweeney <> wrote:

Hi Ted, 
I have a question for you.  In your last couple emails when you said the words "permanent identifier", did you mean:

the string always matches the same object forever
the string will always be an identifier for these particular types of objects
the string is disposable and there will never be another string like it again.

On May 20, 2020 at 6:42 PM Ted Hardie <> wrote:

On Tue, May 19, 2020 at 6:32 PM Timothy Mcsweeney <> wrote:
Thank you very much for the feedback. Would I be correct in deducing from your reply that if the 'drop' scheme remained a locator that you would recommend it remain a URI over a URN?

Because you can use the DDDS to get from a URN to the a retrieval
step, I'm not sure that's the critical property for me. I think for
me the difference is whether the drop-string is unique or not. As an
example, a URN with a NBN
through a resolver to identify a specific resource. In cases like
NBNs (or RFC numbers, for which there are also URNs), the number is
never reassigned; the issuer guarantees that the NBN will change if
the resource changes.

If you are constructing an identifier that is unique but will have
internal references which change (e.g. if the telephone number or
address associated with it change), you can still use a URN, but it
will be associated will be a meta-identifier for the collection of
changing versions. That's how vCard's CLIENTPIDMAP works, for
example. It sort-of sounds like drop-strings would be dereferenable
versions of this, via something like
CLIENTPIDMAP.well-known-domain.example. The usefulness of that gets
back to the question we discussed before,of whether these are mnemonic
or not; discovering the right drop-string to use becomes a major part
of the exercise.

In general, I think the vCard case might be a useful one for you to
spend some time with, because it may be easier to communicate what
drop-string will do if you relate it to an existing case.


Ted Hardie

Hi Tim,
On Tue, May 19, 2020 at 3:40 PM Timothy Mcsweeney <> wrote:
Hi Ted,
Thank you for taking the time to have a look at the draft. I had not considered the use of more than one domain. I will be sure to clarify that there will only be one second level domain used for http. Because I am limited to four flags in the DDDS, at this time I would say my intent would be the same as listed. You are probably right when saying that section will need a rewrite.
Your statement about the drop-string functioning as a permanent identifier with the current telephone number, address, or other contact methods being available as a retrieved resource is spot on but in my head it is a locator. I'm going to give that some more thought. Generally speaking, is this draft something that you would personally find appealing to use?
If this intended to be a permanent identifier and you intend to use the DDDS, I would suggest you consider either a URN or, if you want to look outside the IETF, at an implementation of the handle system, which is currently maintained by the DONA foundation. If you stick with a URN, the result would be a string like this:
Drop is the namespace identifier (NID) in this case. The issuer assigned that NID is the issuer of names-specific-strings and has to maintain certain guarantees related to uniqueness, which may or may not work for you depending on your application model. There is, however, already a specification for how to use the DDDS to retrieve URNs (RFC 3402) as well as some experience with S-NAPTR (RFC 3958), which may simplify your deployment.
Your question about whether or not I feel this would be appealing to use is a little hard to answer without knowing more about the construction of the resources it returns and the creation of the strings. If they are essentially random, the deployment model is hard to get going because the users are trading a series of mnemonic strings for an opaque one. vCards (RFC 6350), for example, can contain a UUID in URN form; this is unique, but not memorable. Systems can use it to confirm that a vCard is a new entry in a contacts database, but the URN UUIDs do not really replace any of the entries in the vCard in other contexts. If the strings are not random, then you get markets in the names, along with risks of squatting and so on. Even for the opaque strings there have been such markets (sales of mnemonic telephone numbers, for example, where either keypad mapping or repeating numbers are valued as easy to remember). Those markets (for domain names, twitter handles, and so on) tend to produce a lot of work in balancing the needs of those trying to maintain trademarks and those wishing to create new marks and identifiers.
Ted Hardie
On May 19, 2020 at 11:45 AM Ted Hardie <> wrote:
Hi Tim,
Thanks for the pointer to the draft. I think there are two issues here which are large enough that you may wish to think about the implied architecture. The first is a syntactic issue: the use of "#" as the only delimiter in the proposed URIs. As RFC 3986 describes it, the "#" delimiter is used for identifying fragments and is thus dependent on the MIME type of the retrieved object:
The fragment's format and resolution is therefore
dependent on the media type [RFC2046] of a potentially retrieved
representation, even though such a retrieval is only performed if the
URI is dereferenced.
This does not appear to match your usage. The usage you appear to be seeking is a transposition of the string to a subdomain of a well-known domain, so that a client can attempt retrieval via the three methods you enumerate; it is not clear from the document whether there will ever be more than one permitted domain here. A simpler implementation would appear to be drop:drop-string.well-known-domain.example.
Second, your document appears to imply that the drop string is used to augment existing telephone numbers and addresses, but it is not terribly clear how it does this. One interpretation might be that the drop-string functions as a permanent identifier with the current telephone number, address, or other contact methods being available as a retrieved resource. This section:
Primarily functioning as a locator there are three ways to get to a
'drop' URI resource, http, srv records, and private resolution for
anything not found using the previous two methods. The first, or
default, action is when an application invokes the 'drop' URI it will
cause a lookup for matching application information starting with an A
record [RFC1035], then on to Service records [RFC2782], and then on to
other available records that may offer a new rule set for resolution.
raises a problem with this approach: the records returned by SRV are fundamentally different, in that they are onward pointers to other domains and resolutions. If the implication is that HTTP is always used to retrieve drop records and the appropriate server is discovered by either using an A record, an SRV record, or private resolution, then this section needs a major re-write (to include AAAA records and to clarify the intent). It's also not clear what long lived utility a new scheme serves here if the result is always https://some-string.discovered-domain.example/" target="_blank" rel="noopener nofollow">https://some-string.discovered-domain.example/ .
If there were a different guarantee of uniqueness than the DNS, this would seem closer to a URN than other URI forms, or possibly an implementation of the handle system (as DOIs are). There is, unfortunately, not enough detail in the draft on the overall system to be confident of that.
Ted Hardie
On Mon, May 18, 2020 at 6:21 PM Timothy Mcsweeney <> wrote:
Hello everyone,
This is a request for a review of the 'drop' URI scheme. The draft can be found here <" rel="nofollow">" rel="noopener" target="_blank" data-mce-href=">">>. Thank you.
Tim McSweeney
Uri-review mailing list