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 <[e-mail]>]

On Wed, Feb 25, 2015 at 9:16 AM, John C Klensin <[e-mail]> 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

_myservice._wks.example.com SRV 0 0 443 host1.example.net

https://host1.example.net/.well-known/myservice/


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