To bring this dead horse back to life... What I said in Montreal is SRV works great if you are a robot, but when humans are involved it never ends well.
I do like where Mr. Finch is taking this discussion. I also don't see the issue with online signing, but that is just me. Tim On Thu, Sep 27, 2018 at 7:27 AM Havard Eidnes <h...@uninett.no> wrote: > >> 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 >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
