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

Larry Masinter wrote (on Monday):

>> 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.

I seriously considered using your syntax instead of rfc822's, but we
decided that since HTTP, RFC 822, and MIME were so closely intertwined,
we should stick with the original syntax.

> 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.

I agree (for most cases) and will fix that in the next version.

>> 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.

Sounds reasonable.

>> 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.

It is a superset because it does not restrict itself to the official
MIME types and x-token types, as does the MIME spec.  Thus, the parsing
is the same but without restricting the token values.  This is equivalent
to the RFC 1590 decision to not constrain media types.

>> 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.

It is equivalent to that in MIME.

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

I don't know if that should go into HTTP/1.0 or HTTP/1.1.
We should discuss this in San Jose.

>> 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).

Right, we should probably just delete this section, as it is not in
current practice and there may be better ways of handling URC alternatives.
Henrik, what was the reason for including this in the spec?  I can't remember.

>> 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.

I'd rather include the generic syntax, just in case the MIME people
change their minds.  I am tempted to just remove MIME-Version altogether
(except for gateways), but that will have to be a group decision.

>> 4.3.3 Message-ID
> 
> Do you care to comment on message-id vs. URN?

Nope. ;-)


......Roy Fielding   ICS Grad Student, University of California, Irvine  USA
                                     <fielding@ics.uci.edu>
                     <URL:http://www.ics.uci.edu/dir/grad/Software/fielding>

Received on Thursday, 1 December 1994 16:45:16 UTC