Margolin@MIT-MULTICS.ARPA (Barry Margolin) (10/18/84)
RFC918 seems quite incomplete as it is currently written, or is at least
making a number of assumptions that are not specified.
1) What is the format for messages being transmitted from the server to
the workstation? The Introduction mentions RFC822, but the context
seems to be referring to the way messages are transfered from the
workstation to the server. Are we to assume then that messages are
transfered from the server to the workstation in RFC822 format, too?
2) How are individual messages delimited?
3) When responding to RETR and RDEL commands, is the "#" meant to be
taken literally, i.e. if there are 5000 characters in the mailbox,
would it respond "500" or "#500"?
4) This protocol seems to be line-oriented; what is the newline
character? Are you assuming NVT-ASCII?
5) Computing the mailbox character count could be difficult if the
contents are to be transmitted in NVT-ASCII as opposed to the server's
native character set. I am assuming that the character count is the
number of characters to be transmitted, so it should be a count of
NVT-ASCII characters. This can differ markedly from the number of
characters stored on the host. Also, even without this problem, by
requiring the server to respond with the total number of characters at
the beginning it must read and format the entire mailbox before sending
anything, so that it can add up the character counts of each message.
Instead, I suggest that you specify a sequence to be used to indicate
that the messages have all been transmitted. You could leave the
character count in as an option for use by those systems for which it is
easy to provide. Thus, an acceptable response to RDEL or RCEV would be
either "#xxx", "+OK" (meaning that an indeterminate amount of text is
coming), or "-ERR". Additionally, the "all done" indicator would only
be recognized after an "end-of-message" delimiter; as long as the the
all-done sequence could never be used to start a message (i.e. as long
as it isn't of the form "<text>: <optional text>") it wouldn't even
have to be quoted if it were embedded in a message, like you would have
to do for the end-of-message delimiter.
6) Does the character count include the inter-message delimiters?
7) There is an inconsistency in the RFC: in the Summary of Commands and
Replies it specifies a reply as "-Error", but in the command
descriptions they specify "-ERR". Which is it?
8) Is the "mailbox" parameter intended to be a pathname, a user name, or
some system-dependent identifier?
Now for a suggestion:
9) One does not always want to read all of one's mail. You might, for
instance, just want the messages that came in since the last time you
extracted your mail. Yes, you could use RDEL all the time, but people
often like to leave messages in their mailboxes.
10) Similarly, if you don't use RDEL, then you need a way to selectively
delete messages.
barmarTIHOR@NYU-CMCL1.ARPA (Stephen Tihor) (10/18/84)
Having an upper bound on the number of NVT-ASCII characters to be transmited is a very useful option for a small workstation which might not be able to handle swallowing and entire vacation's worth (heck a weekend's worth) of mail in one gulp. // ARPAnet: Tihor@NYU-CMCL1 UUCPnet address: ...!ihnp4!cmcl2!cmcl1!tihor \\ (( DEC Enet: RHEA::DECWRL::"""TIHOR@NYU-CMCL1.ARPA""" NYUnet: TIHOR.CMCL1 )) \\ Stephen Tihor / CIMS / NYU / 251 Mercer Street / New York, NY 10012 // -------