Re: [http-state] draft-ietf-httpstate-cookie-09 algorithm descriptions

[Peter Saint-Andre <[e-mail]>]

A point of clarification below...

On 7/15/10 10:23 AM, Adam Barth wrote:
> On Thu, Jul 15, 2010 at 5:21 AM, Julian Reschke <[e-mail]> wrote:
>> On 14.07.2010 19:12, Adam Barth wrote:
>>> On Wed, Jul 14, 2010 at 6:13 AM, Julian Reschke<[e-mail]>
>>>  wrote:
>>>>
>>>> I realize that this may sound like nitpicking, but I really think that
>>>> some
>>>> parts of the spec are both too vague in some aspects, and overly precise
>>>> in
>>>> others.
>>>>
>>>> See, for example, Section 5.4.:
>>>>
>>>>> 5.4. The Cookie Header
>>>>>
>>>>>   When the user agent generates an HTTP request, the user agent SHOULD
>>>>>   attach exactly one HTTP header named Cookie if the cookie-string
>>>>>   (defined below) for the request-uri is non-empty.
>>>>
>>>> It says "SHOULD attach exactly one", but doesn't really state the header
>>>> field value. Oversight?
>>>
>>> I've add the following requirement:
>>> [[
>>>         <t>If the user agent does attach a Cookie header field, the user
>>> agent
>>>         MUST send the cookie-string (defined below) as the value of the
>>> header
>>>         field.</t>
>>> ]]
>>
>> If this is a MUST, you can't make sending a single header a SHOULD. Unless
>> the MUST only applies to UAs that do send a single header.
> 
> Why?  The MUST applies to each Cookie header field individually.  If
> you send 34 Cookie header fields, each one of them MUST contain a
> cookie-string as defined below.
> 
>>>>>   A user agent MAY omit the Cookie header in its entirety.  For
>>>>>   example, the user agent might wish to block sending cookies during
>>>>>   "third-party" requests.
>>>>
>>>> So we have "SHOULD send" and "MAY omit". The "MAY" makes attaching the
>>>> header truly optional (correctly), thus the "SHOULD" requirement is
>>>> incorrect.
>>>
>>> Why is the SHOULD requirement incorrect?  Here are the possibilities
>>> in order of desirability:
>>
>> Because we say "MAY omit".
>>
>>> * Exactly one Cookie header.  (Most desired.)
>>> * Zero Cookie headers.  (Acceptable; might impair functionality but
>>> there are reasonable motivations for to UAs might do this.)
>>> * Exactly two Cookie headers.  (Permitted, but undesirable.)
>>> * Exactly three Cookie headers.  (Permitted, but undesirable.)
>>> * etc
>>
>> 2 or 3 headers would be a violation of the SHOULD.
>>
>>>> It would probably better to start the section by stating that sending the
>>>> header is truly optional, and then describe the remainder of the
>>>> algorithm.
>>>
>>> I'm not sure what "truly" means.  UAs SHOULD send exactly one Cookie
>>> header, but they MAY omit the Cookie header in its entirety.
>>
>> "SHOULD do X" and "MAY do not(X)" doesn't work. It's a conflict of
>> requirements.
> 
> You keep saying that, but you haven't explained why.

In my own specs I've often formulated things as "SHOULD do X, but MAY do
Y instead", however it's not really consistent with RFC 2119, which
defines the terms as follows:

   SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

vs.

   MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)

The way I understand the distinction is that "SHOULD" means "this would
be a MUST except there are legitimate reasons for an implementation or
deployment to act otherwise, such as..." -- whereas "MAY" means "this is
well and truly a matter of preference on the part of software developers
and service providers".

I refrain from judgment about which of these conformance levels applies
to the technical matter under discussion here.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/