On Wed, Feb 25, 2015 at 9:16 AM, John C Klensin <john-ietf(_at_)jck(_dot_)com>
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.