Subject: [Simple] Review comments: draft-roy-simple-presencerss-01.txt

From: "Willekens, Marc (NSN - BE/Belgium - MiniMD)" <[email-masked]>
Date: Sun, 25 Nov 2007 11:19:16 +0100

Hi Arjun,

http://www.ietf.org/internet-drafts/draft-roy-simple-presencerss-01.txt
<http://www.ietf.org/internet-drafts/draft-roy-simple-presencerss-01.txt

If I understand it correctly, the motivation for this draft is the
provisioning of a "feed" concept in the presence server to allow a
Mash-up with other feeds by using current state of art to do this.

4.1 Track it service

I assume in your picture that SIP is the SIP PUBLISH message containing
the presence and location information.

An HTTP feed, i.e. a poll mechanism with the RSS or ATOM format is used
between the Trackit server and the "Map & Track AS". So, basically, a
mapping of the presence document with a RSS or Atom format has to be
performed in the Trackit server.

Is your basic idea to extend every presence server with this Web feed
method?

What will be included in the HTTP feed? The info from one presentity or
for the group of presentities (aggregated or single)? 

6. Security considerations

In the presence server, authorization and filtering of presence
information is made in function of the watcher. In the indicated use
case with the tracker, how will the privacy of the data be guaranteed?
There is no longer a direct relation between the watcher and the
presentity. The Trackit server can do an authentication for the HTTP GET
request for the feed, but on which level, i.e. the Map & Track AS level
or up to the users of this service (the other PUA)?

Is it not possible to combine the SIP SUBSCRIBE with the RSS/Atom feed
functionality?

When the "Map & Track AS" make a SIP SUBSCRIBE to the Trackit presence
server for every PUA requested for the map service, the presence server
is able to do perform its authorization and filtering rules.  But now,
this function has to performed not only for one individual watcher but
for a group of watchers. So, the common denominator for the information
which can be revealed to the group has to be determined. Can this be a
function of a NOTIFY aggregator which then also maps this info to the
RSS/Atom format? 

br,

Marc.

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

---

From: "Arjun Roychowdhury" <[email-masked]>
Date: Mon, 26 Nov 2007 09:56:00 -0500

Hi Marc, thanks for your review
Comment inline:
regds
arjun
On Nov 25, 2007 5:19 AM, Willekens, Marc (NSN - BE/Belgium - MiniMD) <
[email-masked]> wrote:

> provisioning of a "feed" concept in the presence server to allow a Mash-up
> with other feeds by using current state of art to do this.
>

Correct. As I have continued to work on these new-age mashup environments,
it seems to me that RSS Feed is only one possible format. Equally important
(if not more) is also the ability to export as JSON objects (for example,
Facebook accepts JSON input directly using their FBJS directives). Anyhow,
the concept remains the same - export presence in a format that web-based
mashups can access without the need for additional protocol parsing
requirements.

> Is your basic idea to extend every presence server with this Web feed

Yes, it will essentially boil down to a mapping. No, my thought here is not
to extend every presence server. I imagine this 'gateway' would be another
entity which subscribes to a 3rd party presence server and does this
conversion. So conceptually, every presence server does not need to be
extended.

> for the group of presentities (aggregated or single)?

I imagine both. I think that will be clear when we have a requirements
document on what this feed may/may not contain. I started work on it a few
months ago, need to complete it and post it for the review of this group.

> information is made in function of the watcher. In the indicated use case
> with the tracker, how will the privacy of the data be guaranteed? There is
> no longer a direct relation between the watcher and the presentity. The
> Trackit server can do an authentication for the HTTP GET request for the
> feed, but on which level, i.e. the Map & Track AS level or up to the users
> of this service (the other PUA)?
>

To keep it simple, I imagine that the presence server, providing this
feed(s) to the rss-presence gateway applies the required security before
sending any feed to the rss-presence gateway. For example, in the example
shown, I assume that [email-masked] is a PUA that subscribes to the
presence of 'joe', 'alice', 'bob', 'vader'. For this service to work
securely, I assume that the presence server from whom the presence is
obtained is aware that 'mapitntrackit' only has permissions to get notified
of the status of a set of users. Therefore, all security is applied *first*
at the presence server as is usually the case.
Now, the second question comes - does mapitntrackit server perform
authentication before the rss feed is shot out ? Yes, I assume it would do
HTTP authentication. Note also, that nothing stops it from exporting only a
subset as an RSS feed depending on who is the requestor.

> server for every PUA requested for the map service, the presence server is
> able to do perform its authorization and filtering rules.  But now, this
> function has to performed not only for one individual watcher but for a
> group of watchers. So, the common denominator for the information which can
> be revealed to the group has to be determined. Can this be a function of a
> NOTIFY aggregator which then also maps this info to the RSS/Atom format?
>

Yes, as described above, that is a possibility.

-- 
Arjun Roychowdhury