In message <537af637.2030...@necom830.hpcl.titech.ac.jp>, Masataka Ohta writes:
> 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.

We left this for being done on a case by case basis for good reasons
some of which you enumerate above.  I don't think anything has
changed in the intervening 15 years to make doing this generically
work.

What we missed out on doing was going back and doing the case by
case analysis of the existing protocols.  Doing this on a individual
basis may end up saying the same thing multiple times but that is
fine.  Browser/proxy vendors will see the commonality.

Mark

>                                               Masataka Ohta
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: ma...@isc.org

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to