Re: [rest-discuss] REST requires HTTP or other transports
Interesting paper, and one I had not seen before (as a relative newcomer to rest-discuss).
One possible addition to your work: since many clients sit behind firewalls, it seems that HTTP proxying would need to be extended for notification purposes as well. For example, a firewalled sink is unable to receive notifications directly. As an alternative, it could maintain a connection with a proxy server, and receive its notifications via that server.
Perhaps you had envisioned leveraging a notification-enabled HTTP proxy <http://www.w3.org/TR/WD-proxy>, since you cited that in your Acknowledgements section?
JeoffOn 10/10/05, Lucas Gonze <lgonze@...> wrote:
Jeoff Wilks wrote:
>Agreed: spam is a serious side effect of push models.
>If all SMTP messages had a universal resource identifier then perhaps
>spam problems could be mitigated more effectively? For example,
>imagine if SMTP messages were restricted so that they contain only the
>equivalent of an HTTP "302 Found" response. The message itself is not
>allowed to contain any content, only a Location header describing
>where to GET the content. Because the GET requires the information
>source to positively identify itself by means of a Location/URI, there
>is some protection there. The value proposition for spammers goes
>down: while they can still send messages, they can't deliver *content*
>anonymously. A recipient that has never subscribed to that URI can
>simply discard it without retrieving the content; or check the URI
>against a spam registry prior to downloading content; etc.
I have beat this hobbyhorse before, so have to apologize to the many
people who have already seen it, but my "Secure Protocol for Desktop Web
Servers" design uses this same strategy of having all push data be tied
to a subscription: http://www.gonze.com/http-notifications.html
Using that method, a push message is not allowed to contain any content,
but only a notice that content may be pulled. The location of a pull is
fixed before the push arrives, so that pushees ("sinks") can't be
tricked into pulling content they didn't want. A pushee can't even
receive a notice without prior arrangement. Overall, this system should
be no more susceptible to spam than pull-based systems.
(703) 964-7368 mobile
- Jeoff Wilks wrote:
>Interesting paper, and one I had not seen before (as a relative newcomer to
>One possible addition to your work: since many clients sit behind firewalls,
>it seems that HTTP proxying would need to be extended for notification
>purposes as well. For example, a firewalled sink is unable to receive
>notifications directly. As an alternative, it could maintain a connection
>with a proxy server, and receive its notifications via that server.
Let's say there is a proxy sitting on the corporate firewall, and the
proxy is able to initiate traffic within the firewall. Using my
handshake, the client would send a callback URI which was hosted by the
proxy server, then arrange for a pickup from the proxy using the
Such a proxy would indeed be a lot like http://www.w3.org/TR/WD-proxy.