RE: Side Effects of SUBSCRIBE are Harmful (was RE: [Sipping] RE: I-D ACTION:draft-culpepper-sipping-app-interact-reqs-00.txt)

["Fairlie-Cuninghame, Robert" <[e-mail]>]

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:

- Media-based UI components can then be treated the same as presentation- or
input- based components.

- Since it has been suggested that all virtual user interfaces MUST be
associated with a SIP session, it actually makes things a lot cleaner if all
UI components are themselves SIP sessions. For instance, a user that
initiates an application interaction session using a media-based component
(e.g., speaker+microphone) may later wish to switch to web-based interaction
and hangup the handset. This is easily accomplished if both components are
SIP sessions and the virtual user interface is associated with either/both
sessions.

- Additionally, application interactions do not need to be initiated with
media-based (or empty "placeholder") SIP sessions. For instance, an
application can initiate an interaction session with a VoiceXML-only
interface. 

- A user wants/needs to know what entities are listening to their actions
and input. From a security point of view (and more importantly human-factor
POV), it is a lot easier to compare apples to apples. For instance, the user
can see that the SIP sessions for the media-based component (e.g.
speaker+microphone), presentation-based (e.g. web-page), input-based (e.g.
dialpad) components are all associated to the same application. [Rather than
comparing SIP sessions to subscriptions to arbitrary markups]. 

- SIP sessions are time-bounded so that applications should not be able to
"lurk" in the background after an application session has finished.

- By placing all UI components in a SIP session, applications should be able
to update and close created user interface components.

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?

Cheers,

Robert.


> -----Original Message-----
> From: Eric Burger [mailto:[e-mail]]
> Sent: 06 May 2002 16:24
> To: Fairlie-Cuninghame, Robert
> Cc: [e-mail]
> Subject: Side Effects of SUBSCRIBE are Harmful (was RE: [Sipping] RE:
> I-D ACTION:draft-culpepper-sipping-app-interact-reqs-00.txt)
> 
> 
> Mumblings I've been hearing include the thought of using the SUBSCRIBE
> method to request a device to do something, like play a 
> prompt, prompt and
> collect digits, and so on.
> 
> This is bad, verging on EVIL.  Let us look at the definition 
> of SUBSCRIBE,
> from Section 4.1 of draft-ietf-sip-events-04:
> 
>      The SUBSCRIBE method is used to request current state and state
>      updates from a remote node [Notifier].
> 
> 
> SUBSCRIBE is supposed to be a non-invasive method.  With one 
> exception,
> SUBSCRIBE is not supposed to modify the state of the 
> Notifier.  Starting a
> prompt play, displaying a screen, or a prompt & collect operation most
> definitely changes the state of the Notifier.
> 
> The one exception is (obviously) the Notifier responds to the 
> SUBSCRIBE
> request.  If there is a non-zero Expires, the Notifier needs 
> to remember to
> update the Subscriber.  Other than that, SUBSCRIBE should 
> (MUST?) not have
> side effects on the Notifier.
> 
> 
> With respect to the comment below, a session is infinitely 
> more appropriate
> for the interaction model.
> 
> 
> -----Original Message-----
> From: [e-mail] 
[mailto:[e-mail]]On Behalf Of
Fairlie-Cuninghame, Robert
Sent: Friday, April 26, 2002 4:59 AM
To: '[e-mail]'
Cc: '[e-mail]'
Subject: [Sipping] RE: I-D
ACTION:draft-culpepper-sipping-app-interact-reqs-00.tx t

[snip]
I don't see any reason that it wouldn't be possible to place the markup in a
subscription .... or rather, I think perhaps a session is more appropriate
than a subscription for this model.
[snip]

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