Re: [Http-srv] Alternative to SRV?

> On 22 Aug 2018, at 10:44 am, Martin Thomson <martin.thomson@gmail.com> wrote:
> 
> I think that you are free to pretend that HTTPS is the only variant of
> the protocol.  There's no point in shipping improvements for the
> cleartext variant.

We have to make stuff work for http as well as https.  There are still sites
that want to use http at the zone’s name where CNAME doesn’t work.  This is a
CURRENT problem.

> What are you thinking about ALPN?

What are you thinking about?  The default would be the status quo.  I would
like to be able to deploy this without requiring servers (excludes proxies)
to be updated.

Mark

> On Wed, Aug 22, 2018 at 9:40 AM Mark Andrews <marka@isc.org> wrote:
>> 
>> 
>> 
>>> On 22 Aug 2018, at 4:39 am, Ray Bellis <ray@bellis.me.uk> wrote:
>>> 
>>> Thanks Adam, for creating the mailing list.
>>> 
>>> As mentioned at the side-meeting in Montreal, I strongly believe that the way forward should be a new RR that is specific for the use of HTTP(s) (c.f. MX for SMTP) and that would be automatically looked up by recursive resolvers and returned in answers [*]
>>> 
>>> This recursive lookup step would give this record the equivalent performance to CNAME whilst avoiding the complexities (and failings) of SRV or ANAME.
>>> 
>>> I'd like to write that up in a draft, but to do so I'd like to co-author  with HTTP specialists to ensure that any such RR has the fields they deem necessary without the extra ones that SRV has that we heard are not desirable (specifically port numbers and load-balancing / weighting).
>> 
>> Only the port field is a real potential issue with HTTP.  The others can be set appropriately.
>> I wish we had said port==0 implies use the default/specified port.   We could still say this for
>> _http._tcp and _https._tcp.  Part of the reason SRV doesn’t automatically cover a protocol but
>> requires that SRV use be specified for a protocol is to allow for changes like this.
>> 
>>> Who'd be up for helping with this?
>>> 
>>> Ray Bellis
>>> ISC Research Fellow
>>> 
>>> [*] one caveat - the look-up would have to be optional in the specification because making it mandatory would prevent the use of the RR Expert Review process which doesn't allow for the assignment of
>>> RRs with mandatory server side processing.
>>> 
>>> --
>>> Http-srv mailing list
>>> Http-srv@ietf.org
>>> https://www.ietf.org/mailman/listinfo/http-srv
>> 
>> --
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742              INTERNET: marka@isc.org
>> 
>> --
>> Http-srv mailing list
>> Http-srv@ietf.org
>> https://www.ietf.org/mailman/listinfo/http-srv

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org