On Wed, Feb 25, 2015 at 9:16 AM, John C Klensin <john-ietf@xxxxxxx> 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
All we are getting from URI is the ability to point the web service endpoint at any place in the Web site.