Hi, I fully understand the simplicity from one perspective to not define the version of HTTP. And I think the proposed language was an improvement. Using default port I think has an advantage due to the multi transport protocol nature we have here.
On the question about versions I think it has likely interesting implications for CAPPORT implementations. I expect that servers will actually be deployed and potentially not be upgraded after having been installed in a network over significant times in some cases. This will force the clients to actually support the full set of HTTP protocols to support to ensure interoperability over many networks. I guess this is similar for other deployments of HTTP beyond the web. Cheers Magnus Westerlund > -----Original Message----- > From: Mark Nottingham <m...@mnot.net> > Sent: den 12 juni 2020 05:56 > To: Magnus Westerlund <magnus.westerl...@ericsson.com> > Cc: The IESG <i...@ietf.org>; capport-cha...@ietf.org; captive- > port...@ietf.org; Martin Thomson <m...@lowentropy.net>; draft-ietf- > capport-...@ietf.org > Subject: Re: [Captive-portals] Magnus Westerlund's Discuss on draft-ietf- > capport-api-07: (with DISCUSS) > > Just jumping in here, apologies if I don't have all context: > > > On 11 Jun 2020, at 11:38 pm, Magnus Westerlund via Datatracker > <nore...@ietf.org> wrote: > > > > First of all what is the intention of which HTTP version should be > > supported here? And which protocol are the port 443 you are > > recommending, TCP, UDP or SCTP? This also relates to HTTP/3 as it is > > getting close to being published, we can expect that in the future maybe > people would like to upgrade to HTTP/3. > > It's generally bad practice for an API to specify a version of HTTP. > > > Already now I am wondering if the written allow for HTTP/2 over > > TLS/TCP? Note, that I am mostly commenting from the perspective if you > > want to be specific that it is HTTP/1.1. over TLS/TCP that is the > > goal. Then this document should make certain changes in the > > formulation. If you want to be unspecific and don't think that will > > hurt interoperability, then another formulation that the current is also > needed. > > I think what's desired is to say that the URL accessed must have a HTTPS > scheme and a default port, not that communication happen over any specific > wire format. > > > Likely also a discussion about how a client will figure out what > > versions are supported. > > Why would it be different than any other use of HTTP? > > Cheers, > > -- > Mark Nottingham https://protect2.fireeye.com/v1/url?k=3a8ff1cb- > 642f338e-3a8fb150-86b568293eb5-26a118f7c2d94334&q=1&e=d25e7a4c- > f7e3-4e34-a054-2498def27e05&u=https%3A%2F%2Fwww.mnot.net%2F
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
