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 04:48:03 -0700

> 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.

.. or simply to define an SDP profile for these components (which probably
has a few advantages). 

m=application 1080 HTTP
a=href: http://blahblahblah

The key idea is that these UI components are representable as sessions so
that they can be treated in a homogenous manner with media-based components.
Anyway just a thought.

> 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. 

Oops. I meant authentication not authorization.

Robert.

> -----Original Message-----
> From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
> Sent: Tuesday, May 07, 2002 9:22 AM
> To: [email-masked]'
> Cc: 'Paul Kyzivat'; [email-masked]
> Subject: RE: [Sipping] UI Component Generalization Proposal (Was: Side
> Eff ects of SUBSCR IBE are Harmful)
> 
> 
> 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-ap
> p-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
> 

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Tue, 07 May 2002 11:52:03 -0400

Robert,

Finally, based on the message below, I think I understand.

Accomplishing this via SDP seems cleaner to me than establishing the session context some other way. For instance the offer/answer mechanism is there for negotiation.
Trying to achieve this some other way already got us in trouble wrt IM.

There are of course details to work out, but the concept seems interesting.

One issue is how to negotiate the markup language to be used. Another issue is that your example isn't valid SDP because it doesn't specify a codec. These two can be solved
together, if you do something like:

  m=text 1080 HTTP html

This says that I want to use mime type text/html. This also provides a way to negotiate the markup language, by offering multiple "codecs" using offer/answer. I can
speculate that a caller might sent the following in an offer:

  m=text 80 HTTP html xml+vxml xml+dml
  a=sendonly

and the corresponding answer might be something like

  m=text 1080 HTTP html
  a=recvonly

(I don't know if using text/xxx is legal here, but that is how html is defined. I also don't know if there is a valid explicit mime type for vxml, and am speculating on one
for dml.)

	Paul