John C Klensin comments on mailserver URL scheme

Greetings. The following was sent to Larry and I by John C Klensin. He'd
like to see each topic discussed before he passes the mailserver I-D
(draft-ietf-uri-url-mailserver-01) on to a final IESG vote. I've reproduced
his comments below exactly, and I'll comment on each one as I see it in a
followup message. After we've discussed these for a while, I'll batch up
the responses and send them to him.

--Paul Hoffman

* The WG explicitly considered the implications of using MAILSERVER
without defining a canonical return address format and decided that
nothing else was needed.  We are already having problems with
non-repliable mail from MAILTO URLs when people try to respond to
them; MAILSERVER essentially requires a response.  At a minimum, did
the WG explicitly decide that its advice to implementors need not
contain advice about getting the reply address right.

* The WG explicitly considered the problems of messages coming back
to a mailbox without the ability to relink them into the Web (or
wherever) and decided this problem wasn't worth solving.

* The WG explicitly considered the relationship between maximum
practical URL lengths and the sometimes-extensive information
required by some mail servers and decided that mail servers requiring
extensive information weren't worth worrying about.

* The WG noted the fact that a number of mail-based servers require
per-user passwords (or other authentication strings) in order to
process certain requests, noted that there is no way to accomodate
user-supplied passwords in this URL syntax, and explicitly concluded
that those servers would never be the target of URLs.

* The WG noted the fact that we are seeing an increasing number of
mail-based servers on the Internet that accept only digitally-signed
messages to process certain actions (and will certainly see more in
the future) and decided that, when it was necessary to deal with
those servers, a new URL type would be invented.

Editorial comment:  There are many forms of RFC 822 addresses.  A
piece of undefined syntax called "encoded822addr" is not a sufficient
definition of what is permitted or required.

Security comment: displaying a message about to be sent to the user
is likely to be burdensome for many clients, makes common cases
appear to be more complex than they are, and, with most users, will
add confusion but not security.

* Please assure me that the WG considered such alternatives as
*requiring* particular source-labelling on messages being sent out
from mailserver URLs that would appropriately disclaim the issues
noted in the "examples of problems" section.

* Why is the syntax of a MAILSERV URL
   mailserv:host-domain/...
rather than
   mailserv://host-domain/...     ?

The latter would seem more consistent with RFC 1738.

Received on Monday, 5 June 1995 19:22:37 UTC