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

Mark Nottingham <> Fri, 06 July 2012 05:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5EC4E11E809F; Thu, 5 Jul 2012 22:56:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -105.189
X-Spam-Status: No, score=-105.189 tagged_above=-999 required=5 tests=[AWL=-2.590, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uJLAiOh4dOcL; Thu, 5 Jul 2012 22:56:42 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7143711E8097; Thu, 5 Jul 2012 22:56:42 -0700 (PDT)
Received: from (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id CA74E22E253; Fri, 6 Jul 2012 01:56:49 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset=iso-8859-1
From: Mark Nottingham <>
In-Reply-To: <>
Date: Fri, 6 Jul 2012 15:56:46 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Klaas Wierenga <>
X-Mailer: Apple Mail (2.1278)
Cc:, The IESG <>,
Subject: Re: [secdir] secdir review of draft-ietf-httpbis-p4-conditional-19
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 06 Jul 2012 05:56:43 -0000


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

I've opened a new ticket for the security-related issues:

... and another for the editorial matters:

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:

> 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