- I am skeptical that the type can adequately represent current and future
filesystems. In current form, I don't see how it can represent critical
items from the Macintosh filesystem (for example, the Macintosh filetype I
mention above. I'd be interested to see what Ned has to say regarding VMS
here.) Perhaps specific problems of current filesystems could be coped
with by adding to this draft, but it seems to me that for future growth
we'd wind up needing to reinvent a lot of the registry and standards
process we already have, for use inside this thing.
I talked briefly with Al about this privately and meant to make some additional
comments, but then along came the Chicago IETF and I got, well, sidetracked.
But now is as good a time as any...
There are two issues here: Directory structure and file attributes.
VMS doesn't have the concept of a filesystem within which devices are mounted.
It's the other way around: There are devices at the top level, which may or may
not contain filesystems. There are also pseudo-devices that can be used to
elevate some point in the filesystem hierarchy on a given device to being
another device.
In practice this is a nonissue, however, as people don't move around the
contents of multiple devices. And when you ignore this the semantics of VMS
filesystem actually become a proper subset of those of, say, UNIX. (However,
this does include things like hard links.)
File characteristics are another matter. The current draft doesn't do this
correctly. But it turns out that this is actually a pretty simple problem to
solve for VMS -- there's this thing called the file description language, or
FDL, that can be used to construct a single string that contains all of the
attributes of a file that aren't actually part of the file's data. (BTW, most
VMS filesystems use an on-disk format called ODS-2, which can only accomodate a
single fork per file. But there's a VMS format called Spiralog that can
accomodate multiple forks the way NT systems can.) This includes stuff like
file organization, record size, record type, version limit, global buffer
count, protection, and so on. All told there are about 25 different things you
can put in an FDL string that correspond to stuff that's not actually in the
file data.
FDL strings are quite similar to the application/applefile part of a
multipart/appledouble structure. But the nice thing is that every VMS system
comes fully loaded with routines to generate and process FDL strings. It's a
native structure, it's fully extensible, backwards compatible, the OS people
update it as necessary, and so on. In fact we've been sending them around as a
MIME content-type parameters for years now, which half a dozen different
products from different vendors interoperating very nicely in handling VMS
files via email.
So all you need to do, really, is have a single VMS-specific parameter called,
say, vms-fdl, to store this string in, and you've solved the problem of sending
VMS files around with their attributes intact.
But if this means that every filesystem is going to need its own string
for its own set of file attributes, it does sort of beg the question of
how cross-filesystem mapping will work, both for existing and future
filesystems.
It seems to me that the proposal throws away lots of good work that's been
done with MIME. I agree that it would be nice to have a way to transport
filesystems, but I think we would be better off working on something like
multipart/fs along with some new Content-Disposition parameters or
something.
I think there is general agreement that interoperable transport of filesystems
would be a good, perhaps even great, thing. The question is how...
Ned