Document: draft-ietf-sipping-kpml-07.txt
Review: Lucy E. Lynch
Date: 29 mars 2005 

draft-ietf-sipping-kpml-07.txt
"A Session Initiation Protocol (SIP) Event Package
for Key Press Stimulus (KPML)"
Intended Status: Proposed Standard

"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 [7]. 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