Re: Minor issues with HTTP 1.1 draft 6

Regarding <draft-ietf-http-v11-spec-06.txt>, Ross Patterson mentions:

> I can't find any trace of these in the http-wg archives, and they seem like
> "editing" issues, so I hope they're appropriate to bring up at this point in
> the RFC process.  There are a few small points in draft 6 of the HTTP 1.1
> specification that seem to be incorrect:
> 
>    1) On page 30, section 4.2 "Message Headers" states 'Applications SHOULD
>       follow "common form" when generating HTTP constructs, ...'.  The draft
>       does not contain any definition of "common form", although by context it
>       appears to mean "headers without RFC-822-style folding".

No, common form is just that -- whatever is common.  Since that is a
time-dependent function, it can't be defined.  If we were to define it
as "today's common form", then it would be no folding, no space between
field-name and ":", and only a single space between the ":" and the
field-value.  However, I think that might lead to more poor implementations
in the future.

>    2) On page 95, section 14.9 "Cache-Control" contains in the BNF for
>       cache-request-directive, the alternative:
> 
>          '| "max-stale" "=" [ delta-seconds ]'
> 
>       It seems this should read:
> 
>          '| "max-stale" [ "=" delta-seconds ]'
> 
>       All other usages of "thing=value" where the value is optional take the
>       form where the "=" is omitted with the value (i.e.  "max-stale", not
>       "max-stale=").

Yes, that should be fixed -- it was correct in the changes proposed to the
WG mailing list, but just got fudged in editing (it happens).

>    3) On page 105, section 14.15 "Content-Location" contains the phrase '...
>       it is only a statement.  of the location of the resource ...', where the
>       period after 'statement' is a typo.

Yep.

>    4) On pages 128-129, sections 14.45 "Warning", the references to
>       "ISO-8599-1" are typos, they should read "ISO-8859-1".  They should
>       probably also have pointers to reference [22] "ISO-8859 ...".

Yep.

>    5) On page 134, section 15.8 "DNS Spoofing" states that 'The deployment of
>       DNSSEC should help this situation." without citation of DNSSEC.  There
>       doesn't appear to be any RFC to cite at this time, although there are
>       several valid Internet Drafts.  Either a citation should be added (in
>       possible violation of the proper use of Internet Drafts) or the
>       statement should be removed.

I think it should be removed -- we cannot know if it will help until it
is no longer a draft.

>    6) On pages 137-139, section 17 "References", items [5] and [12] are not
>       cited anywhere within the draft, and item [27] is omitted from the list.

Item [5] should be referenced at the end of first para of section 19.6.2.4.
Item [12] can be removed or include a reference to it in the third para
of section 3.3.1 (where RFC 850 is referenced).

I should also note that item [30] currently has two references munged
together, and that the entire list should be listed alphabetically by
the first author's last name.

Larry, these can all be categorized as editorial changes, but should be
made before the document is frozen into RFC form.


 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92697-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Monday, 15 July 1996 20:07:21 UTC