- From: Koen Holtman <koen@win.tue.nl>
- Date: Mon, 14 Jul 1997 19:59:59 +0200 (MET DST)
- To: Graham Klyne <GK@acm.org>
- Cc: koen@win.tue.nl, http-wg@cuckoo.hpl.hp.com
Graham Klyne: > >Koen, > >I am taking a second bite at understanding your negotiation draft, and have >a few more questions and comments for you: > >At 08:23 PM 6/7/97 +0200, Koen Holtman wrote: >>> >>>* 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. > >I don't understand this response, which probably means I still don't >understand the full implications of TCN. The kind of re-use which is encouraged at the end of 4.10 is not really particular to TCN, it is a general thing in the HTTP protocol suite. So I guess what you are missing is the general picture of how protocol elements are re-used in HTTP. Re-use in HTTP is often creative abuse. For example, HTTP/1.1 abuses the HTTP/1.0 semantics of Expires: <yesterday> to tunnel various things safely through HTTP/1.0 proxies. 1.1 will add Expires to responses which contain fresh information (from a 1.1 viewpoint), even even though this means violating the letter of the 1.0 protocol, in which Expires is supposed to tell when the content gets stale. So, though 1.1 reuses the 1.0 expires header, it pays no attention whatsoever to the `meaning' which is attributed to this header by 1.0. It only pays attention to the plain semantics defined by 1.0. As another example of creative abuse, TCN defines `structured entity tags', and goes on to creatively abuse the semantics of the 1.1 entity tag related headers, even though 1.1 declares that entity tags are opaque. In HTTP practice, a protocol extension is allowed to ignore everything but the plain semantics of the protocol elements which are reused. This means that TCN cannot be very specific about the ways in which its protocol elements may be reused. Basically, everything goes. Back to your question: how might invocation of an "other negotiation scheme" be distinguished from your transparent negotiation? The answer is that an other negotiation scheme, say the X scheme, can distinguish itself in any way it wants to. It would presumably do so with new keywords. But it could also use PEP, for example. Also, there is no requirement that clients which do not understand the X scheme, for example plain 1.1 clients or 1.1+TCN clients, are able to detect that the X scheme is being used. The X scheme may even trick a TCN-capable client into thinking it is dealing with a TCN-negotiated resource, so that the client, following the TCN spec semantics, takes some action which happens to suit the purposes of the X scheme. >But on reflection and partial re-reading of the draft I have formed the >idea that the features used by TCN are identified by virtue of appearing in >an 'Alternates' header. But the description of 'Alternates' suggests that >this understanding is, at best, incomplete. I think you are confusing the features _of_ TCN (i.e. the TCN protocol elements) with the feature tags used by TCN here, but I am not sure. [...] >I've constructed myself a little graph showing the relationships between >the various headers and feature-related syntax productions. Have I missed >anything vital here? No, this looks about right, though I would add feature-set --> ftag > 'Accept-features:' --> feature-expr --> ftag > > 'Alternates:' --> variant-description --> > variant-attribute-list --> ) feature-list > 'Content-features:' --> ) > > feature-list --> fpred --> ftag > >I conclude from this that 'feature-expr' and 'fpred' are counterparts, in >that 'feature-expr' describes the features of a message recipient (more >strictly: an HTTP client), and 'fpred' describes features of a message >value which may be supplied by a server (a 'variant'; a particular >representation of a resource). No, I would not put it this way. You are trying to construct a symmetry between sender and receiver which is not present. feature-expr and fpred are not counterparts: fpreds are part of the core semantics of the protocol and feature-exprs are only part of an optimization device. [...] >My own thinking about the issues of content negotiation (posted to the >HTTP-WG list) leads me to believe that the process should be performed >within a symmetric framework (at least insofar as the identification of >negotiable features is concerned). Therefore I find myself questioning the >asymmetry in your proposal. See my response to your message `Content negotiation requirements'. Differences between feature-expr and fpred are not a flaw in the symmetry of TCN, they are symptoms of its fundamental asymmetry. [...] > >And I have some more editorial comments regarding your draft: > >* Section 5.7: > >I think the reference to "new dimensions" of negotiation contradicts >section 4.7. I'm not sure what you mean here, I see no contradiction. The `future specifications' do not need to be specifications of TCN. >* Section 6.3, 1st para: > >This implies that a feature predicate can exist *only* in the context of a >specific request. ?? I don't read it as implying that, but I'll change it to: Feature predicates are predicates on the contents of feature sets. >* Section 6.4: > >I assume that true-improvement < 1 or false-degradation > 1 are permitted? Yes. This will make life easier for some automatic predicate generators. >* Section 8.4: > >Are there any circumstances in which a response from a transparently >negotiable resource is not required to include an 'Alternates:' header? Yes. If the response is an error, list or adhoc response, Alternates need not be included. >GK. Thanks for your comments, Koen.
Received on Monday, 14 July 1997 11:02:36 UTC