Testing the waters for text/troff

[Bruce Lilly]

On Thu November 25 2004 17:53, ned.freed at 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).