Re: [Uri-review] Request for review

Ted Hardie <ted.ietf@gmail.com> Tue, 19 May 2020 15:46 UTC

Return-Path: <ted.ietf@gmail.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 B3BAB3A0863 for <uri-review@ietfa.amsl.com>; Tue, 19 May 2020 08:46:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.117
X-Spam-Level:
X-Spam-Status: No, score=-0.117 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_BL=1.979, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMcE8iSU04MJ for <uri-review@ietfa.amsl.com>; Tue, 19 May 2020 08:46:17 -0700 (PDT)
Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C8423A0783 for <uri-review@ietf.org>; Tue, 19 May 2020 08:46:17 -0700 (PDT)
Received: by mail-ot1-x329.google.com with SMTP id c3so11409699otr.12 for <uri-review@ietf.org>; Tue, 19 May 2020 08:46:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CLWPqXgEmRTYf7Wz3+xQAgJPUWURkd382w4Az6qfYe4=; b=OPFO1DAruY3YuvcdnQtCeCGsqjdNLK3td129/EK/cZiW0oi7RCzZAksEtD7SgOz8jw Dy5ui3DhhCGceXHk68hnVEu+qJqoGDit2rb2w4Gg81ecpC+q3Y0RyJ2xL6vdM/FJSD8w cVG22dNlRXMekdeOcs8WiHwb9NkD5RFOzcBLIvoGft17UrYFmVBeD5ujKKEO8d6tNQIF LzsLV8632vxrOaeQan6RUWdiwNQEqfPgkWgObQNF5yj+QpFM90TYNSsbE2bi7LKQsfIp s6iU17+s8zVkm3KNLyCmqIMl/G7f67Ix+YXM49k40jugbY9E9ywUvBRhPSgrPJgbB/Gz D7Lw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CLWPqXgEmRTYf7Wz3+xQAgJPUWURkd382w4Az6qfYe4=; b=BmwoF3RsNeFY7bfh9G3Oxs3yrEwhdK2kzRAY5v6BZXayduvT8l7/opZzD5X8D+CHh8 EOJxO6qbILmSYDCSJ7fiFSuJbPqwcwCqa2GAKr9QjLhAIXpGilyLSKfQRvqj6pXLW35v QHywQChKCIv+/6P760A7XQkJIj4Gy8MVcs050sFKqr4P7ZY4yN5EDbYeGfo6Pgq0Mq2v hKxzpJIrJDpLHZ0aDLf6sxY+8rWAgGh80cN92Uo4wVPwdUD6/aVX1QF/v7clc/Ub01y1 kUDpyjKc532wMmSZC5nEe2x93m4PlcQSLO7jWmh63p9Z8RPhZf43ddxc565qaYiIvMj8 KBHg==
X-Gm-Message-State: AOAM532WZBWLBnerFxEcfwO26SZYnhLwu2hBE+W7O/Ntq5cQTCtHNtKd ECzXq+jIwjFeGAQGY0iJheBKYJYd0IOoAJvYGTM=
X-Google-Smtp-Source: ABdhPJyEN4AE5vG5PiYJoamH+J5ZebpasimCxivrdxotAQ2jdn8LJGLTYuUEXiwruLcHZnD3DcmYSdHm/tgqAvlknBU=
X-Received: by 2002:a9d:544:: with SMTP id 62mr16629526otw.165.1589903176135; Tue, 19 May 2020 08:46:16 -0700 (PDT)
MIME-Version: 1.0
References: <491516506.246380.1589851279474@email.ionos.com>
In-Reply-To: <491516506.246380.1589851279474@email.ionos.com>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Tue, 19 May 2020 08:45:33 -0700
Message-ID: <CA+9kkMAdWj+qZA=3u_9vGG6KybHbk-vvj6LHfGakPTs4A7LoFg@mail.gmail.com>
To: Timothy Mcsweeney <tim@dropnumber.com>
Cc: uri-review@ietf.org
Content-Type: multipart/alternative; boundary="0000000000000a775c05a6022ea7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/uri-review/9PU8AkZd8H8Q65-7F4dgDjDDnT4>
Subject: Re: [Uri-review] Request for review
X-BeenThere: uri-review@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 19 May 2020 15:46:20 -0000

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 <tim@dropnumber.com>
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
> Uri-review@ietf.org
> https://www.ietf.org/mailman/listinfo/uri-review
>