Re: feature negotiation

>> [## Question to be resolved: Should a rudimentary feature negotiation
>> facilities that work for 90% of the cases be added as a stopgap??
[...]
>I think we should just put this as a separate issue.
>
>Here's a strawman proposal:
>
>*   request that IANA extend media type registrations to allow
>    registration of feature names for each media type.
>    90% solution says: feature names are atomic, contain
>    only alphanumeric characters, feature registration
>    for an Internet Media Type requires same documentation
>    rules as for Media Type but no waiting period (since
>    there are no additional security considerations).
>
>*    Extend syntax of Accept: to allow
>     :features=f1;f2;f3;f4
>
>Example:
>
>Register "color, 24bit" to image/gif, "color" to
>application/postscript and "tables, font, style, center" to text/html.
>
>Accept: text/html;version=2:q=0.8:features=tables;font

Larry,

Sorry to be hitting this discussion at such a late date, but I haven't had
anywhere near the time available lately as I'd like to devote to this.

I won't pretend to understand all the server-side details of content
negotiation, but there are several issues in client-side HTML feature
negotiation that I don't think could be handled adequately without
additional feature keyword specification, and I'd like to at throw this on
the table to possibly flesh out some of the details of an IANA
registration.

As Brian has mentioned, I've made statements about this previously and have
incorporated some of these thoughts in the latest versions of the modular
draft, which I had planned on submitting last week, but am currently
inquiring as to whether or not it is considered an ietf discussion item.
There are two related drafts, the modular DTD draft and an FPI naming
scheme draft, a very rough version of which is available at:

    http://www.stonehand.com/murray/draft-altheim-fpi-ptd-00.txt

Appendix B discusses a possible feature negotiation scenario. I haven't
updated the e-text to match my handwritten notes, but it provides a rough
sketch with some things I have or need to fix. I will try to update this
document to a version altheim-02 this week, incorporating these notes. It
is currently not ready for draft submission, so please consider it a
work-in-progress.

Basically, I would make the claim that we need three items in a
registration scheme: ownerID, feature name, and version number. If the
resultant keyword is considered too long, a shortened keyword could be used
so long as it was associated in the registration with the rest. Having a
unique ownerID allows developers to operate safely within their own
namespace. Rather than run my mouth here, I'll recommend reading Appendix B
mentioned above.

Murray

______________________________________________________
    Murray Altheim, Program Manager
    Spyglass, Inc., Cambridge, Massachusetts
    email: <mailto:murray@spyglass.com>
    http:  <http://www.stonehand.com/murray/murray.htm>

Received on Sunday, 25 February 1996 21:46:43 UTC