Subject: [MEDIACTRL] Comments/nits on draft-ietf-mediactrl-ivr-control-package-02

From: Dan York <[email-masked]>
Date: Sun, 16 Nov 2008 19:58:07 -0500

Scott & others involved with the IVR control package,

Here are some comments and typos/nits related to the IVR control  
package.  Overall, the package has come a long way and I definitely  
like most of what is in here.

First comments, then nits.

Comments:

1. TOO MANY RECOMMENDATIONS/SHOULDS/MAYs - It is unclear to me how an  
implementer should view text that is RECOMMENDED.  Is this a MUST? or  
a SHOULD? If I implement this language, how will I know if someone  
else will implement it the same way?

I understand the desire to give guidance to implementers, but it's not  
clear to me that this text should be included in the main part of the  
document.

For instance, in section 4.2.2, on page 22 of the text file, right  
before section 4.2.2.1, the doc states "It is RECOMMENDED the MS  
support the following cases:".  How can we do interop testing on this  
basis?  Is this mandatory? or optional?  It seems optional to me,  
which means that interop testing will be correspondingly more difficult.

Similarly, in section 4.3.1.1.3 for <par> (text page 40):

    It is RECOMMENDED that the MS implementation at least supports
    playback different media (e.g. audio and video) in parallel where
    mixing of media on the same stream is not required.  The MS MAY
    support transcoding between the media resource format and the output
    stream format.

Again, how do we test that a devices is "compliant" with this RFC?  If  
a developer is writing code for a MS that implements it one way... and  
then moves it to another MS that implements it the opposite way... how  
happy will the developer be?

Likewise, in section 4.3.1.1.3.1 for <seq>, on text page 41:

    It is RECOMMENDED that the MS implementation at least supports
    playback of the same media (e.g. audio only) within a <seq> element.

First, the text isn't very clear to me but then second, this would  
seem like a MUST to me.

In section 4.3.1.4 for <record> on text page 50:

    If the MS does not support the configuration required for recording
    from the input media streams to one or more <media> elements, the MS
    MUST send a <response> with a 423 status code (Section 4.5).  It is
    RECOMMENDED that the MS implementation at least supports recording
    different media (e.g. audio and video) in parallel to different
    locations.  The MS MAY support transcoding between the input stream
    format and the recording location format.

I'm again wondering how an implementer determines what to do. To be  
compliant with this RFC, there are several choices here.  I would  
convert the RECOMMENDED into some MUSTs - or remove it and create a  
separate RFC that supports recording different media in parallel to  
different locations.

In section 4.3.1.5 for <media> on text page 52 and 53:

The "loc" attribute has a SHOULD and MAY, and the "type" attributed  
has multiple MAYs... all of which again make it hard to say what it  
means to be "compliant" with this specification.

Another example would be section 4.3.2.4, <recordinfo> on text page 55:

    When the record operation is successful, the MS SHOULD specify the
    same number of <mediainfo> child elements as recorded media
    destinations in <record> (Section 4.3.1.4).

Again... how is an implementation compliant?  Is there any reason why  
we don't just say the MS *MUST* specify the same number of <mediainfo>  
child elements?  This would seem to be to be the logical thing to do.

-----------------------------------------------------------------------------

2. VAD USAGE IS CONFUSED AS TO BEING OPTIONAL OR NOT

Somewhat in line with the previous comment, in section 4.3.1.4 for  
<record> on page 49 the default value for "vadinitial" and "vadfinal"  
is "true", but the text indicates that this means a MS *MAY* use VAD:

   vadinitial:  Control whether voice activity detection can be used to
       initiate the recording operation.  A valid value is a boolean  
(see
       Section 4.6.1).  A value of true indicates the MS MAY initiate
       recording using voice activity detection.  A value of false
       indicates that the MS MUST NOT initiate recording using voice
       activity detection.  The attribute is optional.  The default  
value
       is true.

    vadfinal:  Control whether voice activity detection can be used to
       terminate the recording operation.  A valid value is a boolean
       (see Section 4.6.1).  A value of true indicates the MS MAY
       terminate recording using voice activity detection.  A value of
       false indicates that the MS MUST NOT terminate recording using
       voice activity detection.  The attribute is optional.  The  
default
       value is true.

However, later in the section on page 51, the 9-step execution model  
runs counter to these MAYs in steps 2 and 9:

    2.  If DTMF input (not matching a <control> operation) is received
        during prompt playback and the prompt bargein attribute is set  
to
        true, then the MS activates the record execution.  Otherwise,  
the
        MS activates it after the completion of prompt playback.

    9.  If vadfinal attribute has the value true, then the MS terminates
        the recording operation when a period of silence, with the
        duration specified by the value of the finalsilence attribute,  
is
        detected.  This period of silence is not part of the final
        recording.  The status is reported to the dialog container  
with a
        <recordinfo> (see Section 4.3.2.4) where the termmode attribute
        is set to finalsilence.

Neither step can in fact be completed as written because THERE IS NO  
GUARANTEE that VAD is available. Setting vadinitial and/or vadfinal to  
"true" (or just not including it to use the default state) is of no  
real value because there is no assurance that VAD is available.

Either the vadinitial/vadfinal MAYs should be changed to MUSTs or the  
text of steps 2 and 9 needs to be changed to reflect the reality that  
VAD may not occur.

-----------------------------------------------------------------------------

3. AUDIT MENTIONS AN AS TAKING OVER MANAGEMENT, BUT NOT HOW

In section 4.4, "Audit Elements" on text page 56, it states:

    Second, auditing enables
    discovery of the existence and status of dialogs currently managed  
by
    the package on the MS.  This allows one AS to take over management  
of
    the dialogs when the AS which initiated the dialogs fails or is no
    longer available.

This statement is made, but then nowhere in the rest of the text did I  
see any information about HOW one AS could take over management of the  
dialogs when the initiating AS fails or is no longer available.  Did I  
miss mention of this?  Is this something defined in more detail in the  
Control Framework document?

This does seem like a valuable function (although I'll also mention  
this in a security review), but I think there needs to be some text  
about how this actually occurs - even if it is referencing discussion  
around this in another document.

============================================

Nits/typos:

- Introduction, 2nd paragraph ("The package defines dialog...").   
About midway through there is a sentence that says "This package  
defines a own lightweight IVR dialog language..."  I am guessing you  
meant either "defines A lightweight" or "defines ITS own lightweight".

- Section 4.1 <mscivr> There is a </dialogstart> missing from the  
first example following "For example, a request to the MS to start an  
IVR dialog playing a prompt:"

   <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
     <dialogstart>
      <dialog>
       <prompt>
        <media loc="http://www.example.com/welcome.wav"/>
       </prompt>
      </dialog>
    </mscivr>

Regards,
Dan

-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Build voice applications based on open standards.
Find out how at http://www.voxeo.com/free

_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: Dan York <[email-masked]>
Date: Sun, 16 Nov 2008 22:47:18 -0600

Hmmm... so I made a mistake in the 9-step execution model.  I meant to  
say that it runs counter to the VAD MAYs in steps *5* and 9, not 2 and  
9.  Step 5 is:

    5.  Initiation of the recording operation depends on the value of  
the
        vadinitial attribute.  If vadinitial has the value false, then
        the recording operation is initiated immediately.  Otherwise,  
the
        recording operation is initiated when voice activity is  
detected.

This last sentence is NOT guaranteed to be true because based on the  
fact that the MS MAY initiate recording using VAD, there is no  
guarantee that VAD is available.

So it was step 5 and not step 2.  (That's what I get for writing this  
review on the airplane ride up and having to end my note quickly as  
they were telling us to shut down and prepare for landing.)

Regards,
Dan

On Nov 16, 2008, at 6:58 PM, Dan York wrote:
> <record> on page 49 the default value for "vadinitial" and  
> "vadfinal" is "true", but the text indicates that this means a MS  
> *MAY* use VAD:
>
> GUARANTEE that VAD is available. Setting vadinitial and/or vadfinal  
> to "true" (or just not including it to use the default state) is of  
> no real value because there is no assurance that VAD is available.
>
> Either the vadinitial/vadfinal MAYs should be changed to MUSTs or  
> the text of steps 2 and 9 needs to be changed to reflect the reality  
> that VAD may not occur.
>
> This statement is made, but then nowhere in the rest of the text did  
> I see any information about HOW one AS could take over management of  
> the dialogs when the initiating AS fails or is no longer available.   
> Did I miss mention of this?  Is this something defined in more  
> detail in the Control Framework document?
>
> about how this actually occurs - even if it is referencing  
> discussion around this in another document.
>
> first example following "For example, a request to the MS to start  
> an IVR dialog playing a prompt:"
>

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Mon, 17 Nov 2008 13:30:50 +0100

In regard to the comment on RECOMMENDED below, it RFC 2119 terms it
means exactly the same as SHOULD, i.e. I can construct a sentence
including SHOULD with the same meaning.

Generally there are two things with the use of SHOULD (I have not looked
in detail in this document to decide if these apply), and therefore it
gets used too often.

1)	Too often it means "The xxxx SHOULD do this because because I
could not be bothered to work out all the conditionals to allow it to be
a SHALL." In these cases we need to work through this and write SHALL.

2)	If we do find it is needed, guidance is required on the areas
where an exception is expected, otherwise one ought ot be able to write
a MAY, because there are in effect no interoperability conditions from
allowing it to be a MAY.

And in general I would be very dubious of any requirement that ended up
saying "SHOULD support".

regards

Keith 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dan York
> Sent: Monday, November 17, 2008 12:58 AM
> To: [email-masked]
> Subject: [MEDIACTRL] Comments/nits 
> ondraft-ietf-mediactrl-ivr-control-package-02
> 
> Here are some comments and typos/nits related to the IVR 
> control package.  Overall, the package has come a long way 
> and I definitely like most of what is in here.
> 
> 1. TOO MANY RECOMMENDATIONS/SHOULDS/MAYs - It is unclear to 
> me how an implementer should view text that is RECOMMENDED.  
> Is this a MUST? or a SHOULD? If I implement this language, 
> how will I know if someone else will implement it the same way?
> 
> I understand the desire to give guidance to implementers, but 
> it's not clear to me that this text should be included in the 
> main part of the document.
> 
> For instance, in section 4.2.2, on page 22 of the text file, 
> right before section 4.2.2.1, the doc states "It is 
> RECOMMENDED the MS support the following cases:".  How can we 
> do interop testing on this basis?  Is this mandatory? or 
> optional?  It seems optional to me, which means that interop 
> testing will be correspondingly more difficult.
> 
> Again, how do we test that a devices is "compliant" with this 
> RFC?  If a developer is writing code for a MS that implements 
> it one way... and then moves it to another MS that implements 
> it the opposite way... how happy will the developer be?
> 
> First, the text isn't very clear to me but then second, this 
> would seem like a MUST to me.
> 
> I'm again wondering how an implementer determines what to do. 
> To be compliant with this RFC, there are several choices 
> here.  I would convert the RECOMMENDED into some MUSTs - or 
> remove it and create a separate RFC that supports recording 
> different media in parallel to different locations.
> 
> The "loc" attribute has a SHOULD and MAY, and the "type" 
> attributed has multiple MAYs... all of which again make it 
> hard to say what it means to be "compliant" with this specification.
> 
> Again... how is an implementation compliant?  Is there any 
> reason why we don't just say the MS *MUST* specify the same 
> number of <mediainfo> child elements?  This would seem to be 
> to be the logical thing to do.
> 
> Somewhat in line with the previous comment, in section 
> 4.3.1.4 for <record> on page 49 the default value for 
> "vadinitial" and "vadfinal"  
>        initiate the recording operation.  A valid value is a 
> boolean (see
>        activity detection.  The attribute is optional.  The 
> default value
>        is true.
> 
>        voice activity detection.  The attribute is optional.  
> The default
>        value is true.
> 
> However, later in the section on page 51, the 9-step 
> execution model runs counter to these MAYs in steps 2 and 9:
> 
>         during prompt playback and the prompt bargein 
> attribute is set to
>         true, then the MS activates the record execution.  
> Otherwise, the
>         duration specified by the value of the finalsilence 
> attribute, is
>         recording.  The status is reported to the dialog 
> container with a
> Neither step can in fact be completed as written because 
> THERE IS NO GUARANTEE that VAD is available. Setting 
> vadinitial and/or vadfinal to "true" (or just not including 
> it to use the default state) is of no real value because 
> there is no assurance that VAD is available.
> 
> Either the vadinitial/vadfinal MAYs should be changed to 
> MUSTs or the text of steps 2 and 9 needs to be changed to 
> reflect the reality that VAD may not occur.
> 
>     discovery of the existence and status of dialogs 
> currently managed by
>     the package on the MS.  This allows one AS to take over 
> management of
> This statement is made, but then nowhere in the rest of the 
> text did I see any information about HOW one AS could take 
> over management of the dialogs when the initiating AS fails 
> or is no longer available.  Did I miss mention of this?  Is 
> this something defined in more detail in the Control 
> Framework document?
> 
> This does seem like a valuable function (although I'll also 
> mention this in a security review), but I think there needs 
> to be some text about how this actually occurs - even if it 
> is referencing discussion around this in another document.
> 
> About midway through there is a sentence that says "This 
> package defines a own lightweight IVR dialog language..."  I 
> am guessing you meant either "defines A lightweight" or 
> "defines ITS own lightweight".
> 
> - Section 4.1 <mscivr> There is a </dialogstart> missing from 
> the first example following "For example, a request to the MS 
> to start an IVR dialog playing a prompt:"
>

---

From: Eric Burger <[email-masked]>
Date: Mon, 17 Nov 2008 06:41:15 -0600

Agreed!

---

From: "McGlashan, Scott" <[email-masked]>
Date: Mon, 17 Nov 2008 13:45:13 +0000

Hi Dan,

Thanks for the comments. Here is a proposal to address them. Let me know if you (or anyone else on the list) disagrees.

1. TOO MANY RECOMMENDATIONS/SHOULDS/MAYs

RFC2119 defines RECOMMENDED as equivalent to SHOULD so that's how implementors should view it.

However, I take your point about minimizing RECOMMENDED/SHOULD for interoperability. We could tighten up the compliant language so that spec uses MUST/MAY only:

A. 4.2.2.1: MS MAY support playing multiple dialogs on same connection/conference (RECOMMENDED text re-written as examples). i.e. not mandatory behavior.

B. 4.3.1.1: <variable>: MS MUST support time, date and digits (clarification of time and date value attribute required). New mandatory behavior.

C. 4.3.1.1.3: <par>: MS MUST support parallel playback of different media where mixing is not required. New mandatory behavior.

D. 4.3.1.1.3.1: <seq>: MS MUST support playback of same media within a <seq>. New mandatory behavior.

E. 4.3.1.4: <record>: MS MUST support parallel record of different media. New mandatory behavior.

F. 4.3.1.5: <media>: MS MUST support authentication information in loc URI. New mandatory behavior.

G. 4.3.2.4: <mediainfo>: MS MUST report on each <media> (and clarify case where no <media> child is specified in <record>).

[2] VAD USAGE IS CONFUSED AS TO BEING OPTIONAL OR NOT.

Agreed that language needs to be clarified on how vadinitial and vadfinal are used. In particular: 'true' values in vadinitial and vadfinal indicate that an MS MUST start/stop recording if the VAD is triggered. It can never be triggered if (a) there is no VAD support (throws 'unsupported VAD' error code), or (b) the configured connection/conference does not provide an audio stream towards the MS (no-op). Or do we want to require that all MSs support VAD?

[3] AUDIT MENTIONS AN AS TAKING OVER MANAGEMENT, BUT NOT HOW.

I'll add references to this package's Security Section (which in turn references the Control Framework security section). Neither discuss how-to (previous mailing list discussion characterized it as implementation detail), but indicate it is a feature of the security policy. A review of the whole Security Section would be much appreciated.

Thanks

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan York
Sent: Monday, November 17, 2008 01:58
To: [email-masked]
Subject: [MEDIACTRL] Comments/nits on draft-ietf-mediactrl-ivr-control-package-02

Here are some comments and typos/nits related to the IVR control package.  Overall, the package has come a long way and I definitely like most of what is in here.

Comments:

1. TOO MANY RECOMMENDATIONS/SHOULDS/MAYs - It is unclear to me how an implementer should view text that is RECOMMENDED.  Is this a MUST? or a SHOULD? If I implement this language, how will I know if someone else will implement it the same way?

I understand the desire to give guidance to implementers, but it's not clear to me that this text should be included in the main part of the document.

For instance, in section 4.2.2, on page 22 of the text file, right before section 4.2.2.1, the doc states "It is RECOMMENDED the MS support the following cases:".  How can we do interop testing on this basis?  Is this mandatory? or optional?  It seems optional to me, which means that interop testing will be correspondingly more difficult.

Again, how do we test that a devices is "compliant" with this RFC?  If a developer is writing code for a MS that implements it one way... and then moves it to another MS that implements it the opposite way... how happy will the developer be?

First, the text isn't very clear to me but then second, this would seem like a MUST to me.

I'm again wondering how an implementer determines what to do. To be compliant with this RFC, there are several choices here.  I would convert the RECOMMENDED into some MUSTs - or remove it and create a separate RFC that supports recording different media in parallel to different locations.

The "loc" attribute has a SHOULD and MAY, and the "type" attributed has multiple MAYs... all of which again make it hard to say what it means to be "compliant" with this specification.

Again... how is an implementation compliant?  Is there any reason why we don't just say the MS *MUST* specify the same number of <mediainfo> child elements?  This would seem to be to be the logical thing to do.

Somewhat in line with the previous comment, in section 4.3.1.4 for <record> on page 49 the default value for "vadinitial" and "vadfinal"
is "true", but the text indicates that this means a MS *MAY* use VAD:

   vadinitial:  Control whether voice activity detection can be used to
       initiate the recording operation.  A valid value is a boolean (see
       Section 4.6.1).  A value of true indicates the MS MAY initiate
       recording using voice activity detection.  A value of false
       indicates that the MS MUST NOT initiate recording using voice
       activity detection.  The attribute is optional.  The default value
       is true.

       voice activity detection.  The attribute is optional.  The default
       value is true.

However, later in the section on page 51, the 9-step execution model runs counter to these MAYs in steps 2 and 9:

    2.  If DTMF input (not matching a <control> operation) is received
        during prompt playback and the prompt bargein attribute is set to
        true, then the MS activates the record execution.  Otherwise, the
        MS activates it after the completion of prompt playback.

    9.  If vadfinal attribute has the value true, then the MS terminates
        the recording operation when a period of silence, with the
        duration specified by the value of the finalsilence attribute, is
        detected.  This period of silence is not part of the final
        recording.  The status is reported to the dialog container with a
        <recordinfo> (see Section 4.3.2.4) where the termmode attribute
        is set to finalsilence.

Neither step can in fact be completed as written because THERE IS NO GUARANTEE that VAD is available. Setting vadinitial and/or vadfinal to "true" (or just not including it to use the default state) is of no real value because there is no assurance that VAD is available.

Either the vadinitial/vadfinal MAYs should be changed to MUSTs or the text of steps 2 and 9 needs to be changed to reflect the reality that VAD may not occur.

    Second, auditing enables
    discovery of the existence and status of dialogs currently managed by
    the package on the MS.  This allows one AS to take over management of
    the dialogs when the AS which initiated the dialogs fails or is no
    longer available.

This statement is made, but then nowhere in the rest of the text did I see any information about HOW one AS could take over management of the dialogs when the initiating AS fails or is no longer available.  Did I miss mention of this?  Is this something defined in more detail in the Control Framework document?

This does seem like a valuable function (although I'll also mention this in a security review), but I think there needs to be some text about how this actually occurs - even if it is referencing discussion around this in another document.

Nits/typos:

- Introduction, 2nd paragraph ("The package defines dialog...").
About midway through there is a sentence that says "This package defines a own lightweight IVR dialog language..."  I am guessing you meant either "defines A lightweight" or "defines ITS own lightweight".

- Section 4.1 <mscivr> There is a </dialogstart> missing from the first example following "For example, a request to the MS to start an IVR dialog playing a prompt:"

Regards,
Dan