Subject: Re: p4-conditional proofreading

From: Julian Reschke <[email-masked]>
Date: Mon, 01 Feb 2010 15:26:54 +0100

Barry Leiba wrote:
> ...
> Oh, my, I certainly think it's wrong and unclear, and it needs to be
> changed (and I don't think "they" is sufficient).  I also can't
> imagine that the RFC Editor would let it pass.  Each normative clause
> has to have a subject, and it's confusing the have the subject sort of
> presented at the beginning of the list.  That's not good English.
> 
> For example:
> 
>      HTTP/1.1 clients:
> 
>      * If an entity tag has been provided by the origin server, MUST
>      use that entity tag in any cache-conditional request (using If-Match
>      or If-None-Match).
> 
> This asks people to mentally insert "HTTP/1.1 clients" where there's a
> missing subject.  Ah, I see, there's a missing subject before MUST, so
> that's where I need to stick it.  No, that's too much to ask of the
> reader.  That it's been that way for a long time doesn't mean that
> it's right, only that no one has complained.  It's only been reviewed
> by people who knew what you meant already, so they breezed through it.
> 
> Please change the list to look something like this:
> 
>      For HTTP/1.1 clients:
> 
>      * If an entity tag has been provided by the origin server, HTTP/1.1 clients
>      MUST use that entity tag in any cache-conditional request (using If-Match
>      or If-None-Match).
> 
> That really isn't a hard change to make, it will avoid any
> misunderstandings, and it will avoid interaction on this with the RFC
> Editor when the time comes.
> ...

Understood.

Here's an alternative proposal; reverse the sentences so that the BCP14 
keyword comes first (like in the previous list about servers):

- snip -
   HTTP/1.1 clients:

   o  MUST use that entity tag in any cache-conditional request (using
      If-Match or If-None-Match) if an entity tag has been provided by
      the origin server.

   o  SHOULD use that value in non-subrange cache-conditional requests
      (using If-Modified-Since) if only a Last-Modified value has been
      provided by the origin server.

   o  MAY use that value in subrange cache-conditional requests (using
      If-Unmodified-Since) if only a Last-Modified value has been
      provided by an HTTP/1.0 origin server.  The user agent SHOULD
      provide a way to disable this, in case of difficulty.

   o  SHOULD use both validators in cache-conditional requests if both
      an entity tag and a Last-Modified value have been provided by the
      origin server.  This allows both HTTP/1.0 and HTTP/1.1 caches to
      respond appropriately.
- snip -

Feedback appreciated,

Julian

---

From: Barry Leiba <[email-masked]>
Date: Mon, 1 Feb 2010 09:33:44 -0500

>     origin server.  This allows both HTTP/1.0 and HTTP/1.1 caches to

That's a fine re-write, and I'm mostly happy with it.  May I make a
small edit?  In order to avoid people wondering whether "that value"
refers back to the previous bullet, how's this?:

  HTTP/1.1 clients:

  o  MUST use the entity tag in any cache-conditional request (using
     If-Match or If-None-Match) if an entity tag has been provided by
     the origin server.

  o  SHOULD use the Last-Modified value in non-subrange cache-conditional
     requests (using If-Modified-Since) if only a Last-Modified value has been
     provided by the origin server.

  o  MAY use the Last-Modified value in subrange cache-conditional requests
     (using If-Unmodified-Since) if only a Last-Modified value has been
     provided by an HTTP/1.0 origin server.  The user agent SHOULD
     provide a way to disable this, in case of difficulty.

Barry

---

From: Julian Reschke <[email-masked]>
Date: Mon, 01 Feb 2010 15:44:12 +0100

>      origin server.  This allows both HTTP/1.0 and HTTP/1.1 caches to

It is much better, indeed.

Applied with <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/755>.

Best regards, Julian