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
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
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
------=_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----- Original Message -----From:=20 Tim=20 MelanchukSent: Wednesday, January 04, = 2006 12:16=20 AMSubject: [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
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.=20Dave
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
------=_NextPart_000_0456_01C619FF.193CD5D0-- --===============0384866298== 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 --===============0384866298==-- From speechsc-bounces@ietf.org Sun Jan 15 15:26:01 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 1EyERt-0001GV-5H; Sun, 15 Jan 2006 15:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyERq-0001FI-T3 for speechsc@megatron.ietf.org; Sun, 15 Jan 2006 15:25:58 -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 PAA12805 for----- Original Message -----From:=20 Dave=20 BurkeSent: Saturday, January 14, = 2006 2:26=20 PMSubject: [Speechsc] Speaker = Verification=20 (Section 11) review commentsHello,Had cause to review Section 11 of = MRCPv2-09.=20 Needs editorial attention - please see below:Dave1. TyposRespository-URI -> = Repository-URIVoiceprint-Identity ->=20 Voiceprint-Identifier2. Error in = examplesAccording 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
requestto: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 recognizerresources 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)?
_______________________________________________
Speechsc = mailing=20 = list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speec= hsc