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=40apple....@dmarc.ietf.org> > 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=40ericsson....@dmarc.ietf.org >> <mailto: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 <mailto: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 <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
