Your suggested rewording works for me, modulo one question: Might it be better to say, "SHOULD use the default https port", rather than giving the port number here? Or perhaps, if you really want to say "443", make it, "SHOULD use the default https port, 443."
Barry On Thu, Jun 11, 2020 at 1:12 PM Tommy Pauly <tpauly=40apple....@dmarc.ietf.org> wrote: > > > > 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, 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
