Greg,
You say:
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)
1) I have no idea what this layer of dependency is, between content-???
headers. Please clarify. I don't see any such dependency, so we have a
basic disconnect, here.
2) I don't know what you or John are referring to, about 'hierarchy of options'
so am, again, at a loss to respond. Please give me some sort of detailed
example to chew on, since I'm clearly missing a key point.
3) If you have two mail servers, then you have two Access-type headers.
Could it be that some/all of you are thinking that the Access-type headers
occur in the message- headers sections? They don't. They are in they
"body" of the part, as is the Content-type that is to apply to the retrieved
data.
The issue of having long, complicated command sequences, to drive a particular
access-type is an interesting point.
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.
Well, you are exactly right that you need to register these little goodies.
I think that the assumption that a) a single spec will handle multiple
access types, and/or that b) people will automatically understand the
details of each access type is simply wrong.
To automate the handling of Access methods, software will have to understand
considerable detail. To date, the detail isn't specified anywhere. It will
have to be and the Access-type reference to the behavior which is so
specified will have to be registered as invoking that formally specified
behavior. Really. This doesn't happen by magic.
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".
Well, this is a very strong argument, in favor of /alternative, I admit,
thought we could create the same rule for the list of Access-type headers
in my proposal. (Yes, I prefer to re-use existing mechanism, too, but
remember that the original proposal requires re-stating the actual content-type
for each and every access-type spec. Also keep in mind that this think that
we are referring to, out there, is not a message, so putting it under the
message content-type seems utterly confusing to me.
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).
Each of these subtypes need registering. Further, I think that the idea
of external references is sufficiently generic, and sufficiently useful
that it deserves to be identified explicitly. I have hesitated to suggest
that it be created as its own Content-type, but actually believe that it
would be reasonable to do.
Dave