Throw away the Internet and start over?

[Jeff Bone]

On Tuesday, Apr 22, 2003, at 17:02 US/Central, Justin Mason wrote:

> Yeah, but the problem of spam would not be fixed by such a beast.  
> That's
> the issue that's driving this idea of replacing SMTP, and unless a new
> protocol can actually solve that issue, it won't have made any 
> difference,
> apart from a lot of upgrade pain.

I think you missed the point.  Go re-read Paul's write up:  it's a 
substantial change from "fire-and-forget" to "notify me that I need to 
come get something."

It's a lot harder for you to spam me when all you can do is give me a 
notification that you've stored a message on *your* server that I need 
to come and get.  The onus is on you, for storage, for retrieval 
bandwidth, etc.  It changes the economics of spam dramatically, 
providing negative incentives.  Any unsuccessful spammer would simply 
get ignored, and any successful spammer would be strangled by their own 
success.

Plus, it's a lot easier to filter / avoid bogus structured metadata 
content in the notification (i.e., I only accept notifications with the 
following fields, containing the following values (white list) etc.) 
than it is to try to semantically classify the content itself by which 
time I've already received and stored it.

> In SMTP, the sender is not authenticated.  In SMTP-over-HTTP, there'll
> still be spam, unless the sender is authed.  And who does the authing
> across the entire internet?   Verisign? ;)

Yeah, that's a point.  But I think you can make stone soup w/o the rack 
of lamb. ;-)  (It takes a tough man to make a tender chicken, etc. ;-)

To the point, though, you can do presence, FOAF, white listing, etc.  
all w/ HTTP.  Authentication, authorization, and principal management 
are all orthogonal to the push / pull, sync / async, and direct vs. 
"routed" nature of the underlying protocol.  A non-toy proposal should 
of course address some of these concerns as well.

Extra credit:  contemplate implications of an end-to-end HTTP-based 
mail solution on:  mailing lists, mailing list management, mailing list 
archival, ***groupware*** (what's a message?  what's a group?), 
calendar coordination, contact information and contact management, etc. 
etc.

I will simply not ReST (bah-dump-bump) until every piece of information 
I touch can be created, accessed, and searched, sorted, filtered, 
edited if appropriate, annotated, referred to, and otherwise fiddled 
with via HTTP. ;-) :-)

jb