Re: mailserver URL
"Roy T. Fielding" <fielding@avron.ics.uci.edu> Sat, 04 February 1995 06:24 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25732; 4 Feb 95 1:24 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa25728; 4 Feb 95 1:24 EST
Received: from services.Bunyip.COM by CNRI.Reston.VA.US id aa09758; 4 Feb 95 1:24 EST
Received: (from daemon@localhost) by services.bunyip.com (8.6.9/8.6.9) id AAA21344 for uri-out; Sat, 4 Feb 1995 00:56:12 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.9/8.6.9) with SMTP id AAA21339 for <uri@services.bunyip.com>; Sat, 4 Feb 1995 00:56:08 -0500
Received: from paris.ics.uci.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA07237 (mail destined for uri@services.bunyip.com) on Sat, 4 Feb 95 00:56:04 -0500
Received: from avron.ics.uci.edu by paris.ics.uci.edu id aa27830; 3 Feb 95 21:53 PST
To: "Stephen R. van den Berg" <berg@pool.informatik.rwth-aachen.de>
Cc: uri@bunyip.com
Subject: Re: mailserver URL
In-Reply-To: Your message of "Tue, 31 Jan 1995 13:48:55 +0100." <9501311248.AA14007@tabaqui>
Date: Fri, 03 Feb 1995 21:53:43 -0800
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Roy T. Fielding" <fielding@avron.ics.uci.edu>
Message-Id: <9502032153.aa27830@paris.ics.uci.edu>
X-Orig-Sender: owner-uri@bunyip.com
Precedence: bulk
> In principle I'm charmed by the scalability of the approach to allow > arbitrary header fields to be specified. But, if people consider this > to be too much of a security hazard, why not simply state in the RFC that > implementors should initially ignore any header fields except Subject, and > that on explicit configuration, some specified headers fields are to be > accepted. For three reasons: 1) Adding arbitrary headers does not provide any additional scalability, nor does it provide any additional extensibility (what you meant). Mail servers need to be able to accept requests from mail agents. Many mail agents do not allow users to send arbitrary headers. Some mail gateways change the content and order of mail header fields. Some mail gateways drop all unknown header fields. Therefore, mail servers must provide a way for these fields to be given in the body of a message instead of the header. MIME explicitly deprecates the use of Subject for mail-server commands, and only allows it because some existing mail servers do require a subject. MIME does not allow any other header fields to be used in a mail-server access. Allowing the mailserver URL to do something that other mail agents cannot do (or, for security reasons, are explicitly prevented from doing) is unnecessary. Providing a feature for mail server access that is not even allowed by MIME is a total waste of time. 2) It requires the user agent to perform additional work and to support an interface that displays arbitrary header fields instead of just subject. Consider what it would take to implement an interface that allows the user to see, recognize, and *understand* any arbitrary header field that may be configured for use by an application. Note that the application may have been configured by someone other than the user. Now, compare that to one where you know that the only fields are the address, subject, and body content. 3) It adds the case-insensitive string "subject:" to any mailserver URL that includes a subject. > This way you can have the best of both worlds. I.e. the RFC doesn't forbid > the use of extra fields, it just recommends that they are ignored by default. > It would allow an implementation to allow some header field to be included > if it became popular some time in the future. If the URL is intended to fulfill the requirements of access to a mailserver, this additional complexity is completely unnecessary. ......Roy Fielding ICS Grad Student, University of California, Irvine USA <fielding@ics.uci.edu> <URL:http://www.ics.uci.edu/dir/grad/Software/fielding>
- Re: mailserver URL Jim Conklin
- Re: mailserver URL Roy T. Fielding