Re: [Captive-portals] Magnus Westerlund's Discuss on draft-ietf-capport-api-07: (with DISCUSS)

[Magnus Westerlund <[e-mail]>]

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 <[e-mail]>
> Sent: den 12 juni 2020 05:56
> To: Magnus Westerlund <[e-mail]>
> Cc: The IESG <[e-mail]>; [e-mail]; captive-
> [e-mail]; Martin Thomson <[e-mail]>; draft-ietf-
> [e-mail]
> 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
> <[e-mail]> 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