Re: Draft text: The Core Feature Set (Sections 1 - 4)

Larry Masinter:
>
>The new proposal for media type registration proposes a different
>syntax for standards track, vendor, personal, and experimental media
>type trees. The factors that motivated making the status of a
>registration syntactically visible in the media type name might well
>also apply to feature names.

Yes, I agree the same factors may apply.  I don't know that these
factors are, though.  The mime-reg draft does not really tell.

> Your examples make no such distinction.

Don't worry, they will be updated if we decide to have a particular
mechanism for making the distinction.

[...]
>>  - feature tag registration document: standards track
>
>My understanding is that 'process' documents ("how you go about
>registering X") are usually candidates for "BCP" status rather than
>standards track.

Oh. OK.

>> - core feature set: informational, contents registered with IANA
>
>If the 'process' distinguishes between standards-track features and
>non-standards-track features, then some of the features in the core
>feature set will have to be standards track and not informational.

I'd rather avoid the potentially endless discussions needed to
separate the feature tags in the core set into `standards track' and
`vendor specific' feature tags.  I don't think that would be a
productive use of http-wg (and html-wg) time.  The core set aims to
record the current status of the marketplace (and this record can be
an informational RFC with only `vendor specific' tags), it does not
attempt to record IETF recommendations or certifications.

Mind you, I think we should allow for the creation of standards track
feature tags by any IETF wg that wants to.  But I don't think _we_
want to bother with standards-track discussions.

>This sounds like a lot of process without content, but I think the net
>effect is that feature negotiation may have to change:
>
>-  media features that are media-type independent (e.g., screen
>   resolution) might need to have all of the same options: standards
>   track, vendor, private and experimental trees. Think of the
>   registration mechanism as an extension to existing MIME practice.

The four trees are not existing MIME practice yet, and I think it
would be very dangerous to copy them without careful thought.  You are
_not_ copying tried and tested technology, you are copying an
attempted fix to a mechanism which did not work for the web.

>-  media features that apply only to one media type (e.g., html
>   table version) might be negotiated with a different style of
>   content negotiation, e.g., treat them as parameters.

If you are thinking about MIME type parameters, we established some
time ago that they are only allowed to express very few of the things
things you want to express in a web context.

And I don't think we need a new style of content negotiation in
addition to feature negotiation.  The feature negotiation framework can
handle `single media type features' perfectly.  If you want to
separate `general features' from `single media type features', split
the feature tag namespace into two parts, don't duplicate the feature
negotiation mechanism in order to get a second namespace.

>-  feature negotiation for protocol extensions (e.g., rather than
>   media type extensions) should be rationalized with PEP.

This has been the idea all along; TCN negotiates representations, not
transmission methods.  Protocol extensions are beyond the scope of
TCN, and thus beyond the scope of the feature tag namespace.

>Regards,
>
>Larry

Koen.

Received on Monday, 7 October 1996 02:45:07 UTC