Re: New feature negotiation syntax

Larry Masinter:
>
   [Koen Holtman:]
>> Call for opinions: If you would like to see a TCN requirements
>> document, please say so on the list or in private e-mail, in which
>> case I'll summarize on the list.  Note that a TCN requirements
>> document will contain things like `it has to be a HTTP extension'
and
>> `it must not rely on Java or any other scripting language'.  This
>> document will not contain all requirements for all forms of
>> negotiation.
>
>Such a document would be useless. The question is not "why this
>particular TCN proposal", but  "what problem is it that TCN
>is supposed to solve".
>
>I think the main requirement is:
>  - Allow a single resource identified by a single URL to
>    serve different entities to different clients without
>    the client having to a priori send all of its features
>    and capabilities with each request.

Yes, that is more or less the main requirement.

>I think there may be a few other requirements, too, but
>what? And if the above is the only requirement, then 
>why _not_ dynamic content?

Larry, it seems that you want me to write a requirements document
which proves that Yaron's approach is wrong.  But I cannot write such
a document, because I think Yaron's approach is right.

I do not see TCN, PEP, and script based negotiation as competing
mechanisms, I see them as complementary.  As I said at www6, it will
be up to the service author do decide which negotiation mechanism, or
which combination of negotiation mechanisms, is appropriate for the
content at hand.

This is what I wrote about it in the latest draft:

 4.10 Relation with other negotiation schemes

   The HTTP/1.x protocol suite allows for many different negotiation
   mechanisms.  Transparent content negotiation specializes in
   scalable, interoperable negotiation of content representations at
   the HTTP level.  It is intended that transparent negotiation will
   co-exist with other negotiation schemes, both open and proprietary,
   which cover different application domains or work at different
   points in the author-to-user chain.  Ultimately, it will be up to
   the resource author to decide which negotiation mechanism, or
   combination of negotiation mechanisms, is most appropriate for the
   task at hand.

   As far as the relation with other negotiation mechanisms is
   concerned, two parts of this specification are particularly
   important:

     1. the syntax and semantics of variant descriptions (section 5-6)

     2. the transport and caching protocol for negotiated data (section
        8-10)

   This specification explicitly encourages other negotiation
   mechanisms to re-use both parts.

Bottom line, I don't see the negotiation issue as an either-or
question, and I'm not volunteering to write an either-or requirements
draft.

I can write something about in which situations TCN would be more
appropriate than script based negotiation, and vice versa, and in
which situations it is appropriate to use them both.  For example, TCN
is nicer on indexing robots, and avoids many of the security and
privacy problems of scripting.  But any such writing about
applicability will be speculative at best, because there will be lots
of considerations we cannot even begin to imagine until we have some
more experience with deployed Web negotiation.

>Regards,
>
>Larry

Koen.

Received on Sunday, 1 June 1997 11:08:53 UTC