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

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. Your examples make no such distinction.

>  - main TCN document : standards track

OK
>  - 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.

> - 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.

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.

-  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.

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

Regards,

Larry