Subject: RE: NEW ISSUE: 13.1.2's Definition of 1xx Warn-Codes

From: "Joris Dobbelsteen" <[email-masked]>
Date: Thu, 28 Dec 2006 02:11:45 +0100

>-----Original Message-----
>From: Travis Snoozy (Volt) [mailto:[email-masked]] 
>Sent: woensdag 27 december 2006 22:46
>To: Joris Dobbelsteen
>Cc: [email-masked]
>Subject: RE: NEW ISSUE: 13.1.2's Definition of 1xx Warn-Codes
>

I shall try to cut down the text a bit.

[snip]
>
>Then my point is proven: if I can interpret it wrong, it needs 
>to be rewritten ;) (see also Murphy's Law).

Not for a debate, but that's possible with (nearly) anything.
Unfortunally this seems to be the most important point in this
discussion however...

>But seriously, according to BCP14: MAY "mean[s] that an item 
>is TRULY OPTIONAL" (emphasis mine). Clearly, it is not truly 
>optional for 1xx warn- codes to "be generated by a cache only 
>when validating a cached entry."

I'll get back to that later...

>Certain 1xx warn-codes MUST be generated by any 
>conformant/conditionally conformant cache (section 14.46, page 
>149). May is being used correctly in the English sense, but 
>not in the BCP14 MAY sense.

Agreed...
(Side note: It took me (some) time, but I believe you mean the "MUST"
requirement where each response code description starts with. For me a
description is quite an unexpected location for requirements to appear,
not 'scan-reading' friendly.)

[snip]

>telling me to "read it another way" is totally unhelpful.

I'll get back on that later on.

[snip]

For some common on my positive vs negative. In my native language
(dutch) you can only be sure of the answer when it is posed positively.
Especially if you give a "yes"/"no" answer. Hence my principles that too
many negations may make the text non-understandable.
It was not too relevant here, sorry for that. I believe it should fall
out of this discussion.

[snip]

>BETTER (new proposed)
>
>"A cache MUST NOT generate 1xx warn-codes for any messages 
>except cache entries, and MUST NOT add 1xx warn-codes to cache 
>entries except in response to a validation attempt."

After several misreading and now getting the whole information together,
I agree this conforms to the specification.

[snip]
>I'm not replacing the
>*entire* paragraph, just the last two sentences. There are no 
>issues with the first sentence. My mistake.
[snip]
>
>> >3. One would think that proxies could include caches (though I have 
>> >yet to find where this is permitted with a true BCP14 MAY).
>>
>> Read the defitions:
>
[snip]
>
>You left out the *only* normative bit in the definitions 
>(which, consequently, is the one that makes it so that proxies 
>can't have caches):
>
>* Proxies MUST conform to both server and client requirements 
>Normative (!)

My interpretation:
"An intermediary program which ACTS as both a server and a client..."
and
"A proxy MUST IMPLEMENT both the client and server requirements of this
specification"

Thus it can ACT as a client ("making connections for the purpose of
sending requests"), and thus it must implement to client requirements to
conform to the specification.
It can also ACT as a server ("accepts connections in order to service
requests by sending back responses") and thus it must implement the
server requirements to adhere to the specification.
Thus it must IMPLEMENT both behaviours, however it is NOT specified that
it MUST apply both behaviours at the same time. Thus it might be
resonable, and perhaps the intention of the specification writer, to
explain it that the rules to be applied depend on the role taken. In
order to apply a rule, it must be implemented of course.

[snip]

Wrap-up
=======

This discussion is about interpretation of the texts, mostly.
That was what I intended to say with you should read it differently,
there are multiple ways to interpret or explain it. It all depends on
the meaning we give to the works, since in human languages they are
commonly ambigues and not strongly defined.

Some nice phrase comes to mind "Lies, damn lies, statistics". You can
prove anything, just explain it to your liking.

Thus I agree that the "MAY" in "1XX warn-codes MAY be generated by a
cache only when validating a cached entry." was not the best choice. But
again that depends on how "truly optional" may be defined.
Interpretation again.
Same applies to "It MUST NOT be generated by clients", I think it the
statement is valid. It more explicitly expresses that received responses
should not have 1xx warn-codes added to it.

Hopefully this is useful...

Kind regards,

- Joris Dobbelsteen

---

From: "Travis Snoozy (Volt)" <[email-masked]>
Date: Thu, 28 Dec 2006 10:58:31 -0800

> >From: Travis Snoozy (Volt) [mailto:[email-masked]]

<snip>

> it MUST apply both behaviours at the same time.

Section 1.2 (Requirements, page 8):

   An implementation is not compliant if it fails to satisfy one or more
   of the MUST or REQUIRED level requirements for the protocols it
   implements.

Proxies _implement_ the client and server protocols. By implementing the
cache protocol, a proxy would fail "to satisfy one or more of the MUST or
REQUIRED level requirements" for the client protocol. This failure would
make such a proxy "not compliant".

We could split all sorts of hairs over this, but that would be irrelevant if
we can agree that both interpretations are reasonable. If there is more than
one reasonable interpretation, we should work to pick the sane one, and make
it crystal clear that that is the intent of the spec.

> Thus it might be resonable, and perhaps the intention of the specification
> writer, to explain it that the rules to be applied depend on the role
> taken. In order to apply a rule, it must be implemented of course.

I think we're in violent agreement that allowing caches is clearly the
intent. The specification makes reference to "caching proxies," and states
informatively in more than one place that caches are allowed in anything but
a tunnel. However, even if we take your interpretation that proxies are
allowed to use caches (while they're acting like a "server"), that still
doesn't fix the problem about clients (e.g., user agents) not being allowed
to have caches. The proxy issue was just an extension of the client issue.
My point is that we need to fix the wording, because even though the spec
almost certainly _intends_ to allow caching, the literal interpretation
practically forbids caching everywhere where it would be useful.

> prove anything, just explain it to your liking.

But a good spec makes it really hard to do ;). English can be very precise,
accurate, and unambiguous, but it takes a _lot_ of effort (it helps if you
have a punster on the editing board).

> again that depends on how "truly optional" may be defined.

It is defined in BCP14, and BCP14 is _very_ explicit about what MAY means.
MAY (a.k.a. OPTIONAL) means it's totally, completely, unequivocally,
absolutely, utterly optional. One vendor may implement it, and another
vendor may throw it out the third story window. However all implementations
MUST be able to interoperate with one another (regardless of whether "the
other guy" implements the MAY parts or not). I have included the full text
of the relevant section of BCP14 at the end of this message for reference.

> statement is valid.

Nope. The definition of a client means that the client can't use a cache,
because the cache is part of the client, and caches generate 1xx warn-codes
under certain conditions. It MUST NOT be generated by clients that don't
implement a cache, perhaps, but "clients" is the union of "clients with
caches" and "clients without caches".

> It more explicitly expresses that received responses should not have 1xx
> warn-codes added to it.

You MUST add a warn code to certain received responses. If a message is in
the app's cache, either the app generated the message, or the message is a
response that the app received at some point. The likely intent here is
probably that the client can't just slap on a warn code in the *actual act
of receiving the message*, i.e., it MUST go to the caching subsystem first
(and the caching subsystem MUST follow certain rules about when to apply the
appropriate warn-codes). But that's not what the spec says. If that's what
we mean, that's what we should say. So, let's take another shot at the
wording.

Proposed fix:

"Only caches and origin servers may generate 1xx warn-codes; other
(sub)systems MUST NOT generate 1xx warn-codes. A cache MUST NOT generate
1xx warn-codes for any messages except cache entries, and MUST NOT generate
1xx warn-codes to cache entries except in response to a validation attempt."

> Hopefully this is useful...

... Useful enough for me to make revisions. :)

Thanks,

-- Travis

BCP14 (RFC 2119) Section 5, page 2:

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