Re: Questions on draft-ietf-http-negotiation-00.txt

Paul Sutton:
>
>First, a typo: examples in section 10.2 show "Accept: text/html, *". "*" 
>is not valid media type on the Accept header. 

Oops, thanks for catching that.

>
>Now for a few questions:
>
>1.  What is the strategy for choosing an rvsa algorithm? For example,
>    if server can handle versions 1.0, 1.3 and 3.5, what should it
>    pick to handle each of the following requests:

The picking strategy is beyond the scope of the specification: the server
can pick whichever algorithm is allowed by the header.

>
>        Negotiate: 1.0, 3,5
>
>     (presumably 3.5 since that is the 'highest')

Maybe 3.5 is an extemely simple algorithm that generally makes choices
inferior to 1.0.  The point is, if the server implements both, the server
author will now what preference to code.

[...]
>        Negotiate: trans
>
>     (UA supports tcn but doesn't appear to support any rvsa-version.
>     Should the server pick any version, or not use tcn?)

The server must send a list response in this case.  It may not run a rvsa
with this header.

>2.  Should the response include "Vary: negotiate" if the resource is
>    capable of being transparently negotiated but none of the
>    rvsa-versions listed on the Negotiate header are acceptable?

Yes.  This is really an issue of interpreting 1.1.  Vary: negotiate may only
be omitted if the server sends the same response for _every_ negotiate
header.

>    In this case the contents of the Negotiate header is used to
>    determine whether or not to perform tcn, so Vary: negotiate
>    should be returned in _all_ responses, not just tcn responses,
>    of this resource. 
>
>    In particular, should section 10.6.1 really mean to say '....  servers
>    use the information in the Negotiate header when choosing
>    whether to use a tcn algorithm, and if so, this header determines
                      ^^^^^^^^^^^^^

I assume you mean variant selection algorithm.  A server does TCN even if it
does not run a variant selection algorithm.

>    what algorithm and therefore what variant and type of response
>    is returned'.

No, the current text is correct.  In HTTP/1.1 terms, a list response is also
a response which contains particular variant data.  Vary does not just cover
the possible variation among choice responses, it covers the variation among
all non-error responses. (Yes, I know the `variant' terminology is a bit
confusing.  We never got this quite right in 1.1.)

>3.  In section 6.2 and 6.3 can you clarify whether LWS is allowed between
>    the elements of the definition of feature-expr and fpred.

TCN uses the HTTP/1.1 grammar, so if things are unclear, this is a fault in
the 1.1 spec :) .

>    For example, is the following feature-expr valid:
>
>       bleb = "on"

Yes.

>    (rfc2068 allows LWS between tokens and between tokens and tspecials.
>    ftag and tag-value are tokens, and "=" is a tspecial). If LWS is allowed
>    here, what about
>
>       bleb ! = "off"

Invalid, if I read 1.1 right.

>
>    and
>
>       bleb = < 100 - 200 >

Invalid because of the = < .

>    (and so on). Not allowing any LWS in the definition of feature-expr
>    and fpred would make parsing much easier and quicker.

I have implemented a parser, and had no particular problems with LWS.  The
idea is that server programs internally use the same LWS-aware parsing
primitives for both TCN and HTTP/1.1 (and also HTTP/1.0, by the way).
Disallowing LWS in TCN where 1.1 allows it would therefore not make life
easier for servers.

>     None of the
>    examples of feature lists and attributes show white space (except
>    between with items in #(...) and %... lists).

True.  I'll add some examples with whitespace to bring the point across.  I
considered adding some before, but I decided against it because the 1.1 spec
also does not have such examples.  Maybe such examples should be in the 1.1
spec too.

>Paul

Thanks for your comments,

Koen.

Received on Thursday, 20 February 1997 14:37:19 UTC