On Wed, Mar 2, 2022, at 14:18, Benjamin Kaduk via Datatracker wrote: > This (mostly implicit) requirement is a potential barrier for adoption of > the HTTPS RRtype, and while the precondition is very often going to be > satisfied, I wanted to get a sense for whether we should make the > requirement more explicit, and possibly more prominent in the document > (e.g., mention it in the Introduction). I don't know what the right > answer is, but it seems important enough to ensure that the topic receives > deliberate consideration.
Your point about highlighting more than loss of functionality is a good one. The idea that request semantics might be altered by swapping the scheme is far more relevant. That said, I'm comfortable with deploying with the upgrade requirement as stated. While we did have a number of examples where the assumed HTTP<->HTTPS equivalence did not hold in the past, the diminishing share of cleartext HTTP usage is overwhelmingly the vestiges that do not have any HTTPS service on the same name. As noted, those servers with a need to maintain distinct resources that differ only in scheme simply cannot use the HTTPS RR. That is entirely appropriate. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop