Subject: [dix] authenticated feedreaders and current draft

From: Robert Yates <[email-masked]>
Date: Tue, 28 Feb 2006 10:05:30 -0500

The current draft specifies that browsers are the only "Dumb Client".  
I'd argue that for widespread adoption the specification also needs to 
target feedreaders and potentially other dumb http clients.  Feeds are 
becoming increasingly important and authenticated feeds are needed for 
subscribing to things like gmail or apple's photocasts.  I think that 
feedreaders need to be able to utilize the SSO aspects of DIX.

One means of achieving this is by allowing POSTS or GETS to move the 
messages. If a request to the homesite is received via a GET then its 
response should also be a GET and an HTTP redirect should be used to 
bounce the message via the users "dumb client".

Rob

_______________________________________________
dix mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dix

---

From: Dick Hardt <[email-masked]>
Date: Tue, 28 Feb 2006 13:12:09 -0800

On 28-Feb-06, at 7:05 AM, Robert Yates wrote:

> The current draft specifies that browsers are the only "Dumb  
> Client".  I'd argue that for widespread adoption the specification  
> also needs to target feedreaders and potentially other dumb http  
> clients.  Feeds are becoming increasingly important and  
> authenticated feeds are needed for subscribing to things like gmail  
> or apple's photocasts.  I think that feedreaders need to be able to  
> utilize the SSO aspects of DIX.
>
> One means of achieving this is by allowing POSTS or GETS to move  
> the messages. If a request to the homesite is received via a GET  
> then its response should also be a GET and an HTTP redirect should  
> be used to bounce the message via the users "dumb client".

Great suggestion Robert.

For discussion sake, let's call things like feedreaders and other non- 
browser http clients "Rich Clients", since they are doing more then  
just getting a page and displaying it. This is a much deeper problem  
then fetching RSS feeds. There is much more complexity when you get  
into identity issues with full Web Services -- something that the WS- 
* efforts are working to solve. I would argue that a more RESTful  
identity exchange mechanism would be of great benefit to RESTful web  
services.

A design constraint of DIX was being able to work with unmodified  
browsers (easier to get adoption), but I think Rich Clients can be  
modified to support a more seamless exchange of identity data.

There was an IETF BOF on Beyond Basic Auth that I had hoped would  
develop some richer Auth mechanisms within HTTP that could work with  
DIX.

Unfortunately, I think adding support for Rich Clients to the DIX  
charter would widen the scope too much. :(

-- Dick