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

Joris Dobbelsteen said:
> >-----Original Message-----
> >From: Travis Snoozy (Volt) [mailto:a-travis@microsoft.com]

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

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.

> [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.

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

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

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.

> Interpretation again.
> Same applies to "It MUST NOT be generated by clients", I think it the
> 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.)

Received on Thursday, 28 December 2006 18:58:56 UTC