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

From: [email-masked]
Date: Sat, 1 Feb 2003 11:29:15 +0200

Hi,

inline

> inline.
> 
> [email-masked] wrote:
> > 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.
> 
> 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?

I didn't want to imply that it would be free. Points was that operators
would like to implement service based charging for some services. For
example without signaling context being free users would have to pay for
unanswered calls.    
 
> 
> > 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.
> 
> No doubt this is extra infrastructure to maintain. However,
> such things 
> will frequently exist anyway (i.e., MMSC provides a similar function).

MMSC (Multimedia Messaging Service Centre) is network element used in
messaging service. In some systems such elements exist but to require
such element being present to implement presence or to couple messaging
service to presence may not make that much sense. 
 
> >  
> > 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.
> 
> 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.
> 
> > 
> > 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.
> 
> One feature of indirection is that it indicates when its changed. So,
> you would know only to download the content in those cases.

Exactly and if it changes frequently then you are prompted as
frequently. Also using CI user really have no means to make decision
whether to fetch the content or not. What I mean is that user sees the
URL but cannot really know if he/she would be interested in this content
until it is fetched. 

> 
> 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.

This is fair. However, reading your mail I couldn't find any of these
complexities. Could you be more specific what you think causes this
complexity. As the partial notification mechanism is largely based on
same mechanism as winfo is PS and UAs should already (if they support
winfo)  have means to handle partial notifications.

Regards
- Mikko

> -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]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 03 Feb 2003 10:32:02 -0500

inline.

> example without signaling context being free users would have to pay for

That doesnt change the point here. If transfer of content within 
presence is covered as part of my fee for the service, but fetching of 
content outside of it costs money, then users will end up generally 
sending content through the presence service because its cheaper.

Anyway, if you do wish to do such a thing, and you are using the PDP 
conext to flag what is byte-metered vs. what is not, the real problem is 
that you can only bind a PDP context to a single protocol. Many 
protocols and operations may be involved in providing a service. That is 
the root cause problem. Designing application protocols to fit the 
packet metering methodology is not.

> service to presence may not make that much sense. 

If you are not using messaging, you can get something else that provides 
the function that is not an mmsc. Repositories for content are not hard 
to come by.

> URL but cannot really know if he/she would be interested in this content

I doubt that is true. The indirections contain meta-data, such as size 
and type. Many of the PC-based IM programs prompt the user with this 
meta-data before files are accepted. Indeed, content indirection is the 
core of MMS. Content is NEVER sent directly to the recipient!

Are you really trying to say that you dont think recipients should be 
given a choice about downloading large content??

> winfo)  have means to handle partial notifications.

Yes, it is the same as winfo, more or less. The complexity there is the 
need for the UA to handle partial information, ask for full-state 
updates, and for the server to deal with this as well. Its not hard, but 
it requires code and specifications to do. The point I have been trying 
to make is that I believe you need content indirection in either case, 
and so the benefits of the partial notifications are quite small, IMHO, 
not big enough to outweigh the work they introduce.

-Jonathan R.

---

From: "Dean Willis" <[email-masked]>
Date: Wed, 5 Feb 2003 19:26:05 -0600

> I didn't want to imply that it would be free. Points was that
> operators would like to implement service based charging for 
> some services. For example without signaling context being 
> free users would have to pay for
> unanswered calls.    

So what keeps me from putting the information I want transmitted into the
body of an INVITE, which my confederate then does not answer (or declines)?
I could probably come up with steganographic techniques to allow me to do
Napster-like file sharing using INVITES with fairly normal (and LEGAL) SDP
bodies . . . Hey, that's pretty cool, I think I'll work on it in my copious
free time. Consider this an IPR declaration. It'll make a nice April 1 RFC.
What do you think of "Parasitic Peer-to-Peer Networking using SDP
Steganography over SIP in 3G Networks" as a title?

Followup, if any, should probably be in a different forum, as this issue
really isn't a SIMPLE thing.

--
Dean