Reduction Proposals by: JumpJet July 2008 ----------------------- "Item-types" specify resources that are both static files and "services". It is extremely important that ALL files on a server be assigned an Item-type. Tweaks I am proposing to Item-types deal mostly with the handling of static files, rather than the identification of services being connected to. I feel that Item-types do not hold the significance they once did, and can be made BROADER in their scope (i.e., just general indicators of a files purpose, such as: s = any kind of Sound file, g = any kind of Graphic file, etc.). The great thing about many modern file openers are that they are able to distinguish for themselves the type of file they are being asked to open, so you don't have to endlessly keep creating new Item-types to help them out. Remember that Gopher was originally written as a CWIS for a single university. Item-types were selected primarily because they were at the time commonly being used by students and staff at UMN, and for little other reason. I suggest falling back to the following Item-type designations, because they better reflect the kinds of files that are now being served up. Efforts have been made to minimize drastic changes, in order to maximize compatibility with older Gopher Clients: 0 = Plain text file 1 = Directory 2 = Connect to a CSO (qi/ph phonebook) service 3 = ERROR 4 = Unspecified non-executable file 5 = Any kind of binary archive file, or binary disk-image file 6 = Any kind of encoded binary-to-text file 7 = Connect to a WAIS (document search) service 8 = Connect to a TelNet service, as any kind of terminal 9 = Unspecified executable file {and files of an unknown format} g and G = Any kind of Graphic file h and H = Any kind of stand-alone HyperText Markup Language file i and I = Informational text that is displayed as if it was a normal file name, but does not NECESSARILY link to anything. p and P = Any kind of Portable Document Format file s and S = Any kind of Sound file t and T = Any kind of Spreadsheet file v and V = Any kind of Video file w and W = Any kind of Word Processor file + = Shorthand for a redundant server To prevent errors, I recommend that letters be "case neutral" (so for example type "I" and "i" would BOTH be the indicators of an "Informational text"). "8" has absorbed "TN3270", due to the limited usage of IBM System/360 TN3270, ["T" has been re-purposed as another way to specify "t" - spreadsheet]. "6" has absorbed "BinHex", due to the limited usage of Classic Mac BinHex, ["4" has been re-purposed to mean: "any unspecified non-executable file"]. "g" has absorbed "image files other than GIF", because combining makes sense, ["I" has been re-purposed as another way to specify "i" - information]. New item-types: "p" - Because PDF files are now a major file type category "t" - Because spreadsheet files are now a major file type category "v" - Because video files are now categorized separately from graphic files "w" - Because word processor files are now a major file type category Note: I chose to re-purpose "4", "I" and "T", rather than choosing new Item-types, because it is extremely unlikely that the re-purposing of these Item-types would produce even a blip of inconvenience, and by using them I don't have to steal from the limited pool of remaining unused letters. Upper case "T" might perhaps be an issue with a few ancient clients, but lower case "t" will not (the ultimate solution being not to use ANY upper case letters to designate an Item-type residing on your server). Examples of how some files might be grouped under my proposed Item-types: Type 0 = DIZ, TXT Type 4 = ASM, DB, PPT, TTF Type 5 = ARC, GZ, ISO, LHA, LZH, RAR, TAR, TGZ, Z, ZIP Type 6 = HQX, SEA, UUE Type 9 = COM, DLL, EXE Type g = BMP, GIF, JPG, PNG, TIFF Type h = HTM, HTML Type p = PDF Type s = AU, MP3, WAV Type t = WKS, XLS Type v = AVI, MOV, MPG Type w = DOC, RTF ============================================================================ ============================================================================ Expansion Proposasls by: Cameron Kaiser July 2008 ------------------------ Right now, the type list I work off of looks like this: 0-9 the usual suspects s sound file (wide type -- handled internally as application/octet-stream) ; movie file (don't ask me, this is something I've seen used historically; wide type) h HTML g GIF p PNG d PDF I generic image T 3270 i info My proposal is: - avoid typographical characters due to URL encoding problems, with ; as the sole historically tolerated exception (deprecated but supported) - 0-9 are well-defined and atomic and don't change - a-z represent specific MIME types for document classes (s being exception) such as PDFs, images, RTF, HTML, XML, etc. immediate changes: j JPEG t TIFF b BMP r RTF x XML c CSS f favicon k XBM (eKs Bee Em) s deprecated but supported - A-S represent specific MIME types for media or interactive classes such as WAV, AIFF, AAC, MP3, MOV, AVI, OGG, etc. (I being exception). Since many of these share the first character, reserve mnemonic types for free or common codecs such as MP3 or OGG. immediate changes: O OGG H tHeora (sorry) M MP3 A AVI S WAV Q QuickTime MOV I deprecated but supported - T remains 3270 - U-Z reserved for application specific internal handlers and can be used freely with client-defined behaviour for internal URLs (such as using a U item type to run a different client handler, etc.) ---------- Incidentally, I reconsidered (r, RTF); maybe a better one would be (r, RSS) and (t, RTF)?