A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)
Note: This ballot was opened for revision 08 and is now closed.
(Allison Mankin) Yes
(Brian Carpenter) No Objection
Comment (2005-03-30 for -)
I didn't throw another DISCUSS on this, but the Gen-Art review comments are very close to DISCUSS: "This draft is on the right track but has open issues, described in the review." (me too) There have been several discusses thrown on this draft already. I can't speak to Scott Hollenbeck's issue (I would never have caught it!) but I read the document and agree with both Russ and Sam's comments. NOTES: The section of draft-ietf-sipping-app-interaction-framework-04.txt below supplies a rational for KPML that should be addressed in the abstract: "4.3 Flip-Flop A middle-ground approach is to flip back and forth between a client-local and client-remote user interface. Many voice applications are of the type which listen to the media stream and wait for some specific trigger that kicks off a more complex user interaction. The long pound in a pre-paid calling card application is one example. Another example is a conference recording application, where the user can press a key at some point in the call to begin recording. When the key is pressed, the user hears a whisper to inform them that recording has started. The ideal way to support such an application is to install a client-local user interface component that waits for the trigger to kick off the real interaction. Once the trigger is received, the application connects the user to a client-remote user interface that can play announcements, collect more information, and so on. The benefit of flip-flopping between a client-local and client-remote user interface is cost. The client-local user interface will eliminate the need to send media streams into the network just to wait for the user to press the pound key on the keypad. The Keypad Markup Language (KPML) was designed to support exactly this kind of need . It models the keypad on a phone, and allows an application to be informed when any sequence of keys have been pressed. However, KPML has no presentation component. Since user interfaces generally require a response to user input, the presentation will need to be done using a client-remote user interface that gets instantiated as a result of the trigger. It is tempting to use a hybrid model, where a prompt-and-collect application is implemented by using a client-remote user interface that plays the prompts, and a client-local user interface, described by KPML, that collects digits. However, this only complicates the application. Firstly, the keypad input will be sent to both the media stream and the KPML user interface. This requires the application to sort out which user inputs are duplicates, a process that is very complicated. Secondly, the primary benefit of KPML is to avoid having a media stream towards a user interface. However, there is already a media stream for the prompting, so there is no real savings." Section 3 of draft-ietf-sipping-kpml-07.txt is clearly written and the concept of local/remote flip flopping is addressed (3.7), but the case for KPML is not made as clearly as in the framework document. Section 4 of the document is new as of version 07 and actually defines the kpml event package. The user driven SUBSCRIBE piece of this was fairly clear to me but the NOTIFY options were less clear. I wasn't always sure when control flopped between local and remote (assuming that user input=local) particularly in sections 4.7 and 4.8 Section 8 (security) see Sam Hartman (below) on authentication and authorization. I think my confusions with section 4.7 and 4.8 and the question of local vs. remote may also be related to the issue of authorization. "Section 8 discusses the need for authentication but does not discuss authorization. My initial impression on reading the draft is that anyone who can authenticate to the UA can subscribe to this event package. That's clearly wrong; I don't just want anyone (even though I know who they are) subscribing to my calling card number. The draft needs to discuss authorization and to give a default authorization policy that is both implementable and reasonably secure." Tiny Nits: bottom of page 26: NOTE: KPML does not include a timestamp. There are a number of reasons for this. First, what timestamp would in include? ^^ "would it" idnits 1.61 tmp/draft-ietf-sipping-kpml-07.txt: tmp/draft-ietf-sipping-kpml-07.txt(1146): Line contains control character TAB in position 4. tmp/draft-ietf-sipping-kpml-07.txt(1354): Line has weird spacing: '...BE (see below...' tmp/draft-ietf-sipping-kpml-07.txt(1548): Line contains control character TAB in position 4. Checking nits according to http://www.ietf.org/ID-Checklist.html : Checking conformance with RFC 3978/3979 boilerplate... the boilerplate looks good. No nits found. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt : Nothing found here (but these checks does not cover all of 1id-guidelines.txt yet). Miscellaneous warnings: None. No nits found Lucy E. Lynch Academic User Services Computing Center University of Oregon llynch @darkwing.uoregon.edu (541) 346-1774
(Margaret Cullen) No Objection
(Bill Fenner) (was Discuss) No Objection
(Sam Hartman) (was Discuss) No Objection
(Scott Hollenbeck) (was Discuss) No Objection
(Russ Housley) (was Discuss) No Objection
Please spell out "DTMF" the first time it is used.