Subject: [MEDIACTRL] Extensibility issue in IVR package

From: "McGlashan, Scott" <[email-masked]>
Date: Fri, 10 Jul 2009 12:18:09 +0000

As a result of feedback from our AD Robery Sparks, we need to make an explicit decision on how to support extensibility in the IVR package. Robert's full email on this issue is at: http://www.ietf.org/mail-archive/web/mediactrl/current/msg01324.html.

The issue concerns how we manage the extensibility of the two types of status code:

1. <dialogexit> status attribute indicating why a dialog exited. Integer value where we have defined 0-4 and reserved 5-9 values. 

2. <response>/<auditresponse> status attributes indicating a response to a request. Integer values where we have defined and reserved 200 (ok), 400-439 (errors). 

Our spec isn't sufficient to avoid interoperability issues - e.g. 2 different MS assign their own (and different) meaning to dialogexit status 15, or to response code 440. We need to pick between (a) using registries or (b) reserving all codes for IETF usage for each of these. As Robert says: 

	"The group should make an explicit choice on whether and how this extensibility should be 	controlled.

(a)	There are a wide range of choices for that how - registries are typical, but not necessary. 	If you really don't expect extensions in the future, creating a registry is work that won't 	have much payback, but if you expect there will be even a few, it's probably worth the 	effort.

(b)	If you don't expect extensions, a typical pattern is to reserve _all_ the undefined points 	and declare that something formal (like an RFC) is needed to add a new one. Then if you are 	surprised by an extension later, you can create a registry at that time."

My preference for both 1. and 2. is not to create a registry at this stage since I don't think there will extensions without a new version of the specification (1.1, 2.0, etc). Also in both cases, we have general codes as well as specific ones. So I would prefer to add a statement for both that all undefined codes are reserved for future use and that a standards-track RFC is required to defined new codes. 

Does the WG agree or not?  If not, alternative suggestions please! 

Thanks

Scott

---

From: Lorenzo Miniero <[email-masked]>
Date: Fri, 10 Jul 2009 14:36:31 +0200

Hi Scott,

I think your proposal is fine and I'd go with that as well.

L.

On Fri, 10 Jul 2009 12:18:09 +0000
"McGlashan, Scott" <[email-masked]> wrote:

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

-- 
Lorenzo Miniero <[email-masked]>

---

From: "Steve Buko" <[email-masked]>
Date: Fri, 10 Jul 2009 08:59:14 -0400

Scott,
 
I am OK with your proposal also.

________________________________

From: [email-masked] on behalf of Lorenzo Miniero
Sent: Fri 7/10/2009 8:36 AM
To: McGlashan, Scott
Cc: [email-masked]
Subject: Re: [MEDIACTRL] Extensibility issue in IVR package

Hi Scott,

L.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 10 Jul 2009 09:21:19 -0500

Re: [MEDIACTRL] Extensibility issue in IVR packagespeaking as individual, i also agree.

spencer
  ----- Original Message ----- 
  From: Steve Buko 
  To: McGlashan, Scott 
  Cc: [email-masked] 
  Sent: Friday, July 10, 2009 7:59 AM
  Subject: Re: [MEDIACTRL] Extensibility issue in IVR package

  Scott,

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

  Hi Scott,

  L.

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

---

From: Tim Melanchuk <[email-masked]>
Date: Fri, 10 Jul 2009 11:07:47 -0700

i agree with this proposal.   -- timm

On 10-Jul-09, at 5:18 AM, McGlashan, Scott wrote:

> As a result of feedback from our AD Robery Sparks, we need to make  
> an explicit decision on how to support extensibility in the IVR  
> package. Robert's full email on this issue is at: http://www.ietf.org/mail-archive/web/mediactrl/current/msg01324.html 
> .
>
> 1. <dialogexit> status attribute indicating why a dialog exited.  
> Integer value where we have defined 0-4 and reserved 5-9 values.
>
> 2. <response>/<auditresponse> status attributes indicating a  
> response to a request. Integer values where we have defined and  
> reserved 200 (ok), 400-439 (errors).
>
<snip>

> My preference for both 1. and 2. is not to create a registry at this  
> stage since I don't think there will extensions without a new  
> version of the specification (1.1, 2.0, etc). Also in both cases, we  
> have general codes as well as specific ones. So I would prefer to  
> add a statement for both that all undefined codes are reserved for  
> future use and that a standards-track RFC is required to defined new  
> codes.
>
>