Subject: [Sipping] UI Component Generalization Proposal (Was: Side Effects of SUBSCR IBE are Harmful)

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Mon, 6 May 2002 17:21:40 -0700

Hi Paul,

This is just an idea I an throwing up.

SIP is a Session Initiation Protocol. I conjecture that we think of all UI
components also as a session that can/must be created, updated and closed by
an application - exactly what a SIP is created for. This is what we already
do for media-based UI components, why not leverage this for other UI
component types as well? 

Currently we really only use SIP dialogs to negotiate SDP sessions (designed
for media-based mediums), however this does not always have to be the case.
There are many types of session that could be established. 

When I mean application interaction session, yes, I mean a SIP dialog [a
dialog being the basic foundation of SIP sessions]. A SIP dialog is defined
by the SIP message headers and not by the message bodies they carry. 

Each UI component class could merely define how the component session is
negotiated and then be used within the normal framework. For instance, if
you are creating a session for a markup-based UI component then the INVITE
message would perhaps carry a HTTP url for the UAS to use. I don't see this
as a perversion of SIP - its in fact exactly what it was designed for -
session initiation. 

This application interaction mechanism is not designed to be interacting
with proxies. It is design to be an interaction between a user device and a
network application server. 

The beauty of this solution is that the media-based SIP session is just one
of many possible ways of interacting with an application - so let's treat it
that way: a generic UI component. A user device can know that all UI
component session dialogs are all in fact connected to the same application
instance but each component is still an independent session that can be
setup, updated or closed independently by the application.

Robert.

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: 07 May 2002 00:08
> To: Fairlie-Cuninghame, Robert
> Cc: [email-masked]'; [email-masked]
> Subject: Re: Side Effects of SUBSCRIBE are Harmful (was RE: [Sipping]
> RE: I-D ACTION:draft-culpepper-sipping-app-interact-reqs-00.txt)
> 
> 
> Robert - question below.
> 
> "Fairlie-Cuninghame, Robert" wrote:
> > 
> > Hi Eric,
> > 
> > I agree. In fact I'm glad you say that as it reinforces an 
> idea I've been
> > toying with over the last few days.
> > 
> > I think that it would actually be good to represent ALL 
> user interface
> > components (conforming to this framework) as SIP sessions. 
> There are a
> > number of reasons I think this might be a good idea:
> ... 
> > This framework also fits very nicely (in fact almost 
> transparently) into the
> > SIP framework. An application that wants to interact with a 
> device (using
> > this framework) simply requests that the device issue a virtual user
> > interface identifier when establishing the initial SIP 
> session. To add
> > additional components to the VUI, the application uses the 
> received virtual
> > user interface identifier (which could even be a Contact-style URL).
> > 
> > Now the problem is almost reduced to defining SIP payload 
> formats for the
> > user interface components [e.g., markup reference in INVITE 
> message body].
> > 
> > Comments?
> 
> I am not sure I understand what you are suggesting.
> 
> Are you suggesting that each application establish a special 
> kind of *media* session, via SDP in an INVITE? Or are you 
> suggesting that the application establish a special
> kind of *dialog* with the device? Or something else?
> 
> Suppose that the application becomes aware of the need to 
> interact as result of association with some proxy along the 
> path of a request the device has sent. What would be
> the relationship between the session you are postulating and 
> the dialog that might be established between the device and 
> its intended target? 
> 
> 	Paul
> 

_______________________________________________
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: [email-masked]
Date: Mon, 6 May 2002 21:42:27 -0400

Hi Robert,
thanks for clarifying my prev. mail.

You mentioned that a draft-culpepper-sipping-app-interact-reqs-01 is out. However I found no references  to the same in the
sipping page or a google search.

Hence, my questions are still  based on the 00 draft:

besides the fact that SIP does offer a model to initiate/modify/close 
sessions, do you feel using SIP would leverage any of its other 
properties like routing, address translation (to think of two) or others ?

If not, do I surmise that the benefit of SIP that you perceive is a 
protocol that is being using to exchange information between two 
components ?

It would be great if you could provide some examples of other benefits 
that are perceived that SIP  can provide here.

Regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems
11717 Exploration Lane, Germantown MD 20876
(O): 301-212-7860        (M): 240-475-2139

"Fairlie-Cuninghame, Robert" <[email-masked]>
Sent by: [email-masked]
05/06/02 08:21 PM

        To:     "'Paul Kyzivat'" <[email-masked]>
        cc:     "[email-masked]'" <[email-masked]>, [email-masked]
        Subject:        [Sipping] UI Component Generalization Proposal (Was: Side Effects of 
SUBSCR IBE are Harmful)

Hi Paul,

SIP is a Session Initiation Protocol. I conjecture that we think of all UI
components also as a session that can/must be created, updated and closed 
by
an application - exactly what a SIP is created for. This is what we 
already
do for media-based UI components, why not leverage this for other UI
component types as well? 

Currently we really only use SIP dialogs to negotiate SDP sessions 
(designed
for media-based mediums), however this does not always have to be the 
case.
There are many types of session that could be established. 

When I mean application interaction session, yes, I mean a SIP dialog [a
dialog being the basic foundation of SIP sessions]. A SIP dialog is 
defined
by the SIP message headers and not by the message bodies they carry. 

message would perhaps carry a HTTP url for the UAS to use. I don't see 
this

This application interaction mechanism is not designed to be interacting
with proxies. It is design to be an interaction between a user device and 
a
network application server. 

The beauty of this solution is that the media-based SIP session is just 
one
of many possible ways of interacting with an application - so let's treat 
it
that way: a generic UI component. A user device can know that all UI
component session dialogs are all in fact connected to the same 
application
instance but each component is still an independent session that can be
setup, updated or closed independently by the application.

Robert.