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

Larry,
sorry for dropping into the middle without reading all the mail,
but this is a detail:

> A feature like 'implements vendor-B version 2.0 variation of tables'
> shouldn't be standards track if vendor-B's version 2.0 variation of
> tables isn't.

I think we have common practice that we DO include such things in
standards.
Consider:

- IP over Ethernet refers to Ethernet, which is not IETF standard
- PGP in MIME (draft-elkins) is standard, but refers to RFC 1991,
  which is informational
- Most security stuff refers to the RSA algorithm, which isn't
  standards-track
- Most stuff with characters in them refer to either ASCII or
  UNICODE/ISO 10646, none of which are IETF standards-track.

Generally, a standards-track document can refer to anything it wants
to, EXCEPT experimental protocols (because these can, in theory, be
moved onto the standards track if they were really good ideas).

But I'll promise to sit on anything that comes up which doesn't have
at least a reference to a published specification of SOME kind; I don't
care whether it's ITU documents, Addison-Wesley books, WIRED magazine
or something else, as long as it's a stable reference that people can
follow (I'd like to add "at reasonable cost", but that's wishing for
too much as long as we want to include ISO standards :-)

The reason is simply that if we can't say with reasonable clarity WHAT
a feature is, registering it is not terribly useful.

                     Harald A