Peter Davis wrote:
As near as I can discern from atom-pub [1], it is, at it's heart, webDAV for
ATOM-based representations. Which means a feed reader/editor is, by
definition, an HTTP(s) user agent.
Agreed.
The present atom-pub ID is ambiguous for UA support for 3xx class response
codes (which would be required for the HTTP redirect binding). The POST
binding carries no such dependencies on HTTP 3xx responses however.
SAML POST only requires access to the POST and GET verbs of HTTP, and for
convenience, support for response codes 3xx (redirect response codes), but
those are not MTI for SAML POST to properly function.
The defense RESTs ;-)
Not so fast ;-) The SAML POST binding requires that the HTTP UA be a
browser or at the very least it MUST be capable of rendering HTML forms
and then making posts of media type
`application/x-www-form-urlencoded'. There is no such requirement on
atom clients, nor any HTTP UA. Google, for example, has an ATOM client
that is a plugin for word http://buzz.blogger.com/bloggerforword.html.
This certainly can't presently make use of SAML's POST binding. While
it can be argued that these clients could make use of this binding I
think the burden of being capable of parsing HTML Forms, forming a post
of media type 'application/x-www-form-urlencoded' and dealing with all
the character encoding pitfalls of html is too great when all they are
trying to do is authenticate.
The SAML redirect binding has more potential, as all HTTP UAs should
honor the 3xx return codes. The problem with this binding, that is also
shared with the POST binding, is how the user indicates to the SP the
location of his IdP. One approach is that the url that the client
initially hits (e.g. the feed url) contains the users IdP, so that the
SP knows where to send the redirect (in use case 4, the user is not
around). Embedding state into the urls of web resources is NOT REST
based web services as it breaks one of the foundational assumptions.
(this is getting religious). Practically speaking though, doing so
creates a set of problems for Elliot's Dad, Elliot and I. Here's the
problem.
Elliot's dad's photostream has the following url.
http://apple.com/photostreams/elliots-dad. He e-mails the url of this
feed to Elliot and I. Now what?
Am not sure you can REST just yet. Your witness ;-)
Rob
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
