Re: New feature negotiation syntax

Larry Masinter:
>
>What do you think about splitting out the 'Requirements'
>part of the TCN document, and seeing if we can release it
>as an Informational RFC that is a product of the working group.

Splitting out the TCN requirements could be done.  I don't know how
useful such a document would be, however, and am hesitant to spend
editorial time on it if there is no clear demand.

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.

>The exact proposal, then, can be released as Experimental.
>
>That would encourage experimentation, and allow simple
>migration to standards track if experimentation proved it
>successful as a way of dealing with things like handhelds,
>embedded web browsers in your cell phone & microwave oven,
>etc.

Hmm, sounds good.  I'd rather freeze it as a proposed standard, and
decide later whether to progress it on the standards track or move to
experimental (i.e. the model we seem to be using for hit metering),
but freezing it as experimental first would also be fine.

At the moment, I'm more concerned about freezing this thing than about
converging on what the long-term IETF plans for content negotiation
should be.  Scott Lawrence tells me that Agranat Systems is
implementing parts already, and that they would like to see it frozen
yesterday.

[...]
>Could we get three documents finished by August?
>
>  "Requirements for Content Negotiation" => Informational RFC

Make that "Requirements for Transparent Content Negotiation".

>  "Registration of features for content negotiation" => BCP
>  "Transparent Content Negotiation in HTTP" => Experimental

August sounds good.  If the milestone says something specific like
`freezing transparent content negotiation as Experimental', with the
understanding that there won't be long discussions about whether TCN
supports everything people ever want to do, August is a realistic
date.

TCN was designed to be a big improvement over the HTTP/1.0 way of
negotiation, and that is the claim I want to make for it.  I do not
want to claim that TCN is the ultimate Web negotiation solution, and I
believe that we cannot even talk intelligently about ultimate Web
negotiation solutions before we have seen some partial solutions in
action.

Koen.

Received on Saturday, 31 May 1997 13:22:02 UTC