Subject: RE: [Simple] 3GPP Presence requirements I-D: how the requirementsare handled

From: [email-masked]
Date: Wed, 14 Aug 2002 16:17:08 +0300

Hi,

> > IETF54 made a consensus about integrating the 3GPP Presence 
> requirements
> > 
> (http://www.softarmor.com/simple/drafts/draft-kiss-simple-pres
> ence-wirel
> > ess-reqs-00.txt) into the chartered requirements document. 
> I assume the
> > integration could be done for most of the requirements, 
> however we might
> > need further discussions for some of the "tricky" 
> requirements. Hereby I
> > have tried collecting these:
> > 
> > 1. Filtering. The minutes of the SIMPLE session states: "there are
> > requirements for filtering in a lot of our discussions, we 
> should add to
> > charter." I guess there is consensus here, so filtering 
> should be added
> > to SIMPLE charter.
> 
> I agree filtering is important. What is not clear is whether 
> we should 
> start with requirements, and where those should be done, and 
> then where 
> the filtering work should occur. I suppose that, since its not a sip 
> extension per se, SIMPLE would be OK. However, I would hope that the 
> work is not presence specific, and would be generally useful 
> for sip events.

I agree that we should go for a general "sip-events" filtering. Probably SIMPLE would be the best place for this.
I guess quick requirements I-D would be useful, we could even come up with one if there is consensus on it.
 
> > 2. Partial publication/notification: during the SIMPLE 
> session it was
> > commented that CPIM and partial notification are conflicting
> > requirements. This requirement is considered an important 
> feature for
> > wireless environment, however I am not sure how to resolve 
> the conflict
> > with CPIM. See also related mail in
> > 
> http://mailman.dynamicsoft.com/pipermail/simple/2002-July/001691.html
> 
> It is not at all clear to me that this will actually save you 
> anything. 
> I suspect that SIGCOMP would, right now, give you much better overall 
> bandwidth utilization than partial notifications. There is 
> simply not a 
> sufficient amount of data in the presence for a single user 
> to warrant 
> partial updates, IMHO.

I try to make a simple example: let's assume that a JPEG picture is part of my presence information. I usually do not want to update the picture, however from time to time I want to change my picture in order to keep my watchers up-to-date. If I don't need to send my unchanged picture in every PUBLISH and my watchers don't receive it in every NOTIFY (only when it has changed), then I think we manage to save a lot of bandwidth. Certainly in this case the PUBLISH/NOTIFY is always dependent on the previous one. 
I guess pictures/logos/tones can be considered as soft state, if always one of them is associated with one profile in the phone. SIGCOMP only saves bandwidth in the air interface (in 3GPP environment), while with partial publication/notification we could also save bandwidth in the whole network.
I hope this also answers Sean's concerns.

> > 4. "Keep all PUAs aware of each other's publishing": this 
> requirement
> > might be fulfilled with the solution when every PUA 
> subscribes to its
> > own presence. Using filtering mechanisms, the PUA could 
> filter out its
> > own publication when receiving notifications in order to 
> save bandwidth.
> 
> I asked this during the meeting, and I will ask again - why?
> 
> The whole model of presence is that each PUA is independent. 
> They don't 
> need, and in fact, don't want, to know the details of the other PUA 
> publishing for the presentity. Indeed, I can imagine cases 
> where a PUA 
> is authorized to publish for a presentity, but not authorized 
> to see its 
> presence! Consider the case of a web server that publishes 
> information 
> on the web page I am currently browsing; I might not want 
> that site to 
> know anything about me; but its OK for it to publish that I 
> am currently 
> browsing their site.

Perhaps it is not clear for me what the PUBLISH draft says about this, but what happens if the same information (i.e. the same tuple) can be updated from multiple PUAs? (e.g. I am logged on to the same IM application from two devices)
It might be so that the PUAs should not care about each others publishing, so the compositor should be responsible to realize that the different publishers publish the same information and it should always notify the watchers about the latest published information.
It would be also useful for the PUA to know what happened with its publication. E.g. if it publishes status=closed, but the presence document says status=open for some reason.

Thanks,
Krisztian

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 20 Aug 2002 14:10:33 -0400

inline.

[email-masked] wrote:

> I try to make a simple example: let's assume that a JPEG picture is part
> of my presence information. I usually do not want to update the picture,
> however from time to time I want to change my picture in order to keep
> my watchers up-to-date.

Including the jpeg in the presence doc is a bad idea, for many reasons. 
You are much better off passing an http reference to it. If it changes, 
send a new reference.  IMPP went through a long debate about whether to 
include this kind of static contact information (vcard style things) and 
concluded not to even do it.

With a reference, it can be put into the sigcomp dictionary the first 
time, and each subsequent notification will use the value from the 
dictionary. Seems like the same performance as partial notifications.

> I guess pictures/logos/tones can be considered as soft state, if always
> one of them is associated with one profile in the phone. SIGCOMP only
> saves bandwidth in the air interface (in 3GPP environment), while with
> partial publication/notification we could also save bandwidth in the
> whole network.

Using a URI to reference it saves bandwidth in the whole network, and 
won't break interop with regular CPIM/PIDF compliant endpoints.

> Perhaps it is not clear for me what the PUBLISH draft says about this,
> but what happens if the same information (i.e. the same tuple) can be
> updated from multiple PUAs? (e.g. I am logged on to the same IM
> application from two devices)

I would argue that this is actually two contact addresses.

> It might be so that the PUAs should not care about each others
> publishing, so the compositor should be responsible to realize that the
> different publishers publish the same information and it should always
> notify the watchers about the latest published information.

Well, in the case above, the compositor would see publication of 
presence state for two separate IM applications. How it combines those 
is policy specific.

> It would be also useful for the PUA to know what happened with its
> publication. E.g. if it publishes status=closed, but the presence
> document says status=open for some reason.

Well, that it can obtain through presence itself.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com