Subject: RE: [Simple] New I-Ds on partial notification

From: [email-masked]
Date: Wed, 29 Jan 2003 16:22:00 +0200

Hi Jonathan,

As you say CI works pretty well but there are some complications. 
Charging issue is at least partly 3GPP specific. Charging would be
especially difficult in 3GPP type solution where all SIP carried stuff
goes via one PDP context (e.g. signaling PDP context). All other traffic
is going through other PDP contexts. From these the SIP carried stuff
can be free on the bearer level and service based charging is applied in
the application server. Other PDP contexts typically cause bill based on
the data amount transferred. Now if the operator wants to allow large
content as part of the presence and apply a service based changing the
system becomes unnecessarily complex due to CI.
CI requires some storage where content should be places until its
fetched or it expires. This box then needs to maintained and connected
to existing network elements like PS. This may be unnecessary overhead
for some systems.
 
Security is other issue. System should be able to associate HTTP
requests to specific subscription or to specific user. Also if CI is
done in some other domain than subscriber's own this issue gets more
complicated.

One issue relates to usability. If you really want to utilize CI user
should always be prompted to make decision whether content should be
downloaded or not. If these changes happen often user may be prompted
quite frequently (for example every 5 minutes) to make decision about
content downloading. This is not very usable ad for example for flat
rate charging it does not make much sense. 
If you want to limit the amount of content delivered via notifications I
think filtering might be right solution for that. Also partial
notifications allow PS not to send even small amounts of data. In
wireless environment this very useful.
 
Personally I think CI is a fine mechanism but some systems might like to
use some other mechanism like partial notification.

> <tuple deleted="yes" id="wsqw798jcr"/>

We also though about adding this kind of mechanism. Our thinking was
that we could live without it but if others see that it should be added
I don't have anything agents it. This would basically allow PS to send
partial notifications about removed tuples and not enforcing it to send
full presence document.

Regards
- Mikko

> 
> While I really don't have any objection in principal to partial 
> notification (winfo uses it, as you indicate), I am trying to 
> understand better the underlying motivations that are driving it.
> 
> In particular, pushing of large content (such as videos or images), 
> IMHO, is still better handled by conten indirection that partial 
> notifications. The reason is that the subscribing client may not want 
> to pay for receipt of the content. Partial notification avoids
> the need to 
> send it when it doesn't change, but when it does change, the 
> susbcriber 
> still needs to pay for this.
> Thus, content indirection to me seems the ideal solution to
> the charging 
> concerns you raise. Your drafts point out some kind of problem with 
> content indirection, in terms of charging, which I still don't really 
> understand. Can you please clarify exactly what the problem is?
> 
> 
> On the mechanism itself, it seems that a better solution for the case
> where a tuple is deleted, is to define an XML element that explicitly 
> indicates a deletion, carried in a partial update. For example:
> 
> <tuple deleted="yes" id="wsqw798jcr"/>
> 
> -Jonathan R.
> 
>> 
> 
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 31 Jan 2003 10:46:23 -0500

inline.

> system becomes unnecessarily complex due to CI.

Such a differentiated charging model for content opens the door for 
fraud. If sending content through presence is free, but costs money 
other ways, won't users just always send content through presence?

> to existing network elements like PS. This may be unnecessary overhead

No doubt this is extra infrastructure to maintain. However, such things 
will frequently exist anyway (i.e., MMSC provides a similar function).

> done in some other domain than subscriber's own this issue gets more

I would propose that security for indirection needs to be equivalently 
good (or bad) to without indirection. With indirection, if I can 
eavesdrop, I can get the content, unless its e2e encrypted or goes over 
encrypted links.

Now, if the CI URI is cryptographically random, it turns out the same 
holds true. You won't be able to guess the URI. To find it out, you'd 
have to be able to eavesdrop. Of course, if you could eavesdrop, you 
could obtain the content even if there were no indirection. If the URI 
is protected e2e with encryption, or goes over secure links, you will 
get good security.

So, AFAICT, security of indirection can be the same for inline content 
so long as the URI are intelligently chosen.

> rate charging it does not make much sense. 

One feature of indirection is that it indicates when its changed. So, 
you would know only to download the content in those cases.

> use some other mechanism like partial notification.

Well, let me be clear on my position.

I have problem with partial notifications. I dont mind developing a spec 
for them either. However, I think their need is greatly overestimated, 
and it will buy you far less than you think for the complexity it 
introduces.

-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