RE: PROPOSAL: content sniffing [#155]

Julian Reschke wrote:
> Brian Smith wrote:
> > Julian Reschke wrote:
> >> Brian Smith wrote:
> >>> 1. Remove 3.2.1 completely.
> >> I think this goes to far, as it explains the interaction between
> >> Content-Encoding and Content-Type.
> >
> > It is already explained well enough in 5.5, particularly in the
> > section you quoted below. The explanation in 3.2.1 also has
> > the same problem you mention below;
> > "Content-Encoding(Content-Type(data))" doesn't make sense when
> > there is no Content-Type, especially if there is no default
> > content-type.
> 
> Disagreed; I think the concept itself needs to be explained as part of
> Section 3, and not be hidden in the definition of a specific header.

Why do you think so? Removing 3.2.1 makes the specification shorter and more
precise, thus easier to understand. Almost every sentence in 3.2.1 is wrong
in some way (or at least confusingly imprecise) and correcting them all will
make 3.2.1 even more redundant with 5.5 and 5.9. There are many other
instances in RFC 2616 where the introductory/tutorial text creates confusion
with the normative (SHOULD/MUST/MAY) parts of the specification. The best
strategy for resolving these conflicts is to reduce the tutorial text to its
absolute minimum. That will lead to the clearest specification and it should
considerably reduce the amount of time it takes to finish HTTPbis.

Somebody can write a HTTP primer or an annotated version of the spec for
implementers that need more exposition. I think there is a need for such a
document anyway, because many people care about how web browsers and other
kinds of UAs diverge from or subset the specification. Such a document would
be an excellent place to describe content sniffing and its pros and cons,
for example.

- Brian

Received on Saturday, 11 April 2009 15:43:40 UTC