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:...
Dave,
I have several problems with this scheme. 1) It adds a layer of
dependency between content-??? headers that did not presently exist,
which will make things more compex, and 2) as pointed out John Wagner,
there is not a clear concept of hiearchy between the options. 3) This
proposal does not easily fit mail servers. What If I offer two mail
servers with two different sets of commands. How do Identify which
commands go with which server? (Assuming you would put the commands
in the body)
If we adopt Dave's proposal, We now need regester new access-type
content header fields also! Please, keep to the current architecture
where extension is done simply by adding new content types.
On the issue of heararchy, things get complex. It may be that it
really is up to the UA to determine the best match. For example, at
ISI, I'd rather use the FTP.nisc.sri.com internet drafts archive, and
at Mitre, I'd prefer the local nic.ddn.mil archive. Here on my local
site, I'd like people to just copy the file from the directory via NFS.
Multi-part/alternative does currently have a rule that you are to use
the "richest" version you can. I'd like to see the rule generalized a
bit, adding some words to say, use the "best". It is up to the user
and his/her UA to figure out in their context the "best".
So, what am I saying? For the external body, I propose what I
originally sent. This proposal was for use of multipart alternative
with specific subtypes for each retrieval mechanism like,
application/ftp-getter and application/mail-server. (I don't care
anymore whether it is application/mail-server or message/mail-server).
I would also make the following changes to the wording on multipart
alternative. It currently reads (7.2.3)
The multipart/alternative type is syntactically identical to
multipart/mixed, but the semantics are different. In
particular, each of the parts is an "alternative" version of
the same information. User agents should generally display
only the LAST part that they are capable of displaying.
This may be used, for example, to send mail in a fancy text
format in such a way that it can easily be displayed
anywhere:
....
In general, user agents that compose multipart/alternative
messages should place the body parts in increasing order of
preference, that is, with the preferred format last.
Receviers should pick and display the last format they are
capable of displaying. In the case where one of the
alternatives is itself of type "multipart" and contains
unrecognized sub-parts, the user agent may choose either to
show that alternative, an earlier alternative, or both.
I'd prefer the following:
The multipart/alternative type is syntactically identical to
multipart/mixed, but the semantics are different. In
particular, each of the parts is an "alternative" version of
| the same information. User agents should recognise that the
| content of the various parts are interchangable. The user
| agent should either choose the "best" type based on the
users enviroment and preferences, or offer
| the user the available alternatives.
....
In general, user agents that compose multipart/alternative
messages should place the body parts in increasing order of
preference, that is, with the preferred format last.
| For fancy text, the sending UA should put the most
| plain text first and the richer text later. Receiving
| UA's should pick and display the last format they are
| capable of displaying. In the case where one of the
alternatives is itself of type "multipart" and contains
unrecognized sub-parts, the user agent may choose either to
show that alternative, an earlier alternative, or both.
How does this sound?