O.K. let's take a break and correct bigger things during after
more experimentation. I had only today time to look at the new draft
and would like to point out some unclear points there. In the
Message/External-body
It says that the body can contain additional headers to specify e.g. the
real content-type: which is a good idea but I understood it's not
required. I think the first part should be required to be some kind
of headers in case there's going to be additional second part with
e.g. commands to mail servers since otherwise it might be confusing
since some mail servers use commands like Request: foo, Topic: bar etc.
which look like headers in a body. Maybe I have only misread the document
though since even the example uses such commands.
Also I'd like the Example about a message to a listserv be corrected
to use the real Listserv syntax (a la Eric Thomas):
get rfc-xxxx doc
instead of that weird SEND-FILE: command.
For the anon-ftp access-type I'd explicitly specify that the userid
anonymous and password user(_at_)local(_dot_)domain should be used, it may not
be obvious
to some implementors.
I still support my idea that the ftp access method could have in the
body all necessary ftp control commands and only basic parameters like
site, userid (usin name to mean filename or userid in different
access-methods sounds confusing), access-type, port (auth-data?) would
be in the headers. This way you can give any site specific ftp
commands, use multiple get commands, set record lengths etc. Of course
the ftp still would need to be able to little bit parse that command
stream to supply local filenames ports etc. when needed.
One usage which I for a long time have visioned for this is to give BITNET/EARN
style service in for large files in which I can send a cover letter and a
reference to a nonpublic file which the recipients can the retrieve if
they want it. The file would stay non public by the use of long random
filenames (or passwords) that local ls command would not show. Of course
you need a more complex authentication if you want more security than your
mail gives but that's outside the scope of this document.
Anyway I'm happy that we have achieved to define much more
functionality than X.400 can provide in much less time with much less
implementation effort. I wonder how complex gateways we might need in
the future... One X.400 (and BITNET/EARN) feature that's still
missing is standard way to request acknowledgements but maybe it could
become as a side effect of X.400 gateway standardization or some other
document.
Harri
For the acces