[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Hi Marc, thanks for your review
Comment inline:
regds
arjun
On Nov 25, 2007 5:19 AM, Willekens, Marc (NSN - BE/Belgium - MiniMD) <marc.willekens at nsn.com> wrote:
Hi Arjun,
 

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.

 
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.
 

 

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?

 
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.
 

What will be included in the HTTP feed? The info from one presentity or 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.
 

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)?

 
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 mapitntrackit at hsc.com 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.
 
 

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?

 
Yes, as described above, that is a possibility.

 

br,

Marc.


_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple




--
Arjun Roychowdhury
_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple