Testing the waters for text/troff
I am quite surprised that there is no registered MIME media type for text with nroff/troff markup, especially as that format has traditionally been used for RFC and Internet Draft documents (RFC 2223). I could find no record in the archives of this mailing list of any discussion on the matter. Has there been any proposal for such a text subtype, and if so, what were the reasons that have prevented it from being approved?
I don't remember anything. I guess an explanation for this would be that nroff/troff isn't usually passed to applications directly (i.e. neither for mailers nor for browsers). But if you think it's something you and others want to use, please go ahead and write a draft. At the momement, I can't immagine anything that would lead to a rejection of a well-written proposal. The main issues that I can immagine (although I'm not an expert on ?roff stuff) you will have to deal with would probably have to do with versioning. Regards, Martin. At 04:54 04/11/23, Bruce Lilly wrote:
I am quite surprised that there is no registered MIME media type for text with nroff/troff markup, especially as that format has traditionally been used for RFC and Internet Draft documents (RFC 2223). I could find no record in the archives of this mailing list of any discussion on the matter. Has there been any proposal for such a text subtype, and if so, what were the reasons that have prevented it from being approved?
On Mon November 22 2004 18:51, Martin Duerst wrote:
I don't remember anything. I guess an explanation for this would be that nroff/troff isn't usually passed to applications directly (i.e. neither for mailers nor for browsers).
Curiously, the original Content-Type specification (RFC 1049) did mention troff. I definitely wouldn't want to encourage automatic passing of content to applications, as there are security implications. Nevertheless, the textual content (ignoring formatting directives) is still comprehensible when viewed as ordinary text, comparable to (some would say better than) SGML and its variants. Having a registered label as a text media subtype provides a way to indicate the content type as text (with markup) as opposed to an opaque blob (application/octet-stream).
But if you think it's something you and others want to use, please go ahead and write a draft.
I've started one.
At the momement, I can't immagine anything that would lead to a rejection of a well-written proposal. The main issues that I can immagine (although I'm not an expert on ?roff stuff) you will have to deal with would probably have to do with versioning.
There are certainly version and other compatibility (application- level interoperability) issues, but I believe that they're manageable. Regarding the mechanics of dealing with the registration template, the biggest problem seems to be finding something appropriate for some of the obscure things asked for; for example, I have no idea what "Macintosh File Type Code(s)" is supposed to mean [searching for "Macintosh File Type Code" on the Apple web site yielded zero useful results].
At 7pm on 23/11/04 you (Bruce Lilly) wrote:
some of the obscure things asked for; for example, I have no idea what "Macintosh File Type Code(s)" is supposed to mean [searching for "Macintosh File Type Code" on the Apple web site yielded zero useful results].
Apple calls them 'creator' and 'type' (IIRC) codes. Each file on an Apple (HFS) filesystem is labelled with two four-octet codes, a 'creator' which indicates which application to open with and a 'type' which indicates which of the formats that application supports this file is in. So, for example, a TIFF saved from Photoshop has creator '8BIM' which, for reasons best known to Adobe and Apple, means Photoshop, and type 'tiff'. In your case, as *roff is unused on Apple systems, you could simply state that there is no Apple type code. Ben -- And if you wanna make sense / Whatcha looking at me for? (Fiona Apple) * ben@morrow.me.uk *
On Wed November 24 2004 15:40, Ben Morrow wrote:
At 7pm on 23/11/04 you (Bruce Lilly) wrote:
some of the obscure things asked for; for example, I have no idea what "Macintosh File Type Code(s)" is supposed to mean [searching for "Macintosh File Type Code" on the Apple web site yielded zero useful results].
Apple calls them 'creator' and 'type' (IIRC) codes. Each file on an Apple (HFS) filesystem is labelled with two four-octet codes, a 'creator' which indicates which application to open with and a 'type' which indicates which of the formats that application supports this file is in. So, for example, a TIFF saved from Photoshop has creator '8BIM' which, for reasons best known to Adobe and Apple, means Photoshop, and type 'tiff'.
In my search for "Macintosh File Type Code", I found one document that mentions "File Type Codes", but that is specifically for Mac OS 9 and earlier, not for "Macintosh" in general (indeed, "Macintosh" appears nowhere in that document ( http://docs.info.apple.com/article.html?artnum=55381 )).
In your case, as *roff is unused on Apple systems, you could simply state that there is no Apple type code.
I'm not so sure about that; I have seen literally dozens of references to troff on Apple systems (all seem to refer to "Mac OS X"), so it's certainly not true that "*roff is unused on Apple systems". I recall an Apple UNIX-based system called "Lisa" a few years back, and I know of several versions of troff packages for a variety of platforms, so I would not be at all surprised to find pre-OS-X troff on Apple systems. Aside from this specific exercise, there are broader issues that should be addressed in the media type registration form: 1. If what is meant by "Macintosh File Type Code" is in fact "Mac OS 9 File Type Code" it would help if the registration template were revised to say so. It's too late to help me for this case, but it might save others many hours of fruitless searching. 2. It would also help if there were a pointer to a definitive source of information for these OS-specific, platform-specific codes. As the registration procedure and template seem to be undergoing an update (draft-freed-media-type-reg-01.txt), that might be a good opportunity to clarify such issues (or perhaps to elide that idiosyncratic item altogether).
On Wed November 24 2004 15:40, Ben Morrow wrote:
At 7pm on 23/11/04 you (Bruce Lilly) wrote:
some of the obscure things asked for; for example, I have no idea what "Macintosh File Type Code(s)" is supposed to mean [searching for "Macintosh File Type Code" on the Apple web site yielded zero useful results].
Apple calls them 'creator' and 'type' (IIRC) codes. Each file on an Apple (HFS) filesystem is labelled with two four-octet codes, a 'creator' which indicates which application to open with and a 'type' which indicates which of the formats that application supports this file is in. So, for example, a TIFF saved from Photoshop has creator '8BIM' which, for reasons best known to Adobe and Apple, means Photoshop, and type 'tiff'.
In my search for "Macintosh File Type Code", I found one document that mentions "File Type Codes", but that is specifically for Mac OS 9 and earlier, not for "Macintosh" in general (indeed, "Macintosh" appears nowhere in that document ( http://docs.info.apple.com/article.html?artnum=55381 )).
Well, the very first Google search I did with the string you specified turned up this as the initial reference: http://developer.apple.com/datatype/ This includes a concise explanation of the codes, how they are used, how to register them, how to find what ones are in use, and a FAQ. Seems to me you've made this many times harder than it needed to be.
In your case, as *roff is unused on Apple systems, you could simply state that there is no Apple type code.
I'm not so sure about that; I have seen literally dozens of references to troff on Apple systems (all seem to refer to "Mac OS X"), so it's certainly not true that "*roff is unused on Apple systems". I recall an Apple UNIX-based system called "Lisa" a few years back, and I know of several versions of troff packages for a variety of platforms, so I would not be at all surprised to find pre-OS-X troff on Apple systems.
Mac OS X ships with groff, which provides both nroff and troff emulation. So yes, it is used on Mac OS X. However, AFAIK there is no type code registered for *roff documents.
Aside from this specific exercise, there are broader issues that should be addressed in the media type registration form:
1. If what is meant by "Macintosh File Type Code" is in fact "Mac OS 9 File Type Code" it would help if the registration template were revised to say so.
File type codes are used in all versions of Mac OS, including Mac OS X. As such, the revision you propose is totally inappropriate.
It's too late to help me for this case, but it might save others many hours of fruitless searching.
A simple question about the role of type and creator codes directed at anyone even slightly familiar with Mac OS internals would have sufficed. Or a google search, as I showed above.
2. It would also help if there were a pointer to a definitive source of information for these OS-specific, platform-specific codes.
I'll consider adding a reference to Apple's data type registration page, but whether or not it will survive the RFC Editor is anyone's guess.
As the registration procedure and template seem to be undergoing an update (draft-freed-media-type-reg-01.txt), that might be a good opportunity to clarify such issues (or perhaps to elide that idiosyncratic item altogether).
The fact of the matter is that file type codes are far less ideosyncratic in their behavior, specification, and handling than file name extensions are. Removing the ability to specify them in a registration is therefore completely inappropriate. You're making a mountain out of a molehill here, Bruce. Ned
On Thu November 25 2004 17:53, ned.freed@mrochek.com wrote:
Well, the very first Google search I did with the string you specified turned up this as the initial reference:
http://developer.apple.com/datatype/
This includes a concise explanation of the codes, how they are used, how to register them, how to find what ones are in use, and a FAQ.
Seems to me you've made this many times harder than it needed to be.
You must be seeing things that I can't see; the URL you provided is a page about "Creator Codes" for applications, not "File Codes" for data formats. It not only doesn't say how to determine which codes are in use, it specifically says that Apple won't release that information, but will only tell if a specific code is in use (but won't say by whom or for what).
1. If what is meant by "Macintosh File Type Code" is in fact "Mac OS 9 File Type Code" it would help if the registration template were revised to say so.
File type codes are used in all versions of Mac OS, including Mac OS X. As such, the revision you propose is totally inappropriate.
The suggestion is to change "Macintosh" to "Mac OS", since that is apparently how the codes are referred to by Apple. Not surprising since it appears to be OS-related rather than hardware-related.
A simple question about the role of type and creator codes directed at anyone even slightly familiar with Mac OS internals would have sufficed. Or a google search, as I showed above.
The role isn't the question; which specific code is used is the question (which is as yet unanswered). And your Google search result was about an entirely different type of code.
I'll consider adding a reference to Apple's data type registration page, but whether or not it will survive the RFC Editor is anyone's guess.
Thanks. I guess it would help if there were some assurance that the reference is stable (e.g. if the information appears in some printed documentation).
The fact of the matter is that file type codes are far less ideosyncratic in their behavior, specification, and handling than file name extensions are.
They're idiosyncratic to the extent that they apply only to one particular OS (several versions) on one particular hardware platform, with obscure documentation not amenable to search by non-Apple media type registrants. File name "extensions" are another matter, and I have a paragraph written about them.
Removing the ability to specify them in a registration is therefore completely inappropriate.
Nobody is suggesting removing the ability to specify them, which is certainly possible via the "Any other information that the author deems interesting may be added" portion. Rather it is being suggested that the *requirement* for registrants to determine and specify such idiosyncratic information might be either facilitated (by providing information about how to find that information) or dropped (leaving it as optional information supplied by authors who deem it to be interesting).
On Thu November 25 2004 17:53, ned.freed@mrochek.com wrote:
Well, the very first Google search I did with the string you specified turned up this as the initial reference:
This includes a concise explanation of the codes, how they are used, how to register them, how to find what ones are in use, and a FAQ.
Seems to me you've made this many times harder than it needed to be.
You must be seeing things that I can't see; the URL you provided is a page about "Creator Codes" for applications, not "File Codes" for data formats. It not only doesn't say how to determine which codes are in use, it specifically says that Apple won't release that information, but will only tell if a specific code is in use (but won't say by whom or for what).
Yes, sorry, that's the page for creator codes. However, the many other references that search turns up talk about file type codes in considerable detail.
1. If what is meant by "Macintosh File Type Code" is in fact "Mac OS 9 File Type Code" it would help if the registration template were revised to say so.
File type codes are used in all versions of Mac OS, including Mac OS X. As such, the revision you propose is totally inappropriate.
The suggestion is to change "Macintosh" to "Mac OS", since that is apparently how the codes are referred to by Apple. Not surprising since it appears to be OS-related rather than hardware-related.
Fine, whatever. This is a difference that makes no difference IMO.
A simple question about the role of type and creator codes directed at anyone even slightly familiar with Mac OS internals would have sufficed. Or a google search, as I showed above.
The role isn't the question; which specific code is used is the question (which is as yet unanswered). And your Google search result was about an entirely different type of code.
Actually, the two are tightly interrelated and material discussing one usually discussses the other. The way this works is that the creator code attached to a file is used to determine what application to fire up when you double-click on the file. The type code is then used by the application to determine what sort of data is in the file. Applications also make known the list of file types they can handle. This comes into play when the creating application cannot be found - in this case the OS then has the ability to list all of the applications that handle material of this type. Now, as far as this particular type goes, AFAIK there is no Mac OS GUI version of nroff/troff. As I said before, Mac OS X does ship with groff, but only as a command line utility. While I suppose it is possible that a command line utility could look at file type codes, groff doesn't appear to have been enhanced in this way. As such, it is very unlikely that a file type code has been defined for this format, nor is there any real need to define such a code. HTML files are a lot more uquitous than nroff files and they make do with the TEXT type.
I'll consider adding a reference to Apple's data type registration page, but whether or not it will survive the RFC Editor is anyone's guess.
Thanks. I guess it would help if there were some assurance that the reference is stable (e.g. if the information appears in some printed documentation).
Well, given that the reference doesn't cover file type codes in any detail it seems unreasonable to add it.
The fact of the matter is that file type codes are far less ideosyncratic in their behavior, specification, and handling than file name extensions are.
They're idiosyncratic to the extent that they apply only to one particular OS (several versions) on one particular hardware platform, with obscure documentation not amenable to search by non-Apple media type registrants. File name "extensions" are another matter, and I have a paragraph written about them.
File name extensions are in fact far more ideosyncratic. Not only does their meaning vary widely from one OS to the next, they vary from version to version and even from application to application. As a result there are numerous conflicts and inconsistencies. Not only is it impossible to determine what extension to use for a given object in all cases, it is impossible to say what a given extension means in all cases. If similar issues exist for Mac file type codes I am unaware of them.
Removing the ability to specify them in a registration is therefore completely inappropriate.
Nobody is suggesting removing the ability to specify them, which is certainly possible via the "Any other information that the author deems interesting may be added" portion. Rather it is being suggested that the *requirement* for registrants to determine and specify such idiosyncratic information might be either facilitated (by providing information about how to find that information) or dropped (leaving it as optional information supplied by authors who deem it to be interesting).
There is not now and never has been any requirement that such information be provided as part of any registration. The registration procedure is VERY clear about this. It says: Various sorts of optional information SHOULD be included in the specification of a media type if it is available: So, if you don't know the code, you leave it out. The point was, is, and always has been that if you do know the code you should include it. Why is this so hard to understand? Ned
On Fri November 26 2004 17:47, ned.freed@mrochek.com wrote:
HTML files are a lot more uquitous than nroff files and they make do with the TEXT type. [...]
The fact of the matter is that file type codes are far less ideosyncratic in their behavior, specification, and handling than file name extensions are.
They're idiosyncratic to the extent that they apply only to one particular OS (several versions) on one particular hardware platform, with obscure documentation not amenable to search by non-Apple media type registrants. File name "extensions" are another matter, and I have a paragraph written about them.
File name extensions are in fact far more ideosyncratic. Not only does their meaning vary widely from one OS to the next,
Clearly Mac OS file type codes only apply to one OS, and are meaningless for all other OSes. I.e. their meaning varies from none to some from one OS to the next.
they vary from version to version and even from application to application. As a result there are numerous conflicts and inconsistencies. Not only is it impossible to determine what extension to use for a given object in all cases,
It seems to be impossible to determine what Mac OS file type code to use for a given object (e.g. the case in point).
it is impossible to say what a given extension means in all cases.
Given your statement regarding HTML and "TEXT", it sounds like that's also the case for Mac OS file type codes; it appears that sometimes "TEXT" means plain text and sometimes it means HTML.
If similar issues exist for Mac file type codes I am unaware of them.
See above.
There is not now and never has been any requirement that such information be provided as part of any registration.
Yes, I overstated the case. Sorry.
FYI, I've prepared an Internet Draft for a text/troff type registration. It's available via ftp from: ftp://ftp.isi.edu/in-notes/internet-drafts/draft-lilly-text-troff-00.txt PostScript and PDF versions are also available (there is some difference in the example formatting detail and in such minutiae as copyright symbol vs. "(C)") as: ftp://ftp.isi.edu/in-notes/internet-drafts/draft-lilly-text-troff-00.ps ftp://ftp.isi.edu/in-notes/internet-drafts/draft-lilly-text-troff-00.pdf I plan the following changes for the next version: the command line for the example is missing "pic" more de-PC-ing of boilerplate ("HE/SHE" -- ptui) an additional example (approximation of the diagram in RFC 2821 section 2.1).
Bruce Lilly <blilly@erols.com> writes:
ftp://ftp.isi.edu/in-notes/internet-drafts/draft-lilly-text-troff-00.txt
One comment on the "versions" parameter. If it is only meant to be humanly readable, why can it not be written as a comment? MIME parameters are presumably intended for use by software. It seems unnecessary to allocate a MIME parameter field for something that isn't used by software. The "process" parameter, as in: Content-Type: text/troff ; process="GROFF_NO_SGR=1 dformat | pic -n | troff -ms" makes me feel uneasy. Are MUAs expected to parse the expression to recognize dangerous commands? Is this portable? I looked at how Gnus implement troff files: (".man" . "application/x-troff-man") (".me" . "application/x-troff-me") (".ms" . "application/x-troff-ms") (".tr" . "application/x-troff") (".troff" . "application/x-troff") This suggest that maybe the troff format should not be a considered a separate MIME sub-type, but rather a set of languages. Much like XML. While I think the "+xml" for XML formats was a horrid idea, I can't help but feel that we'd might have the same situation here, as in: text/man+troff text/ms+troff text/mdoc+troff That is, those types would be interpreted by loading the -man, -ms and -mdoc macros, respectively, in troff. That is, "troff -man", "troff -ms", "troff -mdoc" respectively. You could create new types for dformat+pic data. Thanks, Simon
I disagree. I see no reason why you cannot allocate a param as a comment and I support it. Al ----- Original Message ----- From: "Simon Josefsson" <jas@extundo.com> To: <ietf-types@alvestrand.no> Sent: Monday, December 06, 2004 3:59 PM Subject: Re: Testing the waters for text/troff
Bruce Lilly <blilly@erols.com> writes:
ftp://ftp.isi.edu/in-notes/internet-drafts/draft-lilly-text-troff-00.txt
One comment on the "versions" parameter. If it is only meant to be humanly readable, why can it not be written as a comment? MIME parameters are presumably intended for use by software. It seems unnecessary to allocate a MIME parameter field for something that isn't used by software.
The "process" parameter, as in:
Content-Type: text/troff ; process="GROFF_NO_SGR=1 dformat | pic -n | troff -ms"
makes me feel uneasy. Are MUAs expected to parse the expression to recognize dangerous commands? Is this portable?
I looked at how Gnus implement troff files:
(".man" . "application/x-troff-man") (".me" . "application/x-troff-me") (".ms" . "application/x-troff-ms") (".tr" . "application/x-troff") (".troff" . "application/x-troff")
This suggest that maybe the troff format should not be a considered a separate MIME sub-type, but rather a set of languages. Much like XML.
While I think the "+xml" for XML formats was a horrid idea, I can't help but feel that we'd might have the same situation here, as in:
text/man+troff text/ms+troff text/mdoc+troff
That is, those types would be interpreted by loading the -man, -ms and -mdoc macros, respectively, in troff. That is, "troff -man", "troff -ms", "troff -mdoc" respectively. You could create new types for dformat+pic data.
Thanks, Simon
On Mon December 6 2004 15:59, Simon Josefsson wrote:
Bruce Lilly <blilly@erols.com> writes:
ftp://ftp.isi.edu/in-notes/internet-drafts/draft-lilly-text-troff-00.txt
One comment on the "versions" parameter. If it is only meant to be humanly readable, why can it not be written as a comment? MIME parameters are presumably intended for use by software. It seems unnecessary to allocate a MIME parameter field for something that isn't used by software.
The versions parameter is intended to be human-readable. "A comment" is somewhat nebulous (support for comments, as well as specific syntax, may differ in some contexts). Also, there is no expectation that comments will be preserved during transport and processing, whereas there is no reason to believe that any parameter would be discarded. I see nothing in RFCs 2045, 2048 that indicate that parameters are intended solely for machine use. The purpose of labeling some content as a particular media type is presumably to provide some useful metadata about the content, regardless of whether that metadata is used by a human or by a machine.
The "process" parameter, as in:
Content-Type: text/troff ; process="GROFF_NO_SGR=1 dformat | pic -n | troff -ms"
makes me feel uneasy. Are MUAs expected to parse the expression to recognize dangerous commands?
I would say that MUAs may ignore the parameter, or they may offer to run commands subject to user approval. Under no circumstances should execution of general-purpose processing programs be performed by MUAs without user consent -- see RFC 2046 discussion of application/postscript. In this case, similar considerations apply (e.g. while it may be safe for a UA to process this content via deroff, there should be no automatic processing of the originator-specified command pipeline. I believe the issues are discussed in the Security considerations section of the registration template. Bear in mind the fact that the optional process parameter is provided as a means of conveying formatting process information associated with the media; such processing is not necessary to read the *text* in the media (similar to text/sgml).
Is this portable?
Portability issues are addressed in the Interoperability considerations section of the registration template, and via the versions parameter.
I looked at how Gnus implement troff files:
(".man" . "application/x-troff-man") (".me" . "application/x-troff-me") (".ms" . "application/x-troff-ms") (".tr" . "application/x-troff") (".troff" . "application/x-troff")
This suggest that maybe the troff format should not be a considered a separate MIME sub-type, but rather a set of languages. Much like XML.
While I think the "+xml" for XML formats was a horrid idea, I can't help but feel that we'd might have the same situation here, as in:
text/man+troff text/ms+troff text/mdoc+troff
That is, those types would be interpreted by loading the -man, -ms and -mdoc macros, respectively, in troff. That is, "troff -man", "troff -ms", "troff -mdoc" respectively. You could create new types for dformat+pic data.
IMO that way lies madness. Such details do not affect the ability to read *text* in the media. Moreover, there are so many possibilities that the number of media sub-sub-subtypes would be daunting -- I don't need and wouldn't want a text/dformat+chem+grap+pic+eqn+tbl+mm+4014 media type, or a text/dformat+chem+grap+pic+tbl+eqn+mm+4014 media type (depending on whether or not equations appear within tables). Now that might (or might not) make sense for an *application* subtype scheme, but it is uncalled for for the purpose of a *text* media type. I thought I had addressed that issue in section 3 of the draft (Scope of Specification), but I can reword that section more forcefully if necessary.
[I am not a Mac expert...] At 4pm on 25/11/04 you (Bruce Lilly) wrote:
In my search for "Macintosh File Type Code", I found one document that mentions "File Type Codes", but that is specifically for Mac OS 9 and earlier, not for "Macintosh" in general (indeed, "Macintosh" appears nowhere in that document ( http://docs.info.apple.com/article.html?artnum=55381 )).
Yes. Mac OS X and Mac OS Classic (9 and earlier) are completely separate operating systems that happen to look similar. OSX is a perfectly normal BSDish system with a GUI derived from NeXTStep on top of it. AFAIK OSX doesn't use the Classic file type codes at all, though what it does do by way of 'file associations' I'm not sure. I *certainly* hope it doesn't use file extensions...
On Wed November 24 2004 15:40, Ben Morrow wrote:
In your case, as *roff is unused on Apple systems, you could simply state that there is no Apple type code.
I'm not so sure about that; I have seen literally dozens of references to troff on Apple systems (all seem to refer to "Mac OS X"), so it's certainly not true that "*roff is unused on Apple systems". I recall an Apple UNIX-based system called "Lisa" a few years back, and I know of several versions of troff packages for a variety of platforms, so I would not be at all surprised to find pre-OS-X troff on Apple systems.
This is all true; however, the Mac file type codes are only relevant to Mac OS Classic, which very rarely has *roff installed.
Aside from this specific exercise, there are broader issues that should be addressed in the media type registration form: 1. If what is meant by "Macintosh File Type Code" is in fact "Mac OS 9 File Type Code" it would help if the registration template were revised to say so. It's too late to help me for this case, but it might save others many hours of fruitless searching.
This I would definitely agree with.
2. It would also help if there were a pointer to a definitive source of information for these OS-specific, platform-specific codes. As the registration procedure and template seem to be undergoing an update (draft-freed-media-type-reg-01.txt), that might be a good opportunity to clarify such issues (or perhaps to elide that idiosyncratic item altogether).
No, that would be a bad idea, at least until Classic is firmly in the dustbin of history (I don't think it's quite there, yet). Any sane system of file type identifications would use MIME types directly; however, the registry provides a mapping to legacy systems such as Mac OS types and Win32 file extensions for situations such a browser saving a downloaded file, and web servers giving an entity a type without other explicit information. Ben -- And if you wanna make sense / Whatcha looking at me for? (Fiona Apple) * ben@morrow.me.uk *
[I am not a Mac expert...]
I'm not either, but Mac OS X is the primary platform I work on, so I am at least somewhat familiar with how this stuff works.
At 4pm on 25/11/04 you (Bruce Lilly) wrote:
In my search for "Macintosh File Type Code", I found one document that mentions "File Type Codes", but that is specifically for Mac OS 9 and earlier, not for "Macintosh" in general (indeed, "Macintosh" appears nowhere in that document ( http://docs.info.apple.com/article.html?artnum=55381 )).
Yes. Mac OS X and Mac OS Classic (9 and earlier) are completely separate operating systems that happen to look similar. OSX is a perfectly normal BSDish system with a GUI derived from NeXTStep on top of it. AFAIK OSX doesn't use the Classic file type codes at all,
Actually, it does use them, although it also uses file name extensions. The results can get to be a bit messy - I cited a web page in a previous post that discusses this issue to some extent. Note that the messiness has more to do with the fact that some applications pay attention to type codes while others pay attention to file name extensions than it does to any confusion at the OS level. Creator codes are used much more extensively than type codes. However, this is also true of Mac OS 9. Of course this is just common sense: A given file _type_ may be of interest to many applications, but a creator code binds a file to a specific application. Specific information trumps general information.
though what it does do by way of 'file associations' I'm not sure. I *certainly* hope it doesn't use file extensions...
Mac OS X understands file extensions and handles them specially, but AFAIK it does not use them to associate an application with a file. That's still done with type and creator codes. Of course this doesn't prevent specific applications from doing this, and in fact that's exactly what happens. Mozilla on Mac OS X, for example, has a table that maps either MIME types or file name extensions to creator codes. In case you care, here's a discussion of file name extension handling in Mac OS X: http://cocoa.mamasam.com/COCOADEV/2001/09/1/11740.php I will also point out that Mac OS X has various security features surrounding double clicking on files that at least attempt to prevent bad things from happening.
On Wed November 24 2004 15:40, Ben Morrow wrote:
In your case, as *roff is unused on Apple systems, you could simply state that there is no Apple type code.
I'm not so sure about that; I have seen literally dozens of references to troff on Apple systems (all seem to refer to "Mac OS X"), so it's certainly not true that "*roff is unused on Apple systems". I recall an Apple UNIX-based system called "Lisa" a few years back, and I know of several versions of troff packages for a variety of platforms, so I would not be at all surprised to find pre-OS-X troff on Apple systems.
This is all true; however, the Mac file type codes are only relevant to Mac OS Classic, which very rarely has *roff installed.
They aren't. See above.
Aside from this specific exercise, there are broader issues that should be addressed in the media type registration form: 1. If what is meant by "Macintosh File Type Code" is in fact "Mac OS 9 File Type Code" it would help if the registration template were revised to say so. It's too late to help me for this case, but it might save others many hours of fruitless searching.
This I would definitely agree with.
I don't because it is based on an incorrect conclusion.
2. It would also help if there were a pointer to a definitive source of information for these OS-specific, platform-specific codes. As the registration procedure and template seem to be undergoing an update (draft-freed-media-type-reg-01.txt), that might be a good opportunity to clarify such issues (or perhaps to elide that idiosyncratic item altogether).
No, that would be a bad idea, at least until Classic is firmly in the dustbin of history (I don't think it's quite there, yet).
It most certainly isn't, and isn't likely to be for a very long time. I know plenty of people who still use OS 9 and I know of applications people depend on that haven't been ported to OS X yet.
Any sane system of file type identifications would use MIME types directly;
Agreed, but sadly that's not how things work in practice. And our security is the worse for it. Ned
participants (6)
-
Al Costanzo -
Ben Morrow -
Bruce Lilly -
Martin Duerst -
ned.freed＠mrochek.com -
Simon Josefsson