Subject: RE: [Sipping] I-D ACTION:draft-culpepper-sipping-app-interact-re qs-00.txt

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Thu, 11 Apr 2002 03:30:25 -0700

Thanks for the comments, very helpful.  Bert Culpepper and myself have
discussed them. Here are our combined responses. Bert please speak up if
I've misrepresented your position or missed anything.

> From: Jonathan Rosenberg
> 
> This is an excellent start at requirements. Some comments on the
> requirements there, and some suggestions for additional requirements:
> 
> R1 reads:
> 
> > The mechanism must support collecting device/user input which 
> >         is associated with an established SIP session but must also 
> >         support collecting device/user input that is outside of any 
> >         established sessions. 
> 
> I am concerned about the security and scope issues about listening for
> device/user input outside of a session. This seems like a
> standards-based approach for implementing the government key input
> snooper.... I know what you had in mind for this (things like service
> activation for call forwarding), but I think that there are 
> better ways
> to do it (web page, anyone?).

I would agree there are better mechanisms for user service interaction
outside of a session.  A web interface is certainly viable and "richer" for
control of CLASS 5-like or PBX-like services. I myself am happy with
dropping this part of the requirement.  On the other hand, many SIP devices
may have no more of a UI than today's common cell phones so is a web-based
mechanism appropriate for these devices?  

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

> 
> >  R6:  The mechanism must support filtering so that only user 
> >         indications of interest are transmitted. 
> 
> I don't know what this means.

Well, an application that wants only digits should be able to apply a
generate a request so that only it gets digits.  This may help the problem
of "application interaction" and bandwidth.  Agree that filtering is not a
good word - will re-write.

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

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

> 
> Some additional requirements:
> 
> * 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."

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?

Perhaps it would be best to respond to this point in a separate thread. 

> 
> * 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? [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?

> 
> * 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?

> 
> * The mechanism should allow a device to indicate support for multiple
> user interfaces, and allow the application to select which 
> one is to be
> used

Good point.

> 
> * The mechanism should allow a device to indicate relative preferences
> amongst the various user interfaces

OK.

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

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

Agree that more specific rewording and strength upgrading is needed.

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

> 
> * 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?)

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

but we will try to re-word it to include this explicitly.

> 
> * 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?

> 
> * The mechanism must not require excessive bandwidth on the 
> access link
> to the device, in order to support mobiles
> 

R3 was meant to cover this ...

R3:	The transport mechanism must be sensitive to the limited bandwidth
constraints of some signaling planes, for instance, reliability through
blind retransmission is not acceptable.

From SIP, we learned that for mobile deployment (ie low bandwidth) it is
better to concentrate on ROHC compression [or other binary encoding schemes
(e.g. XML->ASN.1)] rather than constraining the size/syntax of the actual
message format to the achieve the desired bandwidth constraints. The number
of messages required is much more of a consideration as a design criteria in
this area!

[Aside: we are actually in the process of rewriting our
draft-culpepper-sip-key-events-xx draft to use XML. We originally wrote the
key-events draft to use a much more compact SDP-like syntax but after much
thought, we believe that in the long run an easier to implement XML scheme
is better even at the cost of larger (uncompressed) messages. When bandwidth
is really an issue compression or binary encoding will be used in any case
(and the message body is only one part of the message in any case). ]

We look forward to continuing this discussion.

Regards,

Robert & Bert.

_______________________________________________
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: "Bert Culpepper" <[email-masked]>
Date: Thu, 11 Apr 2002 16:54:23 -0400

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 25 Apr 2002 01:18:47 -0400

inline.

"Fairlie-Cuninghame, Robert" wrote:

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

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

> Are you suggesting we reword or simply drop ? Can you suggest anything

I am suggesting to drop unless you can define more specifically what the
requirement is.

> idea of what you mean by "The mechanism should support devices ... which

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. 

> These are two very different requirements. Or do you have something

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. 

> to "say a command" or something similar? 

Yes. 

> [I presume you aren't talking
> about

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.

> Perhaps it could be broadened. Any suggestions?

Voice, hyperlinks, biometrics, brain waves, etc.

> do with "application action in response to input". I'm not sure it is in

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. 

> D3:     The mechanism should attempt to reduce recovery delays under

I don't read D3 as saying the same thing as above.

> Each relationship between an application and a user interface would be a

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. 

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

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

> 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