> On Jun 11, 2020, at 6:38 AM, Magnus Westerlund via Datatracker > <nore...@ietf.org> wrote: > > Magnus Westerlund has entered the following ballot position for > draft-ietf-capport-api-07: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-capport-api/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Section 4.1: > > The API server endpoint MUST be accessed using HTTP over TLS (HTTPS) > and SHOULD be served on port 443 [RFC2818]. > > I have another reason than Roman to discuss this particular sentence. > > 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. > 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. Likely also a discussion about how a client will > figure > out what versions are supported.
This is an interesting point. In my interpretation, this text does apply to HTTP/1.1 over TLS/TCP, HTTP/2 over TLS/TCP, and HTTP/3 over QUIC (which uses TLS for encryption, still uses port 443, and still maintains the URI scheme of https://). > > And maybe one of the ART ADs can help untangle if RFC 2818 really is the right > normative reference here? Or if it should be RFC 7230 and possibly additional > references for HTTP/2? Looking at RFCs like the one for DoH, https://www.rfc-editor.org/rfc/rfc8484.html <https://www.rfc-editor.org/rfc/rfc8484.html>, RFC 2818 is still the reference for https: over HTTP [RFC7540] using https [RFC2818] URIs (and therefore TLS [RFC8446] security for integrity and confidentiality). My suggestion is that we can reword the sentence in question here to: The API server endpoint MUST be accessed over HTTP using an https URI [RFC2818], and SHOULD be served on port 443. Does that work for everyone? Thanks, Tommy > > > > > > _______________________________________________ > Captive-portals mailing list > Captive-portals@ietf.org > https://www.ietf.org/mailman/listinfo/captive-portals
_______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
