Subject: [MEDIACTRL] Working Group Last Call on draft-ietf-mediactrl-ivr-control-package-02.txt

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 4 Nov 2008 12:58:51 -0600

This e-mail is kicking off a two-week WGLC on the following draft, which 
will end on November 19, just before our face-to-face meeting in 
Minneapolis.

It's a great time to read the draft carefully - discussion of WGLC comments 
is on the agenda for Minneapolis, and our goal is to finish IVR and MIXER 
and start serious work on MRB.

Thanks,

Spencer, as co-chair

>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
> This draft is a work item of the Media Server Control Working Group of the 
> IETF.
>
>
> Title           : An Interactive Voice Response (IVR) Control Package for 
> the Media Control Channel Framework
> Author(s)       : S. McGlashan, et al.
> Filename        : draft-ietf-mediactrl-ivr-control-package-02.txt
> Pages           : 130
> Date            : 2008-11-03
>
> This document defines a Media Control Channel Framework Package for
> Interactive Voice Response (IVR) dialog interaction on media
> connections and conferences.  The package defines dialog management
> request elements for preparing, starting and terminating dialog
> interactions, as well as associated responses and notifications.
> Dialog interactions are specified in a dialog language.  This package
> defines a lightweight IVR dialog language (supporting prompt
> playback, runtime controls, DTMF collect and media recording) and
> allows other dialog languages to be used.  The package also defines
> elements for auditing package capabilities and IVR dialogs.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-mediactrl-ivr-control-package-02.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>

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

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

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

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 10 Nov 2008 13:21:41 -0600

I'm sending along some comments, mostly editorial, on the IVR draft. In
general, I'm pleased with the readability of the draft.

Maybe not nits:

In 4.2.5.1, I was expecting to see a reserved range for additional defined
status codes, between the currently defined status codes and the MS-defined
status code range. If this isn't necessary, fine, I thought I'd ask now,
rather than later.

In 4.2.1.3, the default value for termtimeout is 0 - could this say "the
default value is 0s (no delay)"? Some variables define 0 as having special
significance, so I'd suggest being clear here.

In 4.3.1.4, "The MS MUST have uploaded the recorded data to this resource as
soon as possible after recording is complete" - this probably isn't a 2119
MUST (I'm also thinking "MUST have" reads oddly). What's the text trying to
say?

Nits:

s/defines a own/defines a/

In 6.1.4, /is sent by to the AS/ is broken. I think this is "is sent by the
MS to the AS", which seems wordy, but the sentence needs help.

The Contributions and Acknowledgement sections list affiliations in many,
but not all, cases. I'll spare the "IETF is made up of individuals" pep
talk, but was the inconsistency intentional? Given how many affiliations
change during the life of an RFC, I'm not sure listing them is helpful when
we move to RFC.

---

From: "McGlashan, Scott" <[email-masked]>
Date: Tue, 11 Nov 2008 10:37:11 +0000

Thanks for review Spencer. I'll apply this week.

One comment:

In 4.3.1.4, "The MS MUST have uploaded the recorded data to this resource as soon as possible after recording is complete" - this probably isn't a 2119 MUST (I'm also thinking "MUST have" reads oddly). What's the text trying to say?

We're trying to say that the MS shouldn't take too long to upload the recording. I'll rephrase without the RFC2119 language so it is just a description.

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Spencer Dawkins
Sent: Monday, November 10, 2008 20:22
To: [email-masked]
Subject: Re: [MEDIACTRL] Working Group Last Call ondraft-ietf-mediactrl-ivr-control-package-02.txt

I'm sending along some comments, mostly editorial, on the IVR draft. In general, I'm pleased with the readability of the draft.

Maybe not nits:

In 4.2.5.1, I was expecting to see a reserved range for additional defined status codes, between the currently defined status codes and the MS-defined status code range. If this isn't necessary, fine, I thought I'd ask now, rather than later.

In 4.2.1.3, the default value for termtimeout is 0 - could this say "the default value is 0s (no delay)"? Some variables define 0 as having special significance, so I'd suggest being clear here.

In 4.3.1.4, "The MS MUST have uploaded the recorded data to this resource as soon as possible after recording is complete" - this probably isn't a 2119 MUST (I'm also thinking "MUST have" reads oddly). What's the text trying to say?

Nits:

In 6.1.4, /is sent by to the AS/ is broken. I think this is "is sent by the MS to the AS", which seems wordy, but the sentence needs help.

The Contributions and Acknowledgement sections list affiliations in many, but not all, cases. I'll spare the "IETF is made up of individuals" pep talk, but was the inconsistency intentional? Given how many affiliations change during the life of an RFC, I'm not sure listing them is helpful when we move to RFC.

---

From: Lorenzo Miniero <[email-masked]>
Date: Tue, 11 Nov 2008 12:10:11 +0100

Since we're on it, I've got a couple of doubts as well, which came  
while upgrading the prototype to the -02 versions of IVR and Mixer  
drafts.

IVR:
there's no error code associated with a subscription error: in the  
Mixer package there's a 422 error for that (Unable to create  
subscription), wouldn't this be useful in the IVR package as well?

Mixer:
there's no error for non-existent connections, just non-existent  
conferences (406); since the IVR envisages both (407 connection does  
not exist, 408 conferenceid does not exist) I'd suggest adding one to  
the Mixer package too; in the prototype we currently trigger a 426  
error (Unable to join - mixing connections not supported) which,  
besides being too generic for the AS to debug, is probably incorrect  
as well (the connection is not unsupported, it just does not exist).

Hope that helps,
Lorenzo

Quoting "McGlashan, Scott" <[email-masked]>:

> In 4.3.1.4, "The MS MUST have uploaded the recorded data to this   
> resource as soon as possible after recording is complete" - this   
> probably isn't a 2119 MUST (I'm also thinking "MUST have" reads   
> oddly). What's the text trying to say?
>
> We're trying to say that the MS shouldn't take too long to upload   
> the recording. I'll rephrase without the RFC2119 language so it is   
> just a description.
>
> Scott
>
>
> Subject: Re: [MEDIACTRL] Working Group Last Call   
> ondraft-ietf-mediactrl-ivr-control-package-02.txt
>
> I'm sending along some comments, mostly editorial, on the IVR draft.  
>  In general, I'm pleased with the readability of the draft.
>
> Maybe not nits:
>
> In 4.2.5.1, I was expecting to see a reserved range for additional   
> defined status codes, between the currently defined status codes and  
>  the MS-defined status code range. If this isn't necessary, fine, I   
> thought I'd ask now, rather than later.
>
> In 4.2.1.3, the default value for termtimeout is 0 - could this say   
> "the default value is 0s (no delay)"? Some variables define 0 as   
> having special significance, so I'd suggest being clear here.
>
> In 4.3.1.4, "The MS MUST have uploaded the recorded data to this   
> resource as soon as possible after recording is complete" - this   
> probably isn't a 2119 MUST (I'm also thinking "MUST have" reads   
> oddly). What's the text trying to say?
>
> Nits:
>
> In 6.1.4, /is sent by to the AS/ is broken. I think this is "is sent  
>  by the MS to the AS", which seems wordy, but the sentence needs help.
>
> The Contributions and Acknowledgement sections list affiliations in   
> many, but not all, cases. I'll spare the "IETF is made up of   
> individuals" pep talk, but was the inconsistency intentional? Given   
> how many affiliations change during the life of an RFC, I'm not sure  
>  listing them is helpful when we move to RFC.
>
>

-- 
Lorenzo Miniero, Junior Researcher
Dipartimento di Informatica e Sistemistica
Universita' degli Studi di Napoli "Federico II"
Via Claudio 21 -- 80125 Napoli (Italy)
Phone: +390817683821 - Fax: +390817683816
Email: [email-masked]
_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: "McGlashan, Scott" <[email-masked]>
Date: Fri, 14 Nov 2008 14:01:33 +0000

Good catches. I'll fix them.

Thanks

Scott

-----Original Message-----
From: Lorenzo Miniero [mailto:[email-masked]]
Sent: Tuesday, November 11, 2008 12:10
To: McGlashan, Scott
Cc: Spencer Dawkins; [email-masked]
Subject: Re: [MEDIACTRL] Working Group Last Call ondraft-ietf-mediactrl-ivr-control-package-02.txt

Since we're on it, I've got a couple of doubts as well, which came while upgrading the prototype to the -02 versions of IVR and Mixer drafts.

IVR:
there's no error code associated with a subscription error: in the Mixer package there's a 422 error for that (Unable to create subscription), wouldn't this be useful in the IVR package as well?

Mixer:
there's no error for non-existent connections, just non-existent conferences (406); since the IVR envisages both (407 connection does not exist, 408 conferenceid does not exist) I'd suggest adding one to the Mixer package too; in the prototype we currently trigger a 426 error (Unable to join - mixing connections not supported) which, besides being too generic for the AS to debug, is probably incorrect as well (the connection is not unsupported, it just does not exist).

Hope that helps,
Lorenzo

Quoting "McGlashan, Scott" <[email-masked]>:

> We're trying to say that the MS shouldn't take too long to upload the
> recording. I'll rephrase without the RFC2119 language so it is just a
> description.
>
> Scott
>
>

Dipartimento di Informatica e Sistemistica Universita' degli Studi di Napoli "Federico II"