RE: Allow is not in 13.5.2

David Morris:
> On Fri, 22 Dec 2006, Henrik Nordstrom wrote:
>
> > 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.
>
> 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.

+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

Received on Friday, 22 December 2006 17:51:45 UTC