W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 1996

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

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
Message-Id: <96Oct6.134341pdt."2757"@golden.parc.xerox.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1706
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

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:00 UTC