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.

Received on Tuesday, 10 January 1995 10:46:22 UTC