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

[Tommy Pauly <[e-mail]>]

Hi Magnus,

I’ve published the proposed text in the -08 version of the draft: 

https://datatracker.ietf.org/doc/html/draft-ietf-capport-api <https://datatracker.ietf.org/doc/html/draft-ietf-capport-api>

Please take a look, and update your evaluation if it looks good!

Best,
Tommy

> On Jun 15, 2020, at 9:15 AM, Tommy Pauly <tpauly=[e-mail]> wrote:
> 
> Thanks all for the input. The text in our working copy now reads:
> 
> The API server endpoint MUST be accessed over HTTP using an https URI {{!RFC2818}}, and SHOULD use the default https port.
> 
> (https://capport-wg.github.io/api/draft-ietf-capport-api.html#name-api-connection-details <https://capport-wg.github.io/api/draft-ietf-capport-api.html#name-api-connection-details>)
> 
> 
>> On Jun 12, 2020, at 7:43 AM, Magnus Westerlund <magnus.westerlund=[e-mail] <mailto:magnus.westerlund=[e-mail]>> wrote:
>> 
>> 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. 
> 
> As a client implementer, I think this is both entirely standard and entirely necessary. Any device that is currently interacting with a user-facing captive portal needs to support generic browser-style webpages, which means that support for older versions HTTP for compatibility reasons is a necessity. I agree with Mark that the text here shouldn’t specify anything about the wire format version, since it has no requirements on capabilities specific to HTTP/2, HTTP/3, etc.
> 
> Best,
> Tommy
>> 
>> Cheers
>> 
>> Magnus Westerlund
>> 
>>> -----Original Message-----
>>> From: Mark Nottingham <[e-mail] <mailto:[e-mail]>>
>>> Sent: den 12 juni 2020 05:56
>>> To: Magnus Westerlund <[e-mail] <mailto:[e-mail]>>
>>> Cc: The IESG <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>; captive-
>>> [e-mail] <mailto:[e-mail]>; Martin Thomson <[e-mail] <mailto:[e-mail]>>; draft-ietf-
>>> [e-mail] <mailto:[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] <mailto:[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- <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 <http://2fwww.mnot.net/>%2F
>> 
>> _______________________________________________
>> Captive-portals mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/captive-portals <https://www.ietf.org/mailman/listinfo/captive-portals>
> _______________________________________________
> Captive-portals mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/captive-portals <https://www.ietf.org/mailman/listinfo/captive-portals>