Re: New feature negotiation syntax

Ted Hardie:
>
>On Jun 4, 11:39pm, Koen Holtman wrote:
>> Subject: Re: New feature negotiation syntax
>Koen writes:
>> Here is the problem I think we were solving:
>>
>>   Problem: The HTTP/1.x negotiation infrastructure (Accept headers,
>>   User-Agent header, Vary) is not good enough.
>>
>> At the core, it is really as simple as that.  Can we agree on this
>> problem description?
>>
>
>I actually think that we identified the problem a bit differently:
>we agreed that Accept headers, if widely and properly used
>would solve all negotiation problems.  The unfortunate
>downside is that they would also swallow all available bandwidth
>in the process and that the processing of all the possible accept headers
>would reduce response time past any conceivable usability threshold.

Yes, but the infinite Accept header problem is only one of the many
problems with the 1.x infrastructure.  As Joel N. Weber pointed out,
another problem is that the current Accept headers do not convey
everything we want conveyed: this is why we have feature negotiation.

Additional problems with the 1.x infrastructure are:

- leads to cache-unfriendly solutions
- leads to stupid user-agent header tricks in servers
- leads to stupid user-agent header tricks in user agents
- robots have problems traversing server-driven negotiated content
- language matching leads to the wrong results for some languages
  (though this is a bit controversial, I have yet to see a list of
   real-life cases where it goes wrong, though I am told these cases 
   exist)
- users cannot correct result of negotiation by hand
- sending long accept headers can be a privacy problem

TCN addresses all of these problems to some extent.

As I said before, I think there are more problems lurking around the
corner, but we won't see them until we have deployed some actual
negotiation mechanisms.

[...]
>That, I think gives us two things to test once TCN is made
>experimental:  is it as good or better than accept headers?
>is there a bandwidth reduction using TCN?

These are two good tests.  Ultimately, the real test is whether the
negotiation infrastructure is improved by adding TCN, and we can see
that by looking if people are using TCN to make available negotiated
content.

>Of course, we would also need to know if real-world experience
>demonstrates some awful, unknown side result.

Yes, that too.

>I personally don't think that a full-blown requirements
>document is needed for this; I believe a strong statement of scope
>at the beginning and a description of what you plan to test
>would be enough.

I agree.

>  Something like:

[...]

This is a bit slanted towards the long accept header problem only, but
otherwise a good start.

>If experience shows that the method does provide the expected savings
>in bandwidth and otherwise performs at least as well as the current
accept
>header method,  the authors intend that the protocol be re-submitted
>to the IESG for consideration as Proposed Standard.  Until that time,
>however, changes in the design are possible, and implementors should
>keep in mind that possiblity."

The part about `changes in the design are possible' is not compatible
with the pressure I get from implementers to freeze the design so that
they can ship.  It has to be something like:

 If it is found that the proposed protocol extension does not perform
 well, a revision of the extension (which is downwards compatible with
 the version in this document), or a completely new protocol extension
 may be proposed.

>Just a quick shot at it,
>                regards,
>                        Ted Hardie
>                        NASA NIC

Koen.

Received on Thursday, 5 June 1997 02:06:23 UTC