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.
I was assuming that access-type should be called content-access-type
or some such, and would be a content header. Currently you do not have
to know the content-type to de-transport-encode something.
Content-encoding and content-type are not dependent. Content-type
application/external reference depends on the existance of one or more
content-access-type headers in the body part.
The argument for eliminating dependency where possible was one reason
why charset is an attribute rather than a content-header, and the
reason external-filename is also an attribute. We decided to put
things in attributes to eliminate the inter-content-line dependencies.
2) I don't know what you or John are referring to, about 'hierarchy of option
s'
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.
I guess I mis-sent something. "first try nfs, then try ftp, then try a
mailserver" is what I'm calling a hiearchy of options. At one point
I thought this was a good thing, but now I realize that each of the
above is "better" in different circumstances, and If I am on bitnet, I
just will never try NFS or FTP, and go strait for mailserver. With
the changes I suggested to multi-part/alternative, this is really a
non-issue.
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.
Well, if you were going to have
content-access-type: MAILSERVER; to: "mailserver(_at_)cs(_dot_)wahoo(_dot_)u";
subject line = "Hi!"; Firstline =
"access internet drafts"; Secondline = "get index"; Thirdline
= "get help"; Thirdline = "end"
I would understand your point, but this is UGLY!
Ohhh. Wait, think, Eureka! Are your access-type non-content headers?
If they are in a formatted body type then this makes sense!
content-type: external reference
content-something or other:
access-type: FTP; user = "whatever"; passwd = "yickystf"; directory =
"usr/bogus/somthing"; file = "mime.txt"
access-type: MAILSERVER; command = "
to: mailserver(_at_)cs(_dot_)wahoo(_dot_)u
Subject: "hi"
access internet drafts
get index
get help
end
"
access type: NFS; directory = "/home/internet-drafts"; file = "mime.txt"
Gee. I do like my syntax better :-)
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.
If we can leverage existing code and content-type parsers this can be
easy! Why add a new parser?
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.
How about calling all the subtypes of my proposal
content-type message(-or-application)/externalreference-ftp
and
content-type message(-or-application)/externalreference-nfs
and
content-type message(-or-application)/externalreference-mailserver
This gives an appearance of organization without adding a n-level
content-type or adding a new top level type.
Greg V.