Testing the waters for text/troff

ned.freed at mrochek.com (ned.freed@mrochek.com) Tue, 03 January 2006 16:22 UTC

From: "ned.freed at mrochek.com"
Date: Tue, 03 Jan 2006 16:22:52 +0000
Subject: Testing the waters for text/troff
In-Reply-To: "Your message dated Thu, 25 Nov 2004 16:13:05 -0500" <200411251613.06413.blilly@erols.com>
References: <200411221454.48418.blilly@erols.com> <200411231921.03262.blilly@erols.com> <20041124204033.GA5030@osiris.mauzo.dyndns.org> <200411251613.06413.blilly@erols.com>
Message-ID: <01LHNM7Z5SR800005R@mauve.mrochek.com>
X-Date: Tue Jan 3 16:22:52 2006

> 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