A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)
draft-ietf-sipping-kpml-08

[Ballot discuss]
Minor detail in the ABNF:

1. ABNF strings default to case-insensitive, so there's no need to include both "A" and "a".

2. The DRegexCharacter ABNF has two sequential slashes across the line break, a syntax error:

DRegexCharacter  = DIGIT / "A" / "B" / "C" / "D" / "*" / "#" /
                                        / "a" / "b" / "c" / "d"

I think the solution is to just make this

DRegexCharacter  = DIGIT / "A" / "B" / "C" / "D" / "*" / "#"

That solves the problem of the slashes and integrates ABNF's natural case-insensitivity.

[Ballot comment]
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 [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

Lucy E. Lynch Academic User Services
Computing Center University of Oregon
llynch  @darkwing.uoregon.edu (541) 346-1774

[Ballot discuss]
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.

[Ballot discuss]
Section 8 says:
  >
  > As an XML markup, all of the security considerations of RFC3023 [3]
  > and RFC3406 [6] must be met.
  >
  s/must/MUST/

[Ballot discuss]
There's an extra "/" in the ABNF spec found in section 5.1:

DRegexCharacter  = DIGIT / "A" / "B" / "C" / "D" / "*" / "#" /
          / "a" / "b" / "c" / "d"
(Remove the leading "/" from the second line.)

Per section 4 of RFC 3688, please change the registrant info in the namespace and schema registration requests (section 7) to either the IESG or add "as designated by the IESG".

[Note]: 'Trying to bring to IESG by end of June - T1S1 liaison stating Time- Sensitive requirement Gave comments some time ago - discussion of these at interim in Bedford on May 25' added by Allison Mankin

[Note]: 'Trying to bring to IESG by end of June - T1S1 liaison stating Time-
Sensitive requirement
Gave comments some time ago - discussion of these at
interim in Bedford on May 25' added by Allison Mankin