Re: [secdir] secdir review of draft-ietf-httpbis-p4-conditional-19

[Mark Nottingham <[e-mail]>]

On 06/07/2012, at 7:11 PM, Klaas Wierenga wrote:
>>> 
>>> "ought to" is not very normative. Why not make it MUST or SHOULD?
>> 
>> We've used that terminology when we want to give implementation advice, but cannot impose a new RFC2119-level requirement, because it would make existing implementations non-conformant (as per our charter).
> 
> So would that not be a good case for SHOULD with perhaps some explanation along the above lines why it isn't a MUST?

No, because that still affects conformance (saying "you SHOULD do this unless you're an old implementation is awkward and hard to enforce; it also encourages implementations not to update themselves).


>>> 4.1 p17, Not modified, second paragraph
>>> 
>>> A 304 response..... isn't this a fine case of a SHOULD rather than a
>>> MUST? Or perhaps "A 304 response MUST include a Date header field,
>>> unless the origin server.... , in that case a Date header field MUST
>>> NOT be provided", and what actually does "reasonable approximation" mean?
>> 
>> I'm not sure what you're concerned about here; it's a MUST requirement because it's important for interop.
> 
> it is really just for clarity, I had a bit of trouble parsing, rereading I think my remark about SHOULD probably doesn't make sense. Still, I read it like "you MUST do A unless condition B applies in which you MUST NOT do A", I just suggested rephrasing, perhaps to:
> 
> "If condition B applies you MUST do A, if condition B does NOT apply you MUST NOT do A" 


OK, I'll pass that on to the editors.


Thanks again,

--
Mark Nottingham   http://www.mnot.net/