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

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

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:

        Negotiate: 1.0, 3,5

     (presumably 3.5 since that is the 'highest')

        Negotiate: 1.0, 1.1

     (could be 1.0 because that is the only exact match, or
     1.1 since that is a higher version, although not exact)

        Negotiate: 1.0, 3.0

     (similar to above - is it best to pick as exact match or the
     'highest'?)

        Negotiate: 1.0, *

     (again, pick exact match or pick highest?)

        Negotiate: trans

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

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?
    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
    what algorithm and therefore what variant and type of response
    is returned'.

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.
    For example, is the following feature-expr valid:

       bleb = "on"

    (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"

    and

       bleb = < 100 - 200 >

    (and so on). Not allowing any LWS in the definition of feature-expr
    and fpred would make parsing much easier and quicker. None of the
    examples of feature lists and attributes show white space (except
    between with items in #(...) and %... lists).


Paul
--
Paul Sutton, Technical Director, UK Web ---- http://www.ukweb.com/~paul/
Editor, Apache Week .. the latest Apache news http://www.apacheweek.com/

Received on Thursday, 20 February 1997 05:43:06 UTC