Subject: Re: [MEDIACTRL] Using SRGS in IVR draft

From: "Chris Boulton" <[email-masked]>
Date: Mon, 4 Feb 2008 15:42:46 -0000

sorry for the typo - I meant that SRGS does not support long and double
key press.

Support from Voxeo in W3C to extend SRGS with these features is much
apprecated - thanks.

If there are no objections from the group to the proposal for custom
DTMF grammar formats that

 implementations SHALL support SRGS and MAY support KPML

then I'll add that in the next basic IVR draft.

[Chris Boulton] Just wanted to check that we are happy with this
statement (sorry if I have missed this already being discussed).  I
thought we wanted a mandatory to implement?  If that is the case
shouldn't we be using language like 'MUST' and 'MAY' support KPML (while
also quantifying the MAY).

Chris.

thanks

Scott

  _____  

From: Dan York [mailto:[email-masked]] 
Sent: Wednesday, January 30, 2008 14:45
To: McGlashan, Scott
Cc: Spencer Dawkins; [email-masked]; Dan Burnett
Subject: Re: [MEDIACTRL] Using SRGS in IVR draft

Scott, 

Thank you for the great explanation.  Just to be clear I believe you
meant in #1 below that SRGS does NOT support long and double press
features, correct?

When I asked my (Voxeo) colleague Dan Burnett about this, he responded
that his preference would be:

- to mandate support for SRGS,

- to permit support for KPML DTMF, and

- to work within W3C to extend SRGS to provide support for long and
double keypresses.

and added that he would be willing to help push these SRGS extensions
along with W3C.

So if I translate that into IETF lingo it would be that implementations
SHALL support SRGS and MAY support KPML, with the idea being that over
time we could (if we chose to do so) phase out the KPML usage and wind
up only with SRGS.

It seems a reasonable approach to me.

Regards,

Dan

On Jan 30, 2008, at 5:45 AM, McGlashan, Scott wrote:

We are definitely using SRGS for DTMF. It is also the required format
for JSR 309.

The questions the design team is looking at are:

(a) should we have one custom DTMF grammar format which compliant
implementations of the basic IVR package must support?

(b) if yes to (a), what format should be manadatory?

The current version of the package allows a custom DTMF grammar, but
does not mandate any format. The editors note says:

 [Editors note: The format of the custom DTMF grammar is not yet
defined. Possibilities include: [SRGS]
<file:///C:\smcglashan\ietf\control\basic-ivr\releases\draft-boulton-ivr
-control-package-05.html#SRGS> [H.248.1]
<file:///C:\smcglashan\ietf\control\basic-ivr\releases\draft-boulton-ivr
-control-package-05.html#H.248.1>  and [RFC4730]
<file:///C:\smcglashan\ietf\control\basic-ivr\releases\draft-boulton-ivr
-control-package-05.html#RFC4730> . If more than one format is
permitted, then an additional input parameter "grammartype" would
indicate the format used in the grammar parameter.]

If we were to mandate a format, there seems to be two major candidates,
each with pros and cons (both are supported in the field):

1. SRGS: powerful format supporting both DTMF and speech input, used in
VoiceXML and other standards. This allows developers to use the same
DTMF format consistently in the base package, the VoiceXML package, ASR
package. etc. The downside is that SRGS does support long press and
double press features.

2. KPML DTMF format: basically H248.1 DRegex format with some fixes.
This format is simpler and targeted specifically at DTMF and supports
long and double key presses. On the downside, it doesn't apply to speech
formats, not used in VoiceXML and would require developers to learn 2
formats, and platforms to support 2 formats, for speech and VoiceXML
usage.

I would like to get more input from the group on these questions before
updating the spec - should we mandate one format and, if so, which one?

thanks

Scott

  _____  

From: Spencer Dawkins [mailto:[email-masked]] 
Sent: Wednesday, January 30, 2008 06:21
To: Dan York
Cc: [email-masked]
Subject: Re: [MEDIACTRL] Using SRGS in IVR draft

Hi, Dan,

I didn't mean to give the impression that any action was imminent - Eric
and I are just making sure whether people are actually using both KPML
and SRGS for DTMF IVR work.

Thanks,

Spencer

	----- Original Message -----

	From: Dan York <mailto:[email-masked]> 

	To: Spencer Dawkins <mailto:[email-masked]> 

	Cc: [email-masked] <mailto:[email-masked]> 

	Sent: Tuesday, January 29, 2008 7:55 PM

	Subject: Re: [MEDIACTRL] Using SRGS in IVR draft

	Spencer, 

	We are aware that some of our customers heavily use SRGS for
DTMF.  Is the discussion about removing support for SRGS from the Basic
IVR draft?

	Regards,

	Dan

	On Jan 29, 2008, at 3:13 PM, Spencer Dawkins wrote:

	Eric and I are hearing that the design team thinks their work on
IVR is almost complete, and we have an opportunity to finish one
discussion point and help them get the next revision out quickly...

	KPML and SRGS - is anybody actually using SRGS in IVR systems
*for DTMF*, or are people just talking about something that could be
done?

	Thanks,

	Spencer, as co-chair 

	-- 

	Dan York, CISSP, Director of Emerging Communication Technology

	Office of the CTO    Voxeo Corporation     [email-masked]
<mailto:[email-masked]> 

	Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
<http://www.voxeo.com> 

	Blogs: http://blogs.voxeo.com <http://blogs.voxeo.com>
http://www.disruptivetelephony.com <http://www.disruptivetelephony.com> 

	Bring your web applications to the phone.

	Find out how at http://evolution.voxeo.com
<http://evolution.voxeo.com> 

	

 

-- 

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

Bring your web applications to the phone.

Find out how at http://evolution.voxeo.com

 

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

---

From: Dan York <[email-masked]>
Date: Mon, 4 Feb 2008 14:43:44 -0500

Chris,

Per RFC 2119 ( http://www.ietf.org/rfc/rfc2119.txt ), "SHALL" and  
"MUST" are identical:
-----
1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
    definition is an absolute requirement of the specification.
-----
so it would seem to me to be really up to the author of the draft or  
the conventions of the particular working group as to whether they  
choose "MUST" or "SHALL".

Dan

On Feb 4, 2008, at 10:42 AM, Chris Boulton wrote:

>
>
> sorry for the typo - I meant that SRGS does not support long and  
> double key press.
>
> Support from Voxeo in W3C to extend SRGS with these features is  
> much apprecated - thanks.
>
> If there are no objections from the group to the proposal for  
> custom DTMF grammar formats that
>
> shouldn’t we be using language like ‘MUST’ and ‘MAY’ support KPML  
> (while also quantifying the MAY).
>
> Chris.
>
>
> thanks
>
> Scott
>
>
> Thank you for the great explanation.  Just to be clear I believe  
> you meant in #1 below that SRGS does NOT support long and double  
> press features, correct?
>
> When I asked my (Voxeo) colleague Dan Burnett about this, he  
> responded that his preference would be:
>
> and added that he would be willing to help push these SRGS  
> extensions along with W3C.
>
> So if I translate that into IETF lingo it would be that  
> implementations SHALL support SRGS and MAY support KPML, with the  
> idea being that over time we could (if we chose to do so) phase out  
> the KPML usage and wind up only with SRGS.
>
> We are definitely using SRGS for DTMF. It is also the required  
> format for JSR 309.
>
> The current version of the package allows a custom DTMF grammar,  
> but does not mandate any format. The editors note says:
>
> defined. Possibilities include: [SRGS] [H.248.1]  and [RFC4730]. If  
> more than one format is permitted, then an additional input  
> parameter "grammartype" would indicate the format used in the  
> grammar parameter.]
>
> If we were to mandate a format, there seems to be two major  
> candidates, each with pros and cons (both are supported in the field):
>
> 1. SRGS: powerful format supporting both DTMF and speech input,  
> used in VoiceXML and other standards. This allows developers to use  
> the same DTMF format consistently in the base package, the VoiceXML  
> package, ASR package. etc. The downside is that SRGS does support  
> long press and double press features.
>
> 2. KPML DTMF format: basically H248.1 DRegex format with some  
> fixes. This format is simpler and targeted specifically at DTMF and  
> supports long and double key presses. On the downside, it doesn't  
> apply to speech formats, not used in VoiceXML and would require  
> developers to learn 2 formats, and platforms to support 2 formats,  
> for speech and VoiceXML usage.
>
> I would like to get more input from the group on these questions  
> before updating the spec - should we mandate one format and, if so,  
> which one?
>
> thanks
>
> Scott
>
>
>
> I didn't mean to give the impression that any action was imminent -  
> Eric and I are just making sure whether people are actually using  
> both KPML and SRGS for DTMF IVR work.
>
> Thanks,
>
> Spencer
> From: Dan York
> To: Spencer Dawkins
> We are aware that some of our customers heavily use SRGS for DTMF.   
> Is the discussion about removing support for SRGS from the Basic  
> IVR draft?
>
> Regards,
> Dan
>
> KPML and SRGS - is anybody actually using SRGS in IVR systems *for  
> DTMF*, or are people just talking about something that could be done?
>
> Thanks,
>
> Spencer, as co-chair
>
> --

---

From: "Chris Boulton" <[email-masked]>
Date: Mon, 4 Feb 2008 21:06:54 -0000

Chris,

Per RFC 2119 ( http://www.ietf.org/rfc/rfc2119.txt ), "SHALL" and "MUST"
are identical:

-----

-----

so it would seem to me to be really up to the author of the draft or the
conventions of the particular working group as to whether they choose
"MUST" or "SHALL".

[Chris Boulton] Totally agree with you.  But experience in Working
Groups suggests that using MUST with a quantified MAY is the
clearer/cleaner mechanism and more readily recognized by folks who read
IETF docs (I am not that passionate about it :-)).

Chris.

Dan

 

Chris.

thanks

Scott

  _____  

Scott,

Regards,

Dan

-control-package-05.html#SRGS>

thanks

Scott

  _____  

Hi, Dan,

Thanks,

Spencer

	----- Original Message -----

	Spencer,

	Regards,

	Dan

	Thanks,

	Spencer, as co-chair 

	-- 

	 

 

-- 

 

-- 

 

This email was protected during delivery to Avaya with TLS encryption
_______________________________________________
MEDIACTRL mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 19 Feb 2008 11:20:07 -0600

Hi, Scott,

Eric and I are calling this as working group consensus on " implementations SHALL support SRGS and MAY support KPML".

I have a slight preference for the use of "MUST" instead of "SHALL" - although "SHALL" is perfectly good 2119 language, we do see participants who don't realize this.

So, for extra credit - could you submit a version of the IVR draft that reflects the resolution of our last open issue, so that we can start WGLC and meet our current milestones?  :-)

Cutoff for this draft would be on Monday, of course...

Thanks!

Spencer

  ----- Original Message ----- 
  From: Chris Boulton 
  To: McGlashan, Scott ; Dan York 
  Cc: Dan Burnett ; [email-masked] 
  Sent: Monday, February 04, 2008 9:42 AM
  Subject: Re: [MEDIACTRL] Using SRGS in IVR draft

  sorry for the typo - I meant that SRGS does not support long and double key press.

  Support from Voxeo in W3C to extend SRGS with these features is much apprecated - thanks.

  If there are no objections from the group to the proposal for custom DTMF grammar formats that

  [Chris Boulton] Just wanted to check that we are happy with this statement (sorry if I have missed this already being discussed).  I thought we wanted a mandatory to implement?  If that is the case shouldn't we be using language like 'MUST' and 'MAY' support KPML (while also quantifying the MAY).

  Chris.

  thanks

  Scott

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

  Scott, 

  Thank you for the great explanation.  Just to be clear I believe you meant in #1 below that SRGS does NOT support long and double press features, correct?

  When I asked my (Voxeo) colleague Dan Burnett about this, he responded that his preference would be:

  - to work within W3C to extend SRGS to provide support for long and double keypresses.

  and added that he would be willing to help push these SRGS extensions along with W3C.

  So if I translate that into IETF lingo it would be that implementations SHALL support SRGS and MAY support KPML, with the idea being that over time we could (if we chose to do so) phase out the KPML usage and wind up only with SRGS.

  Regards,

  Dan

  We are definitely using SRGS for DTMF. It is also the required format for JSR 309.

  (a) should we have one custom DTMF grammar format which compliant implementations of the basic IVR package must support?

  The current version of the package allows a custom DTMF grammar, but does not mandate any format. The editors note says:

   [Editors note: The format of the custom DTMF grammar is not yet defined. Possibilities include: [SRGS] [H.248.1]  and [RFC4730]. If more than one format is permitted, then an additional input parameter "grammartype" would indicate the format used in the grammar parameter.]

  If we were to mandate a format, there seems to be two major candidates, each with pros and cons (both are supported in the field):

  1. SRGS: powerful format supporting both DTMF and speech input, used in VoiceXML and other standards. This allows developers to use the same DTMF format consistently in the base package, the VoiceXML package, ASR package. etc. The downside is that SRGS does support long press and double press features.

  2. KPML DTMF format: basically H248.1 DRegex format with some fixes. This format is simpler and targeted specifically at DTMF and supports long and double key presses. On the downside, it doesn't apply to speech formats, not used in VoiceXML and would require developers to learn 2 formats, and platforms to support 2 formats, for speech and VoiceXML usage.

  I would like to get more input from the group on these questions before updating the spec - should we mandate one format and, if so, which one?

  thanks

  Scott

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

  Hi, Dan,

  I didn't mean to give the impression that any action was imminent - Eric and I are just making sure whether people are actually using both KPML and SRGS for DTMF IVR work.

  Thanks,

  Spencer

    ----- Original Message -----

    From: Dan York

    To: Spencer Dawkins

    Cc: [email-masked]

    Spencer, 

    We are aware that some of our customers heavily use SRGS for DTMF.  Is the discussion about removing support for SRGS from the Basic IVR draft?

    Regards,

    Dan

    Eric and I are hearing that the design team thinks their work on IVR is almost complete, and we have an opportunity to finish one discussion point and help them get the next revision out quickly...

    KPML and SRGS - is anybody actually using SRGS in IVR systems *for DTMF*, or are people just talking about something that could be done?

    Thanks,

    Spencer, as co-chair 

    -- 

  -- 

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

---

From: "McGlashan, Scott" <[email-masked]>
Date: Tue, 19 Feb 2008 17:44:27 +0000

hi Spencer,

Yes, latest IVR draft will be available by Friday. I've used MUST to be consistent with the rest of the text.

Don't know about WGLC - the document is currently an individual ID. Counting on support from you and Eric for making the doc a WG item at the F2F - and then onto WGLC as soon as humanly possible.

thanks

Scott

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Spencer Dawkins
Sent: Tuesday, February 19, 2008 18:20
To: [email-masked]
Subject: Re: [MEDIACTRL] Using SRGS in IVR draft

Hi, Scott,

Thanks!

Spencer

----- Original Message -----
From: Chris Boulton<mailto:[email-masked]>
To: McGlashan, Scott<mailto:[email-masked]> ; Dan York<mailto:[email-masked]>
Cc: Dan Burnett<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]>
Sent: Monday, February 04, 2008 9:42 AM
Subject: Re: [MEDIACTRL] Using SRGS in IVR draft

Chris.

thanks

Scott

________________________________

Regards,
Dan

 [Editors note: The format of the custom DTMF grammar is not yet defined. Possibilities include: [SRGS] <file:///C:\smcglashan\ietf\control\basic-ivr\releases\draft-boulton-ivr-control-package-05.html#SRGS> [H.248.1] <file:///C:\smcglashan\ietf\control\basic-ivr\releases\draft-boulton-ivr-control-package-05.html#H.248.1>  and [RFC4730]<file:///C:\smcglashan\ietf\control\basic-ivr\releases\draft-boulton-ivr-control-package-05.html#RFC4730>. If more than one format is permitted, then an additional input parameter "grammartype" would indicate the format used in the grammar parameter.]

thanks

Scott

________________________________
From: Spencer Dawkins [mailto:[email-masked]]
Sent: Wednesday, January 30, 2008 06:21
To: Dan York
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [MEDIACTRL] Using SRGS in IVR draft
Hi, Dan,

Thanks,

Spencer
----- Original Message -----
From: Dan York<mailto:[email-masked]>
To: Spencer Dawkins<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Sent: Tuesday, January 29, 2008 7:55 PM
Subject: Re: [MEDIACTRL] Using SRGS in IVR draft

Spencer,

Regards,
Dan

Thanks,

Spencer, as co-chair

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

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

________________________________

---

From: Eric Burger <[email-masked]>
Date: Fri, 22 Feb 2008 10:21:15 -0500

[chair hat off]

I was initially going to say, "Pick one, and only one, grammar format, even
if that means ditching KPML."  This is because every point of choice in a
protocol is a virtual guarantee of interoperability problems.

However, it seems that EVERY grammar format has flaws:

SRGS: Doesn't implement common DTMF use cases like long digit detection or
double digit detection.  None of the major MS vendors support it in their
IVR packages.  Very complex to implement and learn.  By ports deployed, one
could argue few applications use it.  However, by number of VoiceXML
applications, one would think there is a sizable contingent that has been
exposed to its use.
The argument "Easy to move application from DTMF IVR to speech" is a non
sequitur: either your call flows change dramatically when you go from DTMF
to speech, or your speech application sucks.  Just a personal opinion.  From
painful experience.
Digit detection can be fixed in W3C.  Given history, we can expect to see it
by 2011.

H.248.1: Yuck

KPML: Very close, yet slightly different, from MSCML and MOML.

Given the above, I am back to what we have here: "Pick one, and only one,
grammar format for everyone to implement.  Make sure the protocol allows us
to negotiate other grammar formats."  I think that is what we will have
here, so a +1 from me, too.

On 2/4/08 10:42 AM, "Chris Boulton" <[email-masked]> wrote:

> [Chris Boulton] Just wanted to check that we are happy with this statement
> (sorry if I have missed this already being discussed).  I thought we wanted a
> mandatory to implement?  If that is the case shouldn¹t we be using language
> like ŒMUST¹ and ŒMAY¹ support KPML (while also quantifying the MAY).
>  
> Chris.
>  
>  
> thanks
>  
> Scott
>  
>  
> 
> 
> Thank you for the great explanation.  Just to be clear I believe you meant in
> #1 below that SRGS does NOT support long and double press features, correct?
> 
>  
> 
> So if I translate that into IETF lingo it would be that implementations SHALL
> support SRGS and MAY support KPML, with the idea being that over time we could
> (if we chose to do so) phase out the KPML usage and wind up only with SRGS.
> 
>  
> 
> The current version of the package allows a custom DTMF grammar, but does not
> mandate any format. The editors note says:
>  
>  [Editors note: The format of the custom DTMF grammar is not yet defined.
> Possibilities include: [SRGS]
> <file:///C:\smcglashan\ietf\control\basic-ivr\releases\draft-boulton-ivr-contr
> ol-package-05.html#SRGS> [H.248.1]
> <file:///C:\smcglashan\ietf\control\basic-ivr\releases\draft-boulton-ivr-contr
> ol-package-05.html#H.248.1>  and [RFC4730]
> <file:///C:\smcglashan\ietf\control\basic-ivr\releases\draft-boulton-ivr-contr
> ol-package-05.html#RFC4730> . If more than one format is permitted, then an
> additional input parameter "grammartype" would indicate the format used in the
> grammar parameter.]
>  
> If we were to mandate a format, there seems to be two major candidates, each
> with pros and cons (both are supported in the field):
>  
> VoiceXML and other standards. This allows developers to use the same DTMF
> format consistently in the base package, the VoiceXML package, ASR package.
> etc. The downside is that SRGS does support long press and double press
> features.
> 
>  
> 
> 2. KPML DTMF format: basically H248.1 DRegex format with some fixes. This
> format is simpler and targeted specifically at DTMF and supports long and
> double key presses. On the downside, it doesn't apply to speech formats, not
> used in VoiceXML and would require developers to learn 2 formats, and
> platforms to support 2 formats, for speech and VoiceXML usage.
> 
>  
> 
> I didn't mean to give the impression that any action was imminent - Eric and I
> are just making sure whether people are actually using both KPML and SRGS for
> DTMF IVR work.
> 
>  
> 
> Thanks,
> 
>  
> 
> Spencer
>> 
>> We are aware that some of our customers heavily use SRGS for DTMF.  Is the
>> discussion about removing support for SRGS from the Basic IVR draft?
>> 
>>  
>> 
>> Regards,
>> 
>> Dan
>> 
>>  
>> 
>> Eric and I are hearing that the design team thinks their work on IVR is
>> almost complete, and we have an opportunity to finish one discussion point
>> and help them get the next revision out quickly...
>> 
>>  
>> 
>> KPML and SRGS - is anybody actually using SRGS in IVR systems *for DTMF*, or
>> are people just talking about something that could be done?
>> 
>>  
>> 
>> Thanks,
>> 
>>  
>> 
>> Spencer, as co-chair
>>  

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
_______________________________________________
MEDIACTRL mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: Eric Burger <[email-masked]>
Date: Fri, 22 Feb 2008 10:10:59 -0500

There is nothing special about the F2F.  Once your new draft is posted we
will ask the list if it is a candidate for WG draft.  In fact, we cannot
decide that at the F2F, as everything is done on the public mediactrl list.

On 2/19/08 9:44 AM, "McGlashan, Scott" <[email-masked]> wrote:

> Don't know about WGLC - the document is currently an individual ID. Counting
> on support from you and Eric for making the doc a WG item at the F2F - and
> then onto WGLC as soon as humanly possible.
>  
> thanks 
>  
> Scott
>  
> 
> 
> Eric and I are calling this as working group consensus on " implementations
> SHALL support SRGS and MAY support KPML".
>  
> I have a slight preference for the use of "MUST" instead of "SHALL" - although
> "SHALL" is perfectly good 2119 language, we do see participants who don't
> realize this.
>  
> So, for extra credit - could you submit a version of the IVR draft that
> reflects the resolution of our last open issue, so that we can start WGLC and
> meet our current milestones?  :-)
>  
>> From:  Chris Boulton <mailto:[email-masked]>
>>  
>> To: McGlashan, Scott <mailto:[email-masked]>  ; Dan York
>> <mailto:[email-masked]>
>>  
>> Cc: Dan Burnett <mailto:[email-masked]>  ; [email-masked]
>>  
>> (sorry if  I have missed this already being discussed).  I thought we wanted
>> a  mandatory to implement?  If that is the case shouldn¹t we be using
>> language like ŒMUST¹ and ŒMAY¹ support KPML (while also quantifying the
>> MAY).
>>  
>>  
>>  
>> Chris.
>>  
>>  
>>  
>>  
>>  
>> thanks
>>  
>>  
>>  
>> Scott
>>  
>>  
>>  
>>  
>>  
>>  
>> 
>>  
>>  
>> 
>> Thank you for the great explanation.  Just to be  clear I believe you meant
>> in #1 below that SRGS does NOT support long and  double press features,
>> correct?
>>  
>>  
>> 
>>  
>>  
>>  
>> 
>> SHALL support SRGS and MAY support KPML, with the idea  being that over time
>> we could (if we chose to do so) phase out the KPML usage  and wind up only
>> with SRGS.
>>  
>>  
>> 
>>  
>>  
>>  
>> 
>> The  current version of the package allows a custom DTMF grammar, but does
>> not  mandate any format. The editors note says:
>>  
>>  
>>  
> I didn't  mean to give the impression that any action was imminent - Eric and
> I are just  making sure whether people are actually using both KPML and SRGS
> for DTMF IVR  work.
>  
>  
> 
>  
>  
>  
> 
> Thanks,
>  
>  
> 
>  
>  
>  
> 
> Spencer
>  
>>  
>>  
>>