Subject: [Sipping] Comments to draft-garcia-sipping-resource-desc-pidf-00.txt

From: "Willekens, Marc" <[email-masked]>
Date: Wed, 7 Mar 2007 09:51:33 +0100

Hi,
 
Some general comments to the draft:
http://www.ietf.org/internet-drafts/draft-garcia-sipping-resource-desc-pidf-00.txt <http://www.ietf.org/internet-drafts/draft-garcia-sipping-resource-desc-pidf-00.txt> 
 
I have a specific remark on [Page 3], 1 Introdcution, §3:
Why no new presence information component resource in addition to person, service, device? Why is the resource an extension of the device?
When the resource can be stored on any place in a p2p network, why should there be a fixed relation towards a device?

Best regards,
Marc Willekens.
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 07 Mar 2007 12:23:51 +0200

Hi Marc:

Thanks for your questions and comments. See inline discussion.

Willekens, Marc wrote:
> http://www.ietf.org/internet-drafts/draft-garcia-sipping-resource-desc-pidf-00.txt
>  
> Why no new presence information component resource in addition to 
> person, service, device?

The idea is to reuse what we already have. In this case, we have PIDF 
(RFC 3863) and the presence data model (RFC 4479). The presence data 
model (and not the PIDF like the draft says) structures the presence 
information in three components: the person, the service, and the 
device. So it is expected that presentities model their presence 
information according to RFC 4479.

> Why is the resource an extension of the device?

Because we want to advertise resources that are "available" at that 
particular device. For example, if I have stored in my phone a few 
images that I want to advertise through my presence information, I 
cannot use the service nor the person components of the PIDF because 
these images are not tied to any service or person. Rather, these images 
are only available in the particular device that I am describing in the 
device component of the PIDF.

Imagine that I am publishing my presence information from a laptop and 
from a phone. In the <device> component that represents my phone I will 
advertise the availability of those pictures. In the laptop component I 
won't advertise them. Then the compositor can appropriately compose the 
presence information to watchers, potentially signalling those devices 
as separated devices, one including resources for pictures.

> When the resource can be stored on any place in a p2p network, why 
> should there be a fixed relation towards a device?

At the moment, the PIDF extension for resource descriptions (the draft 
you mentioned) does not work well in P2P environments. This is because 
when you subscribe to the presence information of a presentity, you 
subscribe to the URI of such presentity. So you will be able to learn 
resources *of that presentity*.

In other words: you wouldn't be able to subscribe to the "resource" 
itself, and learn which peers are storing that resource. For this, you 
can use the resource event package,

http://www.ietf.org/internet-drafts/draft-garcia-sipping-resource-event-package-01.txt

> Marc Willekens.

BR,

          Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 7 Mar 2007 11:22:56 -0500

I can understand using presence to say that one can print, or has  
video, or even that a device can store files and a rough idea of  
amount of space. However, once we get into providing a list of every  
file that is available for sharing on a device, I am worried that  
this may not be appropriate information to try and use presence for.  
It's easy to imagine millions of entries with a fairly rapid rate of  
change. I'm don't think presence  is the right tool for listings of  
file entries. On the other-hand I may have misunderstood what you  
were suggestion in the draft :-)

Cullen <with my individual hat on>

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 08 Mar 2007 09:05:56 +0200

Hi Cullen:

And you might be right... The original idea is to define a standalone 
'resource' event package for providing a remote file directory. The use 
case is described at the high-level in Section 3.2 of 
http://www.ietf.org/internet-drafts/draft-garcia-sipping-resource-sharing-framework-01.txt
and the high-level flow in Section 5 of the same document.

Then at the last IETF meeting I got some comments that it would make 
sense to combine this resource directory with presence, so that when I 
announce my presence information to my buddies I also announce resources 
I want to share. This makes sense in the context of authorization 
policies, where I can indicate which files to share to which watchers. 
The use case is presented in Section 3.3 of 
http://www.ietf.org/internet-drafts/draft-garcia-sipping-resource-sharing-framework-01.txt
and the high-level flow in Section 4.2 of the same document.

I think it should be possible for a presentity to advertise resources he 
wants to share, including files. We have seen pretty much the same 
function in commercial P&IM systems. Since everything is a resource, I 
don't know how we could limit such advertising to resources that aren't 
files.

I don't agree that "millions of entries with a fairly rapid rate of 
change". For my experience, people do not have millions of files for 
sharing, and they are mostly static entries. And if we apply partial 
notifications, filtering, and perhaps event throttling, the rate of 
notifications goes down substantially. In fact, RPID itself will 
generate more notifications than this draft.

But if this is a concern, we could study other ideas, for example: the 
PIDF could have some sort of "event package indirection", so it could 
provide a URL for subscritpion to the 'resource' even package. The 
problem is that there aren't any 'resource' ESCs out there, while there 
are 'presence' ESC, so we will miss aggregation if go into that direction.

BR,

        Miguel

Cullen Jennings wrote:
> 
> I can understand using presence to say that one can print, or has video, 
> or even that a device can store files and a rough idea of amount of 
> space. However, once we get into providing a list of every file that is 
> available for sharing on a device, I am worried that this may not be 
> appropriate information to try and use presence for. It's easy to 
> imagine millions of entries with a fairly rapid rate of change. I'm 
> don't think presence  is the right tool for listings of file entries. On 
> the other-hand I may have misunderstood what you were suggestion in the 
> draft :-)
>