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

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.

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.

>>* 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.

To correct my earlier statement, I notice that MIME RFC 2045 section 2.2
defines the term "character set" in the sense that you used it in refering
to UTF-8.

>>* 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've constructed myself a little graph showing the relationships between
the various headers and feature-related syntax productions.  Have I missed
anything vital here?

  '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).

I observe that the syntactic differences between 'feature-expr' and 'fpred'
are really quite small:  where 'fpred' has an allowable instance "[ range
]", 'feature-expr' has "{ tag-value }" and "*".

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.  Further, I believe that a symmetric framework
would ultimately be a simpler framework, because separate sets of concepts
for sender and recipient in a data transfer could be replaced by a single,
common, set of concepts.

>>Regarding the "Dimensions of negotiation" (section 4.7):
>>It seems to me that dimensions 1-3 are singled out by accident of history
>>
>>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 [...]
>
>[...]  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.

I have to agree regarding the complexity.  BUT I cannot escape feeling that
adopting a cleaner solution would help to remove some of this complexity.

It has been my experience that a more general approach to a problem of data
representation can often lead to a simpler solution.  I feel this would be
true in the matter of representing negotiation metadata.


----

And I have some more editorial comments regarding your draft:


* Section 2.2, definition of 'variant description', and section 5.1:

I think there is a small possibility that this terminology could cause some
confusion with the "description" option in a 'variant-attribute'.


* Section 4.9:

Would it be worth noting under "security considerations" the possibility of
a tension between efficiency and security in relation to:

"user agents which implement a scripting language for content rendering are
encouraged to make the availability of this language visible for
transparent content negotiation"

(This as an issue distinct from privacy concerns already mentioned:
scripting languages tend to open security loopholes.)


* Section 5.7:

I think the reference to "new dimensions" of negotiation contradicts
section 4.7.


* Section 6.2, 2nd para:

If I am understanding correctly, the first sentence is not strictly true in
light of the definition in section 6.1.  I understand a 'feature set' to be
a set of feature tags *and associated feature values*.

I note para. 3 goes on to say this.


* Section 6.3, 1st para:

This implies that a feature predicate can exist *only* in the context of a
specific request.  I would have thought a feature predicate would be a
predicate which can be applied to *any* feature set.


* Section 6.4, 3rd para:

I think "...in a variant descriptor..." should read "...in a variant
descriptor or a 'Content-Features:' header...".


* Section 6.4:

I assume that true-improvement < 1 or false-degradation > 1 are permitted?

I also assume that by 'quality degradation factors of the elements' you
mean both 'true-improvement' and 'false-degradation' factors.  It migh be
clearer to say 'quality factor' or 'quality adjustment factor'.


* Section 8.3, 1st para:

You say: "...the presence or absence of certain features in the feature set
for the current request...".

I think the phrase "... the feature set for ..." is unclear:  I think you
mean "... the client's feature set as it relates to ...".

Assuming I am now understanding this issue correctly, I think my earlier
confusion regarding this point was caused by the fact that the header name
'Accept-Features' (being a verb+noun construct) implies that the parameters
are  features (of the server or data) which will be accepted *by* the
client, rather than features *of* the client.  Hence the suggested
re-wording to clarify the issue.


* Section 8.4:

Are there any circumstances in which a response from a transparently
negotiable resource is not required to include an 'Alternates:' header?


* Section 8.5:

You say:
   The Content-Features response header can be used by a server to
   indicate how the presence or absence of particular feature tags in
   the user agent affects the overall quality of the response.

I suggest:
   The Content-Features response header can be used by a server to provide
   feature information relating to the actual resource value returned, thus
   indicating how the presence or absence of particular feature tags in
   the user agent affects the overall quality of the response.


* Section 8.7, middle para:

I think MUST NOT would read better than MUST NEVER.


[[I have not done a detailed read-through of sections 9 onwards]]

GK.
---

------------
Graham Klyne
GK@ACM.ORG

Received on Thursday, 3 July 1997 10:16:54 UTC