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

From: [email-masked]
Date: Fri, 23 Aug 2002 14:53:42 +0300

Hi,

Some further thoughts about partial publication and notification:

Is there a good enough security solution for using content indirection and HTTP for the purpose described below? I think doing it inter-domain will be difficult in the general case. Also, partial notifications with SIP would be easier in an environment where charging of "signaling" is somehow special.

I understand that this stuff will not be interesting or needed for the whole SIMPLE deployment base (due to complexity reasons), and that interoperability is of extreme importance. But if 3GPP specifically wants this feature, can THEY do it if it meets the following requirements:
- Everyone must also support normal operation (i.e. no partial updates)
- Capability for partial updates is always negotiated when setting up the dialog, and if the other end does not have it, normal operation is assumed.

I guess this could work by defining and registering a new content-type in addition to PIDF, which has the partial update capability. Support for this could be negotiated with Accept: header.

I don't see any harm in this. Any objections? Of course the best way would be to have SIMPLE WG do it completely.

Markus 

Jonathan Rosenberg wrote:
> 
> inline.
> 
> [email-masked] wrote:
> 
> >>>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/00
> 1691.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.
> 
> 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.
> 
> 
> 
> >>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)
> 
> 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
> 
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 27 Aug 2002 22:27:33 -0400

[email-masked] wrote:
 > Is there a good enough security solution for using content
 > indirection and HTTP for the purpose described below? I think doing
 > it inter-domain will be difficult in the general case.

I think security can be exactly the same.

If you assume that there is no S/MIME, including the content inline is 
only "secure" in the sense that the only way someone else can see the 
content is eavesdropping/interception/MITM. If you can eavesdrop, you 
have the content. The content can also be "leaked" if the recipient 
sends it to someone else; there is no protection against that. For 
content indirection, the URI in the indirection needs to be sufficiently 
randomized, so that is unguessable. In that case, the only way to obtain 
the content is to know the URI. The only way to know the URI is to 
eavesdrop/intercept/MITM. If can also be leaked in the same way, if the 
URI is emailed.

Of course, within the same domain, security is a bit better. The content 
indirection server can authenticate the recipient with digest, so even 
if a user eavesdrop the URI they can't get the content.

If you assume S/MIME, well, then you S/MIME the content before uploading 
it to the indirection server, and security is just as good as including 
it as an attachment.

 > Also, partial
 > notifications with SIP would be easier in an environment where
 > charging of "signaling" is somehow special.

Well, the perils of that are obvious. Anyway I don't see how compression 
would still achieve the same (if not better) impact for clients.

 >
 > I understand that this stuff will not be interesting or needed for
 > the whole SIMPLE deployment base (due to complexity reasons), and
 > that interoperability is of extreme importance. But if 3GPP
 > specifically wants this feature, can THEY do it if it meets the
 > following requirements: - Everyone must also support normal operation
 > (i.e. no partial updates) - Capability for partial updates is always
 > negotiated when setting up the dialog, and if the other end does not
 > have it, normal operation is assumed.

I would rather protocol work be done in IETF.

I have no problem doing partial notification if the case can be made 
that it really is needed. However, it is my sense that this is one of 
these things that appears essential at first glance, but when you 
examine it, becomes less clear that it buys you all that much, and it 
comes with many headaches.

-Jonathan R.