Message-Id: <firstname.lastname@example.org> Date: Mon, 5 Jun 1995 16:24:36 -0700 To: email@example.com From: firstname.lastname@example.org (Paul Hoffman) Subject: 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.