Re: [Uri-review] Request for review

[Ted Hardie <[e-mail]>]

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
<https://tools.ietf.org/html/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/
.

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.

regards,

Ted Hardie


On Mon, May 18, 2020 at 6:21 PM Timothy Mcsweeney <[e-mail]>
wrote:

> Hello everyone,
>
> This is a request for a review of the 'drop' URI scheme.  The draft can be
> found here < https://datatracker.ietf.org/doc/draft-mcsweeney-drop-scheme/>gt;.
> Thank you.
>
> Sincerely,
> Tim McSweeney
> _______________________________________________
> Uri-review mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uri-review
>