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

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Tue, 7 May 2002 01:21:43 -0700

Arjun,

The draft was announced last Thursday:

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Network Application Interaction Requirements
	Author(s)	: B. Culpepper, R. Fairlie-Cuninghame
	Filename	: draft-culpepper-sipping-app-interact-reqs-01.txt
	Pages		: 9
	Date		: 01-May-02
	
http://www.ietf.org/internet-drafts/draft-culpepper-sipping-app-interact-req
s-01.txt

When searching for drafts, I normally go to http://www.ietf.org, click on
"Internet Drafts" and then do a keyword search.

I listed quite a few in the first email, some of which are important IMO
(especially the human-factor issues, comparing apples-to-apples). There are
many other benefits SIP includes: identification and authorization framework
(eventually :), end-to-end security, firewall address translation to setup
sessions and routing to mention a few. I see no reason why these are RTP
media session specific. Even the simple ability to establish/update/close a
session is not a trivial task - its more than just exchanging information
between to components.

Please note that, just like media-based sessions, SIP does not have to carry
the actual component content. For instance, for markup UI components the SIP
message bodies could only carry a URL *reference* used by the UA to do a
HTTP GET. A re-INVITE will cause the UA to update the browser window with
the supplied URL and a BYE will force it to close the browser windows
associated with this component.

Robert.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 07 May 2002 02:42
> To: Fairlie-Cuninghame, Robert
> Cc: [email-masked]'; 'Paul Kyzivat'; [email-masked]
> Subject: Re: [Sipping] UI Component Generalization Proposal (Was: Side
> Effects of SUBSCR IBE are Harmful)
> 
> 
> 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,
> 
> 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
> 
> 
> 

_______________________________________________
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