(Response) Comments on draft-roy-simple-presencerss-00

(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 <eburgerbea.com> 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
Simpleietf.org
https:/
/www1.ietf.org/mailman/listinfo/simple