Testing the waters for text/troff

[ned.freed at mrochek.com]

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

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