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