Subject: [Simple] (Response) Comments on draft-roy-simple-presencerss-00

From: "Arjun Roychowdhury" <[email-masked]>
Date: Mon, 18 Jun 2007 09:25:38 -0400

(For some reason, this list thinks I am not a subscriber - while I am
subscribed using this email. Anyway,  I resubscribed again, hope this
goes through)

Eric, thanks for your list review, and your offline comments.
Responses to the list   comments below:

On 6/18/07, Eric Burger <[email-masked]> wrote:
> As I see it, there are two things to work out.  The first is rather easy and
> straightforward: determine the format and ontology of the RSS feed.  The
> second is a bit harder: how do we handle the data access entitlements?  We

ARC> Another idea that I received was to ditch RSS and start with
ATOM, the latter being an IETF effort and significantly more rich than
RSS (euphemism for more complex as well). It doesn't really matter to
this draft, since most of the mashup environments I have worked on
support both.

> have a rich set of policy enforcement at the SIP SUBSCRIBE level.  Would we
> try to replicate that at the RSS level, use RSS equivalents, or punt and say
> that a different access protocol results in a different policy enforcement
> regime?  I would offer that would open up a bunch of security
> considerations.  None the least would be a stricture to enforce the user's
> data access policy across all access modalities.

ARC> No, we should not try and replicate any presence related authorization
schemes at all at RSS. The only authorization scheme that should
remain at RSS level is the authorization to access the RSS list (which
exists today in form of authenticated RSS). Any presence related
authentication is applied before converting it to an RSS feed. The
interesting thing, however, taking the draft example, is what happens
if 'B' is not allowed to see 'A's presence directly via SIP. However,
'A' allows 'trackit' to see it's state and then B uses 'Trackit' to
see the state (since 'trackit' is a service). However, this
technically maps to A allowing any user C to see it's state and C
allowing B to see that same state, so I am not sure if this is
something that is unique to the example.
<snip>
> A key feature of Mash-Ups is Domain A has *NO* need to access ANY data in
> Domain B to provide the service.  Of course, the caveat is Domain A may
> require authentication and authorization of the users of Domain A's web
> service.  However, that still imposes no burden on Domain A to access Domain
> B to provide a service to Domain B.  Having such interdependencies means
> that in order to create a Mash-Up, you would have to somehow educate the
> component providers about your service.  This is a combinatorial and
> economically infeasible situation.

I do not believe that is true. If there was absolutely NO
data-sharing, then the applicability and scope of mashups in terms of
what they can do is limited. Therefore, I prefer the term *limited*
(what is needed for that service) as opposed to *NONE*. For example,
many 3rd party data sources allow me to construct a query to get back
their data in JSON format to plug into my service (example, playlist
information). This is what I am referring to as data. Similiarly, back
to the draft example, the RSS list that 'trackit' is sharing with
'mapitntrackit' in response to the HTTP GET for RSS is also what I am
referring to as 'Data'.

>
> I would also offer that one not get hung up on being browser-centric.  Lots
> of interesting applications may use Web Portal technologies, but do not have
> actual browser-based displays.

Yes, I agree. The crux is to use standard web technologies. If a
non-browser supports it, that is fine too. I will make this change.

>
> I also would not focus exclusively on "Provider Generated" mash-ups.  The
> whole point of Web 2.0 are user-generated applications!

Again a good point. Will reflect this change appropriately.

--
Arjun Roychowdhury

-- 
Arjun Roychowdhury

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