W3C home > Mailing lists > Public > www-tag@w3.org > March 2002

Re: section 1, intro, for review

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 19 Mar 2002 22:22:02 -0800
Cc: "www-tag@w3.org" <www-tag@w3.org>
To: Rob Lanphier <robla@real.com>
Message-Id: <CAD053E8-3BCA-11D6-AFA9-000A27836A68@mnot.net>

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 
> Rob
Mark Nottingham
Received on Wednesday, 20 March 2002 01:22:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:50 UTC