Subject: [speechsc] Speech-Marker issues x 2

From: "Dave Burke" <[email-masked]>
Date: Sat, 6 May 2006 12:31:28 +0100

Issue 1:

A SPEECH-MARKER event is generated when a PENDING SPEAK request becomes
IN-PROGRESS. In this case, the corresponding Speech-Marker header field has
a "null string" and a timestamp. What does that look like? -

    Speech-Marker: ;timestamp=123456

or

    Speech-Marker: null;timestamp=123456

The ABNF will not allow the former. However, the latter is
dangerous for obvious reasons  (<mark name="null"/>). So, perhaps
go with the former and change 1*VCHAR to *VCHAR in the 
speech-marker expansion.

Issue 2:

Why should Speech-Marker be returned in CONTROL / STOP responses and
SPEAK-COMPLETE events? Seems redundant to me and I don't see any
race-condition (e.g. if on receipt of a STOP the resource still has a mark
to send then send SPEECH-MARKER before the response to STOP etc). Besides,
none of the examples are showing this today.

Dave

_______________________________________________
Speechsc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc

---

From: "Carter, Jerry" <[email-masked]>
Date: Mon, 8 May 2006 13:17:42 -0400

For completeness, I noticed a minor problem with my proposal.  The original
UTFCHAR definition [1] did not allow 0x20 whereas that character would need
to be legal within the marker name.

[1] http://www1.ietf.org/mail-archive/web/speechsc/current/msg01666.html

> -----Original Message-----
> From: Dave Burke [mailto:[email-masked]]
> Sent: Monday, May 08, 2006 12:25 PM
> To: Carter, Jerry; [email-masked]
> Subject: Re: [speechsc] Speech-Marker issues x 2
> 
> Works for me.
> 
> Dave
> 
> ----- Original Message -----
> From: "Carter, Jerry" <[email-masked]>
> To: "Dave Burke" <[email-masked]>; <[email-masked]>
> Sent: Monday, May 08, 2006 4:24 PM
> Subject: RE: [speechsc] Speech-Marker issues x 2
> 
> 
> >I agree with your second issue, but the first is incomplete.  Today, the
> > ABNF for SPEECH-MARKER does not allow MRCP servers to fully support
> SSML.
> >
> > As I've noted previously [1], the ABNF does not allow characters outside
> a
> > subset of Latin-1.  The <mark> tag in SSML in contrast supports nearly
> > arbitrary Unicode character sequences in the 'name' attribute [2].
> > Specifically, the 'name' attribute has type 'xsd:token' which is
> > essentially
> > any sequence of
> >
> > [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]
> >
> > excluding without leading or trailing spaces (#x20) and with internal
> > space
> > characters collapsed.  As such, xsd:token is not a token in the
> > traditional
> > sense [3].
> >
> >
> > Hence, your first example
> >
> > could correspond to an
> > <mark name=";timestamp=123456"/>
> >
> > element embedded within the SSML.
> >
> >
> > The ABNF should probably be changed to the more verbose but more
> flexible
> >
> >   speech-marker = "Speech-Marker" ":"
> >                   "timestamp" "=" [time-stamp-value] ";"
> >                   [1*UTFCHAR] CRLF
> >
> > using the UTFCHAR definition from [1].
> >
> > [1] http://www1.ietf.org/mail-archive/web/speechsc/current/msg01666.html
> > [2] http://www.w3.org/TR/2004/REC-speech-synthesis-20040907/#edef_mark
> > [3] http://books.xmlschemata.org/relaxng/ch19-77319.html
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: Dave Burke [mailto:[email-masked]]
> >> Sent: Saturday, May 06, 2006 7:31 AM
> >> To: [email-masked]
> >> Subject: [speechsc] Speech-Marker issues x 2
> >>
> >> Issue 1:
> >>

---

From: "Shanmugham, Saravanan" <[email-masked]>
Date: Thu, 11 May 2006 06:39:43 -0700

Comments inline. 

     -----Original Message-----
     From: Dave Burke [mailto:[email-masked]] 
     Sent: Thursday, May 11, 2006 2:28 AM
     To: Shanmugham, Saravanan; [email-masked]
     Subject: Re: [speechsc] Speech-Marker issues x 2
     
     Comments inline.
     
     Thanks, Dave
     
     ----- Original Message -----
     From: "Shanmugham, Saravanan" <[email-masked]>
     To: "Dave Burke" <[email-masked]>; <[email-masked]>
     Sent: Wednesday, May 10, 2006 7:17 PM
     Subject: RE: [speechsc] Speech-Marker issues x 2

     On Issue 1 about format of the ABNF not allowing null and 
     unicodes. I am
     fine with Jerry's proposal. If there are no other objects to that
     proposal, that change can be accomodated in the specification.
     
     On Issue 2, the marker header in a STOP or CONTROL response and
     SPEAK-COMPLETE events allow the client to know exactly where in the
     speak request the STOP/CONTROL method was received and 
     enforced or in
     the case of SPEAK-COMPLETE timestamp where it finished the SPEAK
     request.. Both in terms of time(timestamp) as well the 
     last marker that
     was hit(which may be redundant assuming an associated 
     SPEECH-MARCKER
     event was received by the client).
     
     --------
     DB:
     
     Thanks for the clarification. Few issues with this:
     
     1. The text in 8.4.8 could be improved to explain that the 
     Speech-Marker 
     header is used *both* for carrying bookmarks encountered 
     in the markup and 
     for carrying timestamp information associated with 
     important events within 
     the lifecycle of a request (start of SPEAK processing, end 
     of SPEAK 
     processing, receipt of CONTROL/STOP/BARGE-IN-OCCURRED) - 
     certainly would 
     make the overloaded intent of the header field clearer.
Sarvi>> Sounds good.
     
     2. We also need Speech-Marker on BARGE-IN-OCCURRED response.
Sarvi> I agree
     
     3. Having Speech-Marker in SPEAK-COMPLETE is a little 
     non-symmetrical 
     because we don't always know the timestamp when the SPEAK started. 
     Interestingly, we do if the SPEAK request state goes from 
     PENDING to 
     IN-PROGRESS but not if it goes to IN-PROGRESS directly. 
     This would mean we 
     add Speech-Marker to a IN-PROGRESS SPEAK response also.
     .
Sarvi>> I agree

     4. None of the examples show the Speech-Marker for 
     CONTROL/STOP/BARGE-IN-OCCURRED responses or SPEAK-COMPLETE events.
Sarvi>> We can fix existing examples. As for new examples, time
permitting only.
     
     5. Using NTP timestamps assumes one has already received 
     an RTCP SR to be 
     able to do the correlation. However, given the current 
     minimum of 5 seconds 
     inter-packet interval for RTCP, there's no guarantee one 
     will have been 
     received a SR for a first, short prompt. I would have gone 
     for the RTP 
     timestamp instead - MRCP just needs to provide information 
     to do correlation 
     between the control channel and media stream - the client 
     can worry about 
     whether it wants that time absolute... (that said, I can 
     live with NTP).
     
     --------

     Thx,
     Sarvi

     
          -----Original Message-----
          From: Dave Burke [mailto:[email-masked]]
          Sent: Saturday, May 06, 2006 4:31 AM
          To: [email-masked]
          Subject: [speechsc] Speech-Marker issues x 2
     
          Issue 1:
     
          A SPEECH-MARKER event is generated when a PENDING SPEAK
          request becomes IN-PROGRESS. In this case, the
          corresponding Speech-Marker header field has a "null
          string" and a timestamp. What does that look like? -

          or

          The ABNF will not allow the former. However, the latter is
          dangerous for obvious reasons  (<mark name="null"/>). So,
          perhaps go with the former and change 1*VCHAR to *VCHAR in
          the speech-marker expansion.
     
          Issue 2:
     
          Why should Speech-Marker be returned in CONTROL / STOP
          responses and SPEAK-COMPLETE events? Seems redundant to me
          and I don't see any race-condition (e.g. if on receipt of
          a STOP the resource still has a mark to send then send
          SPEECH-MARKER before the response to STOP etc). Besides,
          none of the examples are showing this today.
     
          Dave