More importantly, it seems to me that the fact of multiple access
mechanisms will be quite common and that we should facilitate it. The
scheme in the current spec looks like it will work, but the fact that you
have to repeat the real content type, for each alternative access type,
feels klunky (that's a technical term) and I'd like to suggest the
following alternative:
From: someone
To: someone else
Content-type: application/external
Content-type: application/postscript
Access-type: NFS; Name=/pub/read-only/some.ps
Access-type: FTP; host=east.filestore.org; user=anonymous;
pass=email-retriever; name=some.ps
Access-type: FTP; host=west.filestore.org; user=anonymous;
pass=email-retriever; name=some.ps
Access-type:...
So, the application/external content type indicates that there is a
headers-only part, which contains the real content-type of the data to
be retrieved, and one or more specifications for methods of accessing
the file.
Thoughts?
I'd be more comfortable if this explicitly labeled the contents as
alternatives and not leave open the possible mis-interpretation of sequential
steps to be done. I expect that programs can be made to understand the
correct interpretation, but users with less intelligent UA's could be a big
problem ("I retrieved these files from all the places I was told to, but they
all contain the same thing. There must be something wrong").
Additionally, I think an "escape mechanism" must be provided to allow
non-unix, non-hierarchical file access (VM being my prime example). It should
be possible to specify "issue these commands in this sequence", such as:
Access-type: Commands; cmd1=first command; cmd2 = second command; ...
John Wagner