Paul Vixie wrote:
> i was there when SRV was conceived. we intended it to be used
> opportunistically, like MX before it, falling back to AAAA or even A
> queries if there was no SRV. it can be added to any protocol at any
> time, including HTTP/0.9 clients to the extent there are still any of
> those around. SRV's rules are defined for a service not by the client.
> if we decide that web servers can be reached by SRV records, then any
> web client can start looking for the SRV that describes that service,
> falling back to whatever tin-cups-and-string it did before if it can't
> find the SRV it wants.
A problem of SRV is that, purely within DNS, SRV is well defined
and fine, but within wider context, it is not.
For example, for browsers, as both SRV RRs and URLs can specify
port numbers, what if they specify different port numbers?
For another example for browsers, correspondences between
"service" of SRV and "proto" in URLs are not clear. Does
"proto" of "mailto" should use "service" name of "smtp"?
Maybe, it does, but correspondences are not straight forward.
Thus, it is not easy for browser developers, who do not have
much expertise in IETF process on DNS, to support SRV.
I have a proposal in:
http://tools.ietf.org/html/draft-ohta-urlsrv-00
on the problems.
Masataka Ohta
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
