Subject: RE: [Sipping] KPML Digit Maps

From: Adam Roach <[email-masked]>
Date: Wed, 12 Nov 2003 14:11:07 -0600

Unless doing so will significantly impair progress, I'm
inclined to agree with Dave's recommendation: one digit
map format, and make it regexes.

/a

> -----Original Message-----
> From: David R. Oran [mailto:[email-masked]]
> Sent: Wednesday, November 12, 2003 13:59
> To: Sipping (E-mail)
> Subject: Re: [Sipping] KPML Digit Maps
> 
> 
> Before giving up and playing negotiation games, I'd like to see if it 
> impossible politically to "just pick".
> 
> So, I would like to formally propose:
> 
> 1a. We pick regular expressions as the only digit map style 
> supported by 
> KPML.
> 
> I won't be terribly unhappy if this is shot down, but our 
> lives would sure 
> be better if we could KISS digit maps for KPML.
> 
> Dave.
> 
> --On Wednesday, November 12, 2003 11:04 AM -0500 Eric Burger 
> <[email-masked]> wrote:
> 
> > Right now, KPML specifies 3 mandatory digit map styles:
> >  - Regular Expressions
> >  - H.248.1 digitmap
> >  - J.162   digitmap
> >
> > Choices are:
> >  1. We can pick one, and only one digit map style.
> >  2. We can negotiate the style, with a mandatory
> >     to implement for guaranteed baseline
> >     interoperability.
> >
> > There was a leaning in Minneapolis towards option #2.  The mechanism
> > roughly would be to put a parameter on the event: kpml header in the
> > SUBSCRIBE, with a suitable failure if the style is not 
> supported by the
> > KPML server.  Given that there are already three (or four, 
> see below)
> > different digit map styles, this probably would become an 
> IANA-registered
> > tag.
> >
> > For the people that think expression evaluation is computationally
> > complex, one of the styles can be a hardcode of "match digit."  [Ed.
> > Note: this mode is not really useful for the reasons given, in that
> > expression evaluation is not computationally complex, 
> especially when
> > compared to the computational complexity of running a SIP 
> stack or (if on
> > a single processor) the complexity of detecting DTMF).]
> >
> > Comments?
> >
> >
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use [email-masked] for questions on current sip
> > Use [email-masked] for new developments of core SIP
> 
> 
> 
> ------------------------
> David R. Oran
> Cisco Systems
> 7 Ladyslipper Lane
> Acton, MA 01720
> Office: +1 978 264 2048
> VoIP: +1 408 571 4576
> Email: [email-masked]
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 13 Nov 2003 02:20:57 -0500

I feel strongly that we should pick one. Having multiple ways of doing 
something is a known bad thing, and here it just seems to bring no 
real extra value.

I feel less strongly about what the thing is. But having to negotiate 
this is just silly.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com