Message-Id: <ab3857ee02021003738c@[165.227.40.22]>
Date: Tue, 10 Jan 1995 07:48:35 -0800
To: hoymand@gate.net, uri@bunyip.com
From: ietf-lists@proper.com (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:infobot@kwf.com//send%20current-issue%0D%0Asend%20index/>
instead of:
<mailserver:infobot@kwf.com//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.