Re: (long/architectural version) Last Call: <draft-faltstrom-uri-10.txt> (The Uniform Resource Identifier (URI) DNS Resource Record) to Proposed Standard

Phillip Hallam-Baker <> Sat, 28 February 2015 01:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D3C411A1B27 for <>; Fri, 27 Feb 2015 17:36:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6rbSFM2hXawd for <>; Fri, 27 Feb 2015 17:36:36 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ABE851A1B37 for <>; Fri, 27 Feb 2015 17:36:35 -0800 (PST)
Received: by lbiz11 with SMTP id z11so20577507lbi.5 for <>; Fri, 27 Feb 2015 17:36:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=+yuw21wDFD+iU9xzsLLksNhZ/Tk1XFrbvg2MAW7wl/8=; b=wkbUTD6n2xCItcb0TV7ub9FVV6bG5EQbTGxhBiSOoDX9rLDuGm+4Ewpw12ke4sfNZg 4wXTFLJrShSwJ3qM3KJpvjrBI6TRF2TolwO/Tf8uDSyblNVxadbObB5PiE8fb1+ykJM2 tVNH8BhASf2yOHRnJ5eYlK1DLv7WaKGXyCXLjXolMFPSlwOhDmPwEMjh+YaV2chGB2dP OAw44QQV+nzpWOPqeb4ksGRRvN0EMIb0/nPUN9ka78L4z1ulyMN7toSROHIy6qRVW8gU d4R8upvG7M17R+L80fxEABmUb74yzhW7x7xtPtpGJ5Q9az4M6ZEJUH85mLy6jCSNhqE9 ulOw==
MIME-Version: 1.0
X-Received: by with SMTP id ti2mr15355768lbb.124.1425087394081; Fri, 27 Feb 2015 17:36:34 -0800 (PST)
Received: by with HTTP; Fri, 27 Feb 2015 17:36:34 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Sat, 28 Feb 2015 01:36:34 +0000
X-Google-Sender-Auth: _mggcAsPcb5VB0pyZ2RXfyBqvsw
Message-ID: <>
Subject: Re: (long/architectural version) Last Call: <draft-faltstrom-uri-10.txt> (The Uniform Resource Identifier (URI) DNS Resource Record) to Proposed Standard
From: Phillip Hallam-Baker <>
To: John C Klensin <>
Content-Type: multipart/alternative; boundary=047d7b3a8690e5f47105101c03fe
Archived-At: <>
Cc: =?UTF-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= <>, IETF Discussion Mailing List <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 28 Feb 2015 01:36:38 -0000

On Wed, Feb 25, 2015 at 9:16 AM, John C Klensin <> wrote:

> Hi.
> Speaking of U-NAPTR, this is either a replacement or it isn't.
> "Can be viewed" in Section 8 is unsatisfactory in a
> standards-track document.  If it is a replacement, then this
> document should update RFC 4848 to deprecate that record type
> and mechanism.  If it isn't, then this document should explain
> when to use which one.

No, it is an alternative. And we need an alternative.

I do not like the NAPTR proposal. I have never liked it and would like to
deprecate it as historic because I find it confused and overly complex.

In my view, NAPTR breaks a core architectural principle that DNS text
labels have no structure. I find the matching rules to be a hack and not a
nice one.

But under the new RR allocation scheme, we are merely proposing new
records, not deleting old ones.

> (3) The state of DDDS and further complicating NAPTR
> I may have missed important and widely-deployed applications,
> but my impression is that DDDS, and the original NAPTR record
> format, have not been one of IETF's great success stories, at
> least outside of the ENUM space for which NAPTR was first
> designed.  While I usually believe in general solutions, more
> complexity is both an opportunity for sloppy implementations and
> potential attack vectors waiting to be discovered and exploited.

Again, I agree with this, but I don't see the relationship to URI.

This is because URI is trying to solve a problem that NAPTR has never been
a solution for. Even if the authors thought differently.

ENUM is arguably an area where cruft was needed. But at this point the only
thing to do with the telephone system is plan for a graceful termination of
service along with the telegram and telex. Any technology required by enum
should be limited to enum.

Especially against that backdrop, it is troubling that, while
> the title, abstract, and introduction to this document are about
> adding a URI-specific DNS RRTYPE, Section 5 provides an update
> to the NAPTR spec itself that modifies and extended that spec.
> It does not explain why that modification is desirable and why
> this new RRTYPE does not simply replace NAPTR for relevant uses,
> nor does it make recommendations as to when one or the other
> should be used.

No, it is defining a Web Service discovery mechanism that allows the
location of the Web Service end point to be specified.

But is it really necessary?

We could use SRV and the existing .well-known services registry. All we
need to do is to define a default SRV prefix. So if the .well-known label
is 'myservice' we would use something like SRV 0 0 443

All we are getting from URI is the ability to point the web service
endpoint at any place in the Web site.