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=40ericsson....@dmarc.ietf.org> 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 <m...@mnot.net <mailto:m...@mnot.net>>
>> Sent: den 12 juni 2020 05:56
>> To: Magnus Westerlund <magnus.westerl...@ericsson.com
>> <mailto:magnus.westerl...@ericsson.com>>
>> Cc: The IESG <i...@ietf.org <mailto:i...@ietf.org>>; capport-cha...@ietf.org
>> <mailto:capport-cha...@ietf.org>; captive-
>> port...@ietf.org <mailto:port...@ietf.org>; Martin Thomson
>> <m...@lowentropy.net <mailto:m...@lowentropy.net>>; draft-ietf-
>> capport-...@ietf.org <mailto: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-
>> <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
> Captive-portals@ietf.org <mailto:Captive-portals@ietf.org>
> https://www.ietf.org/mailman/listinfo/captive-portals
> <https://www.ietf.org/mailman/listinfo/captive-portals>
_______________________________________________
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals
