Re: Negotiation in draft 01

At 10:26 PM 8/8/95 -0400, Roy Fielding wrote:
>I very rarely design things on the mailing list, preferring
>instead to work with small groups on particular problems and then presenting
>the result in the form of a draft.

I have to disagree with the current approach if there are going to be 5
month periods between drafts.  Given that many people are already deploying
HTTP applications, and have only the I-Ds to go by, having major changes
like this appear without warning is, IMHO, unacceptible.

I don't have a problem with the idea of having a small group come up with a
proposal for discussion.  But couldn't those proposals be discussed on the
list as they are formed, rather than waiting months for an I-D?

>>1.  The effect of a request not having an Accept-Encoding or Accept-Charset
>>has flipped completely from 00 to 01.  This seems to make the doubtful
>>assumption that current implementations of clients which don't produce these
>>headers can accept any encoding or character set.
>
>That was decided just before Danvers, was discussed at the meeting, and
>should be in the minutes (they are now pointed to by my WG page, though
>I never received a copy either and they contain many errors because they
>were not posted to the list for review prior to being submitted).

I just read the Danvers minutes, and I didn't see this discussed.  When you
say "decided just before Danvers" do you mean it was discussed here?  If so,
could you point me to it in the archives so I can get up to speed on the
discussion that occured at the time?

>All current browsers do accept all formats, in the form of the Save As..
>dialog.  The WG decided that it was better to assume the best than to
>require all clients to be compliant before the feature could be used.

This isn't true.  There are several browsers which will break if, for
example, they get an encoded file (because they don't parse
Content-Encoding).  By this logic, we should also have q default to a
non-zero value for those browsers which don't include */* in their Accept
field (of which there are some).

Also, as I pointed out in item 5 of my last note, not all HTTP clients are
browsers.  An automated WWW searching tool (for example) won't have a Save
As option.  A kiosk-based browser likely wouldn't have a Save As option.
They would just break under this change.  Also, under the new draft, there's
absolutely no way for these types of applications to say that they won't
accept certain encodings and charsets, since even including the headers they
can only get qe and qc down to 0.001.

>>3.  The spec allows you to specify "Accept: " but doesn't say what the
>>effect is.  My reading seems to indicate that this means no MIME type is
>>acceptable, 
>>but it's somewhat ambiguous.
>
>Yes.  What should the definition be?

Having it mean no MIME type is acceptible might be useful as a way to force
a 406 response.  That could provide a consistent way for a client to get a
list of varients for a URI.  If we decide this is desirable, it should be
made explicit.

--
Jim Seidman, Senior Software Engineer
Spyglass Inc., 1230 E. Diehl Road, Naperville IL 60563

Received on Wednesday, 9 August 1995 08:08:29 UTC