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

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

Received on Tuesday, 15 July 1997 12:58:01 UTC