>> I also feel from this discussion, we are all roughly on the same >> page. We want SRV as the long term solution ... > > except that we heard at the side meeting in Montreal (albeit from > browser people rather than content people) that they *don't* want > SRV, because it has fields that are not compatible with the web > security model.
Can you summarize the particulars of the web security model (I'm not sufficiently well versed in that area to immediately key off that phrase) which makes use of SRV non-attractive? Is the aspect that a URL can contain a port number part of the problem, or is it something (a lot?) more involved? When defining the use of SRV for the web protocols (something which remains to be done), one could of course standardize "ignore the port number in the SRV record, use the port number from the URL, or whatever http and https defaults to", especially if that makes the problem go away. > I still want to define a new RR that does have mutually agreed > semantics that's specifically for use by HTTP(s), but so far no > takers. SRV is widely supported today in provisioning frontends, name servers and resolvers. Defining a new RR which is SRV-like is going to seriously prolong the "time to useful deployment". Regards, - Håvard _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
