W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1997

Re: draft-ietf-http-negotiation-02.txt

From: Koen Holtman <koen@win.tue.nl>
Date: Sat, 7 Jun 1997 20:23:52 +0200 (MET DST)
Message-Id: <199706071823.UAA08998@wsooti08.win.tue.nl>
To: Graham Klyne <GK@acm.org>
Cc: http-wg@cuckoo.hpl.hp.com
Graham Klyne:
>
>Sirs,
>
>I have recently read through 'draft-ietf-http-negotiation-02.txt' with an
>interest in applying some aspects of the negotiation features to messaging
>environments.
>
>As a result of this I have a number of questions and comments regarding
>this draft, which I would like to put to you...

First, thank you for your comments on this work.  My responses are
below.

About your related comments on draft-mutz-http-attributes-02.txt: Andy
Mutz, the main editor of this draft, told me some time ago that he was
going to be off-line for a while, and I don't know if he is back
already.  He has been working on a revision of
draft-mutz-http-attributes-02.txt which would, among other things,
bring the notation in sync with draft-ietf-http-negotiation-02.txt.

>
>* Section 1.2
>
>Typo?: "To make it easier to future negotiation schemes..."

Yes, must be `for future negotiation schemes...'

>
>* Section 2.1
>
>Description of "variant":  do you have any example of a resource variant
>which is not subject to negotiation?

`resource variant' is not a 1.1 term or a transparent content
negotiation term, so I am not sure what you are asking for here.  In
any case, transparent content negotiation does not use the 1.1 term
`variant', so it is not necessary to understand this (admittedly
confusing) 1.1 term, and I'll remove its definition in the next draft.

>Description of "server": the description implies that sending back a
>response is always the primary purpose of a server.  What about HTTP "POST"
>operations or "mailto:..." URLs?

mailto: is not handled by HTTP servers, but you have a point about
POSTs.  The editors of the HTTP/1.1 spec, from which this definition
was reproduced, may want to take note.

>* Section 2.2
>
>"transparently negotiable resource":  I was confused for a while by mention
>of the "Alternates" header without reference to the fact that it is defined
>later in the same draft.

I'll add some forward references to make this clear.

>"variant resource":  what constitutes a "simple" GET request?

Simple means `without use of transparent content negotiation' in this
case.  It is a bit ambiguous, I'll improve it.

>
>* Section 3
>
>Final paragraph:  I understood it was now normal practice to refer to RFC
>2119 for meanings of MUST, SHOULD, etc.

I'll see if I can fix it in the next version.

>* Section 4.9
>
>I have the impression (but cannot remember from where) that there is a
>character limit on the length of headers.  Is there any provision for
>splitting long variant lists over multiple headers?

HTTP/1.x has no limit on the length of headers, and I never heard of a
case where long headers were a problem.  Some old implementations do
have problems with long URLs, maybe this is what you remember.  A long
variant list could theoretically be split over multiple Alternates
headers, but this splitting is discouraged in HTTP (at least, proxies
are encouraged to merge split headers.)

>
>* Sections 4.9, 4.10
>
>I find I am not clear how the negotiation scheme described might interact
>with or be distinguished from other schemes, in view of the exhortation in
>4.10.
>
>I am particularly unnsure of the point number 2 in section 4.10:  does the
>encouragement to re-use the "transport and caching protocol" extend to the
>transparent negotiation header names? 

Yes.

> If so, how might invocation of an "other negotiation scheme" be
>distinguished from your transparent negotiation?

The other scheme would presumably use different keywords in the
Negotiate and TCN headers for the invocation of things with different
semantics.  But the spec does not require this, some schemes could use
other methods to distinguish themselves.

>As an example, I was thinking of a hypothetical service which might be able
>to offer a document in a very wide range of formats by performing
>on-the-fly conversions on request.  It seems that this might be able to use
>the transparent negotiation mechanism to select a file format to be
>provided, but the comments in section 4.9 would seem to discourage this
>kind of use.

The comments on long variant lists in 4.9 apply to variant lists under
HTTP transparent content negotiation on the internet, but need not
necessarily apply to variant lists in other protocols.  

However, if you have a conversion engine which can produce 1000
different types of output, it would normally not be useful to
negotiate on this using a 1000-element TCN variant list.  One would
presumably extend the TCN variant list notation so that it can
compactly describe the conversion engine, or choose another form of
metadata entirely.

Appendix 19.3B (Server-side rendering engines) of
draft-holtman-http-negotiation-03.txt (you can get it at
<URL:http://gewis.win.tue.nl/~koen/conneg/>) has an early design of
such a variant list format extension, but this is not the design I
would use now.

Facilities for rendering engines are not in the current negotiation
draft for a number of reasons, including that they would make the
draft more complex (I already have a hard enough time selling the
current complexity to the WG), and that server-side rendering engines
are not something we want to encourage because they seriously decrease
caching efficiency.  

The idea is that, if we find out we _really_ need negotiation on
server-side rendering engines after the current draft is deployed, we
can easily add it in a downwards compatible way.

>
>* Section 5.6
>
>Your reference to the "UTF-8 character set".  I understood UTF-8 to be an
>*encoding scheme* for the *Unicode* and *ISO 10646* character set.
>
>BTW, I have RFC 2044 as a reference for UTF-8.

I did not have a good reference for UTF-8 when I wrote the above, so I
but I believe that IANA has registered UTF-8 in its charset
repository.  Anyway, I'll use your reference to replace the current
language with more appropriate language.

>
>* Section 6.2
>
>1st para: typo: "and the and preferences".
>
>* Sections 6.3, 6.4, 8.3, 8.4, 8.5:
>
>It was not clear to me exactly how these sections are related.
>
>For example section 6.3 defines 'fpred' but I did not note any explicit
>reference to this in any header definition.

6.4 uses fpred to define the features attribute which is used in
variant descriptions which are used in the Alternates header.  I'll
add more cross-references.

>  I notice that section 8.3
>makes informal references to feature predicates without describing or
>referencing how thay may arise.
>
>This may be because I have missed something;  if so, I humbly suggest that
>some cross-reference from the header description might be helpful.
>
>* Section 8.3
>
>How might feature extensions be used?  I assume this is somehow analagous
>to MIME type parameters in 'Accept' headers, but it is not clear to me from
>where the extension tokens might be derived.

Feature extensions are not analogous to MIME type parameters, in that
a feature tag definition does not have the option of specifying some
extension tokens which would carry more information about the feature.
At least, such extra meta-information would not be processed under the
current draft.

Feature-extensions are intended for use by future negotiation protocol
extensions, where the extension tokens would be global, like the `q='
in the other HTTP Accept headers.

>* Section 8.3 (again)
>
>Final example:  you suggest that 'Accept-Features: colordepth={5}'
>satisfies the predicates 'colordepth=[4-]' and 'colordepth=[4-6]'.  But you
>say that 'ftag={V}' implies that the tag is present with the value V and no
>other value.   To me, 'colordepth=[4-6]' implies 'colordepth' is present
>with values 4, 5 and 6.
>
>Can you clarify what am I missing here?

the predicate 'colordepth=[4-6]' does not mean `the colordepth has the
values 4, 5, and 6' but `the colordepth is in the range 4-6'.  The
exact definition in section 6.3.  So the = in colordepth=[4-6] means
`is in the range', not `equals the range'.  Unfortunately, we don't
have an epsilon (the set-theoretical is-in operator) in ASCII.

>* Section 8.5
>
>I think more explanation is needed of the relationship between indicated
>feature tags and the response given.

The relationship is a pretty useless one, and I have been wondering
whether I should not remove the header definition entirely.  The idea
is that this header can contain the XYZ in the {features XYZ} of the
corresponding variant description.  With this XYZ, the user agent
could compute the features-related quality degradation factor of the
response, using the rules in section 6.4.

I'll see if I can add a longer explanation in the next draft.  I may
end up removing the header completely.

>
>-----
>
>Looking back over my comments, it seems they are all either trivial
>drafting points or problems I am having in understanding the detail in the
>draft.
>
>The former, I hope you find helpful.  As to the latter, I offer the
>suggestion that placing cross-references from the protocol header
>descriptions (where the broad intent is fairly clear) to the relevant
>descriptions in the preceding body of the document would make it easier to
>follow for those of us who are not steeped in HTTP usage and lore.
>
>Regarding the "Dimensions of negotiation" (section 4.7):
>It seems to me that dimensions 1-3 are singled out by accident of history
>(i.e. they are already present in HTTP) rather than that they have any
>particular fundamental significance in the transparent negotiation
>framework.  

Yes, they are an historical accident.

>It would seem to me cleaner to define the feature negotiation
>framework to encompass these "dimensions", then provide definitions of the
>corresponding "Accept-" headers which make them equivalent to some
>corresponding "feature-expr" in the "Accept-Feature" header.  In this way,
>a path to a possible future single unified negotiation mechanism for HTTP
>can be created, through future deprecation of the other "Accept-" 
>headers.

I agree that this is cleaner in some sense, and I even know which
extensions to the feature negotiation framework are needed if the
three historical dimensions are to be merged into it.  (You can find a
design for these extensions in appendix 19.3C (Quality factors in the
Accept-Features header) of draft-holtman-http-negotiation-03.txt at
<URL:http://gewis.win.tue.nl/~koen/conneg/>.)

However, as with server-side rendering engines, this work has been
shelved.  I believe that the paradigm shift to a single unified
dimension would be too radical to gain acceptance in the HTTP-WG.  As
I said, I have a hard time selling complexity to the WG already, and
doubly so if a paradigm shift is involved.  I also suspect that a
single unified dimension would be too radical for at least some CGI
authors.  A lot of people are still thinking primarily in terms of the
accept header metadata formats, and if the spec moves away too far
from this thinking, it will lose its audience.

Like server-side rendering engines, a unified dimension is something
which could be deployed, in a downwards compatible way, in future.  I
have some hopes that for HTTP/2.0, which would be a binary protocol,
the HTTP community will go for a unified scheme which merges all four
dimensions.

>Regards,
>
>GK.

Koen.
Received on Saturday, 7 June 1997 11:26:53 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:44 EDT