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

Larry Masinter:
>
>Well, the problem is that some of the features you're proposing to be
>'standards track' are for things that are not themselves standards
>track.

I see what you mean, but I'm not writing the core feature set as a
standards track document, so there is no problem with referencing
things which are not standards track.

Eventually, the tags in the core feature set document will be
registered with IANA.  So the tag descriptions will only have to meet
the (weak) restrictions for feature registration.  The core feature
set document itself could then become an informational RFC, or even an
experimental RFC.

One purpose of the core feature set document is to act as a style
guide for people who want to register features in future.  That means
there must be some examples of referencing to non-standards-track
things (like javascript and server push).

To summarize, we are working on three documents:

 - main TCN document : standards track
 - feature tag registration document: standards track
 - core feature set: informational, contents registered with IANA

We are working on the core set now to have `test cases' for judging
the other two documents.  The core set is not intended as a list of
IETF-approved features.

>Larry

Koen.

Received on Sunday, 6 October 1996 04:50:06 UTC