
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).