Re: Second round for new URL scheme (mailserver)

Paul Hoffman (ietf-lists@proper.com)
Tue, 10 Jan 1995 07:48:35 -0800


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.