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

>-----Original Message-----
>From: Travis Snoozy (Volt) [mailto:a-travis@microsoft.com] 
>Sent: woensdag 27 december 2006 22:46
>To: Joris Dobbelsteen
>Cc: ietf-http-wg@w3.org
>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

Received on Thursday, 28 December 2006 01:11:21 UTC