Subject: RE: [Sipping] App-Interaction: Considering models

From: Adam Roach <[email-masked]>
Date: Wed, 20 Aug 2003 18:12:31 -0500

Cullen Jennings [mailto:[email-masked]] writes:

> So are we coming to the conclusion that the
> GRUU/SUB/NOT is the right way to go? I can try
> and flesh out some details on this if we are.

Personally, I now favor this method, since I consider
the http correlation issue that we've discussed to
be a non-starter. I don't think it's unsolvable; I
just am wary of solutions that obviously need hacks,
even when viewed at the mile-high level.

However, my arguments for preferring explicit
use of SUBSCRIBE over a new method are, at this point,
largely philosophical, not technical. I'm not
certain that discussion has played out completely
yet.

/a

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 25 Aug 2003 17:03:37 -0400

> even when viewed at the mile-high level.

Well, the correlation would work identically to the SIP case. The HTTP 
request would need to carry some kind of dialog identifier, whether 
its in the body or as part of the R-URI.

> certain that discussion has played out completely

Well, let me tease this out a bit.

The purpose of SUBSCRIBE is to ask about the state of something that 
exists already in the network. The SUBSCRIBE message itself does not 
create an instance of the thing being monitored, nor does the lifetime 
of the subscription guide the lifetime of the state being monitored. 
Indeed, I recall that Eric had objected to an explicit SUBSCRIBE for 
carrying the KPML, since it doesnt make sense to have SUBSCRIBE create 
the state being monitored.

I would argue that the App-Info header is what is actually creating 
the state, and the state of this thing exists for the duration of the 
dialog. The results of the user input are the state, but they aren't 
normally sent anywhere. Rather, they are monitored through an explicit 
subscription from the application server.

In this model, I suppose an explicit subscription makes sense, but the 
whole thing seems convoluted. Why bother to explicitly subscribe to 
something when you created the state in the first place, and you are 
the only one who is interested in finding out about it? Why bother 
managing the state of the subscription AND the user input state 
separately?

The overall system, to me, feels a lot more like form input on the 
web. A server in the network provides a script that gives context for 
the user to provide input. This input is then sent back to the source 
of the script in the first place, which then returns (possibly) 
another script to execute.

As such, I have more or less talked myself out of implicit 
subscriptions, but also explicit subscriptions at the same time. I 
would say that this is either a new method or HTTP, which still 
remains my favorite.. I'll respond to Cullen's note on this separately.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com