Subject: On 7.1.4

From: Flemming Andreasen <[email-masked]>
Date: Sat, 11 Mar 2000 11:47:01 -0500

Tom Taylor wrote:

>
> > 7) 7.1.14, last sentence in paragraph beginning with "The letter 'x'
> is
> > used as a wildcard..." specifies that "As a consequence of the thrid
>
> > timing rule above, inter-event timing while matching the dot symbol
> uses
> > the short timer by default." is incorrect. The grammar may continue
> past
> > the dot symbol implying the dot could only possibly produce a
> partial
> > match which furthermore implies that the short timer may not be the
> > right one to use. The sentence should simply be removed.
>         [[TomT]]  Agreed that the grammar may continue past the dot,
> but
> until you get that far you have an ambiguous situation -- you don't
> know how
> many events will be mapped into the dot.  The sentence is correct
> AFAIK.

That's not entirely accurate, e.g. consider "x.#" Now, if what follows
the dot has a non-empty intersection with what precedes the dot
(ignoring timers), you have an ambigous situation. In that case you
could then apply the short timer, or alternatively simply leave the
timing rules undefined then (since you can always rewrite the digit map
to avoid this, well at least in most cases).

>
> > 8) 7.1.14, next paragraph specifies that "A timer specified
> following a
> > dot specifies inter-event timing for all events matching the dot as
> well
> > as for subsequent events". It's unclear why the timer couldn't
> simply be
> > put in front of the dot and thereby be consistent with digit map
> timers
> > in general. In the absence of a compelling argument the sentence
> should
> > simply be removed.
>         [[TomT]]  Same problem as with the previous remark -- you
> don't know
> when you've gone past the dot until it's too late.  If there is a
> timer both
> before and after the dot, a timer after the dot never gets used.  It
> may be
> better just to say that, I suppose, leaving it up to the MGC to set a
> timer
> before the dot if it wants.

You could have have "S.xL", but otherwise I agree.

>
>
> > 9) 7.1.14, numbered list, item 4:    The second sentence and the
> last
> > sentence seem to contradict each other. While absence of
> long-duration
> > may prevent a match from occurring, existence of long-duration
> should
> > not. Consequently, the second sentence is what should be modified.
>         [[TomT]]  I assume you mean the last sentence of the
> paragraph.  You
> will reach this case only if all of the alternatives specifying a
> long-duration event at this point have been discarded.  Thus duration
> becomes irrelevant, but only after it has been taken into account in
> the
> cases where it mattered.

OK, I think I understand now, however the rule then seems to be
incorrect. Consider the digit map "Zx1 | x2" with input "Z1". The way I
read rule 4, the second sentence would lead us to discard alternative
"x2" which doesn't seem like the right thing to do, since "x2" doesn't
prevent us from having a long event, right ?

>
>
> > 10) 7.1.14, numbered list, item 5 specifies that "If exactly one
> > candidate remains, a completion event is generated indicating an
> > unambiguous match". This seems to imply that even a partial match
> (as
> > long as there is only one) will result in a digit map completion
> event,
> > which of course is incorrect.
>         [[TomT]]  Good catch.  This really is an error.  We should
> change
> that to "If exactly one candidate remains and it is fully matched,
> ..."
>
> > 11) 7.1.14, numbered list, item 5:    It is entirely unclear why an
> > event triggering a partial match is not reported as part of the
> matched
> > string. In the absence of a compelling argument, the triggering
> event
> > should be included in the string as it otherwise may be processed
> twice,
> > which is hardly what the user had in mind.
>         [[TomT]]  I had it that way in the first place (with the
> triggering
> event distinguished by being placed in an "extra event" parameter) and
>
> consensus was to change it to what it is now.  Have to overrule you on
> this
> one unless you get more support.

Well, I think it would be more appropriate that those who argue against
explain why. There's got to be a reasonable explanation here, or
reviewing this stuff is a waste of everybody's time.

> I'm also not clear how you get duplicate
> processing -- the situation is logically equivalent to the triggering
> event
> (a non-matching digit) happening just after the digit completion event
> has
> been notified.

Consider an IVR menu where input consists of two or more digits. For
sake of argument, let's say the only valid choice is "12", and I
erroneously enter "13". Upon entering "3" we get a mismatch and I
probably hear a recording telling me that "13" is an invalid choice and
I should try again. When digit map processing resumes for renewed input,
"3" will now be processed and I get another mismatch. The event was
processed twice which is the problem (a "process"/"discard" parameter in
event handling would of course be a general cure for such problems, but
alas, that was not to happen)

>
>
> > 12) 7.1.14, second last paragraph states that "Regardles of whether
> a
> > digit map is activated, this form of event specification will cause
> the
> > individual events to be reported to the MGC as they are detected".
> Some
> > clarification is requested here.
>         [[TomT]]  This paragraph gives the interpretation of e.g. the
> "dd/*"
> event specification.  Using the example digit map which immediately
> follows,
> a dialled "1" will be reported immediately and also accumulated into
> the
> digit map.  Of course, if EventBufferControl is set to LockStep, the
> digit
> map will never complete because a new Event Descriptor will be loaded
> before
> completion can be reported.  (There is a corner case with a dialled
> "0" and
> short timer expiry before the new Event descriptor is loaded, but
> let's not
> go into that.)

I can, to some extent, understand that, although I think this dual
processing does little but underscore the lack of generality in the
event handling scheme (interesting case when you have EventBufferControl
off). At a bare minimum I think you should define that an event detected
can at most match or be consumed by a single "event" specified in the
EventsDescriptor.

What I don't understand in the above sentence is, that it seems to imply
that the name by which we refer to an event impacts the reporting of
that event. With the current "dd" package, you may request digit map
matching without by only requesting the "Digit Map Completion" event,
i.e. do not request DTMF digits (correct ?). Thus I might define another
package, call it "dd2" that only consists of this particular event. What
the above sentence now implies is, that when I request "dd/ce", I will
process according to the digit map, but when I request "dd/*", which can
only expand to "dd/ce", I will report the digits invidually. Doesn't
seem right.

-- Flemming

--
Flemming Andreasen
Cisco Systems