http://info.cern.ch/hypertext/WWW/Protocols/Overview.html

Larry Masinter (masinter@parc.xerox.com)
Mon, 28 Nov 1994 15:21:08 PST 

Formatting on the ascii version leaves something to be desired; I
assume the editors will fix this before moving the document forward.
(DL lists don't indent reasonably, the table of contents is useless,
etc.)
================================================================
> 2.1 Augmented BNF

I went through lots of machinations on BNF for the URL document, and
wound up with:

  This is a BNF-like description of the Uniform Resource Locator
  syntax, using the conventions of RFC822, except that "|" is used to
  designate alternatives, and brackets [] are used around optional or
  repeated elements. Briefly, literals are quoted with "", optional
  elements are enclosed in [brackets], and elements may be preceded
  with <n>* to designate n or more repetitions of the following
  element; n defaults to 0.

The formatting wound up working better to put comments on separate
lines; even though the result was longer, it was easier to read.
It seems like the addition of the # construct doesn't make the BNF
easier to read or interpret at all.

> 4.1 Date/Time Format

I think you should define HTTP as using RFC 822/1123 date formats,
and make the "strong recommendation" be to accept other formats,
rather than the way you have this worded.

> 4.2 Content Types

In what way is the HTTP content-type a superset of the MIME BNF?
If you must repeat some BNF that occurs in another RFC, you must
identify how this is either just a repeat, or a modification, and if
it is a modification, how it is different from the source.

> 4.2.1 Multipart Types

The BNF for multipart types is very confusing, since it isn't at all
clear whether this is just supplying BNF for MIME or something new
that is MIME-like.

I'd appreciate it if you would consider mentioning multipart/form-data
as proposed in draft-ietf-html-fileupload-00.txt.
 
> 4.2.1.1 multipart/alternative

> The "multipart/alternative" content-type is used in MIME to send
> content-type variants of a single entity when the receiver's
> capabilities are not known. This is not the case with HTTP.
> Multipart/alternative can be used to provide metainformation of many
> instances of an object,

This is really annoying if it is current practice (to redefine what
"alternative" might mean).

> 4.3  General Message Header Fields

You're really recommending that HTTP servers send a "MIME-Version"
field? But the MIME committee has basically recommended that there not
be any MIME-Version other than 1.0. You might as well tie
MIME-Version: 1.0 into HTTP/1.0 and suppose that any new MIME-Version
will imply a new HTTP version.

> 4.3.3 Message-ID

Do you care to comment on message-id vs. URN?

....
(more later)