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

From: [email-masked]
Date: Thu, 6 Feb 2003 01:50:50 +0200

Hi Mark,

Some comments inline.

> -----Original Message-----
> From: ext Mark Watson [mailto:[email-masked]]
[snip]

> In my personal opinion, binary content in SIP messages, 
> including the Caller Photo & Multimedia Messages is a bad 
> thing per se and Content Indirection should always be used. 
> (As Jonathan mentioned, the existing MMS does not send the 
> content with the notification of the message - you have to 
> fetch it).  

I happen to agree with you. CI is a very good idea in general. However, there are issues with it in my opinion, which need to be addressed. For example, CI specs intentionally leave out the publishing part - you simply push the content to a repository and get the URL by some means. Now take the scenario where CI is used in presence. For security reasons, you'd like to get a _different_ random URI per individual watcher. That means subscribing first to winfo, and doing some multiplication function on the CI URI, publish (?!) the same document individually for each watcher... Yikes. The other option is to leave all of this for the PS/composer to take care of. Either way, it's not a straight forward piece of machinery, and needs some text in a spec, IMHO.

Also, I don't know whether the notify/fetch is actually a feature of MMS - or a bug (meaning that since there is no way to really push the content all the way, there's a need to first notify). At least my phone currently doesn't prompt me, but goes and fetches the MM automagically.

> Having said that, referencing out from the Presence Document 
> to something which might be at a URL or might be in another 
> MIME part of the Notification might provide a way forward - 
> of course I'd still say that these other MIME parts should be 
> Content-Indirected :-), but at least you have solved the 
> encoding problem and brought the compression problems into 
> the same space as Caller-photos etc.

Yes, I think we are on the same page here.

Cheers,
Aki

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 06 Feb 2003 00:08:00 -0500

inline.

[email-masked] wrote:

 >
 >> In my personal opinion, binary content in SIP messages, including
 >> the Caller Photo & Multimedia Messages is a bad thing per se and
 >> Content Indirection should always be used. (As Jonathan mentioned,
 >> the existing MMS does not send the content with the notification of
 >> the message - you have to fetch it).
 >
 >
 > I happen to agree with you. CI is a very good idea in general.
 > However, there are issues with it in my opinion, which need to be
 > addressed. For example, CI specs intentionally leave out the
 > publishing part - you simply push the content to a repository and get
 > the URL by some means.

Well, as I have argued, there are multiple ways to do this. INdeed, 
several are already standardized, include webdav and regular HTTP PUT. 
Indeed, I know of webdav servers that have recently been sold 
specifically for IM apps using content indirection.

 > Now take the scenario where CI is used in
 > presence. For security reasons, you'd like to get a _different_
 > random URI per individual watcher.

If the URI is random, which I agree it has to be, what is the benefit of 
it being random AND different for each watcher?

 > That means subscribing first to
 > winfo, and doing some multiplication function on the CI URI, publish
 > (?!) the same document individually for each watcher... Yikes.

I dont follow that...

I must admit I am still confused on the technical problems with CI for 
large presence content. Can you provide a crisp and detailed summary of 
the problems that you see? It seems the biggest beef is this mysterious 
charging problem that still eludes me...

Anyway, practically speaking how often does my picture change? Seems 
like the easiest thing is that, from my pc, i put the thing on my web 
page and then just include the URI to it in my presence document.

 > The
 > other option is to leave all of this for the PS/composer to take care
 > of. Either way, it's not a straight forward piece of machinery, and
 > needs some text in a spec, IMHO.

IMHO, all of the protocol machinery needed for this exists. In that 
case, I think a description of how it gets integrated probably belongs 
in the architecture doc that Avshalom and Tony H. are working on.

 >
 > Also, I don't know whether the notify/fetch is actually a feature of
 > MMS - or a bug (meaning that since there is no way to really push the
 > content all the way, there's a need to first notify). At least my
 > phone currently doesn't prompt me, but goes and fetches the MM
 > automagically.

A bug? You must be kidding! I think this is a critical feature! Are you 
telling me that you REALLY want to ALWAYS pay for someone else picture 
of their kids that they put in a presence doc or IM???? Maybe your phone 
always pulls it, but perhaps its time to get a new phone ;)

-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