[gopher] Re: Item Type Suggestions

[Kyevan <kyevan@xxxxxxxxxxx>]

What about the whole world of text-based formats? (text/*)?

I think it might make most sense to put text/* under 1, application/* 
under 9, image/* under I, and audio/* under s.

As a practical matter, for the moment, it might be easiest to just 
prohibit message/* and multipart/*, since the only use I can see 
gopher-wise would be multipart/appledouble, and there it makes more 
sense to use binhex and item type 4. example/* and */example are 
entirely invalid (outside documentation), of course!

video/* and model/* could be either shoved under 9, or we could define 
item types for them. Having item types that parallel the base Internet 
media types seems like it would make sense and would ease conversion... 
but would possibly break compatibility with older clients. Actually, I 
and s have that problem too, though they're wide-spread enough to be 
mentioned on Wikipedia (which, admittedly, could just be one editor 
using them...)

Add fallback types to the hypothetical pie-in-the-sky Gopher Perfect 
that will be specified around the same time as all that vaporware we've 
been 'promised' over the years comes out, I guess. :P

Additionaly, might we want to use something like 
application/[X-]gopher-menu as a type for 0? I mean, it seems like it 
would be nice to have SOMETHING to put in a MIME type-related field for 
menus, if for no other reason than to look nicer to humans reading the 
menu... and besides, then you could do stupid things like return gopher 
menus over http :P

-- Kyevan

Jay Nemrow wrote:
> Also, if we are to deal with mime types at all, I am thinking that all
> of them must be put under the 9 item type, no matter what, just to
> keep old clients from breaking.  If you put a .doc file under the 0
> menu type, the old client wants to dump that to screen as text and you
> will see gibberish and probably crash things.  Everything that doesn't
> fit into the established types will have to be 9 item types, as far as
> I can see.