Subject: [Sipping] RE: I-D ACTION:draft-culpepper-sipping-app-interact-reqs-00.tx t

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Fri, 26 Apr 2002 01:59:29 -0700

Hi Jonathan,

I agree that your approach has a degree of elegance for in handling
user-presentation aspects. However, I think that there are problems with
some areas of your mechanism (as written). I have yet to fully cogitate the
implications. I guess Bert, JF & myself also need to discuss the future
direction of our proposal. 

Hopefully there will be a way to bring out the best of both proposals. As I
see there are definite advantages of both schemes (and not necessarily
mutually exclusive). 

Foremost in my mind is the fact that there is no way an application can
indicate a change or end of a markup/interface (e.g. revoke or update the
markup when the application closes or updates). This is something that is
inherently possible in a subscription (e.g., for stimuli) but awkward in a
traditional markup paradigm [which is more designed for ongoing applications
where all the interaction is through the markup]. 

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.

When you think about it, your user-interface is really a session - an
applications wants to setup the presentation/stimuli, possibly periodically
update it and eventually close it. Perhaps it would be possible to have a
SIP session wrapper around an HTML/DML (or any other markup) reference so
that the application can re-INVITE or BYE it. This would also solve a couple
of OPEN ISSUEs in your draft of enacting and associating/authenticating
markup updates. There's issues in doing this as well but its worth further
thought [and could replace the need for App-Info header with the use of a
Join operation].

One limitation of the current proposal which I believe that needs to be
either accepted or addressed is how to retrieve *specific* information about
the device's user interface. This information goes beyond what would be
classified as device capabilities and user preferences (CC/PP) information
but rather would be "on-demand" information about a particular stimulus. For
example, if an application may want to know the physical label for a
particular key or perhaps the state of a device widget (e.g. volume control,
switch, etc). [HTTP GET? by application to user provided reference]

A minor quibble that I'll raise at this time: If it's decided that the best
approach is to have a separate DML markup just for phone keys [a simplified
subset of full key-based input] (which doesn't sound too unreasonable to
me), then in DML I see no justification for implementing the complicated
digit map logic that MGCP or Megaco allows. This was designed to allow
complicated number matching schemes to avoid post-dial delay which is not a
problem for most applications (and here, digit accumulation does not justify
the complexity either IMO). DML should just allow immediate or stop-and-wait
notification of supported stimuli (*,#,0-9,L and any other telephony related
stimuli allowed) - this makes the UA devices a lot simpler (which is the
whole point of DML). Anyway, this is a minor issue that has no bearing on
the larger model.

Thanks for your responses to the previous mails. I will answer them in
another email.

Regards,

Robert.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Thursday, April 25, 2002 6:19 AM
> To: Fairlie-Cuninghame, Robert
> Cc: [email-masked]; 'Bert Culpepper'
> Subject: Re: [Sipping] I-D
> ACTION:draft-culpepper-sipping-app-interact-reqs-00.txt
> 
> 
> inline.
> 
> "Fairlie-Cuninghame, Robert" wrote:
> > 
> 
> > > > R5:  A network entity desiring user indications must be able to
> > > >         request user indications from another network 
> entity.  The
> > > >         entity receiving a request must be able to 
> respond with its
> > > >         capability/intent to transmit user indications.
> > >
> > > We should be more specific here. We have a caller and a
> > > callee. I think
> > > that by "entity" you mean one of those two.
> > 
> > No, we are purposefully not restricting the mechanism to 
> only caller and
> > callee (or even proxy). So, yes, I agree we need to re-word to
> > explicitly
> > define. Further discussion later.
> 
> That doesn't make sense to me. By definition, user input indication is
> possible only from a human, NOT from an automata. An automata can try
> (web screen scraping...) but that is a known bad thing.
> 
> > > > R15: The receiving application must be able to detect 
> user activity
> > > >         indication loss due to packet loss from received
> > > user activity
> > > >         indications.
> > >
> > > I don't know what this means.
> > 
> > Detecting missing indications.  For example, a PIN is 
> transmitted one
> > digit
> > at a time.  If one message (network packet) gets lost, we want to be
> > able to
> > determine this at the receiver. Will re-word.
> 
> There is an implicit assumption here of UDP based notifications and/or
> notifications that are not stop-and-wait. I think the real requirement
> you want here is ordering - events are delivered to the 
> observer in the
> same order they occurred at the reporter.
> 
> 
> > 
> > >
> > > > D4:  The mechanism should support routing and
> > > identification that is
> > > >         compatible with use in a SIP-based network.
> > >
> > > This is too vague to be useful.
> > >
> > 
> > Are you suggesting we reword or simply drop ? Can you 
> suggest anything
> > more
> > useful/specific?
> 
> I am suggesting to drop unless you can define more 
> specifically what the
> requirement is.
> 
> 
> > > * The mechanism should support devices that possess a UI, 
> and those
> > > which do not possess a UI
> > 
> > Jonathan can you please explain exactly what you mean by this. My
> > feeling is
> > that this is the crux of your new requirements, yet I don't 
> have a clear
> > idea of what you mean by "The mechanism should support 
> devices ... which
> > do
> > not possess a UI."
> 
> Hopefully the recent draft on markup I just submitted explains better.
> The basic idea is that there are many devices that have the ability to
> interact with the user. There could, for example, be a display with
> buttons. The display would present the user with choices, and the user
> would press a button, causing a notification to be sent into the
> network. This is in contrast with devices, like a traditional 
> dumb black
> phone, which have no ability to interact with the user. There is no
> display. There is no way to know, when a user presses a DTMF key, what
> application they were trying to interact with. 
> 
> 
> > 
> > By this requirement, do you mean
> > 1) The mechanism should allow an application to present a 
> virtual user
> > interface and/or the transport of user indications on the virtual
> > interface
> > (when a device has no physical interface aside from a display and
> > possibly a
> > touch-screen or pointing device); or
> > 2) the mechanism should allow an application to determine 
> that a device
> > has
> > no physical interface aside from a display (and possibly a 
> touch-screen
> > or
> > pointing device) and how that resource is accessed?
> > 
> > These are two very different requirements. Or do you have something
> > entirely
> > different in mind?
> 
> The mechanism should support devices like black phones, which have no
> display capabilities that can be used to interact with the user, and
> devices like PC phones which have web browsers that can be used to
> interact with the user. 
> 
> 
> > >
> > > * The mechanism should be capable of handling UIs from 
> simple screens
> > > with buttons, to voice input
> > 
> > I'm not sure what the functional requirement you are asking for here
> > (apart
> > from the fact that the mechanism should be extensible that 
> is mentioned
> > in
> > the next point): "The mechanism should be capable of 
> handling UI's ...
> > with
> > voice input?" Are you meaning local recognition software 
> that allows a
> > user
> > to "say a command" or something similar? 
> 
> Yes. 
> 
> > [I presume you aren't talking
> > about
> > voice recog on the application server here.] Surely, this is just
> > another
> > permutation of mapping some local interface to application specific
> > stimuli?
> 
> Yes. I just want to make sure we cover a range of media, not just
> physical buttons. Hyperlinks, voice, even visual recognition should be
> possible.
> 
> > 
> > >
> > > * The mechanism should be capable of handling future user 
> interfaces
> > > that may be defined down the road
> > 
> > R10 was supposed to cover that ...
> > 
> > R10:    The mechanism must be extensible so that some non 
> key-based user
> > indications can be supported in the future, for instance, 
> sliders, dials
> > or
> > wheels.
> > 
> > Perhaps it could be broadened. Any suggestions?
> 
> Voice, hyperlinks, biometrics, brain waves, etc.
> 
> > >
> > > * The mechanism should support user interfaces which require a new
> > > content to be presented to the user upon input from the 
> user (i.e.,
> > > change the screen when a user presses a button)
> > >
> > 
> > Hmm, this goes beyond "getting indications a device supports" and is
> > more to
> > do with "application action in response to input". I'm not 
> sure it is in
> > scope.
> 
> I think it has to be - thats the whole problem! I think we've been
> thinking far too narrowly on this problem. Its not just about
> notifications of user input. We are talking about supporting stimulus
> signaling for applications, where stimulus signaling is defined in the
> broadest sense. 
> 
> > 
> > > * The mechanism should support user interfaces where user 
> input can be
> > > sent to the application without waiting for a response from
> > > the previous
> > > input
> > 
> > Agreed.  A requirement that the mechanism is not limited to stop and
> > wait.
> > This was what we were aiming at in D3:
> > 
> > D3:     The mechanism should attempt to reduce recovery delays under
> > packet
> > loss scenarios.
> 
> I don't read D3 as saying the same thing as above.
> 
> 
> > > * The mechanism should allow the user to interface with 
> multiple user
> > > interfaces for different applications within the same call
> > > (for example,
> > > a single call may involve a call recording application 
> and a prepaid
> > > calling application, both of which might support a UI)
> > 
> > Good one, although I'm not sure how this is a requirement on the
> > mechanism
> > rather than simply how the user locally selects their user interface
> > (which
> > would be a requirement on how to design a user device, i.e., not in
> > scope).
> > Each relationship between an application and a user 
> interface would be a
> > separate subscription.
> 
> No. We have a fundamental disconnect here. There are two radically
> different approaches for interacting with applications. In approach 1,
> there are a set of applications listening for user input. The 
> user input
> is not directed; that is, the user has no ability to say 
> "this input is
> for app 1" or "this input is for app 2". Directing user input 
> generally
> requires a user interface of sorts, and in approach 1, there is no UI.
> In approach 2, input can be directed. The device has a user interface
> that allows the user to send feedback to specific applications. 
> 
> Let me give concrete examples. A black phone is an example of approach
> 1. Multiple apps can listen for DTMF, but the user can't 
> direct DTMF to
> a specific application. This, BTW, is the source of countless feature
> interaction problems, and is an artifact of the legacy 
> interface of the
> phone. An example of approach 2 is a PC. Lets say I make a 
> call from my
> PC, and there are two applications involved in processing 
> that call. One
> is a prepaid calling app. One of the things this app allows me, the
> user, to do, is to hang up the call and make another without 
> re-entering
> my PIN. The other application is a voice recorder app, which allows me
> to record the audio of the call. This app needs my input to start and
> stop the recording. Once I make the call, two windows pop up. One is a
> control panel for the voice recorder (with start and stop buttons) and
> another is a control panel for the prepaid app. When I click "start
> recording" on the control panel for the voice recorder, this 
> starts the
> recording process. That happens through user input 
> indications, but they
> are directed towards the voice recorder app. They can be 
> directed since
> they occur within a context - a user interface - which allows 
> them to go
> to the right place. Approach 2 has MUCH better feature interaction
> properties, and a much more compelling user experience.
> 
> Approach 1 is a subset of approach 2. We should be seeking to solve
> approach 2, and a result, knock off approach 1. The worst thing we can
> do is continue to develop specifications that proliferate the broken
> mode of user interface which the PSTN has provided us! We 
> should support
> it, but it is not the design goal. 
> 
> 
> > 
> > >
> > > * The mechanism should allow the user to know which application is
> > > associated with which user interface/input
> > 
> > OK.  (satisfied through authentication/authorization of the 
> SUBSCRIBE?)
> 
> You presume SUBSCRIBE - thats a mechanism. The requirement is as it is
> written. In the example above, my PC should be able to tell 
> me that one
> of the popups is for a voice recorder, and the other is for a prepaid
> calling app.
> 
> > 
> > >
> > > * The mechanism must allow a user to have assurances that the
> > > user input
> > > it is providing is only to applications/servers on the call
> > > path between
> > > caller and callee.
> > 
> > I think this is covered by R16 & R17:
> > 
> > R16:    The mechanism must allow for end-to-end 
> security/privacy between
> > source and destination.
> > 
> > R17:    Both entities must be able to authenticate each other.
> 
> No - these are not the same at all. I don't know what end-to-end
> security is. Security encapsulates a lot of functions. I am 
> saying that
> the mechanism should support a specific authorization model - that the
> system can provide guarantees that only servers on the call 
> path can ask
> for my user input. 
> 
> 
> > >
> > > * The mechanism must work with applications that are both 
> proxy and
> > > b2bua.
> > 
> > As mentioned in the discussion of R5, the use of the term "network
> > entity"
> > is purposefully designed to NOT limit the interaction to 
> just proxies or
> > b2bua's. SIP Event's has no such constraints and I don't 
> see that this
> > mechanism should either. Will re-word to make clearer our 
> intent. Do you
> > have a problem with this generalization?
> 
> There are two participants here. There is the user, and the 
> application.
> The application can be a proxy, B2bua, or just UA. The user 
> has to be a
> user, though, not a proxy (see above).
> 
> -Jonathan R.
> 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> Chief Scientist                         First Floor
> dynamicsoft                             East Hanover, NJ 07936
> [email-masked]                 FAX: (973) 952-5050
> http://www.jdrosen.net                  PH:  (973) 952-5000
> http://www.dynamicsoft.com
> 

_______________________________________________
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