Subject: RE: [Simple] RE: Question regarding NOTIFY messages using UDP.

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 4 Dec 2001 11:05:12 -0500

-----Original Message-----
From: Brian Stucker [mailto:[email-masked]]
Sent: Tuesday, December 04, 2001 10:54 AM
To: Jonathan Rosenberg; Jonathan Rosenberg; 'Michael Hammer'
Cc: [email-masked]'; simple; Alex Nava; Patrick Sollee; Sanjoy Sen
Subject: RE: [Simple] RE: Question regarding NOTIFY messages using UDP.

>Great. 
>So, we'll have the ability to specify application/url-list in the SUBSCRIBE
for presence 
>events in the -05 draft? 

Well, we need to decide whether thats really a separate package, or just a
different data format for an existing package.

We also need a few more opinions on this subject, since the list has been
faily quiet of late.

-Jonathan R.

-----Original Message----- 
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Tuesday, December 04, 2001 12:54 AM 
To: Stucker, Brian [NGB:B635:EXCH]; Jonathan Rosenberg; 'Michael Hammer' 
Cc: [email-masked]'; simple; Nava, Alex [NGC:B634:EXCH]; 
Sollee, Patrick [NGC:B680:EXCH]; Sen, Sanjoy [NGB:B692:EXCH] 
Subject: RE: [Simple] RE: Question regarding NOTIFY messages using UDP. 
>Good idea (HTTP url)... 
Thanks. 
>The thought had occurred to me briefly, but I really hadn't 
>thought it out much. 
> 
>Actually, would it be possible to simply throw a request URI into a 
presence notification 
>for any sort of a transfer? 
Huh? The request URI of the NOTIFY is determine through standard Route 
header processing. 

> 
>i.e. to get around problems with message length and firewall/NAT issues, is

it important 
>that we actually include the cpim-xpidf+xml document in the NOTIFY, or 
could we simply add 
>that you might get an application/cpim-xpidf-url document, that the client 
can go grab 
>using HTTP. Solves all of the problems in one tidy package. 
I see no need to define a URL format for each document type. You could 
either: 
1. subscribe to Event: presence.alert, and the Accept header has type 
application/uri-list. The NOTIFY would contain URLs to get at the presence 
doc, presumably with HTTP URLs. This is the proposal below. 
2. subscribe to Event: presence, and the Accept header has type 
application/uri-list, which becomes a valid type for NOTIFY. The NOTIFY 
comes with the URL list. This is similar to what I have suggested below, but

uses the same package. 

>That way clients initiate the transfer of the presence document, and can 
choose TCP if 
>they wish (likely), or if they suspect they're behind a firewall/NAT. When 
they make the 
>subscription, they could include an accept with the 
application/cpim-xpidf-url content 
>type which would simply be an HTTP or HTTPS url to where to grab the 
presence document. 
> 
>Another added advantage would be that you could use a "cheap" transport 
like UDP to send 
>the notification, and then let the client initiate an "expensive" transport

like TCP or 
>TLS, on demand, to go get the document when it needs to. That would allow 
established 
>secure HTTP transfers to take place when retrieving the data that we're 
trying to pull. 
Right. This is exactly what I have proposed below. 
-Jonathan R. 
-----Original Message----- 
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Monday, November 26, 2001 2:03 PM 
To: 'Michael Hammer'; Jonathan Rosenberg 
Cc: [email-masked]'; Stucker, Brian [NGB:B635:EXCH]; simple; 
Nava, Alex [NGC:B634:EXCH]; Sollee, Patrick [NGC:B680:EXCH]; Sen, Sanjoy 
[NGB:B692:EXCH] 
Subject: RE: [Simple] RE: Question regarding NOTIFY messages using UDP. 

> -----Original Message----- 
> From: Michael Hammer [mailto:[email-masked]] 
> Sent: Wednesday, November 21, 2001 10:11 AM 
> To: Jonathan Rosenberg 
> Cc: [email-masked]'; 'Brian Stucker'; simple; Alex Nava; 
> Patrick Sollee; Sanjoy Sen 
> Subject: RE: [Simple] RE: Question regarding NOTIFY messages 
> using UDP. 
> 
> 
> Jonathan, 
> 
> While not favoring any fragmentation mechanism for SIP, does 
> this preclude 
> any implementation (higher level application using SIP) from 
> choosing to 
> send the body of the Notifies as incremental parts?  It would 
> seem that the 
> SIP-level mechanisms would be unaware of the full nature of 
> the body which 
> it carries and should place no restrictions on that body. 
> 
> That is, it provides no mechanism nor precludes use of such a 
> mechanism. 
The spec assumes full-state, and talks about using CSeq to determine the 
most recent document, which wouldn't make sense for partial documents as you

have described. 
An extension could in principle override this, and you could define a 
document format that supports partial information. 
However, I still assert that: 
1. this is a problem in theory only 
2. if the docs do become large, delta encoding is better 
Honestly, the problem is more for other event packages that may convey 
larger amounts of state. 

Brian later writes: 
> Ok, here's a thought... 
> If we're in a position where we think we're going to need to use TCP (or 
some other 
> connection-oriented protocol) to notify the watcher (in this example, a 
presence 
> subscriber), but it's difficult to keep up a bunch of TCP connections, we 
use the 
> following general mechanism. 
> 
> 1. We send the watcher a NOTIFY that says in effect "you need to fetch the

current state 
> of this resource" (in this case, probably using UDP). 
> 
> 2. The watcher responds to the NOTIFY with a 200 OK however it chooses. 
> 
> 3. The watcher sends a SUBSCRIBE in to fetch the current state of the 
resource (in this 
> case a presentity) using the transport of it's choosing. If it knows it's 
behind a 
> firewall, or a NAT, then it can pick TCP, for instance. 
Actually, we've been toying with the idea of not even using SUBSCRIBE for 
this. An HTTP request is just fine for synchronously fetching a document; 
thats what its designed to do. 
One could think of this as another sub-package, say "alert". If you 
subscribe to foo.alert, you get a NOTIFY when foo changes, but the NOTIFY 
contains a body type that is always short - providing a URL for actually 
retrieving the thing that has changed. In fact, the default could be as 
simple as application/uri-list. So: 
SUBSCRIBE sip:[email-masked] SIP/2.0 
Event: presence.alert 
Accept: application/uri-list 
then the NOTIFY: 
NOTIFY sip:[email-masked] SIP/2.0 
Event: presence.alert 
Content-Type: application/uri-list 
http://school.edu/user/current-pres-doc.pl 

One might even have multipel URI there of several schemes, supporting a 
variety of pulls. 

-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

---

From: Sean Olson <[email-masked]>
Date: Tue, 4 Dec 2001 08:08:57 -0800 (PST)

This is a great idea. I don't see the need
to make this a different package, however.
There are good mechanisms in SIP to negotiate
payloads. This should be sufficient for this
purpose.

/sean

--- Jonathan Rosenberg <[email-masked]>
> > following general mechanism. 
=== message truncated ===

=====
--
Sean Olson <[email-masked]>
This is from me. Assume nothing else.

__________________________________________________
Do You Yahoo!?
Buy the perfect holiday gifts at Yahoo! Shopping.
http://shopping.yahoo.com