Subject: Allow is not in 13.5.2

From: "Travis Snoozy (Volt)" <[email-masked]>
Date: Wed, 20 Dec 2006 16:55:42 -0800

Section 14.7 states:

"A proxy MUST NOT modify the Allow header field even if it does not
understand all the methods specified, since the user agent might have other
means of communicating with the origin server."

However, section 13.5.2 (Non-modifiable Headers) makes no mention of Allow. This seems like an error, but I'm not entirely sure what the fix should be -- remove 13.5.2 and push the (not-)modifiable information in the definition of the respective headers, or to maintain 13.5.2 in parallel with all of the header definitions, or to push all the information out of the header definitions into 13.5.2.

The easy fix for now would be to just make a mention of allow in 13.5.2.

-- Travis

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 21 Dec 2006 02:24:29 +0100

> The easy fix for now would be to just make a mention of allow in 13.5.2.

I would propose to also reduce the MUST NOT restriction in 14.7 down to
a SHOULD NOT which is more appropriate for this kind of restriction. Or
drop it entirely from there.

There is many scenarios where the proxy may actually know by
administrative policies outside the protocol that the user agent does
not have any other means of communication, so the assumption made in
14.7 is not necessarily true. MUST level requirements based on false
assumptions isn't that great.. Also, it does not make much sense to me
having this MUST requirement on non-transparent proxies.

So I propose the following

14.7

      A proxy MUST NOT modify the Allow header field even if it does not

changed to

      A proxy SHOULD NOT modify the Allow header field even if it does not

plus the already proposed 

13.5.2

"Allow" added to the first list of unmodifiable headers "A transparent
proxy MUST NOT modify"..

If 14.7 is kept as a MUST requirement then the directive needs to be
added in a new MUST section in 13.5.2 stricter than any of the existing
sections.

Regards
Henrik

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 21 Dec 2006 16:04:40 +0100

> added in a new MUST section in 13.5.2 stricter than any of the existing

Or alternatively no change at all. There is no conflict.

Regards
Henrik

---

From: "Travis Snoozy (Volt)" <[email-masked]>
Date: Thu, 21 Dec 2006 13:13:33 -0800

> Or alternatively no change at all. There is no conflict.

I don't like the idea of leaving this as it is. There is a consistency issue
here, and while it may not cause confusion if you read the whole thing end-
to-end (and retain it), or have that section pointed out to you, it can
cause confusion and implementation error if you write your "do not alter"
logic based solely on 13.5.2. Again, I really think we should:

1. Remove 13.5.2 and put the information out into the header definitions, or

2. Put all the information in 13.5.2 and remove it from the header
   definitions, or

3. Maintain the information both in 13.5.2 and the header definitions,
   consistently.

Anything else has the potential to cause problems, especially in team situations (or if you have really awful memory, like me :).

-- Travis

---

From: Henrik Nordstrom <[email-masked]>
Date: Fri, 22 Dec 2006 10:56:21 +0100

> I don't like the idea of leaving this as it is. There is a consistency issue

13.5.2 only says that those headers MUST/SHOULD not be modified under
the specified conditions, not that all other headers may be modified, so
there is no conflict.

It does not override other requirements on when headers MUST/SHOULD not
be modified.

The end result restrictions is the sum of 13.5.2 plus the rest of the
specification.

But yes, poor reading of the RFC may cause problems if one assumes
13.5.2 is complete and alone authoritative on when headers may be
modified.

Regards
Henrik

---

From: David Morris <[email-masked]>
Date: Fri, 22 Dec 2006 06:33:05 -0800 (PST)

> 13.5.2 is complete and alone authoritative on when headers may be

Fairly commonly paired with poor writing ... and also with large complex
documents. The goal of inter-operative implementations is best served by
clarification or removal of ambiguity when it is detected. This document
if for engineers who find life challenging enough w/o ambiguity, not
lawyers who love ambiguity.

Dave Morris

---

From: "Travis Snoozy (Volt)" <[email-masked]>
Date: Fri, 22 Dec 2006 09:51:15 -0800

> lawyers who love ambiguity.

+1.

It's not even necessarily poor reading. Assigning sections to team members
for them to implement is not uncommon, and it's also not uncommon for said
team members to only read the section(s) they've been assigned (and _maybe_
supporting sections that are referenced). Specs should be self-consistent to
support this. We can't control who reads the spec, or how they read it, so
we should assume the worst (or set some reasonably easy-to-clear bar
representing the worst we want to support) and write to that.

Furthermore, the informative versus normative classification for clauses (let alone sections) is not always clear. There are many areas in my
annotated copy of the spec that I've marked as "probably a requirement"
despite the fact that there are no MUSTs around. I don't think it's
unreasonable to take 13.5.2 as authoritative, because there is absolutely
nothing indicating that it _isn't_, and it appears to be a thorough listing
of non-modifiable headers.

So, you're right: technically there is no issue. However, I argue that
_practically_ there is. Since this change would be totally editorial in
nature anyway (it's a NOP as far as technical meaning is concerned), and
since it would improve the coherency of the document, I don't see why we
shouldn't make it.

-- Travis