Re: Negotiation in draft 01

>I have some concerns with how negotiation works in draft 01 as compared to
>draft 00.  Before I list those, when were all of these changes discussed on
>the mailing list?

They were not.  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.  We spent a great deal of time trying
to find the best way to cache responses given the possible presence of
content variants.  Not all of the conclusions made it into the draft, but
the parsing requirements did.

> I looked through all of the archives and couldn't find
>any discussion of this.  (Nor could I find the minutes from the Danvers
>IETF, but even if it was discussed there, it still should have been on the
>mailing list.)

It is on the mailing list now.  Discussing half-formed ideas and
incomplete proposals is a waste of time.  Now that it is written down,
we can all determine its desirability or lack of it from the same
perspective.

>Anyway, here are my concerns:
>
>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).

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.

>2.  All of the Accept-* headers were defined in 00 as requiring at least one
>item.  In 01 they can have 0.  While RFC822 allows this, under 00 every
>HTTP-header had a field-body.  I wouldn't be surprised if some header
>parsers choke on that.  Requiring empty "Accept-Encoding:" and
>"Accept-Charset:" strings to describe the most common case for a client
>could break many existing servers.

Any server that breaks on an empty field value is already broken,
regardless of what the spec requires.  I can restore the 1#( if that
makes people feel better, but it won't make any difference to robust
implementations.  Besides, how is the client supposed to say that they
do know about Accept-Encoding, but don't accept any?

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

>4.  The Accept example in 8.1 shows a "text/html;version=2.0" and a
>"text/html;level=3".  Section 3.4 does not specify a list of parameters.

It does:

      media-type     = type "/" subtype *( ";" parameter )

>Was the use of both "version" and "level" a deliberate attempt to show that
>any parameter name is valid?  It's a little scary to me that someone could
>create an arbitrary parameter name and expect the server to parse it.

Any parameter name *must* be parseable by the server.  Understanding
its value is a separate matter and is dependent on the handler for
that media type.

>(Also, in this case we need to specify a list of reserved attributes, like
>q, ql, mxb, etc.)  We also need to specify what "more specific" 

Where?  I believe Section 9 is an adequate definition for the latter.

>5.  If qe and qc default to 0.001 instead of 0, do we provide a client with
>any way at all to say that it doesn't want encodings and character sets it
>can't handle?  If a web-searching robot, for example, says that it can't
>handle compressed files then it probably really means that, and would
>probably prefer a "406 none acceptable" to something it can't receive.  Yet
>under 01 there's no way for the robot to avoid having such content sent to it.

Yes, that is true.  Unfortunately, current clients do not send an
Accept-Charset header even if they do support multiple charsets.
I was overruled once on this matter, and the WG will have to state clearly
what they want if I am to change it back again.

>6.  The URI description in 8.28 still doesn't address the issue I brought up
>back in June.  Namely, how would a cache practically use the information
>presented in the URI as described?  Since the URI field doesn't have to
>enumerate all of the variants that are available, it doesn't help to know
>what varies unless the next request has an identical entity header for that
>dimension.

Yes, see my other message.

>I bring this up because the 8.28 says "When the caching proxy gets a request
>for that URI, it must forward the request toward the origin server if the
>request profile includes a variant dimension that has not already been
>cached."  In practice, as currently speced, the request must be forwarded
>unless a requset with an identical profile has been made.

I'll need to fix that.  The request only needs to be forwarded if no
characteristics are provided.

 ....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 Tuesday, 8 August 1995 19:27:47 UTC