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
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.
Some comments on the introduction:
There is a fundamental misconception that percolates through
in a few places
dealing with information sharing between two providers
participating in a
mash-up.
For example:
... if provider 'B' were build a new application on
top
of a service provided by 'A', B would only access
content from A
using well known Web Standards and would not need to
host A's
content in its own domain. Similarly, A does not need
to access
any more data in B's domain beyond what is needed to
make the
service work.
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 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.
I also would not focus exclusively on "Provider
Generated" mash-ups. The
whole point of Web 2.0 are user-generated applications!
Notice: This email message, together with any attachments,
may contain information of BEA Systems, Inc., its
subsidiaries and affiliated entities, that may be
confidential, proprietary, copyrighted and/or legally
privileged, and is intended solely for the use of the
individual or entity named in this message. If you are not
the intended recipient, and have received this message in
error, please immediately return this by email and then
delete it.
_______________________________________________
Simple mailing list
Simple ietf.org
https:/
/www1.ietf.org/mailman/listinfo/simple
|