At 01:03 PM 5/9/00 -0700, Bill Karwin wrote:

>
>subtypes 100..199 = raster image formats (gif, jpg, tiff, bmp, ico, png,
>etc.)
>subtypes 200..299 = audio formats (wav, au, mp3, ra, etc.)
>subtypes 300..399 = video formats (mpeg, mov, avi, qt, etc.)
>subtypes 400..499 = rich text formats (rtf, html, xml, sgml, dvi, ps, eps,
>mif, msword5, msword6, msword7, msword8, etc.)
>subtypes 500..599 = executable code formats (Intel ELF, Intel COFF, Intel
>OMF, Intel a.out, SPARC ELF, etc.)
>subtypes 600..699 = source code file formats (SQL, C, C++, Delphi, Pascal,
>etc.)
>subtypes 700..799 = archive and compressed file formats (GNU gzip, Windows
>zip (LZW), tar, tar.gz, jar, Java zip, Arc, Zoo, Arj, Pak, Cab, Unix
>compress, Unix compact, etc.)
>
>One could go on and on with such groupings.

What is the advantage of a wholey subtype space? Since a filter
is specific pair of subtypes, no semantic significant could apply
to a range. I will concede that this is mostly a question of
taste, but I prefer dense numbering schema.

Having said that, I think we should resist assign subtypes unless
somebody actually wants to use it. We shouldn't be stingy, but I
don't see the point of assigning subtypes on speculation.

I think the minimum standard for assignment of a subtype in the
"Interbase" space should be:

1. A bona fide intention to generate a filter.
2. A publically accessable format specification



Jim Starkey