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 agree, which is why I proposed a 2-week review cycle before the next
draft is produced.

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

Yes, provided that they are not made by the author (me).  My proposals
are made in the form of a new draft -- doing otherwise just increases
the delay between drafts.  I do make mini-proposals during commentary,
but some proposals require more thought.

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

Yes, it was discussed there.  The point was made, by both Henrik and
Dave Kristol, that existing software (XMosaic) did not send an Accept-Encoding
field even when they do accept gzip and compress.  Therefore, the default
should be accept-all.  There were no objections raised at the meeting,
so I recorded it as one of the changes for the next draft, and duly made
that change as soon as I could.  It should also be in the minutes, but
I did not get a chance to review the minutes for accuracy and completeness.

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

Define "break" in a useful manner.  Better, tell me what the draft needs
to say to fix this situation.  If the WG agrees, I *will* change the draft.

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

Right.  So we need to define those semantics.  I suggest that we allow
inclusion of the default charsets, such that

   Accept-Charset: iso-8859-1

implies acceptance of only that charset and US-ASCII (which would always
be implied).  No accept-charset would be the same as accepting all, and
given an accept-charset, unlisted charsets would be qc=0.

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

Yes, I agree.

 ....Roy T. Fielding  Department of ICS, University of California, Irvine USA
                      Visiting Scholar, MIT/LCS + World-Wide Web Consortium
                      (fielding@w3.org)                (fielding@ics.uci.edu)

Received on Wednesday, 9 August 1995 11:41:46 UTC