Failing Parameter in Key Header

I am trying to implement the Key header (from https://tools.ietf.org/html/draft-ietf-httpbis-key-01 <https://tools.ietf.org/html/draft-ietf-httpbis-key-01>) and have a question regarding “fail parameter processing”.   I apologize in advance if this question is best for another forum. The Key header does not appear to be widely discussed yet, so I thought this might be the right place.
 
Why is a key-item with zero parameters treated as a “failing parameter” (going to section 2.2.2) when calculating a secondary cache key?  I would have thought that at step 5, sub-step 2, it would read something like:
  
…append “field-value” (or a normalized version of it) to “secondary-key” (and go to next key item)
 
In other words, if there are zero parameters for a key-item, simply append the value of the header field to the secondary-key and then move on to the next key-item. In all other cases when building the cache key, there is an actual error in the parameter (no = sign, bad parameter name, etc.). In the case of zero parameters, it is not really an error, as the spec explicitly allows for zero or more parameters.
 
In addition, and related, and I think more important, it is unclear to me whether or not each key item stands on its own if there is a failing parameter (or as it stands, no parameters) in one of them. In the step-by-step algorithm it seems to indicate that they are independent, as in case of error the instruction is to move on to the next key-item (after handling the error). But in the failing parameter processing section 2.2.2 it seems to indicate that if there is a single failing parameter, the entire Key header should be ignored (falling back to Vary I assume) or that all of the “nominated header fields being compared match” which is the same as treating the Key header as a Vary header with no parameters for any nominated header field. In either case, one failing parameter in one key-item appear to void all parameters in all key-items.
 
Is the spec unclear here, or am I just not getting it?
 
Thanks,
 
Paul Mansour

Received on Friday, 3 June 2016 09:48:42 UTC