Message

From speechsc-bounces@ietf.org Tue Jan 03 09:10:39 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etms3-0007b8-65; Tue, 03 Jan 2006 09:10:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etms1-0007ay-8B for speechsc@megatron.ietf.org; Tue, 03 Jan 2006 09:10:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27558 for ; Tue, 3 Jan 2006 09:09:23 -0500 (EST) Received: from maild.telecomitalia.it ([156.54.233.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtmxH-0004Ib-A6 for speechsc@ietf.org; Tue, 03 Jan 2006 09:16:04 -0500 Received: from ptpxch007ba020.idc.cww.telecomitalia.it ([156.54.240.50]) by maild.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 Jan 2006 15:10:04 +0100 Received: from PTPEVS106BA020.idc.cww.telecomitalia.it ([156.54.241.224]) by ptpxch007ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 Jan 2006 15:10:13 +0100 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.326 Content-Class: urn:content-classes:message Importance: normal Priority: normal MIME-Version: 1.0 Subject: [Speechsc] Uncorrect RECORD examples Date: Tue, 3 Jan 2006 15:08:13 +0100 Message-ID: <6B0BEC95E14FFF43822F1E730EF5C2566245FA@PTPEVS106BA020.idc.cww.telecomitalia.it> Thread-Topic: [Speechsc] Uncorrect RECORD examples thread-index: AcYQbyJsnSkob6NoT8qNO450w0JXSQ== From: "Bergallo Patrizio" To: X-OriginalArrivalTime: 03 Jan 2006 14:10:13.0225 (UTC) FILETIME=[69FD2590:01C6106F] X-Spam-Score: 0.8 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1530131122==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============1530131122== Content-Transfer-Encoding: 7bit Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6106F.691EE866" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6106F.691EE866 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 in draft 09, 10.4.8 says that Media Type is mandatory in a RECORD method but the examples in 10.6 (RECORD), 10.7 (STOP), and 10.8 (RECORD-COMPLETE) don't include this header. =20 Regards, Patrizio Bergallo, Loquendo. Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons = above and may contain confidential information. If you have received the = message in error, be informed that any use of the content hereof is = prohibited. Please return it immediately to the sender and delete the = message. Should you have any questions, please send an e_mail to = webmaster@telecomitalia.it. Thank = youwww.loquendo.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ------_=_NextPart_001_01C6106F.691EE866 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

Hi,

in = draft 09, 10.4.8=20 says that Media Type is mandatory in a RECORD method but the examples in = 10.6=20 (RECORD), 10.7 (STOP), and 10.8 (RECORD-COMPLETE) don't include this=20 header.

Regards,

Patrizio Bergallo,=20 Loquendo.

Gruppo=20 Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
CONFIDENTIALITY=20 NOTICE
This message and its attachments are addressed solely to the=20 persons
above and may contain confidential information. If you have=20 received
the message in error, be informed that any use of the = content=20 hereof
is prohibited. Please return it immediately to the sender and=20 delete
the message. Should you have any questions, please send an = e_mail=20 to
<mailto:webmaster@telecomitalia= .it>webmaster@telecomitalia.it.=20 Thank you
<http://www.loquendo.com>www.loque= ndo.com
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

------_=_NextPart_001_01C6106F.691EE866-- --===============1530131122== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc --===============1530131122==-- From speechsc-bounces@ietf.org Tue Jan 03 09:22:04 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etn36-0001bM-Rh; Tue, 03 Jan 2006 09:22:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etn36-0001aI-2S for speechsc@megatron.ietf.org; Tue, 03 Jan 2006 09:22:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28919 for ; Tue, 3 Jan 2006 09:20:50 -0500 (EST) Received: from maile.telecomitalia.it ([156.54.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Etn8M-0004d1-W7 for speechsc@ietf.org; Tue, 03 Jan 2006 09:27:32 -0500 Received: from ptpxch008ba020.idc.cww.telecomitalia.it ([156.54.240.51]) by maile.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 Jan 2006 15:21:43 +0100 Received: from PTPEVS106BA020.idc.cww.telecomitalia.it ([156.54.241.224]) by ptpxch008ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 Jan 2006 15:21:52 +0100 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.326 Content-Class: urn:content-classes:message Importance: normal Priority: normal MIME-Version: 1.0 Subject: [Speechsc] Accept and Accept-charset generic headers Date: Tue, 3 Jan 2006 15:19:40 +0100 Message-ID: <6B0BEC95E14FFF43822F1E730EF5C25662461C@PTPEVS106BA020.idc.cww.telecomitalia.it> Thread-Topic: [Speechsc] Accept and Accept-charset generic headers thread-index: AcYQcLvfq+WFdNUnRe6Fd7IkI/FhNA== From: "Bergallo Patrizio" To: X-OriginalArrivalTime: 03 Jan 2006 14:21:52.0391 (UTC) FILETIME=[0AB96970:01C61071] X-Spam-Score: 0.8 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1691948191==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============1691948191== Content-Transfer-Encoding: 7bit Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61071.0292F71B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C61071.0292F71B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 in draft 09, in 6.2 (pag. 29) generic header list doesn't include accept-charset header. Moreover, in 15 - ABNF Normative Definition (pag. 176), generic header list doesn't include both accept and accept-charset headers. =20 Regards, Patrizio Bergallo, Loquendo. Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons = above and may contain confidential information. If you have received the = message in error, be informed that any use of the content hereof is = prohibited. Please return it immediately to the sender and delete the = message. Should you have any questions, please send an e_mail to = webmaster@telecomitalia.it. Thank = youwww.loquendo.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ------_=_NextPart_001_01C61071.0292F71B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

Hi,

in = draft 09, in 6.2=20 (pag. 29) generic header list doesn't include accept-charset=20 header.

Moreover, in 15 -=20 ABNF Normative Definition (pag. 176), generic header list doesn't = include both=20 accept and accept-charset headers.

Regards,

Patrizio Bergallo,=20 Loquendo.

------_=_NextPart_001_01C61071.0292F71B-- --===============1691948191== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc --===============1691948191==-- From speechsc-bounces@ietf.org Tue Jan 03 19:16:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtwKZ-0006jQ-PM; Tue, 03 Jan 2006 19:16:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtwKW-0006jI-Qq for speechsc@megatron.ietf.org; Tue, 03 Jan 2006 19:16:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10087 for ; Tue, 3 Jan 2006 19:15:25 -0500 (EST) Received: from wproxy.gmail.com ([64.233.184.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtwPr-0007Hy-L6 for speechsc@ietf.org; Tue, 03 Jan 2006 19:22:14 -0500 Received: by wproxy.gmail.com with SMTP id i27so1747304wra for ; Tue, 03 Jan 2006 16:16:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=XTivv3L0ZYCoPIPdg5+s89tAocjwBb9/7IzYhZ27duolJfk4NgAHFVBe648X+JPZES3WbHo6nyzGI2ZvVZNL0hSmcvzjA7GPzH2+rOqkr9Ac8Uhqx7WyUSC+tCIq4XGn3fPPrx1j2m76uDnJyRptjz2T+yRYT6v8cCCUtgkp3DY= Received: by 10.65.177.14 with SMTP id e14mr4534588qbp; Tue, 03 Jan 2006 16:16:34 -0800 (PST) Received: by 10.65.150.18 with HTTP; Tue, 3 Jan 2006 16:16:34 -0800 (PST) Message-ID: Date: Tue, 3 Jan 2006 16:16:34 -0800 From: Tim Melanchuk To: speechsc@ietf.org In-Reply-To: MIME-Version: 1.0 References: X-Spam-Score: 0.5 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Subject: [Speechsc] Re: I-D ACTION:draft-melanchuk-speechsc-serverloc-00.txt X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0477369873==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org --===============0477369873== Content-Type: multipart/alternative; boundary="----=_Part_32319_15835922.1136333794276" ------=_Part_32319_15835922.1136333794276 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable the draft below is now available in the archives. we'd appreciate a little feedback on whether the work group feels that this approach is worthwhile. the draft discusses the currently defined mrcpv2 resources and a few other capabilities that may differ between servers but for which a client may choose to express a preference. these were chosen based on previous mail list discussion but we may have missed some. a couple of questions we have are: - what is the right set of capabilities? - is the proposed mrcpv2 tree appropriate or is a more generic approach possible? we chose "mrcpv2" since the goal is to route to a server that supports specific mrcpv2 protocol capabilities. - is hierarchical capabilities expressed as sub-features of each resource the right approach, where indication of the sub-feature (such as jump-size) implies that the server supports that time of resource (such as a speech synthesizer)? cheers, timm On 1/3/06, Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Locating Media Resource Control Protocol > Version 2 (MRCPv2) Servers > Author(s) : T. Melanchuk, C. Boulton > Filename : draft-melanchuk-speechsc-serverloc-00.txt > Pages : 17 > Date : 2006-1-3 > > This specification defines and registers a set of Media Feature Tags > for the Media Resource Control Protocol Version 2 (MRCPv2). Clients > and servers can use these tags in conjunction with the Session > Initiation Protocol (SIP) capabilities framework so that client > requests can be routed to the server best able to satisfy the clients > requirements. > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-melanchuk-speechsc-serverloc-00= .txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of th= e > message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-melanchuk-speechsc-serverloc-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-melanchuk-speechsc-serverloc-00.txt"= . > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > > > ------=_Part_32319_15835922.1136333794276 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable
the draft below is now available in the archives. we'd appreciate
a little feedback on whether the work group feels that this
approach is worthwhile. the draft discusses the currently defined mrcpv2 resources and a few other capabilities that may differ
between servers but for which a client may choose to express a
preference. these were chosen based on previous mail list
discussion but we may have missed some.

a couple of questions we have are:

- what is the right set of capabilities?
- is the proposed mrcpv2 tree appropriate or is
a more generic approach possible? we chose "mrcpv2" since =
the goal is to route to a server that supports specific mrcpv2
protocol capabilities.
- is hierarchical capabilities expressed as sub-features of each
resource the right approach, where indication of the sub-feature
(such as jump-size) implies that the server supports that
time of resource (such as a speech synthesizer)?

cheers,
timm

On 1/3/06, Internet-Drafts@ietf= .org <Internet-Draft= s@ietf.org > wrote:

A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.

        Title &nbs= p;         : Locating Media Resource Control Protocol
     = ;            &n= bsp;        Version 2 (MRCPv2) Servers
        Autho= r(s)       : T. Melanchuk, C. Boulton
&nbs= p;       Filename    = ;    : draft-melanchuk-speechsc-serverloc-00.txt
     =    Pages        &nbs= p; : 17
        Date =            : 2006-1-3

   This specification defines and registers a set= of Media Feature Tags
   for the Media Resource Control Proto= col Version 2 (MRCPv2).  Clients
   and servers can = use these tags in conjunction with the Session
   Initiation Protocol (SIP) capabilities framework so that c= lient
   requests can be routed to the server best able to sat= isfy the clients
   requirements.

A URL for this Intern= et-Draft is:
http://www.ietf.org/internet-drafts/draft-melanchuk-speechsc-serverloc-00.t= xt

To remove yourself from the I-D Announcement list, send a mes= sage to
i-d-announce-re= quest@ietf.org with the word unsubscribe in the body of the message.
You can also = visit https= ://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscr= iption settings.

Internet-Drafts are also available by anonymous FTP. Login with= the username
"anonymous" and a password of your e-mail addres= s. After logging in,
type "cd internet-drafts" and then
        "get draft-melanchuk-s= peechsc-serverloc-00.txt".

A list of Internet-Drafts directorie= s can be found in
http://www= .ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts ca= n also be obtained by e-mail.

Send a message to:
  &nbs= p;     mailse= rv@ietf.org.
In the body type:
        "FILE /internet-drafts= /draft-melanchuk-speechsc-serverloc-00.txt".

NOTE:   = The mail server at ietf.org can return the = document in
        MIME-encoded= form by using the "mpack" utility.  To use this
        feature, insert the com= mand "ENCODING mime" before the "FILE"
  &= nbsp;     command.  To decode the respon= se(s), you will need "munpack" or
    &nbs= p;   a MIME-compliant mail reader.  Different MIME= -compliant mail readers
        exhibit different behav= ior, especially when dealing with
      &n= bsp; "multipart" MIME messages (i.e. documents which have be= en split
        up into multipl= e messages), so check your local documentation on
        how to manipulate these= messages.

Below is the data which will enable a MIME compliant = mail reader
implementation to automatically retrieve the ASCII version o= f the
Internet-Draft.

_______________________________________________
I-D-Announce mai= ling list
I-D-Announce@ietf.org=
htt= ps://www1.ietf.org/mailman/listinfo/i-d-announce

------=_Part_32319_15835922.1136333794276-- --===============0477369873== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc --===============0477369873==-- From speechsc-bounces@ietf.org Wed Jan 04 06:02:44 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu6Pj-0006zh-Tj; Wed, 04 Jan 2006 06:02:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu6Pi-0006zQ-6A for speechsc@megatron.ietf.org; Wed, 04 Jan 2006 06:02:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13189 for ; Wed, 4 Jan 2006 06:01:24 -0500 (EST) Received: from fw01.db01.voxpilot.com ([212.17.54.82] helo=mail.voxpilot.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eu6V4-0002se-TD for speechsc@ietf.org; Wed, 04 Jan 2006 06:08:18 -0500 Received: from daburkewxp (unknown [10.0.0.102]) by mail.voxpilot.com (Postfix) with ESMTP id 97278214042; Wed, 4 Jan 2006 11:02:08 +0000 (GMT) Message-ID: <02f901c6111e$6ccaa9f0$0a01a8c0@db01.voxpilot.com> From: "Dave Burke" To: "Tim Melanchuk" , References: Subject: Re: [Speechsc] Re: I-D ACTION:draft-melanchuk-speechsc-serverloc-00.txt Date: Wed, 4 Jan 2006 11:02:59 -0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.5 (/) X-Scan-Signature: 562cdc9baa87554b29d950396a30cf75 Cc: X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0281685863==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============0281685863== Content-Type: multipart/alternative; boundary="----=_NextPart_000_02F6_01C6111E.6C8144E0" This is a multi-part message in MIME format. ------=_NextPart_000_02F6_01C6111E.6C8144E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Nice to see the capabilities/prefs suggestion turn into a concrete = proposal! Some of the feature tags I was thinking about when suggesting this are = based on bad interoperability experiences seen in practice. I would = offer the following feature tags are very important - second only to = identifying the media resource types: - mrcpv2.speechrecog.grammartypes - specifies the grammar types = supported - mrcpv2.speechrecog.sitagformat - specifies the semantic = interpretation tag format * - mrcpv2.speechrecog.recoresults - specifies format used for = recognition results (i.e. NLSML or EMMA) - mrcpv2.speechrecog.languages - specifies the languages supported = (actually this applies to multiple resource types) Other comments: 1. mrcpv2.speechrecog.grammars is not practical (a server is going to = have a very large cache!) 2. I think putting the version number in the feature tag may not turn = out prudent (will MRCPv2.2 / v3 use mrcpv2 feature tags?) 3. I like the hierarchical structure suggested in feature tags (*) For historical reasons, the application/srgs and = application/srgs+xml MIME types do not imply the tag-format. Today, = there is one SI standard in development (W3C SISR - Candidate Rec = available soon) and at least two well known proprietary SI formats. Real = speech grammars need SI and, IMO, it's easily the biggest problem = affecting true VoiceXML application portability today.=20 Dave ----- Original Message -----=20 From: Tim Melanchuk=20 To: speechsc@ietf.org=20 Sent: Wednesday, January 04, 2006 12:16 AM Subject: [Speechsc] Re: I-D = ACTION:draft-melanchuk-speechsc-serverloc-00.txt the draft below is now available in the archives. we'd appreciate a little feedback on whether the work group feels that this=20 approach is worthwhile. the draft discusses the currently defined =20 mrcpv2 resources and a few other capabilities that may differ between servers but for which a client may choose to express a preference. these were chosen based on previous mail list discussion but we may have missed some. a couple of questions we have are: - what is the right set of capabilities? - is the proposed mrcpv2 tree appropriate or is=20 a more generic approach possible? we chose "mrcpv2" since=20 the goal is to route to a server that supports specific mrcpv2 protocol capabilities. - is hierarchical capabilities expressed as sub-features of each resource the right approach, where indication of the sub-feature (such as jump-size) implies that the server supports that time of resource (such as a speech synthesizer)? cheers, timm On 1/3/06, Internet-Drafts@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts = directories.=20 Title : Locating Media Resource Control Protocol Version 2 (MRCPv2) Servers Author(s) : T. Melanchuk, C. Boulton Filename : draft-melanchuk-speechsc-serverloc-00.txt Pages : 17 Date : 2006-1-3 This specification defines and registers a set of Media Feature = Tags for the Media Resource Control Protocol Version 2 (MRCPv2). = Clients and servers can use these tags in conjunction with the Session=20 Initiation Protocol (SIP) capabilities framework so that client requests can be routed to the server best able to satisfy the = clients requirements. A URL for this Internet-Draft is: = http://www.ietf.org/internet-drafts/draft-melanchuk-speechsc-serverloc-00= .txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body = of the message. You can also visit = https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings.=20 Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-melanchuk-speechsc-serverloc-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE = /internet-drafts/draft-melanchuk-speechsc-serverloc-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this = feature, insert the command "ENCODING mime" before the = "FILE" command. To decode the response(s), you will need "munpack" = or a MIME-compliant mail reader. Different MIME-compliant mail = readers=20 exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been = split up into multiple messages), so check your local = documentation on=20 how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce=20 -------------------------------------------------------------------------= ----- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc ------=_NextPart_000_02F6_01C6111E.6C8144E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Nice to see the capabilities/prefs = suggestion turn=20 into a concrete proposal!

Some of the feature tags I was = thinking about=20 when suggesting this are based on bad = interoperability experiences seen in practice. I would offer the = following=20 feature tags are very important - second only to identifying = the media=20 resource types:

-=20 mrcpv2.speechrecog.grammartypes - specifies the grammar types=20 supported

- = mrcpv2.speechrecog.sitagformat=20 - specifies the semantic interpretation tag format *

- = mrcpv2.speechrecog.recoresults=20 - specifies format used for recognition results (i.e. NLSML or=20 EMMA)

- = mrcpv2.speechrecog.languages -=20 specifies the languages supported (actually this applies to multiple = resource=20 types)

Other comments:

1. mrcpv2.speechrecog.grammars is = not=20 practical (a server is going to have a very large cache!)

2. I think putting the version = number in the=20 feature tag may not turn out prudent (will MRCPv2.2 / v3 use mrcpv2 = feature=20 tags?)

3. I like the hierarchical = structure=20 suggested in feature tags

(*) For historical reasons, the = application/srgs=20 and application/srgs+xml MIME types do not imply the tag-format. = Today,=20 there is one SI standard in development (W3C SISR - Candidate Rec = available=20 soon) and at least two well known proprietary SI formats. = Real speech grammars need SI and, IMO, it's = easily the=20 biggest problem affecting true VoiceXML application portability today.=20

Dave

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

From:=20 Tim=20 Melanchuk

To: speechsc@ietf.org

Sent: Wednesday, January 04, = 2006 12:16=20 AM

Subject: [Speechsc] Re: I-D=20 ACTION:draft-melanchuk-speechsc-serverloc-00.txt

the draft below is now available in the archives. = we'd=20 appreciate
a little feedback on whether the work group feels that = this=20
approach is worthwhile. the draft discusses the currently = defined =20
mrcpv2 resources and a few other capabilities that may = differ
between=20 servers but for which a client may choose to express a
preference. = these=20 were chosen based on previous mail list
discussion but we may have = missed=20 some.

a couple of questions we have are:

- what is the = right set=20 of capabilities?
- is the proposed mrcpv2 tree appropriate or is =
=20 a more generic approach possible? we chose "mrcpv2" since
= the goal=20 is to route to a server that supports specific mrcpv2
= protocol=20 capabilities.
- is hierarchical capabilities expressed as = sub-features of=20 each
resource the right approach, where indication of the=20 sub-feature
(such as jump-size) implies that the server = supports=20 that
time of resource (such as a speech=20 synthesizer)?

cheers,
timm

On 1/3/06, Internet-Drafts@ietf.org= <Internet-Drafts@ietf.org = >=20 wrote:

A=20 New Internet-Draft is available from the on-line Internet-Drafts=20 directories.=20 =

        Title &n= bsp;        =20 : Locating Media Resource Control=20 = Protocol
          &= nbsp;           &n= bsp;   Version=20 2 (MRCPv2)=20 = Servers
        Author(s) = ;     =20 : T. Melanchuk, C.=20 = Boulton
        Filename =        :=20 = draft-melanchuk-speechsc-serverloc-00.txt
    &nbs= p;   Pages        =   =20 :=20 = 17
        Date  &nb= sp;         :=20 2006-1-3

   This specification defines and = registers a set=20 of Media Feature Tags
   for the Media Resource Control = Protocol Version 2 (MRCPv2).  Clients
   and = servers=20 can use these tags in conjunction with the Session
  =20 Initiation Protocol (SIP) capabilities framework so that=20 client
   requests can be routed to the server best = able to=20 satisfy the clients
   requirements.

A URL for = this=20 Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-melanchuk-speechs= c-serverloc-00.txt

To=20 remove yourself from the I-D Announcement list, send a message = to
i-d-announce-request@ietf.o= rg=20 with the word unsubscribe in the body of the message.
You can = also=20 visit https://www1= .ietf.org/mailman/listinfo/I-D-announce
to=20 change your subscription settings.

Internet-Drafts are = also=20 available by anonymous FTP. Login with the username
"anonymous" = and a=20 password of your e-mail address. After logging in,
type "cd=20 internet-drafts" and=20 then
        "get=20 draft-melanchuk-speechsc-serverloc-00.txt".

A list of = Internet-Drafts=20 directories can be found in
http://www.ietf.org/shadow.html<= /A>
or=20 ftp://ftp.ietf.org/iet= f/1shadow-sites.txt

Internet-Drafts=20 can also be obtained by e-mail.

Send a message=20 to:
        mailserv@ietf.org.
In the = body=20 type:
        "FILE=20 = /internet-drafts/draft-melanchuk-speechsc-serverloc-00.txt".

NOTE:=   =20 The mail server at ietf.org can = return the=20 document = in
        MIME-encoded=20 form by using the "mpack" utility.  To use this=20
        feature, insert = the=20 command "ENCODING mime" before the=20 = "FILE"
        command. &= nbsp;To=20 decode the response(s), you will need "munpack"=20 or
        a = MIME-compliant mail=20 reader.  Different MIME-compliant mail readers=20
        exhibit = different=20 behavior, especially when dealing=20 with
        "multipart" = MIME=20 messages (i.e. documents which have been=20 split
        up into = multiple=20 messages), so check your local documentation on=20
        how to = manipulate these=20 messages.

Below is the data which will enable a MIME = compliant=20 mail reader
implementation to automatically retrieve the ASCII = version of=20 = the
Internet-Draft.

_______________________________= ________________
I-D-Announce=20 mailing list
I-D-Announce@ietf.org
https://www1= .ietf.org/mailman/listinfo/i-d-announce=20

_______________________________________________
Speechsc = mailing=20 = list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speec= hsc
------=_NextPart_000_02F6_01C6111E.6C8144E0-- --===============0281685863== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc --===============0281685863==-- From speechsc-bounces@ietf.org Mon Jan 09 14:51:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew33c-0002nq-Og; Mon, 09 Jan 2006 14:51:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew33b-0002nl-VC for speechsc@megatron.ietf.org; Mon, 09 Jan 2006 14:51:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16796 for ; Mon, 9 Jan 2006 14:50:35 -0500 (EST) Received: from zproxy.gmail.com ([64.233.162.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew3A9-0001Jt-EQ for speechsc@ietf.org; Mon, 09 Jan 2006 14:58:42 -0500 Received: by zproxy.gmail.com with SMTP id j2so3435636nzf for ; Mon, 09 Jan 2006 11:51:53 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=mwFCFfg96JcX+ceM6ibTt/yCQ+HBtBilBrsnGwFT9cRQGW/B+9MXxezh27WBoGRxiDQiJUOF4IKUPnT37NFPgn96ih8Uyy6+Pj2Tl1n+R82Q0wrW/9IVcyOVlwJNfGp8JsEm3rDH9mnzdqykdHXgIM/cFvalujYCVRvMbhE0/y0= Received: by 10.65.119.13 with SMTP id w13mr2762299qbm; Mon, 09 Jan 2006 11:51:52 -0800 (PST) Received: by 10.65.150.18 with HTTP; Mon, 9 Jan 2006 11:51:52 -0800 (PST) Message-ID: Date: Mon, 9 Jan 2006 11:51:52 -0800 From: Tim Melanchuk To: Dave Burke Subject: Re: [Speechsc] Re: I-D ACTION:draft-melanchuk-speechsc-serverloc-00.txt In-Reply-To: <02f901c6111e$6ccaa9f0$0a01a8c0@db01.voxpilot.com> MIME-Version: 1.0 References: <02f901c6111e$6ccaa9f0$0a01a8c0@db01.voxpilot.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: speechsc@ietf.org, cboulton@ubiquitysoftware.com X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0988280827==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org --===============0988280827== Content-Type: multipart/alternative; boundary="----=_Part_110923_12798141.1136836312700" ------=_Part_110923_12798141.1136836312700 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable hi dave, thanks for your comments and suggestions. dave oran has suggested that "speechsc" may also be an appropriate prefix instead of a protocol specific prefix. it is starting to look like many of the tags are not protocol specific so i am considering switch to something like "speechsc" instead of "mrcpv2". comments on this proposal form the list would be apreciated. i'm not sure what to do with respect to grammars. there was considerable discussion on the list about pre-loaded grammars and how a client could either request, or know before hand that there would be no significant delay for a grammar. is this still an issue and is there an alternative solution? cheers, timm On 1/4/06, Dave Burke wrote: > > Nice to see the capabilities/prefs suggestion turn into a concrete > proposal! > > Some of the feature tags I was thinking about when suggesting this are > based on bad interoperability experiences seen in practice. I would offer > the following feature tags are very important - second only to identifyin= g > the media resource types: > - mrcpv2.speechrecog.grammartypes - specifies the grammar types > supported > - mrcpv2.speechrecog.sitagformat - specifies the semantic > interpretation tag format * > - mrcpv2.speechrecog.recoresults - specifies format used for > recognition results (i.e. NLSML or EMMA) > - mrcpv2.speechrecog.languages - specifies the languages supported > (actually this applies to multiple resource types) > > Other comments: > 1. mrcpv2.speechrecog.grammars is not practical (a server is going to > have a very large cache!) > 2. I think putting the version number in the feature tag may not turn ou= t > prudent (will MRCPv2.2 / v3 use mrcpv2 feature tags?) > 3. I like the hierarchical structure suggested in feature tags > > (*) For historical reasons, the application/srgs and application/srgs+xml > MIME types do not imply the tag-format. Today, there is one SI standard i= n > development (W3C SISR - Candidate Rec available soon) and at least two we= ll > known proprietary SI formats. Real speech grammars need SI and, IMO, it's > easily the biggest problem affecting true VoiceXML application portabilit= y > today. > > Dave > > ------=_Part_110923_12798141.1136836312700 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable hi dave,

thanks for your comments and suggestions.

dave oran has suggested that "speechsc" may also be an
appropriate prefix instead of a protocol specific prefix.
it is starting to look like many of the tags are not protocol
specific so i am considering switch to something like
"speechsc" instead of "mrcpv2".

comments on this proposal form the list would be apreciated.
i'm not sure what to do with respect to grammars. there
was considerable discussion on the list about pre-loaded
grammars and how a client could either request, or know before
hand that there would be no significant delay for a grammar.
is this still an issue and is there an alternative solution?

cheers,
timm

On 1/4/06, Dave Burke <d= avid.burke@voxpilot.com> wrote:

Nice to see the capabilities/prefs sug= gestion turn=20 into a concrete proposal!

Some of the feature tags I was th= inking about=20 when suggesting this are based on ba= d=20 interoperability experiences seen in practice. I would offer the following= =20 feature tags are very important - second only to identifying the = media=20 resource types:

    -=20 mrcpv2.speechrecog.grammartypes - specifies the grammar types=20 supported

    - mrcpv2.speechreco= g.sitagformat=20 - specifies the semantic interpretation tag format *

    - mrcpv2.speechreco= g.recoresults=20 - specifies format used for recognition results (i.e. NLSML or=20 EMMA)

    - mrcpv2.speechreco= g.languages -=20 specifies the languages supported (actually this applies to multiple resour= ce=20 types)

Other comments:

1. mrcpv2.speechrecog.grammars i= s not=20 practical (a server is going to have a very large cache!)

2. I think putting the version n= umber in the=20 feature tag may not turn out prudent (will MRCPv2.2 / v3 use mrcpv2 fe= ature=20 tags?)

3. I like the hierarchical struc= ture=20 suggested in feature tags

(*) For historical reasons, the applic= ation/srgs=20 and application/srgs+xml MIME types do not imply the tag-format. Today= ,=20 there is one SI standard in development (W3C SISR - Candidate Rec available= =20 soon) and at least two well known proprietary SI formats. = Real speech grammars need SI and, IMO, = ;it's easily the=20 biggest problem affecting true VoiceXML application portability today.=20

Dave

------=_Part_110923_12798141.1136836312700-- --===============0988280827== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc --===============0988280827==-- From speechsc-bounces@ietf.org Fri Jan 13 11:50:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExS8S-0004Nf-U0; Fri, 13 Jan 2006 11:50:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExS8R-0004Mf-5J for speechsc@megatron.ietf.org; Fri, 13 Jan 2006 11:50:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21289 for ; Fri, 13 Jan 2006 11:49:20 -0500 (EST) Received: from firey.dreamhost.com ([66.33.193.188] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExSFm-000341-7U for speechsc@ietf.org; Fri, 13 Jan 2006 11:58:18 -0500 Received: from larson-tech.com (c-67-168-246-94.hsd1.or.comcast.net [67.168.246.94]) by firey.dreamhost.com (Postfix) with ESMTP id EACF816E465 for ; Fri, 13 Jan 2006 08:50:51 -0800 (PST) Message-ID: <43C7DA41.9040702@larson-tech.com> Date: Fri, 13 Jan 2006 08:50:09 -0800 From: "James A. Larson" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: speechsc@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Subject: [Speechsc] The Semantic Interpretation for Speech Recognition language reaches W3C candidate recomendation stage X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1313014380==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============1313014380== Content-Type: multipart/alternative; boundary="------------010503040003040306020100" This is a multi-part message in MIME format. --------------010503040003040306020100 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The Semantic Interpretation for Speech Recognition language reaches W3C candidate recomendation stage Semantic Interpretation for Speech Recognition (SISR), a language used in conjunction with the Speech Recognition Grammar Specification (SRGS) to develop speech applications, has transitioned to "Proposed Recommendation" by the World Wide Web Consortium (W3C). SISR is a procedural language based on ECMAScript is used to process the results returned from a speech recognition system by performing a variety of tasks, including the following Normalize speech recognition results. Users may speak any of several equivalent spoken words which SISR instructions convert to a single textual representation. For example, the words "yes," "ja," "of course," "affirmative," and "sure" are all converted to the single text string "yes." This enables users to speak any of several alias terms without having to memorize the specific words and commands. Process complex utterances. SISR instructions might describe advanced natural language processing algorithms which extract the meaning from a textual phrase. For example, the spoken utterance "Hit him again" would be interpreted as "Hit John" based on previous statements indicating the user is talking about John. SISR enables developers to specify simple natural language processing instructions. Convert speech recognition results to a standard format. Information from a speech utterance can be converted into a structure appropriate for processing by application-specific algorithms. For example, if the application is a Java application, the speech recognition results can be converted to a Java structure. If the application is an XML application, the recognition results can be expressed as an XML structure. If spoken input is to be combined with input express in other modalities such as keyboard or pen, then results can be expressed as Extended Multimodal Annotation (EMMA) notation. The "Proposed Recommendation" stage of W3C's standardization process means that development of the specification is complete. The language now enters a testing phase in which implementations of the language are tested to verify that the specification can be implemented correctly. After this phase is completed, W3C members will vote to adopt SISR as a full W3C recommendation. The specification of SISR is available at http://www.w3.org/TR/semantic-interpretation/ James A. Larson Co-chair, W3C Voice Browser Working Group --------------010503040003040306020100 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit The Semantic Interpretation for Speech Recognition language reaches W3C candidate recomendation stage

Semantic Interpretation for Speech Recognition (SISR), a language used in conjunction with the Speech Recognition Grammar Specification (SRGS) to develop speech applications, has transitioned to “Proposed Recommendation” by the World Wide Web Consortium (W3C). SISR is a procedural language based on ECMAScript is used to process the results returned from a speech recognition system by performing a variety of tasks, including the following

Normalize speech recognition results. Users may speak any of several equivalent spoken words which SISR instructions convert to a single textual representation. For example, the words “yes,” “ja,” “of course,” “affirmative,” and “sure” are all converted to the single text string “yes.” This enables users to speak any of several alias terms without having to memorize the specific words and commands.

Process complex utterances. SISR instructions might describe advanced natural language processing algorithms which extract the meaning from a textual phrase. For example, the spoken utterance “Hit him again” would be interpreted as “Hit John” based on previous statements indicating the user is talking about John. SISR enables developers to specify simple natural language processing instructions.

Convert speech recognition results to a standard format. Information from a speech utterance can be converted into a structure appropriate for processing by application-specific algorithms. For example, if the application is a Java application, the speech recognition results can be converted to a Java structure. If the application is an XML application, the recognition results can be expressed as an XML structure. If spoken input is to be combined with input express in other modalities such as keyboard or pen, then results can be expressed as Extended Multimodal Annotation (EMMA) notation.

The “Proposed Recommendation” stage of W3C’s standardization process means that development of the specification is complete. The language now enters a testing phase in which implementations of the language are tested to verify that the specification can be implemented correctly. After this phase is completed, W3C members will vote to adopt SISR as a full W3C recommendation.

The specification of SISR is available at http://www.w3.org/TR/semantic-interpretation/

James A. Larson
Co-chair, W3C Voice Browser Working Group

--------------010503040003040306020100-- --===============1313014380== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc --===============1313014380==-- From speechsc-bounces@ietf.org Sun Jan 15 11:27:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyAjM-0006Jp-Tc; Sun, 15 Jan 2006 11:27:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyAjL-0006Jk-Lf for speechsc@megatron.ietf.org; Sun, 15 Jan 2006 11:27:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02564 for ; Sun, 15 Jan 2006 11:24:09 -0500 (EST) Received: from fw01.db01.voxpilot.com ([212.17.54.82] helo=mail.voxpilot.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExmTo-0006jM-78 for speechsc@ietf.org; Sat, 14 Jan 2006 09:34:08 -0500 Received: from daburkewxp (dsl-34-34.dsl.netsource.ie [213.79.34.34]) by mail.voxpilot.com (Postfix) with ESMTP id 0FEBB214046 for ; Sat, 14 Jan 2006 14:26:17 +0000 (GMT) Message-ID: <02fd01c61916$95923600$c38ee9d5@db01.voxpilot.com> From: "Dave Burke" To: Date: Sat, 14 Jan 2006 14:27:01 -0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.3 (+) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Speechsc] Clarify Final-Silence uses milliseconds resolution X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0857279936==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============0857279936== Content-Type: multipart/alternative; boundary="----=_NextPart_000_02FA_01C61916.95507210" This is a multi-part message in MIME format. ------=_NextPart_000_02FA_01C61916.95507210 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_02FA_01C61916.95507210 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

------=_NextPart_000_02FA_01C61916.95507210-- --===============0857279936== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc --===============0857279936==-- From speechsc-bounces@ietf.org Sun Jan 15 13:03:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyCC4-0006tv-HS; Sun, 15 Jan 2006 13:01:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyC9P-0004fE-5q for speechsc@megatron.ietf.org; Sun, 15 Jan 2006 12:58:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02900 for ; Sun, 15 Jan 2006 11:25:44 -0500 (EST) Received: from fw01.db01.voxpilot.com ([212.17.54.82] helo=mail.voxpilot.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExmTn-0006Oa-Dl for speechsc@ietf.org; Sat, 14 Jan 2006 09:34:08 -0500 Received: from daburkewxp (dsl-34-34.dsl.netsource.ie [213.79.34.34]) by mail.voxpilot.com (Postfix) with ESMTP id 7AEB7214042 for ; Sat, 14 Jan 2006 14:26:07 +0000 (GMT) Message-ID: <02f601c61916$8fe4f6c0$c38ee9d5@db01.voxpilot.com> From: "Dave Burke" To: Date: Sat, 14 Jan 2006 14:26:51 -0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.8 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Subject: [Speechsc] Speaker Verification (Section 11) review comments X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0958216306==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============0958216306== Content-Type: multipart/alternative; boundary="----=_NextPart_000_02F1_01C61916.8F600F50" This is a multi-part message in MIME format. ------=_NextPart_000_02F1_01C61916.8F600F50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, Had cause to review Section 11 of MRCPv2-09. Needs editorial attention - = please see below: Dave 1. Typos Respository-URI -> Repository-URI Voiceprint-Identity -> Voiceprint-Identifier 2. Error in examples According to the spec: The value of the Verification-Mode header MUST be one of either "train" = or "verify". ... yet none of the examples include said header (and one erroneously = places it in the VERIFY-FROM-BUFFER message - it is only meant to be = present in the START-SESSION message). 3. Not well defined how to specifiy shared resources: The current text for sharing sessions between a co-resident recogniser = or recorder and a speaker verification engine is restrictive and not = accurately specified. The key point is that the related resources are = related because they were allocated within the same SIP dialog and not = that they were allocated within the same (INVITE) message transaction. Suggest changing: It is possible for a speaker verification resource to share the same session with a recognizer resource or to operate in independently. In order to share the same session, the SDP/SIP INVITE message for the verification resource MUST also include the recognizer resource request to: It is possible for a speaker verification resource to share the same session with a recognizer resource or to operate independently. In order to share the same session, the verification and recognizer resources must be allocated from within the same SIP dialog. 4. not defined anywhere in the spec. Doesn't appear in = schema. Probably not necessary. 5. not defined anywhere in the spec. 6. Not clear for some elements if they're required or optional (section = 11.5.x) 7. Define values in section 11.5.6. Presumably "et-phoned-home" is in = context only if we publish on 04/01/xx? 8. Examples missing the xmlns in NLSML in VERIFICATION-COMPLETE message = bodies. Actually, shouldn't the http://www.ietf.org/xml/ns/mrcpv2 = namespace apply to all NLSML documents throughout the specification not = just those associated with verification? 9. What does the grammar attribute on mean in the context of = verification? 10. Many examples include in their NLSML. Presumably this = needs to be deleted (since the element is neither defined nor = specified)? ------=_NextPart_000_02F1_01C61916.8F600F50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

Had cause to review Section 11 of = MRCPv2-09. Needs=20 editorial attention - please see below:

Dave

1. Typos

Respository-URI -> = Repository-URI

Voiceprint-Identity ->=20 Voiceprint-Identifier

2. Error in examples

According to the spec:

The value of the Verification-Mode = header MUST be=20 one of either "train" or "verify".

... yet none of the examples include = said header=20 (and one erroneously places it in the VERIFY-FROM-BUFFER message - it is = only=20 meant to be present in the START-SESSION message).

3. Not well defined how to specifiy = shared=20 resources:

The current text for sharing = sessions between=20 a co-resident recogniser or recorder and a speaker verification engine = is=20 restrictive and not accurately specified. The key point is that the = related=20 resources are related because they were allocated within the same SIP = dialog and=20 not that they were allocated within the same (INVITE) message=20 transaction.

Suggest changing:

   It is possible for a = speaker=20 verification resource to share the same
   session with a=20 recognizer resource or to operate in independently.
   In = order to=20 share the same session, the SDP/SIP INVITE message for
   = the=20 verification resource MUST also include the recognizer = resource
  =20 request

to:

   It is possible for a = speaker=20 verification resource to share the same
   session with a=20 recognizer resource or to operate independently.
   In = order to=20 share the same session, the verification and recognizer

resources must be = allocated from=20 within the same SIP dialog.

4. <result-type> not defined = anywhere in the=20 spec. Doesn't appear in schema. Probably not necessary.

5. <num-frames> not defined = anywhere in the=20 spec.

6. Not clear for some elements if = they're required=20 or optional (section 11.5.x)

7. Define values in section 11.5.6. = Presumably=20 "et-phoned-home" is in context only if we publish on = 04/01/xx?

8. Examples missing the xmlns in NLSML = in=20 VERIFICATION-COMPLETE message bodies. Actually, shouldn't the http://www.ietf.org/xml/ns/mrc= pv2 namespace=20 apply to all NLSML documents throughout the specification not just those = associated with verification?

9. What does the grammar attribute on=20 <result> mean in the context of verification?

10. Many examples include = <extensions> in=20 their NLSML. Presumably this needs to be deleted (since the element is = neither=20 defined nor specified)?

------=_NextPart_000_02F1_01C61916.8F600F50-- --===============0958216306== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc --===============0958216306==-- From speechsc-bounces@ietf.org Sun Jan 15 13:12:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyCMI-0004Dt-3Q; Sun, 15 Jan 2006 13:12:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyCLE-0003Fk-1A for speechsc@megatron.ietf.org; Sun, 15 Jan 2006 13:11:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27064 for ; Sun, 15 Jan 2006 13:09:34 -0500 (EST) Received: from fw01.db01.voxpilot.com ([212.17.54.82] helo=mail.voxpilot.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyCSv-0003K3-Vq for speechsc@ietf.org; Sun, 15 Jan 2006 13:18:59 -0500 Received: from daburkewxp (dsl-34-34.dsl.netsource.ie [213.79.34.34]) by mail.voxpilot.com (Postfix) with ESMTP id 38309214041; Sun, 15 Jan 2006 18:10:41 +0000 (GMT) Message-ID: <045901c619ff$19a64600$c38ee9d5@db01.voxpilot.com> From: "Dave Burke" To: "Dave Burke" , References: <02f601c61916$8fe4f6c0$c38ee9d5@db01.voxpilot.com> Subject: Re: [Speechsc] Speaker Verification (Section 11) review comments -> additional comments Date: Sun, 15 Jan 2006 18:11:25 -0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.8 (/) X-Scan-Signature: 1c0c3d540ad9f95212b1c2a9a2cc2595 Cc: X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0384866298==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============0384866298== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0456_01C619FF.193CD5D0" This is a multi-part message in MIME format. ------=_NextPart_000_0456_01C619FF.193CD5D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Six more comments on Section 11: 11. Missing state machine diagram 12. In section 11.4.3, it says "...voiceprint identifier headers of the = VERIFY method". However, Voiceprint-Identifier is placed in = START-SESSION not VERIFY 13. The BNF is restricting the Voiceprint-Identifer to have only 3 = characters after the period. None of the examples follow this. Why the = restriction in length? Suggest: voiceprint-identifier =3D "Voiceprint-Identifier" ":" 1*VCHAR "." 1*VCHAR *[";" 1*VCHAR "." 1*VCHAR] CRLF 14. What kind of values does take when (a) training has been = performed or (b) for multi-verification (can more than one voice-print = be "accepted"?) 15. Minor inconsistency: Why does range from -1.0 = to 1.0 whereas confidence (for ASR) ranges from 0 to 1.0. Why not align = range with confidence range? 16. Editorial: Use voice-print or voiceprint but be consistent. ----- Original Message -----=20 From: Dave Burke=20 To: speechsc@ietf.org=20 Sent: Saturday, January 14, 2006 2:26 PM Subject: [Speechsc] Speaker Verification (Section 11) review comments Hello, Had cause to review Section 11 of MRCPv2-09. Needs editorial attention = - please see below: Dave 1. Typos Respository-URI -> Repository-URI Voiceprint-Identity -> Voiceprint-Identifier 2. Error in examples According to the spec: The value of the Verification-Mode header MUST be one of either = "train" or "verify". ... yet none of the examples include said header (and one erroneously = places it in the VERIFY-FROM-BUFFER message - it is only meant to be = present in the START-SESSION message). 3. Not well defined how to specifiy shared resources: The current text for sharing sessions between a co-resident recogniser = or recorder and a speaker verification engine is restrictive and not = accurately specified. The key point is that the related resources are = related because they were allocated within the same SIP dialog and not = that they were allocated within the same (INVITE) message transaction. Suggest changing: It is possible for a speaker verification resource to share the = same session with a recognizer resource or to operate in independently. In order to share the same session, the SDP/SIP INVITE message for the verification resource MUST also include the recognizer resource request to: It is possible for a speaker verification resource to share the = same session with a recognizer resource or to operate independently. In order to share the same session, the verification and recognizer resources must be allocated from within the same SIP dialog. 4. not defined anywhere in the spec. Doesn't appear in = schema. Probably not necessary. 5. not defined anywhere in the spec. 6. Not clear for some elements if they're required or optional = (section 11.5.x) 7. Define values in section 11.5.6. Presumably "et-phoned-home" is in = context only if we publish on 04/01/xx? 8. Examples missing the xmlns in NLSML in VERIFICATION-COMPLETE = message bodies. Actually, shouldn't the = http://www.ietf.org/xml/ns/mrcpv2 namespace apply to all NLSML documents = throughout the specification not just those associated with = verification? 9. What does the grammar attribute on mean in the context of = verification? 10. Many examples include in their NLSML. Presumably this = needs to be deleted (since the element is neither defined nor = specified)? -------------------------------------------------------------------------= ----- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc ------=_NextPart_000_0456_01C619FF.193CD5D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Six more comments on Section = 11:

11. Missing state machine = diagram

12. In section 11.4.3, it says = "...voiceprint=20 identifier headers of the VERIFY method". However, Voiceprint-Identifier = is=20 placed in START-SESSION not VERIFY

13. The BNF is restricting the = Voiceprint-Identifer=20 to have only 3 characters after the period. None of the examples follow = this.=20 Why the restriction in length? Suggest:

voiceprint-identifier = =3D =20 "Voiceprint-Identifier"=20 ":"
= &= nbsp; =20 1*VCHAR "."=20 1*VCHAR
&n= bsp; &nb= sp; =20 *[";" 1*VCHAR "." 1*VCHAR] CRLF

14. What kind of values does = <decision> take=20 when (a) training has been performed or (b) for multi-verification (can = more=20 than one voice-print be "accepted"?)

15. Minor inconsistency: Why does=20 <verification-score> range from -1.0 to 1.0 whereas confidence = (for ASR)=20 ranges from 0 to 1.0. Why not align <verification-score> range = with=20 confidence range?

16. Editorial: Use voice-print or = voiceprint but be=20 consistent.

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

From:=20 Dave=20 Burke

To: speechsc@ietf.org

Sent: Saturday, January 14, = 2006 2:26=20 PM

Subject: [Speechsc] Speaker = Verification=20 (Section 11) review comments

Hello,

Had cause to review Section 11 of = MRCPv2-09.=20 Needs editorial attention - please see below:

Dave

1. Typos

Respository-URI -> = Repository-URI

Voiceprint-Identity ->=20 Voiceprint-Identifier

2. Error in = examples

According to the spec:

The value of the Verification-Mode = header MUST be=20 one of either "train" or "verify".

... yet none of the examples include = said header=20 (and one erroneously places it in the VERIFY-FROM-BUFFER message - it = is only=20 meant to be present in the START-SESSION message).

3. Not well defined how to specifiy = shared=20 resources:

The current text for sharing = sessions=20 between a co-resident recogniser or recorder and a speaker = verification engine=20 is restrictive and not accurately specified. The key point is = that the=20 related resources are related because they were allocated within the = same SIP=20 dialog and not that they were allocated within the same (INVITE) = message=20 transaction.

Suggest changing:

   It is possible for a = speaker=20 verification resource to share the same
   session with a = recognizer resource or to operate in independently.
   In = order=20 to share the same session, the SDP/SIP INVITE message = for
   the=20 verification resource MUST also include the recognizer=20 resource
   request

to:

   It is possible for a = speaker=20 verification resource to share the same
   session with a = recognizer resource or to operate independently.
   In = order to=20 share the same session, the verification and recognizer

resources must be = allocated from=20 within the same SIP dialog.

4. <result-type> not defined = anywhere in=20 the spec. Doesn't appear in schema. Probably not = necessary.

5. <num-frames> not defined = anywhere in the=20 spec.

6. Not clear for some elements if = they're=20 required or optional (section 11.5.x)

7. Define values in section 11.5.6. = Presumably=20 "et-phoned-home" is in context only if we publish on = 04/01/xx?

8. Examples missing the xmlns in = NLSML in=20 VERIFICATION-COMPLETE message bodies. Actually, shouldn't the http://www.ietf.org/xml/ns/mrc= pv2 namespace=20 apply to all NLSML documents throughout the specification not just = those=20 associated with verification?

9. What does the grammar attribute on = <result> mean in the context of verification?

10. Many examples include = <extensions> in=20 their NLSML. Presumably this needs to be deleted (since the element is = neither=20 defined nor specified)?

The language in Section 4.2 is = misleading with=20 respect to the possible answerer options for the connection = attribute (see=20 RFC 4145). Suggest changing

   The server MAY respond = with a value=20 of
   "existing" if prefers to share an existing connection = or can=20 answer
   with a value of "new", in which case the client = MUST=20 initiate a new
   transport connection.

If the client specifies a = value of=20 "new", the server MUST respond

with a value of = "new".=20

If the client specifies a = value of=20 "existing", the server MAY respond

with a value of = "existing" if it=20 prefers to share an existing connection
or can = answer with=20 a value of "new", in which case the client MUST

initiate a new transport=20 connection.

Dave

------=_NextPart_000_0481_01C61A11.F7B3A6B0-- --===============0925288890== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc --===============0925288890==--