Subject: Re: [Sipping] I-D ACTION:draft-culpepper-sipping-app-interact-reqs-00.txt

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 10 Apr 2002 00:42:08 -0400

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

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

>  R6:  The mechanism must support filtering so that only user 
>         indications of interest are transmitted. 

I don't know what this means.

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

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

Some additional requirements:

* The mechanism should support devices that possess a UI, and those
which do not possess a UI

* The mechanism should be capable of handling UIs from simple screens
with buttons, to voice input

* The mechanism should be capable of handling future user interfaces
that may be defined down the road

* 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

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

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

* The mechanism should support user interfaces where user input can be
sent to the application without waiting for a response from the previous
input

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

* The mechanism should allow the user to know which application is
associated with which user interface/input

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

* The mechanism must work with applications that are both proxy and
b2bua.

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

Thats it for now.

THanks,
Jonathan R.

[email-masked] wrote:
> 
> 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-00.txt
>         Pages           : 6
>         Date            : 27-Mar-02
> 
> This document defines the requirements for a mechanism based on SIP
> that allows network entities to request and report user indications
> that can be used to interact with applications associated with SIP-
> based services.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-culpepper-sipping-app-interact
> -reqs-00.txt
> 
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the
> message.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the
> username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
>         "get draft-culpepper-sipping-app-interact-reqs-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
>         [email-masked].
> In the body type:
>         "FILE
> /internet-drafts/draft-culpepper-sipping-app-interact-reqs-00.txt".
> 
> NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail
> readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
> 
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
>   ------------------------------------------------------------------------
> 
> Subject:
> Date: Thu, 28 Mar 2002 16:41:59 -0500
> 
>   ------------------------------------------------------------------------
> 
>    ATT36315.txtName: ATT36315.txt
>                Type: Plain Text (text/plain)
> 
>                 Access-Type: anon-ftp
>  Document Info:        Site: internet-drafts
>                        Mode: ftp.ietf.org

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

---

From: "Bert Culpepper" <[email-masked]>
Date: Sat, 13 Apr 2002 18:00:29 -0400

(It seems my post didn't make it to the list intact.  And another comment to
add to one of the "two added points".)

-----Original Message-----
From: Bert Culpepper [mailto:[email-masked]]
Sent: Thursday, April 11, 2002 4:54 PM

Two added points below...

> From: Fairlie-Cuninghame, Robert
>
> 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
> >
> 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?
>

The "outside of a session" part was added to support being able to receive
indications before a SIP session was fully established, (aka "early
sessions").  So do we want to limit the mechanism to established sessions?

[additional comments] First, "early dialog" was meant above, and the
requirement should be re-worded I think so this is clear.  Second, related
to service activation Jonathan mentions above, I can see using SIP for these
things where no SIP session is in progress or established may be (in fact is
most likely) a misuse of the protocol.  For the kinds of service activation
mentioned above, a user could "call" the service and interact with it using
the resulting mechanism we're going for here if the user device was protocol
limited.  I can see other means for doing this (service activation/control)
too so the second part of the requirement is not needed IMHO.

[snip]

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

The comment above got garbled...the requestor should be able to apply a
"mask" so that it is possible to request a subset of supported UI
indications.  This "mask" (or whatever) should of course be able to do other
things as indicated above.

[snip]

Best regards,
Bert