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

From: Mark Nottingham <[email-masked]>
Date: Fri, 6 Jul 2012 15:56:46 +1000

Klass,

Thanks for your review and kind words, and apologies for the delay.

I've opened a new ticket for the security-related issues:
  http://trac.tools.ietf.org/wg/httpbis/trac/ticket/365

... and another for the editorial matters:
  http://trac.tools.ietf.org/wg/httpbis/trac/ticket/366

There are a few remaining below which I'll answer directly.

On 23/04/2012, at 11:51 PM, Klaas Wierenga wrote:

> - - 2.2.2 p7, comparision
> 
> Is it really neccessary to have the elaborate determination whether
> the vlaidator is weak or strong, with arbitrary time intervals etc.?
> It seems very error prone and confusing for implementers. Why not just
> say that Last-Modified is weak, and if you want strong use ETags.

If we were defining the protocol from scratch, I'd agree, but we need to stay consistent with how HTTP is already implemented, used and defined, and that can sometimes be messy / complex.

> - - 2.3 ETag, p9, Note
> 
> "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).

> 3.4 p17, If-Unmodified-Since
> 
> Why not defining the the result of a request having both an
> If-Unmodified-Since and a If-None-Match or If-Modified-Since?

This is already being discussed in:
  http://trac.tools.ietf.org/wg/httpbis/trac/ticket/241

> 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.

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

---

From: Klaas Wierenga <[email-masked]>
Date: Fri, 6 Jul 2012 11:11:13 +0200

On Jul 6, 2012, at 7:56 AM, Mark Nottingham wrote:

Hi Mark,

> Thanks for your review and kind words, and apologies for the delay.

no worries, it is not as if I was blocked on waiting for your reply ;-)

Apologies for the fast response, I am in a boring VC ;-)

> If we were defining the protocol from scratch, I'd agree, but we need to stay consistent with how HTTP is already implemented, used and defined, and that can sometimes be messy / complex.

ok

> 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…

So would that not be a good case for SHOULD with perhaps some explanation along the above lines why it isn't a MUST?

>  http://trac.tools.ietf.org/wg/httpbis/trac/ticket/241

ok

> 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" 

Hope this helps,

Klaas

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 9 Jul 2012 10:52:37 +1000

> 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).

> "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,

---

From: Julian Reschke <[email-masked]>
Date: Mon, 09 Jul 2012 10:59:00 +0200

On 2012-07-09 02:52, Mark Nottingham wrote:
> ...
> ...

That would be a normative change; right now we don't make any 
requirement for the case where condition B is not met.

Best regards, Julian