- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 19 Mar 2002 22:22:02 -0800
- To: Rob Lanphier <robla@real.com>
- Cc: "www-tag@w3.org" <www-tag@w3.org>
Personally, I have a hard time swallowing parts of 3205, especially section three; things like 'traditional use' are, at best, ill-defined. I'm still waiting for a crisp definition of 'substantially new service'; considering the current threads on TAG, what set of data isn't potentially accessible through the HTTP? Artificially limiting the uses of the HTTP because a) firewall administrators are used to using ports as a heuristic for identifying applications, and b) people deploy intermediaries that aren't semantically transparent and force-route messages through them isn't the proper way to address these problems, IMO. On Tuesday, March 19, 2002, at 09:44 PM, Rob Lanphier wrote: > On Tue, 19 Mar 2002, Paul Prescod wrote: >> "Roy T. Fielding" wrote: >>> >>> ... >>> >>> It wouldn't be less useful. The point is that it would gain nothing >>> from doing so. It is a store and forward messaging system -- the >>> application >>> consists of delivering the message, that's all. >> >> If you were tasked with inventing a protocol for fetching mail from a >> remote server, would you choose to make it a specialization of HTTP or >> not? I'm not asking whether there is sufficient cost/benefit to replace >> POP, IMAP, etc. Probably there is not. I'm asking how you decide when >> to >> invent a new application protocol or just use HTTP. > > My 2 cents: no. > > See RFC 3205 for the justification and for a detailed discussion as to > guidelines for using HTTP as a substrate: > > http://www.ietf.org/rfc/rfc3205.txt > > Email constitutes a substantially different service than traditional > HTTP. > > Rob > > > -- Mark Nottingham http://www.mnot.net/
Received on Wednesday, 20 March 2002 01:22:03 UTC