Re: draft-ietf-http-negotiation-02.txt
Graham Klyne (GK@acm.org)
Tue, 15 Jul 1997 20:53:18 +0100
At 07:59 PM 7/14/97 +0200, Koen Holtman wrote:
>>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 think I'm getting the idea. If I understand correctly, it would not, in
general, be possible for some non-TCN negotiation scheme to provide
information in the 'Alternates:' header also used for a TCN resource response.
>>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
I cannot find a syntax production for feature-set in your draft. I would
judge that this concept is "inlined" in the 'Accept-features:' header
description.
>> 'Accept-features:' --> feature-expr --> ftag
>>
>> 'Alternates:' --> variant-description -->
>> variant-attribute-list --> ) feature-list
>> 'Content-features:' --> )
>>
>> feature-list --> fpred --> ftag
>>
>[...]
>>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.
OK, I'm still not convinced, but that leaves the ball in my court.
I think it would be possible to construct a symmetric framework which can
be subsetted (asymmetrically) down to your proposed framework for
deployment within HTTP, and hence I believe should overcome your concern
regarding complexity for HTTP content authors.
When time permits, I shall attempt to construct a proposal to address this
issue. That will be fairly close to the top of my priority list, but I've
a vacation coming up so it could be a while.
>>* 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.
Sorry! I should have said 4.8, not 4.7, in which you say "really a
sub-dimension of the feature dimension". I understand the
'extension-token' of 5.7 to introduce such a *sub*-dimension.
This is a really trivial matter. I think it's the 'accident of history'
(ref some previous message) which tends to muddy the waters here.
>>* 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.
Fine! That certainly removes the implication which I felt was created by
binding the statement to 'the current request'.
>>* 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.
Or simply cases where thr truth of an 'fpred' actually represents a
degradation in quality, or vice versa.
>>* 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.
Aha! So Normal and Choice responses containing a transparently negotiated
resource are required to carry an 'Alternates' header?
GK.
---
------------
Graham Klyne
GK@ACM.ORG