Re: comments on HTTP draft of 5 Nov 93

Tony Sanders <sanders@bsdi.com>
Errors-To: sanders@bsdi.com
Errors-To: sanders@bsdi.com
Message-id: <199312081741.LAA00354@austin.BSDI.COM>
To: Jim Davis <davis@dri.cornell.edu>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: comments on HTTP draft of 5 Nov 93 
In-Reply-To: Jim Davis's message of Wed, 08 Dec 1993 11:13:55 EST.
Errors-To: sanders@bsdi.com
Reply-To: www-talk@nxoc01.cern.ch
Organization: Berkeley Software Design, Inc.
Date: Wed, 08 Dec 1993 11:41:44 -0600
From: Tony Sanders <sanders@bsdi.com>

> 1) It's still not clear to me where SPACEJUMP and TEXTSEARCH are used,
> or rather, the descriptions confuse me.  As the text on page 7 makes
> clear one does not send a SPACEJUMP message, one send GET, and encodes
> the spatial indicies into the URL.  So where are SPACEJUMP and
> TEXTSEARCH used?  If only in the output from SHOWMETHOD, then they should
> not be called methods.  
They are used when returning an object in the Public: or Allowed: headers.
They indicate to the browser that the object can be searched and what form
that search should take.  TEXTSEARCH means use the http:...?query format
and SPACEJUMP means clicking (or other means of spatial selection) should
be used to index into the data and return the relative coordinates of the
selection.

> 3) In my opinion, the specification contains a number of methods
> and features  which are currently not sufficiently clearly defined.
> I would guess that few, if any, have been implemented, and would
> further guess that at least a few are of dubious utility (after
> all, if they were truly needed, someone would be implemented them - look
> how quickly ISMAP spread.)
I think it's a good idea to have the future mapped out so people don't
invent square wheels when someone has already figured out how to make
round ones.  If you remove them then people will implement alternative
solutions that don't fit the model.  This is already a problem as
it stands.

Of course, the official RFC is a different story.  For that I agree with you.

> Don't get me wrong - I am eager to see some of these become part 
> of the spec, particularly the authorization stuff.
There are already implementations of the authorization stuff.

> Re: ACCEPT 1.7.2  Is the order of content types significant?  I
> hope so.
No, the ranking is done with the `q' attribute.

> Re: Accept-Language 1.7.4  Why not use the encoding used in Language
> (2.4.12)?  Also, there must be a way to specify the "q" factor for
> a language, just as for Accept.  Finally, there must be a specification
> of how the q from Content Type and the q from Language interact.
> (Multiplied?)
This is why I voted that Accept-language was the wrong approach.  It
should be an attribute associated with the Accept content-type like all
the other client-profile information is.

--sanders