Jeff and I had a f2f discussion about this point in Vancouver. To paraphrase (and I assume he will correct me if if I mischaracterize anything), Jeff indicated that this really wasn't a MUST level requirement due to the variation and vagaries in application behavior and abilities. Rather, it's more of a "do the best you can" sort of thing. Specifically, he indicated that an implementation that chose to go ahead and serve unprotected content due to the listed caveats on redirecting to HTTPS would necessarily be out-of-compliance. If the requirement really that you SHOULD NOT (rather than MUST NOT) serve unprotected content, then I think the original language is okay. Thanks! Ben. On Aug 9, 2012, at 6:03 PM, Alexey Melnikov <alexey.melnikov@xxxxxxxxx> wrote: > On 02/08/2012 10:46, Ben Campbell wrote: >> Hi, thanks for the response. Comments inline: >> >> On Jul 29, 2012, at 10:29 PM, =JeffH <Jeff.Hodges@xxxxxxxxxxxxxxxxx> wrote: > [...] >>>> -- section 7.2: >>>> >>>> Am I correct to assume that the server must never just serve the content over >>>> a non-secure connection? If so, it would be helpful to mention that, maybe >>>> even normatively. >>> It's a SHOULD, see the Note in that section, so it's already effectively stated normatively, though one needs to understand HTTP workings to realize it in the way you stated it above. Perhaps could add a simple statement as you suggest to the intro para for section 7 Server Processing Model, to address this concern? >>> >> I think something of the form SHOULD redirect to HTTPS, but MUST NOT under any circumstances send the content unprotected would improve the text. > > Sounds good to me. (And yes, this is implied, but it doesn't hurt to state explicitly.) > >> That's probably already implied, and a reasonable implementor wouldn't due it anyway. But my experience is that some readers will find strange interpretations whenever you give them the wiggle room to do so, so it's better to be explicit. > > > _______________________________________________ > Gen-art mailing list > Gen-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art