Message-Id: <email@example.com> Date: Tue, 10 Jan 1995 07:48:35 -0800 To: firstname.lastname@example.org, email@example.com From: firstname.lastname@example.org (Paul Hoffman) Subject: Re: Second round for new URL scheme (mailserver) >Paul, I see a couple of problems here. First, you are assuming the body >only has a single line. This is not always true, many mail servers let you >send multiple commands on multiple lines. The / is my original proposal >was meant to specify the end of line. Here, it's just a separator. For >this to work, you would have to encode an end of line, which was something >I was trying to avoid. Interesting, I was trying to do the opposite. I think of "/" in URLs as field separators, not indicators of lines. For mailserver, they are the same thing. I still prefer encoding CRLFs in the body, such as: <mailserver:email@example.com//send%20current-issue%0D%0Asend%20index/> instead of: <mailserver:firstname.lastname@example.org//send%20current-issue/send%20index/> However, I'm open to either. Discussion from the group on this? >The way I had it, was to just allow for arbitary lines, separated by /, >with the convention that // would be needed to designate the end of the >header. Just like a mail message. This suggests that the spec should be: mailserver:<rfc822-addr-spec>/*[<headername>:<fieldtext>/]/<body> This means that there must be a "//", not a "/", before the body, which might cause a fair number of malformed URLs. However, I think people have gotten used to the ugly interface of the "//" in http and gopher schemes, so they can learn it for this one as well. :-) Again, I'm open to discussion on this. I like the new structure a bit more than the one I put in the 2nd predraft because it puts all the headers up front, like we're used to seeing in mail messages. >Second, a proper e-mail message needs a From: line in the header. Clearly, >this is a client side issue, but I think it should be spelled out in the >specification that this must be added. Agreed. I'll put this in the security section, since putting a wrong name in the From: field could cause security problems.