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.
2) It's not clear to me that HTTP needs to specify the syntax
by which searches are encoded into URLs, as in the sections in 1.6.1
GET (p 7) and 1.6.6 SPACEJUMP and 1.6.7 TEXTSEARCH (p 10). Isn't the URL
syntax a level of abstraction above that of HTTP itself? Or perhaps
it belongs in HTML, since it requires the cooperation of the client
program (interpreting ISMAP and/or FORM directives) and the server.
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.)
They should be removed. Specifically, I mean CHECKOUT and CHECKIN and SEARCH.
One could argue that LINK and UNLINK are too ill-defined right now,
since the very names have been called into question, and I have argued
(above) that TEXTSEARCH and SPACEJUMP should be removed, although for
other reasons.
PUT and DELETE and POST and REPLY seem to be sufficiently well
defined that they could be used, but has anyone implemented them?
There are also a number of headers that are ill-defined, but I won't
speak about them here and now.
There is no benefit to the spec by providing them, in their current
ill-defined form. There is some harm in providing them, since they
make the protocol seem vague. There is no harm in deleting them,
since the protocol is extensible anyway. If anyone wishes to experiment
with such new methods, they can write an experimental server to
test the ideas. Omitting them from the spec does not prevent such
experimentation.
Don't get me wrong - I am eager to see some of these become part
of the spec, particularly the authorization stuff.
But it's not a good idea to use the spec as the site for design discussions.
We can do that better in in www-talk (or comp.infosystems.www),
perhaps also with someone building a working trial implementation.
Remaining comments are keyed to specific sections in the spec:
Re: 1.0 ProtocolVersion is wrong, should be HTTP/1.0
Re: 1.6 Methods - lists five methods that are not further described,
that is, there's nothing in the table of contents about them. They
are HEAD, CHECKOUT, PUT, DELETE, CHECKIN. Also the description of PUT
mentions "REPLY" but this method is not otherwise mentioned or defined.
Finally, the list should either be in alphabetic order or grouped
by semantic similarity e.g.
GET HEAD POST REPLY DELETE, CHECKOUT CHECKIN, LINK UNLINK,
TEXTSEARCH, SPACEJUMP,
Re: GET 1.6.1 says, with regard to query terms: "those search terms are first
stripped off". Stripped by who? the client?
Re: LINK and UNLINK (1.6.2) - you are right, the names are no good when
the concept is generalized. It seems to me that the right names
are SET and CLEAR, since one can think of the header of a document
as containing a set of variables, each of which may be assigned to.
You could also call it ASSIGN and UNASSIGN. "BESTOW" has the connotation
of awarding a priviledge or access right, it's the wrong name.
Do we really need this feature in HTTP?
Re: SEARCH (1.6.4) It's not the least bit clear to me what this thing does,
or why it MUST be in the HTTP spec. Also the correspondance is
formatted funny, it's set in a courier typeface and the lines
are so long they fall off the right margin of the paper.
Re: ACCEPT 1.7.2 Is the order of content types significant? I
hope so.
Also remember that the MIME spec uses semi-colon, not comma, to separate
content-type from parameters, and that tokens in parameters can not
include the period character, so "floating point" numbers must be quoted.
I don't know whether space is allowed or not, someone should check.
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?)
Re: 2.4.9 URI: 1*uri
what does the 1* mean here?
Last and least -- Typos et -- do you have spelling checker? Would you
prefer I not send spelling corrections? Maybe it's a waste of your time?
page 5 1.1 sentence 1 ends with two periods in a row, sentence 2 ends with space before period.
page 6 1.4 has an extra space before comma. also "fromats" abnd "contenst"
page 7 "methos" "incldues" "seperated"; and the last sentence should read
"overwrites any preexisting title".
p 10 "spacified", "postcondidtion", "HTTP2"
p 11 "signifiance"
p 12 "filed" "unspecifies"
p 18 "dimensiosn"
p 19 "smae" Also there is some kind of formatting glitch here
with the URL for url6.ps "informatiiuon" "ofthe"
p 21 "algoritm"
p 24 "resrverd"