- From: Larry Masinter <masinter@parc.xerox.com>
- Date: Sun, 6 Oct 1996 13:43:41 PDT
- To: koen@win.tue.nl
- Cc: koen@win.tue.nl, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
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
Received on Sunday, 6 October 1996 13:56:36 UTC