From speechsc-bounces@ietf.org Thu Feb 3 11:16:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10552 for ; Thu, 3 Feb 2005 11:16:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwjx0-0003MS-Oo for speechsc-web-archive@ietf.org; Thu, 03 Feb 2005 11:35:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwjXV-0000Ix-SG; Thu, 03 Feb 2005 11:09:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwjHN-00085T-8x for speechsc@megatron.ietf.org; Thu, 03 Feb 2005 10:52:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07393 for ; Thu, 3 Feb 2005 10:52:20 -0500 (EST) Received: from dns2.tilab.com ([163.162.42.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwjZu-0002UG-LS for speechsc@ietf.org; Thu, 03 Feb 2005 11:11:36 -0500 Received: from iowa2k01b.cselt.it ([163.162.242.202]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0IBC0026CE8LU5@dns2.cselt.it> for speechsc@ietf.org; Thu, 03 Feb 2005 16:41:09 +0100 (MET) Received: from EXC05A.cselt.it ([163.162.36.249]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Thu, 03 Feb 2005 16:51:26 +0100 Date: Thu, 03 Feb 2005 16:51:39 +0100 From: Baggia Paolo To: speechsc@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [mrcpv2] A few Loquendo's comments on draft-ietf-speechsc-mrcpv2-05.txt - part I thread-index: AcT4wSQ1iAE0K/anQtOhTM2LFzDJPgRRlGCw Content-Class: urn:content-classes:message X-OriginalArrivalTime: 03 Feb 2005 15:51:26.0312 (UTC) FILETIME=[37DC2E80:01C50A08] X-Spam-Score: 0.5 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 Content-Transfer-Encoding: quoted-printable Cc: Baggia Paolo Subject: [Speechsc] Loquendo's comments on draft-ietf-speechsc-mrcpv2-05.txt - part I 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af Content-Transfer-Encoding: quoted-printable Dear Sarvi/Eric/SpeechSC people, A few comments from Loquendo's people who carefully read the MRCPv2 05 draft. We hope they will be useful to improve the spec. Unfortunately this is only the first part. I'll manage to send a second part in a few day. Paolo ------------ LOQUENDO's COMMENTS -------------------- A. References I got a formal error in the references section=20 of "draft-ietf-speechsc-mrcpv2-05.txt". [7] World Wide Web Consortium, "Voice Extensible Markup Language=20 (VoiceXML) Version 2.0", W3C Candidate Recommendation, March=20 2004.=20 [10] World Wide Web Consortium, "Speech Synthesis Markup Language=20 (SSML) Version 1.0", W3C Candidate Recommendation, September=20 2004.=20 =20 [11] World Wide Web Consortium, "Speech Recognition Grammar=20 Specification Version 1.0", W3C Candidate Recommendation,=20 March 2004.=20 The dates are fine, but those spec are "W3C Recommendation" and no more "W3C Candidate Recommendation". This is not only a formal error, because many examples seems to be out-of-date and to refer to older versions of these specs. B. SSML examples with troubles - the Content-Type should be: application/ssml+xml and not application/synthesis+xml first time page 16, but other 14 times - the file extension should be .ssml and not .sml see page 41 and 42 - has some required attributes, such as "xml:lang" and "version". The 13 SSML examples need to comply to it. - is now

first time in page 16, but other 13 times - is now first time in page 16, but other 38 times - uses the "type" attribute, now is "interpret-as", but the SSML does not prescribe any specific values for it, so I'll suggest to avoid to use element in the examples. You can add the element if you like, or you can leave only 0345h, because this type is spec in VoiceXML 2.0 Appendix P ([7]). In page 16 and subsequent 24 times. - it should be spelled only one time in page 7=20 =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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Example1 - CURRENT version (pg. 16, from 42 to 50 many times, 137) =20 =20 =20 =20 You have 4 new messages.=20 The first is from Stephanie Williams=20 and arrived at =20 3:45pm.=20 =20 The subject is ski trip=20 =20 =20 - Example1 - CORRECT version ( should be eliminated replacing "0345p" with the original "3:45pm") =20 =20

=20 You have 4 new messages.=20 The first is from=20 Stephanie Williams and arrived at =20 0345p.=20 =20 The subject is ski trip=20

=20 =20 =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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Example2 - CURRENT version (present in pag. 51) =20 =20 =20 You have 4 new messages.=20 The first is from Stephanie Williams=20 and arrived at =20 3:45pm.=20 =20 The subject is =20 ski trip=20 =20 =20 =20 =20 - Example2 - CORRECT version=20 =20 =20

=20 You have 4 new messages.=20 The first is from =20 Stephanie Williams=20 and arrived at =20 0345p.=20 =20 The subject is =20 ski trip=20 =20 =20

=20 =20 =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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Example3 - CURRENT version (page 138) =20 =20 =20 =20 You have 4 new messages.=20 The first is from Stephanie Williams =20 and arrived at =20 3:45pm.=20 =20 The subject is ski trip=20 =20 =20 - Example3 - CORRECT version =20 =20

=20 You have 4 new messages.=20 The first is from =20 Stephanie Williams =20 and arrived at =20 0345p.=20 =20 The subject is ski trip=20

=20 =20 =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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Example4 - CURRENT version (page 138) =20 =20 =20 =20 Welcome to ABC corporation.=20 Who would you like Talk to.=20 =20 =20 - Example4 - CORRECT version =20 =20

=20 Welcome to ABC corporation.=20 Who would you like Talk to.=20

=20 =20 =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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I'll send you in a short time comments on the examples too. I'd appreciate if you can take advantage of the above mentioned small errors and to apply them in the next revision. Do you have an idea of when a new draft will be released? Would it be possible to acknowledge Loquendo at the end? This is not a strong point for us. Best regards, Paolo Baggia, 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=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 MailAdmin@tilab.com. Thank you =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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Fri Feb 4 17:50:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15622 for ; Fri, 4 Feb 2005 17:50:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxCak-0006wC-LW for speechsc-web-archive@ietf.org; Fri, 04 Feb 2005 18:10:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CxCEL-0001dH-Iv; Fri, 04 Feb 2005 17:47:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CxC7Z-0000Cv-5j for speechsc@megatron.ietf.org; Fri, 04 Feb 2005 17:40:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15000 for ; Fri, 4 Feb 2005 17:40:10 -0500 (EST) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxCQO-0006jL-Vt for speechsc@ietf.org; Fri, 04 Feb 2005 17:59:42 -0500 Received: from nhmail2.needham.brooktrout.com (nhmail2.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j14MbxBs012158 for ; Fri, 4 Feb 2005 17:38:00 -0500 (EST) Received: by nhmail2.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Feb 2005 17:34:19 -0500 Message-ID: From: Eric Burger To: speechsc@ietf.org Subject: RE: [Speechsc] VoiceXML weight attribute Date: Fri, 4 Feb 2005 17:34:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Any thoughts on this? > -----Original Message----- > From: Jeff Kusnitz [mailto:jk@us.ibm.com] > Sent: Thursday, January 20, 2005 4:31 PM > To: speechsc@ietf.org > Subject: [Speechsc] VoiceXML weight attribute > > > In the VoiceXML 2.0, the tag has been extended to include a > weight attribute to allow developers to bias grammars > (section 3.1.1.3). > The current DEFINE-GRAMMAR request doesn't have a "weight" > header though, > so it's not possible for a VoiceXML browser to do anything with the > 's weight attribute. Is this an oversight? Is it > too late to > add "weight" to the DEFINE-GRAMMAR request? > > Thanks, > Jeff > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Fri Feb 4 17:51:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15709 for ; Fri, 4 Feb 2005 17:51:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxCbZ-0006xp-RB for speechsc-web-archive@ietf.org; Fri, 04 Feb 2005 18:11:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CxCET-0001gC-W9; Fri, 04 Feb 2005 17:47:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CxCAM-000102-LD for speechsc@megatron.ietf.org; Fri, 04 Feb 2005 17:43:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15189 for ; Fri, 4 Feb 2005 17:43:03 -0500 (EST) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxCTD-0006ny-LZ for speechsc@ietf.org; Fri, 04 Feb 2005 18:02:36 -0500 Received: from nhmail2.needham.brooktrout.com (nhmail2.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j14McABr012160; Fri, 4 Feb 2005 17:38:10 -0500 (EST) Received: by nhmail2.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Feb 2005 17:34:29 -0500 Message-ID: From: Eric Burger To: David R Oran , Dan Burnett Subject: application/nlsml+xml (was RE: [Speechsc] IANA considerations for group feedback) Date: Fri, 4 Feb 2005 17:34:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: speechsc@ietf.org 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 I would suggest one and only one registration: application/nlsml+xml It is not an x-, as we are registering it. It should end with +xml, per RFC3023. RFC3023 also has to be referenced in the registration. Likewise, the schemas need to be registered per RFC3688. The registration needs to be a part of speechsc, for all of the convoluted reasons you alluded to :) > -----Original Message----- > From: David R Oran [mailto:oran@cisco.com] > Sent: Thursday, January 27, 2005 1:36 PM > To: Dan Burnett > Cc: ThomasGal@LumenVox.com; speechsc@ietf.org; 'Reifenrath, Klaus' > Subject: Re: [Speechsc] IANA considerations for group feedback > > > > On Jan 26, 2005, at 1:27 PM, Dan Burnett wrote: > > > I have some concerns with this. In one of my other > > recent responses I said I would be happen to include a > > registration for application/nlsml in the draft, but I > > would still prefer for that registration to occur > > independently since we don't own the NLSML draft. > > > > This ugly beast has raised its head many times. > > speechsc does not own NLSML but has adopted it (for > > reasons too convoluted to review in this email). > > There was never a MIME type registered for it. > > > > Eric, Dave, what do you think? Should we register > > application/nlsml as part of MRCP, register > > application/nlsml separately, or leave things as they > > are and refer to application/x-nlsml? > > > I think either will have some difficulties convincing the PWB, but I > think we could get either through. I'd hedge bets and put in words in > the IANA considerations asking them to register one OR THE OTHER at > their discretion. > > > -- dan > > p.s. now I know why Eric and Dave wanted someone else > > to volunteer :) > > > > > > --- Thomas Gal wrote: > > > >> Just to make sure it should no longer be x-nlsml if > >> we are standardizing it. > >> From IANA: > >> > >> A server MUST NOT offer unregistered or non-standard > >> capability names, > >> unless such names are prefixed with an "X". > >> > >> More specifically: > >> Begin with "x-": Private use. Begin with "e-": > >> Experimental use, registered > >> FCFS. All others: Expert review. > >> > >> -Tom [snip] _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Fri Feb 4 18:48:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21653 for ; Fri, 4 Feb 2005 18:48:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxDUi-0008EZ-Lf for speechsc-web-archive@ietf.org; Fri, 04 Feb 2005 19:08:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CxD4v-0001tF-EG; Fri, 04 Feb 2005 18:41:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CxD43-0001hD-2M for speechsc@megatron.ietf.org; Fri, 04 Feb 2005 18:40:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20665 for ; Fri, 4 Feb 2005 18:40:35 -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.33) id 1CxDMt-00083n-RC for speechsc@ietf.org; Fri, 04 Feb 2005 19:00:09 -0500 Received: from daburkew2k (dsl-34-34.dsl.netsource.ie [213.79.34.34]) by mail.voxpilot.com (Postfix) with ESMTP id 077AF21403C; Fri, 4 Feb 2005 23:40:12 +0000 (GMT) Message-ID: <000d01c50b12$de520040$0a01a8c0@db01.voxpilot.com> From: "Dave Burke" To: "Eric Burger" , References: Subject: Re: [Speechsc] VoiceXML weight attribute Date: Fri, 4 Feb 2005 23:40:08 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: Jeff Kusnitz 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Seems reasonable to me. The MRCP client workaround (inserting weights uniformly into VoiceXML inline grammars or forcing reflection of external grammar URIs to do same) is untenable. We already have a "Weight" header for voice enrollment... Editorial: Is the ABNF WEIGHT rule defined? It should allow for the VoiceXML 2.0 requirement of n, n., .n, n.n -- Dave ----- Original Message ----- From: "Eric Burger" To: Sent: Friday, February 04, 2005 10:34 PM Subject: RE: [Speechsc] VoiceXML weight attribute > Any thoughts on this? > > > -----Original Message----- > > From: Jeff Kusnitz [mailto:jk@us.ibm.com] > > Sent: Thursday, January 20, 2005 4:31 PM > > To: speechsc@ietf.org > > Subject: [Speechsc] VoiceXML weight attribute > > > > > > In the VoiceXML 2.0, the tag has been extended to include a > > weight attribute to allow developers to bias grammars > > (section 3.1.1.3). > > The current DEFINE-GRAMMAR request doesn't have a "weight" > > header though, > > so it's not possible for a VoiceXML browser to do anything with the > > 's weight attribute. Is this an oversight? Is it > > too late to > > add "weight" to the DEFINE-GRAMMAR request? > > > > Thanks, > > Jeff > > > > _______________________________________________ > > Speechsc mailing list > > Speechsc@ietf.org > > https://www1.ietf.org/mailman/listinfo/speechsc > > > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Tue Feb 8 17:41:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09430 for ; Tue, 8 Feb 2005 17:41:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyeN3-0005XS-QO for speechsc-web-archive@ietf.org; Tue, 08 Feb 2005 18:02:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CydgT-0004cr-Vt; Tue, 08 Feb 2005 17:18:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cycxw-0000Eh-A1 for speechsc@megatron.ietf.org; Tue, 08 Feb 2005 16:32:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26251 for ; Tue, 8 Feb 2005 16:32:08 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CydHY-0001GU-Ek for speechsc@ietf.org; Tue, 08 Feb 2005 16:52:30 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 08 Feb 2005 13:40:06 -0800 Received: from vtg-um-e2k1.sj21ad.cisco.com (vtg-um-e2k1.cisco.com [171.70.93.55]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j18LVVuC010255 for ; Tue, 8 Feb 2005 13:31:31 -0800 (PST) Received: from [10.32.131.112] ([10.32.131.112]) by vtg-um-e2k1.sj21ad.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 8 Feb 2005 13:31:26 -0800 Message-ID: <42092FAD.9040706@cisco.com> Date: Tue, 08 Feb 2005 13:31:25 -0800 From: Sarvi Shanmugham Organization: Cisco Systems Inc. User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "IETF SPEECHSC (E-mail)" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Feb 2005 21:31:26.0210 (UTC) FILETIME=[8B365620:01C50E25] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Subject: [Speechsc] Vendor specific header names - Question 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit We are thinking of using a hierarchical naming convention for this header field. com.cisco.headernameabc com.ibm.headernamexyz com.nuance.headernamexyz I know this naming convention is used in other places now, like in java. But can't seem to find any reference to this naming convention and how it is managed. Can anyone throw in some pointers as to where I should look. Thanks, Sarvi _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Feb 9 08:56:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03078 for ; Wed, 9 Feb 2005 08:56:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyseM-0007mW-PW for speechsc-web-archive@ietf.org; Wed, 09 Feb 2005 09:17:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CysHo-0006OU-HG; Wed, 09 Feb 2005 08:53:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cys9k-0004Z1-Jz for speechsc@megatron.ietf.org; Wed, 09 Feb 2005 08:45:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01858 for ; Wed, 9 Feb 2005 08:45:23 -0500 (EST) Received: from web14122.mail.yahoo.com ([66.163.171.113]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CysTY-0007Rh-2Y for speechsc@ietf.org; Wed, 09 Feb 2005 09:05:53 -0500 Received: (qmail 1210 invoked by uid 60001); 9 Feb 2005 13:45:21 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=pUE79WF7hX0l7wKHAS9M5btwklUzP1k6YvQdKtNjN7ZZHUi/c2a0p8PU++cvawGSKZmMspioN8ck/ZOzLfXVs9DNgx8wJ8D8gXznQeoHTlrW4EqYYmbupK/Bji7lqGD4DyNn3zO6dQXyRg6ko5o43WZxFkv+b76/mLzM2pAHg8k= ; Message-ID: <20050209134521.1208.qmail@web14122.mail.yahoo.com> Received: from [63.193.248.104] by web14122.mail.yahoo.com via HTTP; Wed, 09 Feb 2005 05:45:21 PST Date: Wed, 9 Feb 2005 05:45:21 -0800 (PST) From: Dan Burnett Subject: Re: [Speechsc] IANA considerations for group feedback To: Sarvi Shanmugham In-Reply-To: <41F16675.7050801@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 3.0 (+++) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: speechsc@ietf.org 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 3.0 (+++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 --- Sarvi Shanmugham wrote: ... > > Additional IANA registered value. > One other value that needs to be registered is the > vendor specific ID > for the recognizer context block > Refer "Recognizer Context Block" in section 9.5 and > the header > "Recognizer-Context-Block" for further details. > Actually, this doesn't need to be registered by us. According to the text, it is up to each vendor invidually to register a content type within the existing IANA MIME "vnd." tree. MRCPv2 places no additional requirements on these registry entries and itself defines no new entries (for this section of the draft). -- dan __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Feb 9 09:58:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07626 for ; Wed, 9 Feb 2005 09:58:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cytcg-0000no-0j for speechsc-web-archive@ietf.org; Wed, 09 Feb 2005 10:19:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CytHg-0005xF-FB; Wed, 09 Feb 2005 09:57:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CytDj-0004y0-Dj for speechsc@megatron.ietf.org; Wed, 09 Feb 2005 09:53:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07211 for ; Wed, 9 Feb 2005 09:53:33 -0500 (EST) Received: from web14125.mail.yahoo.com ([66.163.171.116]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CytXY-0000eP-4K for speechsc@ietf.org; Wed, 09 Feb 2005 10:14:04 -0500 Received: (qmail 46542 invoked by uid 60001); 9 Feb 2005 14:53:33 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=B+CkxCfwI9fDHgroQUDDmMZZBPwaCrVX4DEWNqclebAv7Um0F89LdM8JZ8Rq7bSTYUE6kdr7B/qjJzzhFOmrMPn7Q73D+abYIyxjgPMK3t7/y+Ra6ijUat8MFloCEOLixj5PHsGRGnIwRuw+ry8mzslZpvleI4ZmkiGRgm2zcHM= ; Message-ID: <20050209145333.46540.qmail@web14125.mail.yahoo.com> Received: from [63.193.248.104] by web14125.mail.yahoo.com via HTTP; Wed, 09 Feb 2005 06:53:33 PST Date: Wed, 9 Feb 2005 06:53:33 -0800 (PST) From: Dan Burnett Subject: RE: [Speechsc] IANA considerations for group feedback To: ThomasGal@LumenVox.com, "'Reifenrath, Klaus'" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 3.0 (+++) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Cc: speechsc@ietf.org 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 3.0 (+++) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 It appears that the syntax for the URLs in this scheme is intended to be identical to that for the "cid" scheme (see "Content-Id"). Is there any way we can make use of the existing "cid" scheme rather than defining our own? By the way, RFC2111 (reference 15) was obsoleted by RFC2392. --- Thomas Gal wrote: > I thought it was pretty well defined as being > lexically: > > "session:uri". Beyond that it's persistence is only > guaranteed for the > session, and can be overwritten by using the same > URI for another item. I > don't think there's really anything else to > define..... > > RFC 2396 ( and the obsoleted 1738) is about syntax > of URLs so they don't > really have bearing, unless you were referring to > that as the issue....as > for registration it seems to be pretty well covered > in 2717 and 2718. 2717 > explaining the registration process or dare I say > protocol, and 2718 > explaining the necessary rational for syntax of an > extension URI scheme. > > SO is the question the exact format of the URI > because the synatx in the > MRCPv2 document is more or less standard down to > some minor details? > > Otherwise the factors enumerated from the RFC for > appropriatness with some > comments: > > > 2.1 Syntactic compatibility > > New URL schemes should follow the same syntactic > conventions of > existing schemes when appropriate. > > -Again I know that the only real differences are in > quoted text and > some minor details at the bottom of the syntax tree > that are just > simplifications of > > 2.1.1 Motivations for syntactic compatibility > > Why should new URL schemes share as much of the > generic URI syntax > (that makes sense to share) as possible? > > -Basically the reality here is that MRCP is a part > of the grander > scheme of VXML and the web itself and URLs will > often be embedded in a > diverse set of other types of resources so this > justifies syntactic > similarity quite well. > > > 2.1.2 Improper use of "//" following ":" > > -We do have the authority directly following the > slashes as > specified. > > 2.1.3 Compatibility with relative URLs > > URL schemes should use the generic URL syntax if > they are intended > to > be used with relative URLs. > > - We are using the generic URL syntax more or less > > 2.2 Is the scheme well defined? > > -grammars markup etc in our context we've specified > in which > messages this scheme can be used > > 2.2.1 Clear mapping from other name spaces > > -Doesn't really appear to be an issue > > 2.2.2 URL schemes associated with network protocols > For such schemes, the specification should > completely describe how > URLs are > translated into protocol actions in sufficient > detail to make the > access of the network resource unambiguous. > > > -I think we've defined this pretty well > > 2.2.3 Definition of non-protocol URL schemes > > -This is a protocol URL > > 2.2.4 Definition of URL schemes not associated with > data resources > > -These URLs are specifically associated with data > in the cotext of > the protocol > > 2.2.5 Character encoding > > -Section 5 says MRCPv2 is ISO 10646/UTF-8, and the > MRCPv2 headers > are limited to US-ASCII. SO this may be a little bit > ambiguous and I would > propose that we limit this to US-ASCII as well as > these urls are for local > reference, and human readability is not important. > Really since these values > appear in headers of the protocol they are more or > less already definced to > be US-ASCII. > > 2.2.6 Definition of operations > > -Yes this is very clear. > > 2.3 Demonstrated utility > > -Obviously it's nice to have a way to referrence > intermediate > objects in this protocol. I don't think anyone will > dispute the utility. > > 2.4 Are there security considerations? > > -I would hope we don't need a security > considerations section for > the iana section :) > > I think we've pretty well covered it in the > document, it may just need to be > clarified or put into a second document. Certainly > the notion of a session > "scoped" uri could be helpful and applicable in > other areas and protocols as > well. > > - -Tom > > thomasgal@lumenvox.com > > > -----Original Message----- > > From: speechsc-bounces@ietf.org > > [mailto:speechsc-bounces@ietf.org] On Behalf Of > Dan Burnett > > Sent: Wednesday, January 26, 2005 10:18 AM > > To: Reifenrath, Klaus > > Cc: speechsc@ietf.org > > Subject: RE: [Speechsc] IANA considerations for > group feedback > > > > This is a good point. Unfortunately, I don't > think we > > defined this scheme sufficiently for me to write > such > > registration. Suggestions, anyone? > > > > -- dan > > > > --- "Reifenrath, Klaus" > > wrote: > > > > > > > > The URI scheme "session" requires IANA > registration (see > > > RFC2396,RFC1738). > > > > > > Klaus > > > -----Original Message----- > > > From: Reifenrath, Klaus > > > [mailto:Klaus.Reifenrath@Scansoft.com] > > > Sent: Montag, 24. Januar 2005 13:21 > > > To: 'Dan Burnett' > > > Cc: speechsc@ietf.org > > > Subject: RE: [Speechsc] IANA considerations for > group feedback > > > > > > > > > Hi Dan, > > > > > > will you also write the IANA considerations for > application/x-nlsml > > > and the > > > following SDP related entries? > > > media type: > > > - application/mrcpv2 > > > - control > > > NOTE: According to > draft-ietf-mmusic-sdp-new-23.txt > > (sections 8.2.1) > > > the media type "control" is deprecated! > > > attribute field names: > > > - resource > > > - channel > === message truncated === > ATTACHMENT part 2 application/x-pkcs7-signature name=smime.p7s __________________________________ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Feb 9 10:08:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08367 for ; Wed, 9 Feb 2005 10:08:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CytmH-00012X-H2 for speechsc-web-archive@ietf.org; Wed, 09 Feb 2005 10:29:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CytMm-0007oN-Pq; Wed, 09 Feb 2005 10:02:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CytJJ-0006Ed-Be for speechsc@megatron.ietf.org; Wed, 09 Feb 2005 09:59:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07683 for ; Wed, 9 Feb 2005 09:59:19 -0500 (EST) Received: from web14127.mail.yahoo.com ([66.163.171.118]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cytd7-0000oe-64 for speechsc@ietf.org; Wed, 09 Feb 2005 10:19:50 -0500 Received: (qmail 24788 invoked by uid 60001); 9 Feb 2005 14:59:18 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=gWZdg37R2EPDxCkWTCfmIp062mtkf1ziW2ZQ9VW6DL2te9RgAGs8KW63mcsNrMABQjuUkgiD9mCUcMZTqS0vPHm0rB1k2LwPxWM72PmChf1+3iRCl0hdpoMB3XGH1KIqUeQPlR8MLFZSRd3GK9iEGcpRK0xfssJuSyG8ocEc6Mc= ; Message-ID: <20050209145918.24786.qmail@web14127.mail.yahoo.com> Received: from [63.193.248.104] by web14127.mail.yahoo.com via HTTP; Wed, 09 Feb 2005 06:59:17 PST Date: Wed, 9 Feb 2005 06:59:17 -0800 (PST) From: Dan Burnett Subject: RE: [Speechsc] IANA considerations for group feedback To: "Reifenrath, Klaus" , "'ThomasGal@LumenVox.com'" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 3.0 (+++) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: speechsc@ietf.org 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 3.0 (+++) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e I don't think it should be up to us to create a general definition of "control" other than that originally defined. I'm sure not up to it. However, note that the wording is "SHOULD NOT" rather than "MUST NOT". By the way, did you have an answer to my other question, in which namespace(s) the SDP items you mention should be registered? -- dan --- "Reifenrath, Klaus" wrote: > Quoting from > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-23.txt: > Note: The media types "control" and "data" were > listed as valid in > the previous version of this specification [6], > however their > semantics were never fully specified and they are > not widely used. > These media types have been removed in this > specification, although > they still remain valid media type capabilities > for a SIP user agent > as defined in RFC 3840 [23]. If these media > types are considered > useful in future, a Standards Track RFC MUST be > produced to document > their use. Until that is done, applications > SHOULD NOT use these > types and SHOULD NOT declare support for them in > SIP capabilities > declarations (even though they exist in the > registry created by RFC > 3840). > > -----Original Message----- > From: Thomas Gal [mailto:ThomasGal@LumenVox.com] > Sent: Mittwoch, 26. Januar 2005 20:48 > To: 'Dan Burnett'; 'Reifenrath, Klaus' > Cc: speechsc@ietf.org > Subject: RE: [Speechsc] IANA considerations for > group feedback > > > inlinemmusic@ietf.org > > -Tom > > thomasgal@lumenvox.com > > > -----Original Message----- > > From: speechsc-bounces@ietf.org > > [mailto:speechsc-bounces@ietf.org] On Behalf Of > Dan Burnett > > Sent: Wednesday, January 26, 2005 10:15 AM > > To: Reifenrath, Klaus > > Cc: speechsc@ietf.org > > Subject: RE: [Speechsc] IANA considerations for > group feedback > > > > I agree that there needs to be an registration of > > application/x-nlsml (or, as an email from Tom > pointed out, > > application/nlsml). Technically it should be in a > separate > > RFC from MRCP, but I can include it in the draft > if there are > > no objections. > > > > I would certainly agree with not using > "application/nlsml" but something > similar to obviate confusion, even mrcp-nlsml or > something. > > > If "control" is already registered, do we need to > do it? In > > short, it's not clear to me in which > > namespace(s) the SDP items you mention should be > registered. > > Are they new namespaces for MRCP or are there > existing > > namespaces to which the items should be added? > > > > Isn't MRCPv2 "control"? I would guess control is too > ambiguous and probably > why it's being deprecated. > > -Tom > __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Feb 9 10:10:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08542 for ; Wed, 9 Feb 2005 10:10:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CytnX-00014m-5Y for speechsc-web-archive@ietf.org; Wed, 09 Feb 2005 10:30:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CytNM-0008Bq-GB; Wed, 09 Feb 2005 10:03:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CytLl-0007Jn-V1 for speechsc@megatron.ietf.org; Wed, 09 Feb 2005 10:01:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07843 for ; Wed, 9 Feb 2005 10:01:51 -0500 (EST) Received: from web14121.mail.yahoo.com ([66.163.171.112]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cytfa-0000sX-Qi for speechsc@ietf.org; Wed, 09 Feb 2005 10:22:23 -0500 Received: (qmail 83846 invoked by uid 60001); 9 Feb 2005 15:01:51 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=R3AyEYmpeJkXuS9bkmFsj+JxC6wQaXrPZUyrxU08WpYcFAiCCSDC8+QKmNLzr3R1SInvaQK6B2fa2pwQtismzuqF2Vl1o0lEe8rFmDDI0bW65TIKJhHszRQK4OASbmjGmfRyD7juDHVKlL4fzzloivF7n5H/n06jibqyZKu/EPg= ; Message-ID: <20050209150151.83844.qmail@web14121.mail.yahoo.com> Received: from [63.193.248.104] by web14121.mail.yahoo.com via HTTP; Wed, 09 Feb 2005 07:01:51 PST Date: Wed, 9 Feb 2005 07:01:51 -0800 (PST) From: Dan Burnett Subject: Re: [Speechsc] IANA considerations for group feedback To: David R Oran , Sarvi Shanmugham In-Reply-To: <90CF1A56-7092-11D9-A5E2-000A95C73842@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 3.0 (+++) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: "'ThomasGal@LumenVox.com'" , "Reifenrath, Klaus" , speechsc@ietf.org 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 3.0 (+++) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Just to be clear, there are no IANA considerations here, right? The "control" type exists and we do not need to request any sort of registration because of our documented use, right? --- David R Oran wrote: > > On Jan 27, 2005, at 12:57 PM, Sarvi Shanmugham > wrote: > > > Which is exactly what is being done here. > > > > So we are fine. > > > Yes, I agree this is fine. > > > Sarvi > > Reifenrath, Klaus wrote: > > Quoting from > > > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-23.txt: > > Note: The media types "control" and "data" were > listed as valid in > > the previous version of this specification [6], > however their > > semantics were never fully specified and they > are not widely used. > > These media types have been removed in this > specification, although > > they still remain valid media type capabilities > for a SIP user agent > > as defined in RFC 3840 [23]. If these media > types are considered > > useful in future, a Standards Track RFC MUST be > produced to document > > their use. Until that is done, applications > SHOULD NOT use these > > types and SHOULD NOT declare support for them > in SIP capabilities > > declarations (even though they exist in the > registry created by RFC > > 3840). > > > > -----Original Message----- > > From: Thomas Gal [ mailto:ThomasGal@LumenVox.com ] > > Sent: Mittwoch, 26. Januar 2005 20:48 > > To: 'Dan Burnett'; 'Reifenrath, Klaus' > > Cc: speechsc@ietf.org > > Subject: RE: [Speechsc] IANA considerations for > group feedback > > > > > > inlinemmusic@ietf.org > > > > -Tom > > > > thomasgal@lumenvox.com > > > > > > -----Original Message----- > > From: speechsc-bounces@ietf.org > > [ mailto:speechsc-bounces@ietf.org ] On Behalf Of > Dan Burnett > > Sent: Wednesday, January 26, 2005 10:15 AM > > To: Reifenrath, Klaus > > Cc: speechsc@ietf.org > > Subject: RE: [Speechsc] IANA considerations for > group feedback > > > > I agree that there needs to be an registration of > > application/x-nlsml (or, as an email from Tom > pointed out, > > application/nlsml). Technically it should be in a > separate > > RFC from MRCP, but I can include it in the draft > if there are > > no objections. > > > > > > I would certainly agree with not using > "application/nlsml" but > > something > > similar to obviate confusion, even mrcp-nlsml or > something. > > > > > > If "control" is already registered, do we need to > do it? In > > short, it's not clear to me in which > > namespace(s) the SDP items you mention should be > registered. > > Are they new namespaces for MRCP or are there > existing > > namespaces to which the items should be added? > > > > > > Isn't MRCPv2 "control"? I would guess control is > too ambiguous and > > probably > > why it's being deprecated. > > > > -Tom > > > > _______________________________________________ > > Speechsc mailing list > > Speechsc@ietf.org > > https://www1.ietf.org/mailman/listinfo/speechsc > > > > > > > > _______________________________________________ > > Speechsc mailing list > > Speechsc@ietf.org > > https://www1.ietf.org/mailman/listinfo/speechsc > > > David R. Oran > Cisco Fellow > Cisco Systems > 7 Ladyslipper Lane > Acton, MA 01720 USA > Tel: +1 978 264 2048 > Email: oran@cisco.com > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Feb 9 10:20:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09763 for ; Wed, 9 Feb 2005 10:20:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyty1-0001GF-Dw for speechsc-web-archive@ietf.org; Wed, 09 Feb 2005 10:41:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cytdi-0006Ee-IJ; Wed, 09 Feb 2005 10:20:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CytbC-0005S6-DV for speechsc@megatron.ietf.org; Wed, 09 Feb 2005 10:17:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09408 for ; Wed, 9 Feb 2005 10:17:48 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cytv1-0001Ca-N5 for speechsc@ietf.org; Wed, 09 Feb 2005 10:38:20 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 09 Feb 2005 07:17:47 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j19FHAYO018896; Wed, 9 Feb 2005 07:17:11 -0800 (PST) Received: from [10.32.245.155] (stealth-10-32-245-155.cisco.com [10.32.245.155]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j19FCQ9x014784; Wed, 9 Feb 2005 07:12:27 -0800 In-Reply-To: <20050209150151.83844.qmail@web14121.mail.yahoo.com> References: <20050209150151.83844.qmail@web14121.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [Speechsc] IANA considerations for group feedback Date: Wed, 9 Feb 2005 10:17:07 -0500 To: Dan Burnett X-Mailer: Apple Mail (2.619.2) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1107961948.122432"; x:"432200"; a:"rsa-sha1"; b:"nofws:3217"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"GSphQicONPSUqqNHN/2pJwzjOhM8MjxSsnTIU5tAe+9RI8pXcsFkDKJpctPcR00m+YzYbiBP" "zWdBj7LFPkhe4/OLgaYNARCfBe1wVvW0dK58AAdlS/5eNMWdvgrv8Fj7l0UxR4cWn4CeRb2h0e6" "15I/fL0zZAwOktbLwTURC1gc="; c:"From: David R Oran "; c:"Subject: Re: [Speechsc] IANA considerations for group feedback"; c:"Date: Wed, 9 Feb 2005 10:17:07 -0500" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Content-Transfer-Encoding: 7bit Cc: speechsc@ietf.org, Sarvi Shanmugham , "Reifenrath, Klaus" , "'ThomasGal@LumenVox.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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Content-Transfer-Encoding: 7bit On Feb 9, 2005, at 10:01 AM, Dan Burnett wrote: > Just to be clear, there are no IANA considerations > here, right? The "control" type exists and we do not > need to request any sort of registration because of > our documented use, right? > Yes, unless MMUSIC nukes it. Queries launched by Eric to see what's up... > --- David R Oran wrote: > >> >> On Jan 27, 2005, at 12:57 PM, Sarvi Shanmugham >> wrote: >> >>> Which is exactly what is being done here. >>> >>> So we are fine. >>> >> Yes, I agree this is fine. >> >>> Sarvi >>> Reifenrath, Klaus wrote: >>> Quoting from >>> >> > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-23.txt: >>> Note: The media types "control" and "data" were >> listed as valid in >>> the previous version of this specification [6], >> however their >>> semantics were never fully specified and they >> are not widely used. >>> These media types have been removed in this >> specification, although >>> they still remain valid media type capabilities >> for a SIP user agent >>> as defined in RFC 3840 [23]. If these media >> types are considered >>> useful in future, a Standards Track RFC MUST be >> produced to document >>> their use. Until that is done, applications >> SHOULD NOT use these >>> types and SHOULD NOT declare support for them >> in SIP capabilities >>> declarations (even though they exist in the >> registry created by RFC >>> 3840). >>> >>> -----Original Message----- >>> From: Thomas Gal [ mailto:ThomasGal@LumenVox.com ] >>> Sent: Mittwoch, 26. Januar 2005 20:48 >>> To: 'Dan Burnett'; 'Reifenrath, Klaus' >>> Cc: speechsc@ietf.org >>> Subject: RE: [Speechsc] IANA considerations for >> group feedback >>> >>> >>> inlinemmusic@ietf.org >>> >>> -Tom >>> >>> thomasgal@lumenvox.com >>> >>> >>> -----Original Message----- >>> From: speechsc-bounces@ietf.org >>> [ mailto:speechsc-bounces@ietf.org ] On Behalf Of >> Dan Burnett >>> Sent: Wednesday, January 26, 2005 10:15 AM >>> To: Reifenrath, Klaus >>> Cc: speechsc@ietf.org >>> Subject: RE: [Speechsc] IANA considerations for >> group feedback >>> >>> I agree that there needs to be an registration of >>> application/x-nlsml (or, as an email from Tom >> pointed out, >>> application/nlsml). Technically it should be in a >> separate >>> RFC from MRCP, but I can include it in the draft >> if there are >>> no objections. >>> >>> >>> I would certainly agree with not using >> "application/nlsml" but >>> something >>> similar to obviate confusion, even mrcp-nlsml or >> something. >>> >>> >>> If "control" is already registered, do we need to >> do it? In >>> short, it's not clear to me in which >>> namespace(s) the SDP items you mention should be >> registered. >>> Are they new namespaces for MRCP or are there >> existing >>> namespaces to which the items should be added? >>> >>> >>> Isn't MRCPv2 "control"? I would guess control is >> too ambiguous and >>> probably >>> why it's being deprecated. >>> >>> -Tom >>> >>> _______________________________________________ >>> Speechsc mailing list >>> Speechsc@ietf.org >>> https://www1.ietf.org/mailman/listinfo/speechsc >>> >>> >>> >>> _______________________________________________ >>> Speechsc mailing list >>> Speechsc@ietf.org >>> https://www1.ietf.org/mailman/listinfo/speechsc >>> >> David R. Oran >> Cisco Fellow >> Cisco Systems >> 7 Ladyslipper Lane >> Acton, MA 01720 USA >> Tel: +1 978 264 2048 >> Email: oran@cisco.com >> >> _______________________________________________ >> Speechsc mailing list >> Speechsc@ietf.org >> https://www1.ietf.org/mailman/listinfo/speechsc >> > > > > > __________________________________ > Do you Yahoo!? > Meet the all-new My Yahoo! - Try it today! > http://my.yahoo.com > > David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran@cisco.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Feb 9 10:37:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11611 for ; Wed, 9 Feb 2005 10:37:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyuDj-0001e7-55 for speechsc-web-archive@ietf.org; Wed, 09 Feb 2005 10:57:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cytt1-0002fx-8a; Wed, 09 Feb 2005 10:36:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cytra-0002RI-5W for speechsc@megatron.ietf.org; Wed, 09 Feb 2005 10:34:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11439 for ; Wed, 9 Feb 2005 10:34:44 -0500 (EST) Received: from web14127.mail.yahoo.com ([66.163.171.118]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CyuBM-0001bi-Ga for speechsc@ietf.org; Wed, 09 Feb 2005 10:55:16 -0500 Received: (qmail 31620 invoked by uid 60001); 9 Feb 2005 15:34:41 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=4cdeApx7BgGnIKETEIx/UdCzsNczpeUL4ohYGkBYQ4AYiQIDFTYTe+Hjy2RnRFI7im1XmD3jvP79p9hc2yH+Hx2EvEJEU9vxBO3++HlJldmesltBP2q3DyIGDrmtNI2qvi9Z2j6iRGOaoOc4gdrhVychBvbzH1ksfYXy4Izpfbo= ; Message-ID: <20050209153441.31618.qmail@web14127.mail.yahoo.com> Received: from [63.193.248.104] by web14127.mail.yahoo.com via HTTP; Wed, 09 Feb 2005 07:34:41 PST Date: Wed, 9 Feb 2005 07:34:41 -0800 (PST) From: Dan Burnett Subject: RE: [Speechsc] IANA considerations for group feedback To: ThomasGal@LumenVox.com, "'Reifenrath, Klaus'" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 3.0 (+++) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: speechsc@ietf.org 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 3.0 (+++) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Do we actually need to register application/mrcpv2 as a media type? It's not clear from RFC2327 that there is any particular restriction on what strings can go into the media format sub-field of an m= line. As you point out, Tom, MRCP is control info and not really a document format. -- dan --- Thomas Gal wrote: > Klaus, > > MRCPv2 is the "control" for a media server. It can > be > application/mrcpv2 or control/mrcpv2 but not both > correct? Currently we are > specifying it in the draft as application/mrcpv2, > which would obviate the > need for control no? Or are you proposing something > different? I certainly > think control/mrcpv2 makes more sense despite the > seeming tradition toward > using application/xxxx for everything. > > -Tom > > thomasgal@lumenvox.com > > > -----Original Message----- > > From: Sarvi Shanmugham [mailto:sarvi@cisco.com] > > Sent: Thursday, January 27, 2005 9:57 AM > > To: Reifenrath, Klaus > > Cc: Thomas Gal; 'Dan Burnett'; speechsc@ietf.org > > Subject: Re: [Speechsc] IANA considerations for > group feedback > > > > Which is exactly what is being done here. > > > > So we are fine. > > > > Sarvi > > Reifenrath, Klaus wrote: > > > > Quoting from > > > > > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-23.txt: > > Note: The media types "control" and "data" > were > > listed as valid in > > the previous version of this specification > [6], however their > > semantics were never fully specified and they > are > > not widely used. > > These media types have been removed in this > > specification, although > > they still remain valid media type > capabilities for > > a SIP user agent > > as defined in RFC 3840 [23]. If these media > types > > are considered > > useful in future, a Standards Track RFC MUST > be > > produced to document > > their use. Until that is done, applications > SHOULD > > NOT use these > > types and SHOULD NOT declare support for them > in SIP > > capabilities > > declarations (even though they exist in the > registry > > created by RFC > > 3840). > > > > -----Original Message----- > > From: Thomas Gal [mailto:ThomasGal@LumenVox.com] > > Sent: Mittwoch, 26. Januar 2005 20:48 > > To: 'Dan Burnett'; 'Reifenrath, Klaus' > > Cc: speechsc@ietf.org > > Subject: RE: [Speechsc] IANA considerations for > group feedback > > > > > > inlinemmusic@ietf.org > > > > -Tom > > > > thomasgal@lumenvox.com > > > > > > > > -----Original Message----- > > From: speechsc-bounces@ietf.org > > [mailto:speechsc-bounces@ietf.org] On Behalf Of > > Dan Burnett > > Sent: Wednesday, January 26, 2005 10:15 AM > > To: Reifenrath, Klaus > > Cc: speechsc@ietf.org > > Subject: RE: [Speechsc] IANA considerations for > > group feedback > > > > I agree that there needs to be an registration > of > > application/x-nlsml (or, as an email from Tom > > pointed out, > > application/nlsml). Technically it should be > > in a separate > > RFC from MRCP, but I can include it in the > > draft if there are > > no objections. > > > > > > > > > > I would certainly agree with not using > > "application/nlsml" but something > > similar to obviate confusion, even mrcp-nlsml or > something. > > > > > > > > If "control" is already registered, do we need > > to do it? In > > short, it's not clear to me in which > > namespace(s) the SDP items you mention should > > be registered. > > Are they new namespaces for MRCP or are there > existing > > namespaces to which the items should be added? > > > > > > > > > > Isn't MRCPv2 "control"? I would guess control is > too > > ambiguous and probably > > why it's being deprecated. > > > > -Tom > > > > _______________________________________________ > > Speechsc mailing list > > Speechsc@ietf.org > > https://www1.ietf.org/mailman/listinfo/speechsc > > > > > > > > > > > > ATTACHMENT part 2 application/x-pkcs7-signature name=smime.p7s __________________________________ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Feb 9 10:38:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11736 for ; Wed, 9 Feb 2005 10:38:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyuFA-0001gR-CH for speechsc-web-archive@ietf.org; Wed, 09 Feb 2005 10:59:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cytt1-0002g2-IL; Wed, 09 Feb 2005 10:36:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cytrg-0002RV-Qe for speechsc@megatron.ietf.org; Wed, 09 Feb 2005 10:34:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11449 for ; Wed, 9 Feb 2005 10:34:50 -0500 (EST) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyuBU-0001bv-Mo for speechsc@ietf.org; Wed, 09 Feb 2005 10:55:22 -0500 Received: from esealmw127.eemea.ericsson.se ([153.88.254.122]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j19FYIjd012018 for ; Wed, 9 Feb 2005 16:34:48 +0100 (MET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 9 Feb 2005 16:31:01 +0100 Received: from [147.214.237.66] ([147.214.237.66]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 9 Feb 2005 16:31:01 +0100 Message-ID: <420A2C99.70902@ericsson.com> Date: Wed, 09 Feb 2005 16:30:33 +0100 From: Magnus Westerlund User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: speechsc@ietf.org Subject: Re: [Speechsc] IANA considerations for group feedback References: <20050209150151.83844.qmail@web14121.mail.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Feb 2005 15:31:01.0396 (UTC) FILETIME=[5C3B5540:01C50EBC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit David R Oran wrote: > > On Feb 9, 2005, at 10:01 AM, Dan Burnett wrote: > >> Just to be clear, there are no IANA considerations >> here, right? The "control" type exists and we do not >> need to request any sort of registration because of >> our documented use, right? >> > Yes, unless MMUSIC nukes it. Queries launched by Eric to see what's up... > Consider yourself nuked. The following is present in the latest SDP-new (version 23), section 10: It is noted that "text" and "message" are valid media types for use with SDP, but that "control" and "data" are under-specified and deprecated. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Feb 9 12:29:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19703 for ; Wed, 9 Feb 2005 12:29:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyvyO-00047f-DL for speechsc-web-archive@ietf.org; Wed, 09 Feb 2005 12:49:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyvWo-0000st-U8; Wed, 09 Feb 2005 12:21:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyvSR-0007GQ-53 for speechsc@megatron.ietf.org; Wed, 09 Feb 2005 12:16:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17819 for ; Wed, 9 Feb 2005 12:16:52 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyvmF-0003gz-Mh for speechsc@ietf.org; Wed, 09 Feb 2005 12:37:26 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-3.cisco.com with ESMTP; 09 Feb 2005 10:27:46 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.88,190,1102291200"; d="scan'208,217"; a="224784179:sNHT30736936" Received: from vtg-um-e2k1.sj21ad.cisco.com (vtg-um-e2k1.cisco.com [171.70.93.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j19HFxYO005174; Wed, 9 Feb 2005 09:16:00 -0800 (PST) Received: from [10.32.131.112] ([10.32.131.112]) by vtg-um-e2k1.sj21ad.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 9 Feb 2005 09:15:53 -0800 Message-ID: <420A4548.9060800@cisco.com> Date: Wed, 09 Feb 2005 09:15:52 -0800 From: Sarvi Shanmugham Organization: Cisco Systems Inc. User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Burnett Subject: Re: [Speechsc] IANA considerations for group feedback References: <20050209134521.1208.qmail@web14122.mail.yahoo.com> In-Reply-To: <20050209134521.1208.qmail@web14122.mail.yahoo.com> X-OriginalArrivalTime: 09 Feb 2005 17:15:53.0497 (UTC) FILETIME=[029DC090:01C50ECB] X-Spam-Score: 1.0 (+) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: speechsc@ietf.org 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="===============1810339447==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 This is a multi-part message in MIME format. --===============1810339447== Content-Type: multipart/alternative; boundary="------------000800020502010308040504" This is a multi-part message in MIME format. --------------000800020502010308040504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Agreed. But I think this might need further clarification in the text. I will take care of that. thanks, Sarvi Dan Burnett wrote: >--- Sarvi Shanmugham wrote: >... > > >>Additional IANA registered value. >>One other value that needs to be registered is the >>vendor specific ID >>for the recognizer context block >>Refer "Recognizer Context Block" in section 9.5 and >>the header >>"Recognizer-Context-Block" for further details. >> >> >> > >Actually, this doesn't need to be registered by us. >According to the text, it is up to each vendor >invidually to register a content type within the >existing IANA MIME "vnd." tree. MRCPv2 places no >additional requirements on these registry entries and >itself defines no new entries (for this section of the >draft). > >-- dan > > > > >__________________________________ >Do you Yahoo!? >Yahoo! Mail - Helps protect you from nasty viruses. >http://promotions.yahoo.com/new_mail > > > --------------000800020502010308040504 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Agreed. But I think this might need further clarification in the text. I will take care of that.

thanks,
Sarvi
Dan Burnett wrote: 
--- Sarvi Shanmugham <sarvi@cisco.com> wrote:
...
  
Additional IANA registered value.
One other value that needs to be registered is the
vendor specific ID 
for the recognizer context block
Refer "Recognizer Context Block" in section 9.5 and
the header 
"Recognizer-Context-Block" for further details.

    

Actually, this doesn't need to be registered by us. 
According to the text, it is up to each vendor
invidually to register a content type within the
existing IANA MIME "vnd." tree.  MRCPv2 places no
additional requirements on these registry entries and
itself defines no new entries (for this section of the
draft).

-- dan



		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Helps protect you from nasty viruses. 
http://promotions.yahoo.com/new_mail

--------------000800020502010308040504-- --===============1810339447== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc --===============1810339447==-- From speechsc-bounces@ietf.org Wed Feb 9 12:30:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19866 for ; Wed, 9 Feb 2005 12:30:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyvzE-0004Aa-4Z for speechsc-web-archive@ietf.org; Wed, 09 Feb 2005 12:50:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cyvda-00041Z-69; Wed, 09 Feb 2005 12:28:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyvVd-0000Gi-Q4 for speechsc@megatron.ietf.org; Wed, 09 Feb 2005 12:20:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18103 for ; Wed, 9 Feb 2005 12:20:11 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyvpR-0003lG-Tb for speechsc@ietf.org; Wed, 09 Feb 2005 12:40:44 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-3.cisco.com with ESMTP; 09 Feb 2005 10:30:55 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.88,190,1102291200"; d="scan'208,217"; a="224786726:sNHT124429184" Received: from vtg-um-e2k1.sj21ad.cisco.com (vtg-um-e2k1.cisco.com [171.70.93.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j19HJ7YO006027; Wed, 9 Feb 2005 09:19:07 -0800 (PST) Received: from [10.32.131.112] ([10.32.131.112]) by vtg-um-e2k1.sj21ad.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 9 Feb 2005 09:19:07 -0800 Message-ID: <420A460A.8030802@cisco.com> Date: Wed, 09 Feb 2005 09:19:06 -0800 From: Sarvi Shanmugham Organization: Cisco Systems Inc. User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Burnett Subject: Re: [Speechsc] IANA considerations for group feedback References: <20050209145918.24786.qmail@web14127.mail.yahoo.com> In-Reply-To: <20050209145918.24786.qmail@web14127.mail.yahoo.com> X-OriginalArrivalTime: 09 Feb 2005 17:19:07.0094 (UTC) FILETIME=[76024F60:01C50ECB] X-Spam-Score: 0.5 (/) X-Scan-Signature: 8eeb555810cda1f2c5989480370dc4ca Cc: "'ThomasGal@LumenVox.com'" , speechsc@ietf.org, "Reifenrath, Klaus" 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="===============0758904935==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: fca7d4b87f391aa4d413f865ce6efe79 This is a multi-part message in MIME format. --===============0758904935== Content-Type: multipart/alternative; boundary="------------040709090409090608000205" This is a multi-part message in MIME format. --------------040709090409090608000205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit And they have clearly left the door open for a future standards track RFC to define the usage of "control", which is what we are doing here. Sarvi Dan Burnett wrote: >I don't think it should be up to us to create a >general definition of "control" other than that >originally defined. I'm sure not up to it. However, >note that the wording is "SHOULD NOT" rather than >"MUST NOT". > >By the way, did you have an answer to my other >question, in which namespace(s) the SDP items you >mention should be registered? > >-- dan > >--- "Reifenrath, Klaus" > wrote: > > > >>Quoting from >> >> >> >http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-23.txt: > > >> Note: The media types "control" and "data" were >>listed as valid in >> the previous version of this specification [6], >>however their >> semantics were never fully specified and they are >>not widely used. >> These media types have been removed in this >>specification, although >> they still remain valid media type capabilities >>for a SIP user agent >> as defined in RFC 3840 [23]. If these media >>types are considered >> useful in future, a Standards Track RFC MUST be >>produced to document >> their use. Until that is done, applications >>SHOULD NOT use these >> types and SHOULD NOT declare support for them in >>SIP capabilities >> declarations (even though they exist in the >>registry created by RFC >> 3840). >> >>-----Original Message----- >>From: Thomas Gal [mailto:ThomasGal@LumenVox.com] >>Sent: Mittwoch, 26. Januar 2005 20:48 >>To: 'Dan Burnett'; 'Reifenrath, Klaus' >>Cc: speechsc@ietf.org >>Subject: RE: [Speechsc] IANA considerations for >>group feedback >> >> >>inlinemmusic@ietf.org >> >>-Tom >> >>thomasgal@lumenvox.com >> >> >> >>>-----Original Message----- >>>From: speechsc-bounces@ietf.org >>>[mailto:speechsc-bounces@ietf.org] On Behalf Of >>> >>> >>Dan Burnett >> >> >>>Sent: Wednesday, January 26, 2005 10:15 AM >>>To: Reifenrath, Klaus >>>Cc: speechsc@ietf.org >>>Subject: RE: [Speechsc] IANA considerations for >>> >>> >>group feedback >> >> >>>I agree that there needs to be an registration of >>>application/x-nlsml (or, as an email from Tom >>> >>> >>pointed out, >> >> >>>application/nlsml). Technically it should be in a >>> >>> >>separate >> >> >>>RFC from MRCP, but I can include it in the draft >>> >>> >>if there are >> >> >>>no objections. >>> >>> >>> >>I would certainly agree with not using >>"application/nlsml" but something >>similar to obviate confusion, even mrcp-nlsml or >>something. >> >> >> >>>If "control" is already registered, do we need to >>> >>> >>do it? In >> >> >>>short, it's not clear to me in which >>>namespace(s) the SDP items you mention should be >>> >>> >>registered. >> >> >>>Are they new namespaces for MRCP or are there >>> >>> >>existing >> >> >>>namespaces to which the items should be added? >>> >>> >>> >>Isn't MRCPv2 "control"? I would guess control is too >>ambiguous and probably >>why it's being deprecated. >> >>-Tom >> >> >> > > > > > >__________________________________ >Do you Yahoo!? >Yahoo! Mail - You care about security. So do we. >http://promotions.yahoo.com/new_mail > >_______________________________________________ >Speechsc mailing list >Speechsc@ietf.org >https://www1.ietf.org/mailman/listinfo/speechsc > > > --------------040709090409090608000205 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit And they have clearly left the door open for a future standards track RFC to define the usage of "control", which is what we are doing here.


Sarvi
Dan Burnett wrote: 
I don't think it should be up to us to create a
general definition of "control" other than that
originally defined.  I'm sure not up to it.  However,
note that the wording is "SHOULD NOT" rather than
"MUST NOT".

By the way, did you have an answer to my other
question, in which namespace(s) the SDP items you
mention should be registered?

-- dan

--- "Reifenrath, Klaus"
<Klaus.Reifenrath@Scansoft.com> wrote:

  
Quoting from

    
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-23.txt:
  
   Note: The media types "control" and "data" were
listed as valid in
   the previous version of this specification [6],
however their
   semantics were never fully specified and they are
not widely used.
   These media types have been removed in this
specification, although
   they still remain valid media type capabilities
for a SIP user agent
   as defined in RFC 3840 [23].  If these media
types are considered
   useful in future, a Standards Track RFC MUST be
produced to document
   their use.  Until that is done, applications
SHOULD NOT use these
   types and SHOULD NOT declare support for them in
SIP capabilities
   declarations (even though they exist in the
registry created by RFC
   3840).

-----Original Message-----
From: Thomas Gal [mailto:ThomasGal@LumenVox.com]
Sent: Mittwoch, 26. Januar 2005 20:48
To: 'Dan Burnett'; 'Reifenrath, Klaus'
Cc: speechsc@ietf.org
Subject: RE: [Speechsc] IANA considerations for
group feedback


inlinemmusic@ietf.org

-Tom

thomasgal@lumenvox.com  

    
-----Original Message-----
From: speechsc-bounces@ietf.org 
[mailto:speechsc-bounces@ietf.org] On Behalf Of
      
Dan Burnett
    
Sent: Wednesday, January 26, 2005 10:15 AM
To: Reifenrath, Klaus
Cc: speechsc@ietf.org
Subject: RE: [Speechsc] IANA considerations for
      
group feedback
    
I agree that there needs to be an registration of 
application/x-nlsml (or, as an email from Tom
      
pointed out, 
    
application/nlsml).  Technically it should be in a
      
separate 
    
RFC from MRCP, but I can include it in the draft
      
if there are 
    
no objections.

      
I would certainly agree with not using
"application/nlsml" but something
similar to obviate confusion, even mrcp-nlsml or
something.

    
If "control" is already registered, do we need to
      
do it?  In 
    
short, it's not clear to me in which
namespace(s) the SDP items you mention should be
      
registered.  
    
Are they new namespaces for MRCP or are there
      
existing 
    
namespaces to which the items should be added?

      
Isn't MRCPv2 "control"? I would guess control is too
ambiguous and probably
why it's being deprecated.

-Tom

    



	
		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - You care about security. So do we. 
http://promotions.yahoo.com/new_mail

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc

--------------040709090409090608000205-- --===============0758904935== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc --===============0758904935==-- From speechsc-bounces@ietf.org Wed Feb 9 12:37:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20444 for ; Wed, 9 Feb 2005 12:37:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyw5v-0004Kh-Ek for speechsc-web-archive@ietf.org; Wed, 09 Feb 2005 12:57:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyvfE-0004s2-U0; Wed, 09 Feb 2005 12:30:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cyvb1-0003Ba-DA for speechsc@megatron.ietf.org; Wed, 09 Feb 2005 12:25:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18939 for ; Wed, 9 Feb 2005 12:25:44 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyvus-0003vU-1w for speechsc@ietf.org; Wed, 09 Feb 2005 12:46:18 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 09 Feb 2005 09:25:46 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from vtg-um-e2k1.sj21ad.cisco.com (vtg-um-e2k1.cisco.com [171.70.93.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j19HPDYO008936; Wed, 9 Feb 2005 09:25:14 -0800 (PST) Received: from [10.32.131.112] ([10.32.131.112]) by vtg-um-e2k1.sj21ad.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 9 Feb 2005 09:25:08 -0800 Message-ID: <420A4773.5090100@cisco.com> Date: Wed, 09 Feb 2005 09:25:07 -0800 From: Sarvi Shanmugham Organization: Cisco Systems Inc. User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: [Speechsc] IANA considerations for group feedback References: <20050209150151.83844.qmail@web14121.mail.yahoo.com> <420A2C99.70902@ericsson.com> In-Reply-To: <420A2C99.70902@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Feb 2005 17:25:08.0273 (UTC) FILETIME=[4D49DA10:01C50ECC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: speechsc@ietf.org 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit What does the following in draft-23 mean Note: The media types "control" and "data" were listed as valid in the previous version of this specification [6], however their semantics were never fully specified and they are not widely used. These media types have been removed in this specification, although they still remain valid media type capabilities for a SIP user agent as defined in RFC 3840 [23]. If these media types are considered useful in future, a Standards Track RFC MUST be produced to document their use. Until that is done, applications SHOULD NOT use these types and SHOULD NOT declare support for them in SIP capabilities declarations (even though they exist in the registry created by RFC 3840). Does it not allow the use of control a media type if its use is defined by a standards track RFC such as this. Do you have any suggestion as to how we go about addressing this issue. Thanks, Sarvi Magnus Westerlund wrote: > David R Oran wrote: > >> >> On Feb 9, 2005, at 10:01 AM, Dan Burnett wrote: >> >>> Just to be clear, there are no IANA considerations >>> here, right? The "control" type exists and we do not >>> need to request any sort of registration because of >>> our documented use, right? >>> >> Yes, unless MMUSIC nukes it. Queries launched by Eric to see what's >> up... >> > > Consider yourself nuked. The following is present in the latest > SDP-new (version 23), section 10: > > It is noted that "text" and > "message" are valid media types for use with SDP, but that "control" > and "data" are under-specified and deprecated. > > > Cheers > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Feb 9 12:47:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21354 for ; Wed, 9 Feb 2005 12:47:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CywG3-0004eF-Mu for speechsc-web-archive@ietf.org; Wed, 09 Feb 2005 13:08:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cyvs1-0000Nk-LX; Wed, 09 Feb 2005 12:43:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cyvpl-0008OE-6d for speechsc@megatron.ietf.org; Wed, 09 Feb 2005 12:41:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20868 for ; Wed, 9 Feb 2005 12:40:58 -0500 (EST) Received: from web14123.mail.yahoo.com ([66.163.171.114]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cyw9a-0004Tg-E2 for speechsc@ietf.org; Wed, 09 Feb 2005 13:01:32 -0500 Received: (qmail 63572 invoked by uid 60001); 9 Feb 2005 17:40:57 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=Ou751Q0Qhm7U3zsfKtwWEAgY4GsD+FpsxVEDSPkmiOqrS7EE5mL6a47a5CBeW9WrirgMEtpBC5EYO0QnjMplzH1e4BgqNtnVRe7nEVTi7dDUNzGy+j1UuZTLtgKX7+eo6qTBmXuPragl3ct9ow66RPD5R0EaCxd/JoPgjhw/sQ8= ; Message-ID: <20050209174057.63570.qmail@web14123.mail.yahoo.com> Received: from [63.193.248.104] by web14123.mail.yahoo.com via HTTP; Wed, 09 Feb 2005 09:40:57 PST Date: Wed, 9 Feb 2005 09:40:57 -0800 (PST) From: Dan Burnett Subject: Re: [Speechsc] IANA considerations for group feedback To: Sarvi Shanmugham In-Reply-To: <420A460A.8030802@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 3.0 (+++) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Cc: "'ThomasGal@LumenVox.com'" , speechsc@ietf.org, "Reifenrath, Klaus" 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 3.0 (+++) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Does that mean we need to register it? I would still assume *not*. --- Sarvi Shanmugham wrote: > And they have clearly left the door open for a > future standards track > RFC to define the usage of "control", which is what > we are doing here. > > > Sarvi > Dan Burnett wrote: > > >I don't think it should be up to us to create a > >general definition of "control" other than that > >originally defined. I'm sure not up to it. > However, > >note that the wording is "SHOULD NOT" rather than > >"MUST NOT". > > > >By the way, did you have an answer to my other > >question, in which namespace(s) the SDP items you > >mention should be registered? > > > >-- dan > > > >--- "Reifenrath, Klaus" > > wrote: > > > > > > > >>Quoting from > >> > >> > >> > >http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-23.txt: > > > > > >> Note: The media types "control" and "data" were > >>listed as valid in > >> the previous version of this specification [6], > >>however their > >> semantics were never fully specified and they > are > >>not widely used. > >> These media types have been removed in this > >>specification, although > >> they still remain valid media type capabilities > >>for a SIP user agent > >> as defined in RFC 3840 [23]. If these media > >>types are considered > >> useful in future, a Standards Track RFC MUST be > >>produced to document > >> their use. Until that is done, applications > >>SHOULD NOT use these > >> types and SHOULD NOT declare support for them > in > >>SIP capabilities > >> declarations (even though they exist in the > >>registry created by RFC > >> 3840). > >> > >>-----Original Message----- > >>From: Thomas Gal [mailto:ThomasGal@LumenVox.com] > >>Sent: Mittwoch, 26. Januar 2005 20:48 > >>To: 'Dan Burnett'; 'Reifenrath, Klaus' > >>Cc: speechsc@ietf.org > >>Subject: RE: [Speechsc] IANA considerations for > >>group feedback > >> > >> > >>inlinemmusic@ietf.org > >> > >>-Tom > >> > >>thomasgal@lumenvox.com > >> > >> > >> > >>>-----Original Message----- > >>>From: speechsc-bounces@ietf.org > >>>[mailto:speechsc-bounces@ietf.org] On Behalf Of > >>> > >>> > >>Dan Burnett > >> > >> > >>>Sent: Wednesday, January 26, 2005 10:15 AM > >>>To: Reifenrath, Klaus > >>>Cc: speechsc@ietf.org > >>>Subject: RE: [Speechsc] IANA considerations for > >>> > >>> > >>group feedback > >> > >> > >>>I agree that there needs to be an registration of > > >>>application/x-nlsml (or, as an email from Tom > >>> > >>> > >>pointed out, > >> > >> > >>>application/nlsml). Technically it should be in > a > >>> > >>> > >>separate > >> > >> > >>>RFC from MRCP, but I can include it in the draft > >>> > >>> > >>if there are > >> > >> > >>>no objections. > >>> > >>> > >>> > >>I would certainly agree with not using > >>"application/nlsml" but something > >>similar to obviate confusion, even mrcp-nlsml or > >>something. > >> > >> > >> > >>>If "control" is already registered, do we need to > >>> > >>> > >>do it? In > >> > >> > >>>short, it's not clear to me in which > >>>namespace(s) the SDP items you mention should be > >>> > >>> > >>registered. > >> > >> > >>>Are they new namespaces for MRCP or are there > >>> > >>> > >>existing > >> > >> > >>>namespaces to which the items should be added? > >>> > >>> > >>> > >>Isn't MRCPv2 "control"? I would guess control is > too > >>ambiguous and probably > >>why it's being deprecated. > >> > >>-Tom > >> > >> > >> > > > > > > > > > > > >__________________________________ > >Do you Yahoo!? > >Yahoo! Mail - You care about security. So do we. > >http://promotions.yahoo.com/new_mail > > > >_______________________________________________ > >Speechsc mailing list > >Speechsc@ietf.org > >https://www1.ietf.org/mailman/listinfo/speechsc > > > > > > > > __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Feb 9 13:09:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22940 for ; Wed, 9 Feb 2005 13:09:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CywbD-00058B-Bl for speechsc-web-archive@ietf.org; Wed, 09 Feb 2005 13:30:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CywGU-00086c-RX; Wed, 09 Feb 2005 13:08:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CywCS-0006n7-4z for speechsc@megatron.ietf.org; Wed, 09 Feb 2005 13:04:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22532 for ; Wed, 9 Feb 2005 13:04:25 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CywWI-0004yD-LY for speechsc@ietf.org; Wed, 09 Feb 2005 13:24:59 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 09 Feb 2005 10:07:16 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.88,190,1102320000"; d="scan'208,217"; a="160791303:sNHT38335896" Received: from vtg-um-e2k1.sj21ad.cisco.com (vtg-um-e2k1.cisco.com [171.70.93.55]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j19I3pwP009304; Wed, 9 Feb 2005 10:03:53 -0800 (PST) Received: from [10.32.131.112] ([10.32.131.112]) by vtg-um-e2k1.sj21ad.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 9 Feb 2005 10:03:48 -0800 Message-ID: <420A5080.2020101@cisco.com> Date: Wed, 09 Feb 2005 10:03:44 -0800 From: Sarvi Shanmugham Organization: Cisco Systems Inc. User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Burnett Subject: Re: [Speechsc] IANA considerations for group feedback References: <20050209174057.63570.qmail@web14123.mail.yahoo.com> In-Reply-To: <20050209174057.63570.qmail@web14123.mail.yahoo.com> X-OriginalArrivalTime: 09 Feb 2005 18:03:48.0218 (UTC) FILETIME=[B4155DA0:01C50ED1] X-Spam-Score: 1.0 (+) X-Scan-Signature: 7f3077fcbbd2d4a1504dfa044ebcf773 Cc: "'ThomasGal@LumenVox.com'" , speechsc@ietf.org, "Reifenrath, Klaus" 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="===============0683862165==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 1.0 (+) X-Scan-Signature: 645960076aa293effd9740db2f975dc3 This is a multi-part message in MIME format. --===============0683862165== Content-Type: multipart/alternative; boundary="------------040905040800060807090709" This is a multi-part message in MIME format. --------------040905040800060807090709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I would wait for Magnus's response. May be he has an alternate proposal to "control". Sarvi Dan Burnett wrote: >Does that mean we need to register it? I would still >assume *not*. > >--- Sarvi Shanmugham wrote: > > > >>And they have clearly left the door open for a >>future standards track >>RFC to define the usage of "control", which is what >>we are doing here. >> >> >>Sarvi >>Dan Burnett wrote: >> >> >> >>>I don't think it should be up to us to create a >>>general definition of "control" other than that >>>originally defined. I'm sure not up to it. >>> >>> >>However, >> >> >>>note that the wording is "SHOULD NOT" rather than >>>"MUST NOT". >>> >>>By the way, did you have an answer to my other >>>question, in which namespace(s) the SDP items you >>>mention should be registered? >>> >>>-- dan >>> >>>--- "Reifenrath, Klaus" >>> wrote: >>> >>> >>> >>> >>> >>>>Quoting from >>>> >>>> >>>> >>>> >>>> >>http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-23.txt: >> >> >>> >>> >>> >>> >>>> Note: The media types "control" and "data" were >>>>listed as valid in >>>> the previous version of this specification [6], >>>>however their >>>> semantics were never fully specified and they >>>> >>>> >>are >> >> >>>>not widely used. >>>> These media types have been removed in this >>>>specification, although >>>> they still remain valid media type capabilities >>>>for a SIP user agent >>>> as defined in RFC 3840 [23]. If these media >>>>types are considered >>>> useful in future, a Standards Track RFC MUST be >>>>produced to document >>>> their use. Until that is done, applications >>>>SHOULD NOT use these >>>> types and SHOULD NOT declare support for them >>>> >>>> >>in >> >> >>>>SIP capabilities >>>> declarations (even though they exist in the >>>>registry created by RFC >>>> 3840). >>>> >>>>-----Original Message----- >>>>From: Thomas Gal [mailto:ThomasGal@LumenVox.com] >>>>Sent: Mittwoch, 26. Januar 2005 20:48 >>>>To: 'Dan Burnett'; 'Reifenrath, Klaus' >>>>Cc: speechsc@ietf.org >>>>Subject: RE: [Speechsc] IANA considerations for >>>>group feedback >>>> >>>> >>>>inlinemmusic@ietf.org >>>> >>>>-Tom >>>> >>>>thomasgal@lumenvox.com >>>> >>>> >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: speechsc-bounces@ietf.org >>>>>[mailto:speechsc-bounces@ietf.org] On Behalf Of >>>>> >>>>> >>>>> >>>>> >>>>Dan Burnett >>>> >>>> >>>> >>>> >>>>>Sent: Wednesday, January 26, 2005 10:15 AM >>>>>To: Reifenrath, Klaus >>>>>Cc: speechsc@ietf.org >>>>>Subject: RE: [Speechsc] IANA considerations for >>>>> >>>>> >>>>> >>>>> >>>>group feedback >>>> >>>> >>>> >>>> >>>>>I agree that there needs to be an registration of >>>>> >>>>> >>>>>application/x-nlsml (or, as an email from Tom >>>>> >>>>> >>>>> >>>>> >>>>pointed out, >>>> >>>> >>>> >>>> >>>>>application/nlsml). Technically it should be in >>>>> >>>>> >>a >> >> >>>>> >>>>> >>>>> >>>>> >>>>separate >>>> >>>> >>>> >>>> >>>>>RFC from MRCP, but I can include it in the draft >>>>> >>>>> >>>>> >>>>> >>>>if there are >>>> >>>> >>>> >>>> >>>>>no objections. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>I would certainly agree with not using >>>>"application/nlsml" but something >>>>similar to obviate confusion, even mrcp-nlsml or >>>>something. >>>> >>>> >>>> >>>> >>>> >>>>>If "control" is already registered, do we need to >>>>> >>>>> >>>>> >>>>> >>>>do it? In >>>> >>>> >>>> >>>> >>>>>short, it's not clear to me in which >>>>>namespace(s) the SDP items you mention should be >>>>> >>>>> >>>>> >>>>> >>>>registered. >>>> >>>> >>>> >>>> >>>>>Are they new namespaces for MRCP or are there >>>>> >>>>> >>>>> >>>>> >>>>existing >>>> >>>> >>>> >>>> >>>>>namespaces to which the items should be added? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>Isn't MRCPv2 "control"? I would guess control is >>>> >>>> >>too >> >> >>>>ambiguous and probably >>>>why it's being deprecated. >>>> >>>>-Tom >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>>__________________________________ >>>Do you Yahoo!? >>>Yahoo! Mail - You care about security. So do we. >>>http://promotions.yahoo.com/new_mail >>> >>>_______________________________________________ >>>Speechsc mailing list >>>Speechsc@ietf.org >>>https://www1.ietf.org/mailman/listinfo/speechsc >>> >>> >>> >>> >>> >> >> > > > > >__________________________________ >Do you Yahoo!? >Yahoo! Mail - Helps protect you from nasty viruses. >http://promotions.yahoo.com/new_mail > > > --------------040905040800060807090709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I would wait for Magnus's response. May be he has an alternate proposal to "control".

Sarvi
Dan Burnett wrote: 
Does that mean we need to register it?  I would still
assume *not*.

--- Sarvi Shanmugham <sarvi@cisco.com> wrote:

  
And they have clearly left the door open for a
future standards track 
RFC to define the usage of "control", which is what
we are doing here.


Sarvi
Dan Burnett wrote:

    
I don't think it should be up to us to create a
general definition of "control" other than that
originally defined.  I'm sure not up to it. 
      
However,
    
note that the wording is "SHOULD NOT" rather than
"MUST NOT".

By the way, did you have an answer to my other
question, in which namespace(s) the SDP items you
mention should be registered?

-- dan

--- "Reifenrath, Klaus"
<Klaus.Reifenrath@Scansoft.com> wrote:

 

      
Quoting from

   

        
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-23.txt:
    
 

      
  Note: The media types "control" and "data" were
listed as valid in
  the previous version of this specification [6],
however their
  semantics were never fully specified and they
        
are
    
not widely used.
  These media types have been removed in this
specification, although
  they still remain valid media type capabilities
for a SIP user agent
  as defined in RFC 3840 [23].  If these media
types are considered
  useful in future, a Standards Track RFC MUST be
produced to document
  their use.  Until that is done, applications
SHOULD NOT use these
  types and SHOULD NOT declare support for them
        
in
    
SIP capabilities
  declarations (even though they exist in the
registry created by RFC
  3840).

-----Original Message-----
From: Thomas Gal [mailto:ThomasGal@LumenVox.com]
Sent: Mittwoch, 26. Januar 2005 20:48
To: 'Dan Burnett'; 'Reifenrath, Klaus'
Cc: speechsc@ietf.org
Subject: RE: [Speechsc] IANA considerations for
group feedback


inlinemmusic@ietf.org

-Tom

thomasgal@lumenvox.com  

   

        
-----Original Message-----
From: speechsc-bounces@ietf.org 
[mailto:speechsc-bounces@ietf.org] On Behalf Of
     

          
Dan Burnett
   

        
Sent: Wednesday, January 26, 2005 10:15 AM
To: Reifenrath, Klaus
Cc: speechsc@ietf.org
Subject: RE: [Speechsc] IANA considerations for
     

          
group feedback
   

        
I agree that there needs to be an registration of
          
application/x-nlsml (or, as an email from Tom
     

          
pointed out, 
   

        
application/nlsml).  Technically it should be in
          
a
    
     

          
separate 
   

        
RFC from MRCP, but I can include it in the draft
     

          
if there are 
   

        
no objections.

     

          
I would certainly agree with not using
"application/nlsml" but something
similar to obviate confusion, even mrcp-nlsml or
something.

   

        
If "control" is already registered, do we need to
     

          
do it?  In 
   

        
short, it's not clear to me in which
namespace(s) the SDP items you mention should be
     

          
registered.  
   

        
Are they new namespaces for MRCP or are there
     

          
existing 
   

        
namespaces to which the items should be added?

     

          
Isn't MRCPv2 "control"? I would guess control is
        
too
    
ambiguous and probably
why it's being deprecated.

-Tom

   

        

	
		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - You care about security. So do we. 
http://promotions.yahoo.com/new_mail

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc

 

      
    



		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Helps protect you from nasty viruses. 
http://promotions.yahoo.com/new_mail

--------------040905040800060807090709-- --===============0683862165== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc --===============0683862165==-- From speechsc-bounces@ietf.org Wed Feb 9 14:09:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28222 for ; Wed, 9 Feb 2005 14:09:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyxXB-0006jR-BI for speechsc-web-archive@ietf.org; Wed, 09 Feb 2005 14:29:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cyx3A-00041u-N2; Wed, 09 Feb 2005 13:58:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CywzU-0003BX-R4 for speechsc@megatron.ietf.org; Wed, 09 Feb 2005 13:55:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26764 for ; Wed, 9 Feb 2005 13:55:07 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyxJL-0006HY-8D for speechsc@ietf.org; Wed, 09 Feb 2005 14:15:40 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 09 Feb 2005 10:55:06 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from vtg-um-e2k1.sj21ad.cisco.com (vtg-um-e2k1.cisco.com [171.70.93.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j19IsXYO014526; Wed, 9 Feb 2005 10:54:33 -0800 (PST) Received: from [10.32.131.112] ([10.32.131.112]) by vtg-um-e2k1.sj21ad.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 9 Feb 2005 10:54:27 -0800 Message-ID: <420A5C63.20808@cisco.com> Date: Wed, 09 Feb 2005 10:54:27 -0800 From: Sarvi Shanmugham Organization: Cisco Systems Inc. User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: [Speechsc] IANA considerations for group feedback References: <20050209150151.83844.qmail@web14121.mail.yahoo.com> <420A2C99.70902@ericsson.com> In-Reply-To: <420A2C99.70902@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Feb 2005 18:54:27.0059 (UTC) FILETIME=[C75FB430:01C50ED8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: speechsc@ietf.org 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Should we be using either "message" or "application" perhaps for this use instead of "control" Sarvi Magnus Westerlund wrote: > David R Oran wrote: > >> >> On Feb 9, 2005, at 10:01 AM, Dan Burnett wrote: >> >>> Just to be clear, there are no IANA considerations >>> here, right? The "control" type exists and we do not >>> need to request any sort of registration because of >>> our documented use, right? >>> >> Yes, unless MMUSIC nukes it. Queries launched by Eric to see what's >> up... >> > > Consider yourself nuked. The following is present in the latest > SDP-new (version 23), section 10: > > It is noted that "text" and > "message" are valid media types for use with SDP, but that "control" > and "data" are under-specified and deprecated. > > > Cheers > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Feb 9 18:17:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12447 for ; Wed, 9 Feb 2005 18:17:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cz1PT-0003C4-OP for speechsc-web-archive@ietf.org; Wed, 09 Feb 2005 18:38:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cz14y-0000ZZ-Dz; Wed, 09 Feb 2005 18:17:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cz0zZ-0002qW-0q for speechsc@megatron.ietf.org; Wed, 09 Feb 2005 18:11:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11097 for ; Wed, 9 Feb 2005 18:11:26 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cz1JR-0002tz-Mi for speechsc@ietf.org; Wed, 09 Feb 2005 18:32:03 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 09 Feb 2005 15:14:28 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.88,191,1102320000"; d="scan'208"; a="160843195:sNHT23752888" Received: from vtg-um-e2k1.sj21ad.cisco.com (vtg-um-e2k1.cisco.com [171.70.93.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j19NArYO015928; Wed, 9 Feb 2005 15:10:54 -0800 (PST) Received: from [10.32.131.112] ([10.32.131.112]) by vtg-um-e2k1.sj21ad.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 9 Feb 2005 15:10:48 -0800 Message-ID: <420A9878.1010303@cisco.com> Date: Wed, 09 Feb 2005 15:10:48 -0800 From: Sarvi Shanmugham Organization: Cisco Systems Inc. User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sarvi Shanmugham Subject: Re: [Speechsc] IANA considerations for group feedback References: <20050209150151.83844.qmail@web14121.mail.yahoo.com> <420A2C99.70902@ericsson.com> <420A5C63.20808@cisco.com> In-Reply-To: <420A5C63.20808@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Feb 2005 23:10:48.0549 (UTC) FILETIME=[9774D150:01C50EFC] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: Magnus Westerlund , speechsc@ietf.org 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit I did a little bit of searching. It looks like the following draft. http://bgp.potaroo.net/ietf/all-ids/draft-camarillo-mmusic-sdp-bfcp-00.txt uses SDP media type "application" to do something similar in model what MRCPv2 is doing. So, if there is no objecttion, I would propose that we move from "control" to "application" Any thoughts, Sarvi Sarvi Shanmugham wrote: > Should we be using either "message" or "application" perhaps for this > use instead of "control" > > Sarvi > Magnus Westerlund wrote: > >> David R Oran wrote: >> >>> >>> On Feb 9, 2005, at 10:01 AM, Dan Burnett wrote: >>> >>>> Just to be clear, there are no IANA considerations >>>> here, right? The "control" type exists and we do not >>>> need to request any sort of registration because of >>>> our documented use, right? >>>> >>> Yes, unless MMUSIC nukes it. Queries launched by Eric to see what's >>> up... >>> >> >> Consider yourself nuked. The following is present in the latest >> SDP-new (version 23), section 10: >> >> It is noted that "text" and >> "message" are valid media types for use with SDP, but that "control" >> and "data" are under-specified and deprecated. >> >> >> Cheers >> >> Magnus Westerlund >> >> Multimedia Technologies, Ericsson Research EAB/TVA/A >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 8 4048287 >> Torshamsgatan 23 | Fax +46 8 7575550 >> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> >> _______________________________________________ >> Speechsc mailing list >> Speechsc@ietf.org >> https://www1.ietf.org/mailman/listinfo/speechsc >> > > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Thu Feb 10 04:16:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09021 for ; Thu, 10 Feb 2005 04:16:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzAkv-0006Kv-Te for speechsc-web-archive@ietf.org; Thu, 10 Feb 2005 04:37:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzAJa-0006rh-0u; Thu, 10 Feb 2005 04:08:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzA52-0001a4-R1 for speechsc@megatron.ietf.org; Thu, 10 Feb 2005 03:53:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07838 for ; Thu, 10 Feb 2005 03:53:43 -0500 (EST) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzAOz-0005uO-9W for speechsc@ietf.org; Thu, 10 Feb 2005 04:14:23 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j1A8reO6026253 for ; Thu, 10 Feb 2005 09:53:40 +0100 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Feb 2005 09:54:04 +0100 Received: from [147.214.237.66] (vm-client1 [147.214.237.66]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id DT1RMV8G; Thu, 10 Feb 2005 09:53:39 +0100 Message-ID: <420B2112.4040503@ericsson.com> Date: Thu, 10 Feb 2005 09:53:38 +0100 X-Sybari-Trust: f1418997 b8ec86c7 53bb155c 00000139 From: Magnus Westerlund User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sarvi Shanmugham Subject: Re: [Speechsc] IANA considerations for group feedback References: <420A5080.2020101@cisco.com> In-Reply-To: <420A5080.2020101@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Feb 2005 08:54:04.0870 (UTC) FILETIME=[12E39E60:01C50F4E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: ThomasGal@LumenVox.com, "Reifenrath, Klaus" , speechsc@ietf.org 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Hi, Lets first check if we are talking about what I think we are. This discussion is about the media type that should go in the "m=" line within SDP when declaring the MRCPv2 protocol session? Sarvi Shanmugham wrote: > I would wait for Magnus's response. May be he has an alternate proposal to "control". > I would suggest that you use application. It is a matching top level media type, however it is fairly wide. For the alternative see below. > Sarvi > Dan Burnett wrote: > > Does that mean we need to register it? I would still > > assume *not*. > If you want to use a top level media type called "control" you will need to define that top level type. Thus it would require a registration of it, which must address the MIME registration rules, see RFC 2048. My interpretation is that "SHOULD NOT" is directed at proprietary use. For an IETF standards track specification, we really should not break this recommendation and instead define what it means if you intend to use it. So in my view you have two alternatives: 1. Use "application" 2. Define "control" in a separate document and then use it. When it comes to message I it doesn't seem appropriate, please take a look at what exist currently in it (see IANA registry), and its description (Section 5.2 RFC 2046). Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Thu Feb 10 04:45:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11498 for ; Thu, 10 Feb 2005 04:45:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzBDV-0006z8-RD for speechsc-web-archive@ietf.org; Thu, 10 Feb 2005 05:06:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzAjY-0000VD-6i; Thu, 10 Feb 2005 04:35:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzAeG-0007zv-SY for speechsc@megatron.ietf.org; Thu, 10 Feb 2005 04:30:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10147 for ; Thu, 10 Feb 2005 04:30:06 -0500 (EST) Received: from mx2.scansoft.com ([198.71.64.82]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzAyE-0006cj-UH for speechsc@ietf.org; Thu, 10 Feb 2005 04:50:48 -0500 Received: from pb-exchcon.pb.scansoft.com ([10.1.4.73]) by mx2.scansoft.com with InterScan Messaging Security Suite; Thu, 10 Feb 2005 04:31:57 -0500 Received: by pb-exchcon.pb.scansoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Feb 2005 04:28:20 -0500 Message-ID: From: "Reifenrath, Klaus" To: "'Magnus Westerlund'" , Sarvi Shanmugham Subject: RE: [Speechsc] IANA considerations for group feedback Date: Thu, 10 Feb 2005 04:28:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: ThomasGal@LumenVox.com, "Reifenrath, Klaus" , speechsc@ietf.org 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Hi Magnus, yes, here is the "m=" line from the example(s) of draft-ietf-speechsc-mrcpv2-05.txt: m=control 9 TCP application/mrcpv2 Thanks, Klaus -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] Sent: Donnerstag, 10. Februar 2005 09:54 To: Sarvi Shanmugham Cc: Dan Burnett; ThomasGal@LumenVox.com; speechsc@ietf.org; Reifenrath, Klaus Subject: Re: [Speechsc] IANA considerations for group feedback Hi, Lets first check if we are talking about what I think we are. This discussion is about the media type that should go in the "m=" line within SDP when declaring the MRCPv2 protocol session? Sarvi Shanmugham wrote: > I would wait for Magnus's response. May be he has an alternate proposal to "control". > I would suggest that you use application. It is a matching top level media type, however it is fairly wide. For the alternative see below. > Sarvi > Dan Burnett wrote: > > Does that mean we need to register it? I would still > > assume *not*. > If you want to use a top level media type called "control" you will need to define that top level type. Thus it would require a registration of it, which must address the MIME registration rules, see RFC 2048. My interpretation is that "SHOULD NOT" is directed at proprietary use. For an IETF standards track specification, we really should not break this recommendation and instead define what it means if you intend to use it. So in my view you have two alternatives: 1. Use "application" 2. Define "control" in a separate document and then use it. When it comes to message I it doesn't seem appropriate, please take a look at what exist currently in it (see IANA registry), and its description (Section 5.2 RFC 2046). Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Thu Feb 10 07:58:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25715 for ; Thu, 10 Feb 2005 07:58:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzEEF-0002n3-7g for speechsc-web-archive@ietf.org; Thu, 10 Feb 2005 08:19:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzDpo-0003Nc-Az; Thu, 10 Feb 2005 07:54:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzDk0-0002Tg-UJ for speechsc@megatron.ietf.org; Thu, 10 Feb 2005 07:48:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24978 for ; Thu, 10 Feb 2005 07:48:15 -0500 (EST) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzE41-0002Zw-Cy for speechsc@ietf.org; Thu, 10 Feb 2005 08:08:57 -0500 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j1ACmEO6031378 for ; Thu, 10 Feb 2005 13:48:14 +0100 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Feb 2005 13:48:39 +0100 Received: from [147.214.237.66] (vmclient-50 [147.214.237.66]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id DT1R3CXP; Thu, 10 Feb 2005 13:48:12 +0100 Message-ID: <420B580B.50303@ericsson.com> Date: Thu, 10 Feb 2005 13:48:11 +0100 X-Sybari-Trust: e703c5f4 b8ec86c7 53bb155c 00000139 From: Magnus Westerlund User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Reifenrath, Klaus" Subject: Re: [Speechsc] IANA considerations for group feedback References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Feb 2005 12:48:39.0768 (UTC) FILETIME=[D82E9D80:01C50F6E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Cc: ThomasGal@LumenVox.com, Sarvi Shanmugham , speechsc@ietf.org 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Thanks Klaus, Reifenrath, Klaus wrote: > Hi Magnus, > > yes, here is the "m=" line from the example(s) of > draft-ietf-speechsc-mrcpv2-05.txt: > m=control 9 TCP application/mrcpv2 > which could be instead expressed as: m=application 9 TCP/MRCPV2 Which would indicate that this is an application, and that the protocol is MRCPV2 over TCP. If one likes to have SCTP, one can simple define SCTP/MRCPV2 in the future. The reason I am suggesting to define a real protocol identifier instead of simply indicating TCP with a MIME type, is that this is standardized protocol and can't really be mixed with something else on that TCP connection. From draft-ietf-mmusic-sdp-new-23.txt: 8.2.2 Transport protocols ("proto") The "proto" field describes the transport protocol used. This SHOULD reference a standards-track protocol RFC. This memo registers three values: "RTP/AVP" is a reference to RTP [18] used under the RTP Profile for Audio and Video Conferences with Minimal Control [19] running over UDP/IP, "RTP/SAVP" is a reference to the Secure Real-time Transport Protocol [22], and "udp" indicates an unspecified protocol over UDP. If other RTP profiles are defined in the future, their "proto" name SHOULD be specified in the same manner. For example, an RTP profile whose short name is "XYZ" would be denoted by a "proto" field of "RTP/XYZ". New transport protocols SHOULD be registered with IANA. Registrations MUST reference an RFC describing the protocol. Such an RFC MAY be Experimental or Informational, although it is preferable if it is Standards-Track. Registrations MUST also define the rules by which their "fmt" namespace is managed (see below). The registration is not that difficult, and you also have the possibility to use the FMT space for something protocol related, like supported mode, or whatever. One last point is that we should also gather further input on this topic from the MMUSIC WG. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Thu Feb 10 08:55:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00944 for ; Thu, 10 Feb 2005 08:55:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzF7N-0004GQ-G8 for speechsc-web-archive@ietf.org; Thu, 10 Feb 2005 09:16:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzEhd-0007V4-QA; Thu, 10 Feb 2005 08:49:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzEW9-0006gA-1d for speechsc@megatron.ietf.org; Thu, 10 Feb 2005 08:38:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29436 for ; Thu, 10 Feb 2005 08:37:59 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzEq9-0003na-76 for speechsc@ietf.org; Thu, 10 Feb 2005 08:58:42 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 10 Feb 2005 05:48:05 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.88,192,1102320000"; d="scan'208"; a="613560259:sNHT22118240" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j1ADbPTj023536; Thu, 10 Feb 2005 05:37:26 -0800 (PST) Received: from [10.32.245.155] (stealth-10-32-245-155.cisco.com [10.32.245.155]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j1ADWbcx024403; Thu, 10 Feb 2005 05:32:38 -0800 In-Reply-To: <420B580B.50303@ericsson.com> References: <420B580B.50303@ericsson.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [Speechsc] IANA considerations for group feedback Date: Thu, 10 Feb 2005 08:37:21 -0500 To: Magnus Westerlund X-Mailer: Apple Mail (2.619.2) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1108042359.467317"; x:"432200"; a:"rsa-sha1"; b:"nofws:2236"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"eqwvchXl2oZCpSArBnS7CksrsuMaVY7J7uuAwyj3nW8nRpcGowzUvFeIKUIKSnOwVL3kLszt" "ACQG9QXabe+sTx00RPcG0Flygs8lv0xNEx5x5Bvh1VmUga7JwmihmSO0lmLG4pihTxe+aCRS9RR" "cEWOZTJgYcS1tLzRKFXQaSvQ="; c:"From: David R Oran "; c:"Subject: Re: [Speechsc] IANA considerations for group feedback"; c:"Date: Thu, 10 Feb 2005 08:37:21 -0500" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Cc: ThomasGal@LumenVox.com, Sarvi Shanmugham , speechsc@ietf.org, "Reifenrath, Klaus" 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit Magnus' suggestion works for me. On Feb 10, 2005, at 7:48 AM, Magnus Westerlund wrote: > Thanks Klaus, > > Reifenrath, Klaus wrote: >> Hi Magnus, >> yes, here is the "m=" line from the example(s) of >> draft-ietf-speechsc-mrcpv2-05.txt: >> m=control 9 TCP application/mrcpv2 > > which could be instead expressed as: > > m=application 9 TCP/MRCPV2 > > Which would indicate that this is an application, and that the > protocol is MRCPV2 over TCP. If one likes to have SCTP, one can simple > define SCTP/MRCPV2 in the future. The reason I am suggesting to define > a real protocol identifier instead of simply indicating TCP with a > MIME type, is that this is standardized protocol and can't really be > mixed with something else on that TCP connection. > > From draft-ietf-mmusic-sdp-new-23.txt: > > 8.2.2 Transport protocols ("proto") > > The "proto" field describes the transport protocol used. This > SHOULD > reference a standards-track protocol RFC. This memo registers three > values: "RTP/AVP" is a reference to RTP [18] used under the RTP > Profile for Audio and Video Conferences with Minimal Control [19] > running over UDP/IP, "RTP/SAVP" is a reference to the Secure > Real-time Transport Protocol [22], and "udp" indicates an > unspecified > protocol over UDP. > > If other RTP profiles are defined in the future, their "proto" name > SHOULD be specified in the same manner. For example, an RTP profile > whose short name is "XYZ" would be denoted by a "proto" field of > "RTP/XYZ". > > New transport protocols SHOULD be registered with IANA. > Registrations MUST reference an RFC describing the protocol. Such > an > RFC MAY be Experimental or Informational, although it is preferable > if it is Standards-Track. Registrations MUST also define the rules > by which their "fmt" namespace is managed (see below). > > The registration is not that difficult, and you also have the > possibility to use the FMT space for something protocol related, like > supported mode, or whatever. > > > One last point is that we should also gather further input on this > topic from the MMUSIC WG. > > > Cheers > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran@cisco.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Thu Feb 10 09:24:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02944 for ; Thu, 10 Feb 2005 09:24:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzFZY-0004tA-7O for speechsc-web-archive@ietf.org; Thu, 10 Feb 2005 09:45:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzF6G-0002pw-0q; Thu, 10 Feb 2005 09:15:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzEvE-0008Ff-Vj for speechsc@megatron.ietf.org; Thu, 10 Feb 2005 09:03:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01581 for ; Thu, 10 Feb 2005 09:03:55 -0500 (EST) Received: from web14127.mail.yahoo.com ([66.163.171.118]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CzFFB-0004RZ-Jd for speechsc@ietf.org; Thu, 10 Feb 2005 09:24:38 -0500 Received: (qmail 52612 invoked by uid 60001); 10 Feb 2005 14:03:50 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=51NfzuL/Lg51bcy25EKQV6zlrj6PsewTy98dMpyFReKTjU46fKZkoRRXExDryhdGc2oQE3qJPc2m/TJ8YXWDTqrzNQg+lR8NM9UWUSjw3wf3CwhFqhkGHRL0X2IqSu99eSrLh91EoDtw0vnljHbEQTwBMrREI+J6Kl0mCbGmgz4= ; Message-ID: <20050210140350.52610.qmail@web14127.mail.yahoo.com> Received: from [63.193.248.104] by web14127.mail.yahoo.com via HTTP; Thu, 10 Feb 2005 06:03:50 PST Date: Thu, 10 Feb 2005 06:03:50 -0800 (PST) From: Dan Burnett Subject: RE: [Speechsc] IANA considerations for group feedback To: ThomasGal@LumenVox.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 3.0 (+++) X-Scan-Signature: ed68cc91cc637fea89623888898579ba Cc: speechsc@ietf.org 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 3.0 (+++) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Thanks. The registration process requires a discussion of what resources can be accessed via the scheme. Can you (or anyone else on the list) comment on how, if at all, the media type of the resource pointed to by this scheme is known? Although currently we only have a restricted number of resource types (grammars, lexicons, etc.), I can't find any indication of how the type would make its way back to the user. Unlike the "http" scheme, there isn't much of a protocol definition in our spec. I believe the protocol definition is limited to "the resource may be accessed via the scheme". Any thoughts? -- dan --- Thomas Gal wrote: > I thought it was pretty well defined as being > lexically: > > "session:uri". Beyond that it's persistence is only > guaranteed for the > session, and can be overwritten by using the same > URI for another item. I > don't think there's really anything else to > define..... > > RFC 2396 ( and the obsoleted 1738) is about syntax > of URLs so they don't > really have bearing, unless you were referring to > that as the issue....as > for registration it seems to be pretty well covered > in 2717 and 2718. 2717 > explaining the registration process or dare I say > protocol, and 2718 > explaining the necessary rational for syntax of an > extension URI scheme. > > SO is the question the exact format of the URI > because the synatx in the > MRCPv2 document is more or less standard down to > some minor details? > > Otherwise the factors enumerated from the RFC for > appropriatness with some > comments: > > > 2.1 Syntactic compatibility > > New URL schemes should follow the same syntactic > conventions of > existing schemes when appropriate. > > -Again I know that the only real differences are in > quoted text and > some minor details at the bottom of the syntax tree > that are just > simplifications of > > 2.1.1 Motivations for syntactic compatibility > > Why should new URL schemes share as much of the > generic URI syntax > (that makes sense to share) as possible? > > -Basically the reality here is that MRCP is a part > of the grander > scheme of VXML and the web itself and URLs will > often be embedded in a > diverse set of other types of resources so this > justifies syntactic > similarity quite well. > > > 2.1.2 Improper use of "//" following ":" > > -We do have the authority directly following the > slashes as > specified. > > 2.1.3 Compatibility with relative URLs > > URL schemes should use the generic URL syntax if > they are intended > to > be used with relative URLs. > > - We are using the generic URL syntax more or less > > 2.2 Is the scheme well defined? > > -grammars markup etc in our context we've specified > in which > messages this scheme can be used > > 2.2.1 Clear mapping from other name spaces > > -Doesn't really appear to be an issue > > 2.2.2 URL schemes associated with network protocols > For such schemes, the specification should > completely describe how > URLs are > translated into protocol actions in sufficient > detail to make the > access of the network resource unambiguous. > > > -I think we've defined this pretty well > > 2.2.3 Definition of non-protocol URL schemes > > -This is a protocol URL > > 2.2.4 Definition of URL schemes not associated with > data resources > > -These URLs are specifically associated with data > in the cotext of > the protocol > > 2.2.5 Character encoding > > -Section 5 says MRCPv2 is ISO 10646/UTF-8, and the > MRCPv2 headers > are limited to US-ASCII. SO this may be a little bit > ambiguous and I would > propose that we limit this to US-ASCII as well as > these urls are for local > reference, and human readability is not important. > Really since these values > appear in headers of the protocol they are more or > less already definced to > be US-ASCII. > > 2.2.6 Definition of operations > > -Yes this is very clear. > > 2.3 Demonstrated utility > > -Obviously it's nice to have a way to referrence > intermediate > objects in this protocol. I don't think anyone will > dispute the utility. > > 2.4 Are there security considerations? > > -I would hope we don't need a security > considerations section for > the iana section :) > > I think we've pretty well covered it in the > document, it may just need to be > clarified or put into a second document. Certainly > the notion of a session > "scoped" uri could be helpful and applicable in > other areas and protocols as > well. > > - -Tom > > thomasgal@lumenvox.com > > > -----Original Message----- > > From: speechsc-bounces@ietf.org > > [mailto:speechsc-bounces@ietf.org] On Behalf Of > Dan Burnett > > Sent: Wednesday, January 26, 2005 10:18 AM > > To: Reifenrath, Klaus > > Cc: speechsc@ietf.org > > Subject: RE: [Speechsc] IANA considerations for > group feedback > > > > This is a good point. Unfortunately, I don't > think we > > defined this scheme sufficiently for me to write > such > > registration. Suggestions, anyone? > > > > -- dan > > > > --- "Reifenrath, Klaus" > > wrote: > > > > > > > > The URI scheme "session" requires IANA > registration (see > > > RFC2396,RFC1738). > > > > > > Klaus > > > -----Original Message----- > > > From: Reifenrath, Klaus > > > [mailto:Klaus.Reifenrath@Scansoft.com] > > > Sent: Montag, 24. Januar 2005 13:21 > > > To: 'Dan Burnett' > > > Cc: speechsc@ietf.org > > > Subject: RE: [Speechsc] IANA considerations for > group feedback > > > > > > > > > Hi Dan, > > > > > > will you also write the IANA considerations for > application/x-nlsml > > > and the > > > following SDP related entries? > > > media type: > > > - application/mrcpv2 > > > - control > > > NOTE: According to > draft-ietf-mmusic-sdp-new-23.txt > > (sections 8.2.1) > > > the media type "control" is deprecated! > > > attribute field names: > > > - resource > > > - channel > === message truncated === > ATTACHMENT part 2 application/x-pkcs7-signature name=smime.p7s __________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Thu Feb 10 09:32:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03523 for ; Thu, 10 Feb 2005 09:32:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzFgf-00054G-QA for speechsc-web-archive@ietf.org; Thu, 10 Feb 2005 09:52:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzF81-0003Fv-I8; Thu, 10 Feb 2005 09:17:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzEyQ-0000aQ-Tn for speechsc@megatron.ietf.org; Thu, 10 Feb 2005 09:07:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01804 for ; Thu, 10 Feb 2005 09:07:13 -0500 (EST) Received: from web14124.mail.yahoo.com ([66.163.171.115]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CzFIQ-0004VQ-D2 for speechsc@ietf.org; Thu, 10 Feb 2005 09:27:56 -0500 Received: (qmail 96306 invoked by uid 60001); 10 Feb 2005 14:07:11 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=Qh2M7G+Ek7ghrlRJG9+EgqwmIwisFstetOgMHUgH3X35/tC8DSSeyv8wzoLwIZ8Sd18m+y3OW5N83T9CFPWC0nKR7RaRDaUHz9Do4AlPC3wcbcHUxlwZoHJQyUWVzZpnNhaWMFInIKMeP9KPtf+HrY2hA0kf7tG+JG0f2qEE93A= ; Message-ID: <20050210140711.96304.qmail@web14124.mail.yahoo.com> Received: from [63.193.248.104] by web14124.mail.yahoo.com via HTTP; Thu, 10 Feb 2005 06:07:11 PST Date: Thu, 10 Feb 2005 06:07:11 -0800 (PST) From: Dan Burnett Subject: Re: [Speechsc] IANA considerations for group feedback To: David R Oran In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 3.0 (+++) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: speechsc@ietf.org 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 3.0 (+++) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Should we just seal the "fmt" space empty, or can anyone think of something we might wish to use it for (and therefore need to either reserve some formats or develop a management policy as Magnus suggested)? -- dan --- David R Oran wrote: > Magnus' suggestion works for me. > > On Feb 10, 2005, at 7:48 AM, Magnus Westerlund > wrote: > > > Thanks Klaus, > > > > Reifenrath, Klaus wrote: > >> Hi Magnus, > >> yes, here is the "m=" line from the example(s) of > >> draft-ietf-speechsc-mrcpv2-05.txt: > >> m=control 9 TCP application/mrcpv2 > > > > which could be instead expressed as: > > > > m=application 9 TCP/MRCPV2 > > > > Which would indicate that this is an application, > and that the > > protocol is MRCPV2 over TCP. If one likes to have > SCTP, one can simple > > define SCTP/MRCPV2 in the future. The reason I am > suggesting to define > > a real protocol identifier instead of simply > indicating TCP with a > > MIME type, is that this is standardized protocol > and can't really be > > mixed with something else on that TCP connection. > > > > From draft-ietf-mmusic-sdp-new-23.txt: > > > > 8.2.2 Transport protocols ("proto") > > > > The "proto" field describes the transport > protocol used. This > > SHOULD > > reference a standards-track protocol RFC. This > memo registers three > > values: "RTP/AVP" is a reference to RTP [18] > used under the RTP > > Profile for Audio and Video Conferences with > Minimal Control [19] > > running over UDP/IP, "RTP/SAVP" is a reference > to the Secure > > Real-time Transport Protocol [22], and "udp" > indicates an > > unspecified > > protocol over UDP. > > > > If other RTP profiles are defined in the > future, their "proto" name > > SHOULD be specified in the same manner. For > example, an RTP profile > > whose short name is "XYZ" would be denoted by a > "proto" field of > > "RTP/XYZ". > > > > New transport protocols SHOULD be registered > with IANA. > > Registrations MUST reference an RFC describing > the protocol. Such > > an > > RFC MAY be Experimental or Informational, > although it is preferable > > if it is Standards-Track. Registrations MUST > also define the rules > > by which their "fmt" namespace is managed (see > below). > > > > The registration is not that difficult, and you > also have the > > possibility to use the FMT space for something > protocol related, like > > supported mode, or whatever. > > > > > > One last point is that we should also gather > further input on this > > topic from the MMUSIC WG. > > > > > > Cheers > > > > Magnus Westerlund > > > > Multimedia Technologies, Ericsson Research > EAB/TVA/A > > > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 8 4048287 > > Torshamsgatan 23 | Fax +46 8 7575550 > > S-164 80 Stockholm, Sweden | mailto: > magnus.westerlund@ericsson.com > > > > _______________________________________________ > > Speechsc mailing list > > Speechsc@ietf.org > > https://www1.ietf.org/mailman/listinfo/speechsc > > > David R. Oran > Cisco Fellow > Cisco Systems > 7 Ladyslipper Lane > Acton, MA 01720 USA > Tel: +1 978 264 2048 > Email: oran@cisco.com > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > __________________________________ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Thu Feb 10 10:17:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07580 for ; Thu, 10 Feb 2005 10:17:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzGOC-00067O-Dh for speechsc-web-archive@ietf.org; Thu, 10 Feb 2005 10:37:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzFwH-0001yU-Km; Thu, 10 Feb 2005 10:09:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzFrv-0000cg-8O for speechsc@megatron.ietf.org; Thu, 10 Feb 2005 10:04:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06292 for ; Thu, 10 Feb 2005 10:04:33 -0500 (EST) Received: from web14123.mail.yahoo.com ([66.163.171.114]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CzGBw-0005rV-Ns for speechsc@ietf.org; Thu, 10 Feb 2005 10:25:17 -0500 Received: (qmail 69423 invoked by uid 60001); 10 Feb 2005 15:04:29 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=XJ0cqD8U4sUaOZQHy5VSb1yacFnEjC4ZZ/cwyvaRXn9y2p6H4E9JSSigHlnmVesyKfMPu0wCwxyGcervt+rud7rIXGyFr+754HLbTQzDhzf7yrh6pBsAhswhDHvq5oxoDQZ0/V3Uh9BGXvNxm+QY+d8hXxJFWCmOt8fmO9bR79I= ; Message-ID: <20050210150429.69421.qmail@web14123.mail.yahoo.com> Received: from [63.193.248.104] by web14123.mail.yahoo.com via HTTP; Thu, 10 Feb 2005 07:04:29 PST Date: Thu, 10 Feb 2005 07:04:29 -0800 (PST) From: Dan Burnett Subject: RE: [Speechsc] IANA considerations for group feedback To: Dan Burnett , ThomasGal@LumenVox.com In-Reply-To: <20050210140350.52610.qmail@web14127.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 3.0 (+++) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Cc: speechsc@ietf.org 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 3.0 (+++) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 Never mind. --- Dan Burnett wrote: > Thanks. The registration process requires a > discussion of what resources can be accessed via the > scheme. Can you (or anyone else on the list) > comment > on how, if at all, the media type of the resource > pointed to by this scheme is known? Although > currently we only have a restricted number of > resource > types (grammars, lexicons, etc.), I can't find any > indication of how the type would make its way back > to > the user. Unlike the "http" scheme, there isn't > much > of a protocol definition in our spec. I believe the > protocol definition is limited to "the resource may > be > accessed via the scheme". > > Any thoughts? > > -- dan > > > --- Thomas Gal wrote: > > > I thought it was pretty well defined as being > > lexically: > > > > "session:uri". Beyond that it's persistence is > only > > guaranteed for the > > session, and can be overwritten by using the same > > URI for another item. I > > don't think there's really anything else to > > define..... > > > > RFC 2396 ( and the obsoleted 1738) is about syntax > > of URLs so they don't > > really have bearing, unless you were referring to > > that as the issue....as > > for registration it seems to be pretty well > covered > > in 2717 and 2718. 2717 > > explaining the registration process or dare I say > > protocol, and 2718 > > explaining the necessary rational for syntax of an > > extension URI scheme. > > > > SO is the question the exact format of the URI > > because the synatx in the > > MRCPv2 document is more or less standard down to > > some minor details? > > > > Otherwise the factors enumerated from the RFC for > > appropriatness with some > > comments: > > > > > > 2.1 Syntactic compatibility > > > > New URL schemes should follow the same > syntactic > > conventions of > > existing schemes when appropriate. > > > > -Again I know that the only real differences are > in > > quoted text and > > some minor details at the bottom of the syntax > tree > > that are just > > simplifications of > > > > 2.1.1 Motivations for syntactic compatibility > > > > Why should new URL schemes share as much of the > > generic URI syntax > > (that makes sense to share) as possible? > > > > -Basically the reality here is that MRCP is a > part > > of the grander > > scheme of VXML and the web itself and URLs will > > often be embedded in a > > diverse set of other types of resources so this > > justifies syntactic > > similarity quite well. > > > > > > 2.1.2 Improper use of "//" following ":" > > > > -We do have the authority directly following the > > slashes as > > specified. > > > > 2.1.3 Compatibility with relative URLs > > > > URL schemes should use the generic URL syntax > if > > they are intended > > to > > be used with relative URLs. > > > > - We are using the generic URL syntax more or > less > > > > 2.2 Is the scheme well defined? > > > > -grammars markup etc in our context we've > specified > > in which > > messages this scheme can be used > > > > 2.2.1 Clear mapping from other name spaces > > > > -Doesn't really appear to be an issue > > > > 2.2.2 URL schemes associated with network > protocols > > For such schemes, the specification should > > completely describe how > > URLs are > > translated into protocol actions in > sufficient > > detail to make the > > access of the network resource unambiguous. > > > > > > -I think we've defined this pretty well > > > > 2.2.3 Definition of non-protocol URL schemes > > > > -This is a protocol URL > > > > 2.2.4 Definition of URL schemes not associated > with > > data resources > > > > -These URLs are specifically associated with data > > in the cotext of > > the protocol > > > > 2.2.5 Character encoding > > > > -Section 5 says MRCPv2 is ISO 10646/UTF-8, and > the > > MRCPv2 headers > > are limited to US-ASCII. SO this may be a little > bit > > ambiguous and I would > > propose that we limit this to US-ASCII as well as > > these urls are for local > > reference, and human readability is not important. > > Really since these values > > appear in headers of the protocol they are more or > > less already definced to > > be US-ASCII. > > > > 2.2.6 Definition of operations > > > > -Yes this is very clear. > > > > 2.3 Demonstrated utility > > > > -Obviously it's nice to have a way to referrence > > intermediate > > objects in this protocol. I don't think anyone > will > > dispute the utility. > > > > 2.4 Are there security considerations? > > > > -I would hope we don't need a security > > considerations section for > > the iana section :) > > > > I think we've pretty well covered it in the > > document, it may just need to be > > clarified or put into a second document. Certainly > > the notion of a session > > "scoped" uri could be helpful and applicable in > > other areas and protocols as > > well. > > > > - -Tom > > > > thomasgal@lumenvox.com > > > > > -----Original Message----- > > > From: speechsc-bounces@ietf.org > > > [mailto:speechsc-bounces@ietf.org] On Behalf Of > > Dan Burnett > > > Sent: Wednesday, January 26, 2005 10:18 AM > > > To: Reifenrath, Klaus > > > Cc: speechsc@ietf.org > > > Subject: RE: [Speechsc] IANA considerations for > > group feedback > > > > > > This is a good point. Unfortunately, I don't > > think we > > > defined this scheme sufficiently for me to write > === message truncated === __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Thu Feb 10 18:11:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05032 for ; Thu, 10 Feb 2005 18:11:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzNmn-00064B-Co for speechsc-web-archive@ietf.org; Thu, 10 Feb 2005 18:31:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzNIQ-0008Dv-59; Thu, 10 Feb 2005 18:00:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzN8q-0003r8-Ga for speechsc@megatron.ietf.org; Thu, 10 Feb 2005 17:50:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01688 for ; Thu, 10 Feb 2005 17:50:29 -0500 (EST) Received: from web14125.mail.yahoo.com ([66.163.171.116]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CzNSw-0005Gk-7I for speechsc@ietf.org; Thu, 10 Feb 2005 18:11:18 -0500 Received: (qmail 69261 invoked by uid 60001); 10 Feb 2005 22:50:30 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=HCQkQ4aNrt/YPihpDoz8j3VqA290UCHqs+Qt6PsfQBavp5W5s6hMD9J+5cCAqsBKfN2IfbfQNMZiRVn9XoWVJsm7zXLQfZlWYxAE3mAk3vyJdmdDSq9XtsYJMgvoyNs4ZlIMlsONCbCkIeR8BOU8Mlu29DsXUIiv94yJ0BQUK20= ; Message-ID: <20050210225030.69259.qmail@web14125.mail.yahoo.com> Received: from [63.193.248.104] by web14125.mail.yahoo.com via HTTP; Thu, 10 Feb 2005 14:50:30 PST Date: Thu, 10 Feb 2005 14:50:30 -0800 (PST) From: Dan Burnett Subject: Re: [Speechsc] IANA considerations for group feedback To: David R Oran , Magnus Westerlund In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 3.0 (+++) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id RAA01688 Cc: speechsc@ietf.org 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 3.0 (+++) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: quoted-printable So at this time I will register TCP/MRCPV2 both as a transport protocol and as an SDP "proto" value but *not* do this for SCTP/MRCPV2 or TLS/MRCPV2. Any objections? -- dan --- David R Oran wrote: > Magnus' suggestion works for me. >=20 > On Feb 10, 2005, at 7:48 AM, Magnus Westerlund > wrote: >=20 > > Thanks Klaus, > > > > Reifenrath, Klaus wrote: > >> Hi Magnus, > >> yes, here is the "m=3D" line from the example(s) of > >> draft-ietf-speechsc-mrcpv2-05.txt: > >> m=3Dcontrol 9 TCP application/mrcpv2 > > > > which could be instead expressed as: > > > > m=3Dapplication 9 TCP/MRCPV2 > > > > Which would indicate that this is an application, > and that the=20 > > protocol is MRCPV2 over TCP. If one likes to have > SCTP, one can simple=20 > > define SCTP/MRCPV2 in the future. The reason I am > suggesting to define=20 > > a real protocol identifier instead of simply > indicating TCP with a=20 > > MIME type, is that this is standardized protocol > and can't really be=20 > > mixed with something else on that TCP connection. > > > > From draft-ietf-mmusic-sdp-new-23.txt: > > > > 8.2.2 Transport protocols ("proto") > > > > The "proto" field describes the transport > protocol used. This=20 > > SHOULD > > reference a standards-track protocol RFC. This > memo registers three > > values: "RTP/AVP" is a reference to RTP [18] > used under the RTP > > Profile for Audio and Video Conferences with > Minimal Control [19] > > running over UDP/IP, "RTP/SAVP" is a reference > to the Secure > > Real-time Transport Protocol [22], and "udp" > indicates an=20 > > unspecified > > protocol over UDP. > > > > If other RTP profiles are defined in the > future, their "proto" name > > SHOULD be specified in the same manner. For > example, an RTP profile > > whose short name is "XYZ" would be denoted by a > "proto" field of > > "RTP/XYZ". > > > > New transport protocols SHOULD be registered > with IANA. > > Registrations MUST reference an RFC describing > the protocol. Such=20 > > an > > RFC MAY be Experimental or Informational, > although it is preferable > > if it is Standards-Track. Registrations MUST > also define the rules > > by which their "fmt" namespace is managed (see > below). > > > > The registration is not that difficult, and you > also have the=20 > > possibility to use the FMT space for something > protocol related, like=20 > > supported mode, or whatever. > > > > > > One last point is that we should also gather > further input on this=20 > > topic from the MMUSIC WG. > > > > > > Cheers > > > > Magnus Westerlund > > > > Multimedia Technologies, Ericsson Research > EAB/TVA/A > > > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 8 4048287 > > Torshamsgatan 23 | Fax +46 8 7575550 > > S-164 80 Stockholm, Sweden | mailto: > magnus.westerlund@ericsson.com > > > > _______________________________________________ > > Speechsc mailing list > > Speechsc@ietf.org > > https://www1.ietf.org/mailman/listinfo/speechsc > > > David R. Oran > Cisco Fellow > Cisco Systems > 7 Ladyslipper Lane > Acton, MA 01720 USA > Tel: +1 978 264 2048 > Email: oran@cisco.com >=20 > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc >=20 =09 __________________________________=20 Do you Yahoo!?=20 All your favorites on one personal page =96 Try My Yahoo! http://my.yahoo.com=20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Thu Feb 10 18:27:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07458 for ; Thu, 10 Feb 2005 18:27:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzO2h-0006dw-Pr for speechsc-web-archive@ietf.org; Thu, 10 Feb 2005 18:48:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzNZq-0006lQ-DI; Thu, 10 Feb 2005 18:18:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzNVT-0004ZJ-BH for speechsc@megatron.ietf.org; Thu, 10 Feb 2005 18:13:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05696 for ; Thu, 10 Feb 2005 18:13:52 -0500 (EST) Received: from web14124.mail.yahoo.com ([66.163.171.115]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CzNpX-0006F9-Lk for speechsc@ietf.org; Thu, 10 Feb 2005 18:34:42 -0500 Received: (qmail 869 invoked by uid 60001); 10 Feb 2005 23:13:51 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=T3/RtVD8tGna3cvQER+KMlaPefm6zT5R10EuCUL0tZyFiihr+jn6bwUrCbQkkWo4GX4TLlct0kugckXiYblSJeqniwZmA2yDjW+rLQhsC71j3qUqMTx/LA3fnlAWnbtuWVHDIC9aUGo+2ciGy6BA9uytNtxzNg/B+78Y89CJ7h0= ; Message-ID: <20050210231351.867.qmail@web14124.mail.yahoo.com> Received: from [63.193.248.104] by web14124.mail.yahoo.com via HTTP; Thu, 10 Feb 2005 15:13:51 PST Date: Thu, 10 Feb 2005 15:13:51 -0800 (PST) From: Dan Burnett Subject: Re: [Speechsc] IANA considerations for group feedback To: David R Oran , Magnus Westerlund In-Reply-To: <20050210225030.69259.qmail@web14125.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 3.0 (+++) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id SAA05696 Cc: speechsc@ietf.org 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 3.0 (+++) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Content-Transfer-Encoding: quoted-printable Oops. I think I misunderstood the email trail. I will *not* do what I described below. Instead, I'll just register application/mrcpv2 as a MIME type and we can change "control" to "application" in the m=3D line. -- dan --- Dan Burnett wrote: > So at this time I will register TCP/MRCPV2 both as a > transport protocol and as an SDP "proto" value but > *not* do this for SCTP/MRCPV2 or TLS/MRCPV2. >=20 > Any objections? >=20 > -- dan >=20 > --- David R Oran wrote: >=20 > > Magnus' suggestion works for me. > >=20 > > On Feb 10, 2005, at 7:48 AM, Magnus Westerlund > > wrote: > >=20 > > > Thanks Klaus, > > > > > > Reifenrath, Klaus wrote: > > >> Hi Magnus, > > >> yes, here is the "m=3D" line from the example(s) > of > > >> draft-ietf-speechsc-mrcpv2-05.txt: > > >> m=3Dcontrol 9 TCP application/mrcpv2 > > > > > > which could be instead expressed as: > > > > > > m=3Dapplication 9 TCP/MRCPV2 > > > > > > Which would indicate that this is an > application, > > and that the=20 > > > protocol is MRCPV2 over TCP. If one likes to > have > > SCTP, one can simple=20 > > > define SCTP/MRCPV2 in the future. The reason I > am > > suggesting to define=20 > > > a real protocol identifier instead of simply > > indicating TCP with a=20 > > > MIME type, is that this is standardized protocol > > and can't really be=20 > > > mixed with something else on that TCP > connection. > > > > > > From draft-ietf-mmusic-sdp-new-23.txt: > > > > > > 8.2.2 Transport protocols ("proto") > > > > > > The "proto" field describes the transport > > protocol used. This=20 > > > SHOULD > > > reference a standards-track protocol RFC.=20 > This > > memo registers three > > > values: "RTP/AVP" is a reference to RTP [18] > > used under the RTP > > > Profile for Audio and Video Conferences with > > Minimal Control [19] > > > running over UDP/IP, "RTP/SAVP" is a > reference > > to the Secure > > > Real-time Transport Protocol [22], and "udp" > > indicates an=20 > > > unspecified > > > protocol over UDP. > > > > > > If other RTP profiles are defined in the > > future, their "proto" name > > > SHOULD be specified in the same manner. For > > example, an RTP profile > > > whose short name is "XYZ" would be denoted by > a > > "proto" field of > > > "RTP/XYZ". > > > > > > New transport protocols SHOULD be registered > > with IANA. > > > Registrations MUST reference an RFC > describing > > the protocol. Such=20 > > > an > > > RFC MAY be Experimental or Informational, > > although it is preferable > > > if it is Standards-Track. Registrations MUST > > also define the rules > > > by which their "fmt" namespace is managed > (see > > below). > > > > > > The registration is not that difficult, and you > > also have the=20 > > > possibility to use the FMT space for something > > protocol related, like=20 > > > supported mode, or whatever. > > > > > > > > > One last point is that we should also gather > > further input on this=20 > > > topic from the MMUSIC WG. > > > > > > > > > Cheers > > > > > > Magnus Westerlund > > > > > > Multimedia Technologies, Ericsson Research > > EAB/TVA/A > > > > > > ---------------------------------------------------------------------- > > > Ericsson AB | Phone +46 8 4048287 > > > Torshamsgatan 23 | Fax +46 8 7575550 > > > S-164 80 Stockholm, Sweden | mailto: > > magnus.westerlund@ericsson.com > > > > > > _______________________________________________ > > > Speechsc mailing list > > > Speechsc@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speechsc > > > > > David R. Oran > > Cisco Fellow > > Cisco Systems > > 7 Ladyslipper Lane > > Acton, MA 01720 USA > > Tel: +1 978 264 2048 > > Email: oran@cisco.com > >=20 > > _______________________________________________ > > Speechsc mailing list > > Speechsc@ietf.org > > https://www1.ietf.org/mailman/listinfo/speechsc > >=20 >=20 >=20 >=20 > =09 > __________________________________=20 > Do you Yahoo!?=20 > All your favorites on one personal page =96 Try My > Yahoo! > http://my.yahoo.com=20 >=20 > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc >=20 =09 __________________________________=20 Do you Yahoo!?=20 The all-new My Yahoo! - Get yours free!=20 http://my.yahoo.com=20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Fri Feb 11 10:17:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05861 for ; Fri, 11 Feb 2005 10:17:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Czcs6-0000jO-W4 for speechsc-web-archive@ietf.org; Fri, 11 Feb 2005 10:38:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzcRN-0006aq-CR; Fri, 11 Feb 2005 10:10:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzcPm-00067N-Py for speechsc@megatron.ietf.org; Fri, 11 Feb 2005 10:09:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04686 for ; Fri, 11 Feb 2005 10:09:00 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Czck0-0000Vj-5e for speechsc@ietf.org; Fri, 11 Feb 2005 10:29:57 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 11 Feb 2005 07:17:35 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1BF8Mq8023931; Fri, 11 Feb 2005 07:08:22 -0800 (PST) Received: from [10.32.245.155] (stealth-10-32-245-155.cisco.com [10.32.245.155]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j1BF3Zg6003313; Fri, 11 Feb 2005 07:03:36 -0800 In-Reply-To: <20050210225030.69259.qmail@web14125.mail.yahoo.com> References: <20050210225030.69259.qmail@web14125.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <8e230e9f8897ec65786be097dcd7e412@cisco.com> Content-Transfer-Encoding: quoted-printable From: David R Oran Subject: Re: [Speechsc] IANA considerations for group feedback Date: Fri, 11 Feb 2005 10:08:23 -0500 To: Dan Burnett X-Mailer: Apple Mail (2.619.2) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1108134216.782267"; x:"432200"; a:"rsa-sha1"; b:"nofws:3130"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"oSNRI7pJfNU78ODuiCWZuRUPJ3ISQkfNbABjFW3u1k5MfPKU7T6M4id1/CIDmGPrxMAhh/3g" "zZp8hqrA6kSwMIKjwpDAhP9MqMTXVuxdXfrSnnBq6vxryS9a6Dj4qIbEHcipw4BPMhTO16UTs0J" "nbIH5zp1N/wxTI/U+XhVkRIU="; c:"From: David R Oran "; c:"Subject: Re: [Speechsc] IANA considerations for group feedback"; c:"Date: Fri, 11 Feb 2005 10:08:23 -0500" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Content-Transfer-Encoding: quoted-printable Cc: Magnus Westerlund , speechsc@ietf.org 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Content-Transfer-Encoding: quoted-printable On Feb 10, 2005, at 5:50 PM, Dan Burnett wrote: > So at this time I will register TCP/MRCPV2 both as a > transport protocol and as an SDP "proto" value but > *not* do this for SCTP/MRCPV2 or TLS/MRCPV2. > > Any objections? > Yes, please register TLS/MRCPv2. I believe TLS is going to wind up=20 "mandatory to implement". > -- dan > > --- David R Oran wrote: > >> Magnus' suggestion works for me. >> >> On Feb 10, 2005, at 7:48 AM, Magnus Westerlund >> wrote: >> >>> Thanks Klaus, >>> >>> Reifenrath, Klaus wrote: >>>> Hi Magnus, >>>> yes, here is the "m=3D" line from the example(s) of >>>> draft-ietf-speechsc-mrcpv2-05.txt: >>>> m=3Dcontrol 9 TCP application/mrcpv2 >>> >>> which could be instead expressed as: >>> >>> m=3Dapplication 9 TCP/MRCPV2 >>> >>> Which would indicate that this is an application, >> and that the >>> protocol is MRCPV2 over TCP. If one likes to have >> SCTP, one can simple >>> define SCTP/MRCPV2 in the future. The reason I am >> suggesting to define >>> a real protocol identifier instead of simply >> indicating TCP with a >>> MIME type, is that this is standardized protocol >> and can't really be >>> mixed with something else on that TCP connection. >>> >>> =46rom draft-ietf-mmusic-sdp-new-23.txt: >>> >>> 8.2.2 Transport protocols ("proto") >>> >>> The "proto" field describes the transport >> protocol used. This >>> SHOULD >>> reference a standards-track protocol RFC. This >> memo registers three >>> values: "RTP/AVP" is a reference to RTP [18] >> used under the RTP >>> Profile for Audio and Video Conferences with >> Minimal Control [19] >>> running over UDP/IP, "RTP/SAVP" is a reference >> to the Secure >>> Real-time Transport Protocol [22], and "udp" >> indicates an >>> unspecified >>> protocol over UDP. >>> >>> If other RTP profiles are defined in the >> future, their "proto" name >>> SHOULD be specified in the same manner. For >> example, an RTP profile >>> whose short name is "XYZ" would be denoted by a >> "proto" field of >>> "RTP/XYZ". >>> >>> New transport protocols SHOULD be registered >> with IANA. >>> Registrations MUST reference an RFC describing >> the protocol. Such >>> an >>> RFC MAY be Experimental or Informational, >> although it is preferable >>> if it is Standards-Track. Registrations MUST >> also define the rules >>> by which their "fmt" namespace is managed (see >> below). >>> >>> The registration is not that difficult, and you >> also have the >>> possibility to use the FMT space for something >> protocol related, like >>> supported mode, or whatever. >>> >>> >>> One last point is that we should also gather >> further input on this >>> topic from the MMUSIC WG. >>> >>> >>> Cheers >>> >>> Magnus Westerlund >>> >>> Multimedia Technologies, Ericsson Research >> EAB/TVA/A >>> >> > ---------------------------------------------------------------------- >>> Ericsson AB | Phone +46 8 4048287 >>> Torshamsgatan 23 | Fax +46 8 7575550 >>> S-164 80 Stockholm, Sweden | mailto: >> magnus.westerlund@ericsson.com >>> >>> _______________________________________________ >>> Speechsc mailing list >>> Speechsc@ietf.org >>> https://www1.ietf.org/mailman/listinfo/speechsc >>> >> David R. Oran >> Cisco Fellow >> Cisco Systems >> 7 Ladyslipper Lane >> Acton, MA 01720 USA >> Tel: +1 978 264 2048 >> Email: oran@cisco.com >> >> _______________________________________________ >> Speechsc mailing list >> Speechsc@ietf.org >> https://www1.ietf.org/mailman/listinfo/speechsc >> > > > > =09 > __________________________________ > Do you Yahoo!? > All your favorites on one personal page =96 Try My Yahoo! > http://my.yahoo.com > David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran@cisco.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Fri Feb 11 10:18:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06039 for ; Fri, 11 Feb 2005 10:18:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Czct6-0000l6-Pk for speechsc-web-archive@ietf.org; Fri, 11 Feb 2005 10:39:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzcY4-0000EV-BF; Fri, 11 Feb 2005 10:17:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzcRm-0006dt-7P for speechsc@megatron.ietf.org; Fri, 11 Feb 2005 10:11:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04964 for ; Fri, 11 Feb 2005 10:11:04 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Czcm0-0000YT-UK for speechsc@ietf.org; Fri, 11 Feb 2005 10:32:01 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 11 Feb 2005 07:21:21 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.88,195,1102320000"; d="scan'208"; a="613854917:sNHT58905048" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j1BFAVTj002576; Fri, 11 Feb 2005 07:10:31 -0800 (PST) Received: from [10.32.245.155] (stealth-10-32-245-155.cisco.com [10.32.245.155]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j1BF5dDw003324; Fri, 11 Feb 2005 07:05:40 -0800 In-Reply-To: <20050210231351.867.qmail@web14124.mail.yahoo.com> References: <20050210231351.867.qmail@web14124.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <41d8da050df2e0d8910260f3ee9b1b74@cisco.com> Content-Transfer-Encoding: quoted-printable From: David R Oran Subject: Re: [Speechsc] IANA considerations for group feedback Date: Fri, 11 Feb 2005 10:10:26 -0500 To: Dan Burnett X-Mailer: Apple Mail (2.619.2) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1108134340.945301"; x:"432200"; a:"rsa-sha1"; b:"nofws:3701"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"dBQkOqfZ7XJcRqYagL8VG5oKCcnq11VaIR6oscRVqC+IgikCp9o2k/a6PjFW49ZHkgOHOYvo" "uTHYi4KsNsTZAqAROhBClnPYiOGmqkgXhjFBaPcqhrVExFD8DygerL4HSIdWsoZ912Njqh6ffqm" "d8RqN+l5WwL187hYGHPSWA0M="; c:"From: David R Oran "; c:"Subject: Re: [Speechsc] IANA considerations for group feedback"; c:"Date: Fri, 11 Feb 2005 10:10:26 -0500" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Content-Transfer-Encoding: quoted-printable Cc: Magnus Westerlund , speechsc@ietf.org 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Content-Transfer-Encoding: quoted-printable On Feb 10, 2005, at 6:13 PM, Dan Burnett wrote: > Oops. I think I misunderstood the email trail. Oops, me too. > I will *not* do what I described below. Instead, I'll > just register application/mrcpv2 as a MIME type and we > can change "control" to "application" in the m=3D line. > > -- dan > > --- Dan Burnett wrote: > >> So at this time I will register TCP/MRCPV2 both as a >> transport protocol and as an SDP "proto" value but >> *not* do this for SCTP/MRCPV2 or TLS/MRCPV2. >> >> Any objections? >> >> -- dan >> >> --- David R Oran wrote: >> >>> Magnus' suggestion works for me. >>> >>> On Feb 10, 2005, at 7:48 AM, Magnus Westerlund >>> wrote: >>> >>>> Thanks Klaus, >>>> >>>> Reifenrath, Klaus wrote: >>>>> Hi Magnus, >>>>> yes, here is the "m=3D" line from the example(s) >> of >>>>> draft-ietf-speechsc-mrcpv2-05.txt: >>>>> m=3Dcontrol 9 TCP application/mrcpv2 >>>> >>>> which could be instead expressed as: >>>> >>>> m=3Dapplication 9 TCP/MRCPV2 >>>> >>>> Which would indicate that this is an >> application, >>> and that the >>>> protocol is MRCPV2 over TCP. If one likes to >> have >>> SCTP, one can simple >>>> define SCTP/MRCPV2 in the future. The reason I >> am >>> suggesting to define >>>> a real protocol identifier instead of simply >>> indicating TCP with a >>>> MIME type, is that this is standardized protocol >>> and can't really be >>>> mixed with something else on that TCP >> connection. >>>> >>>> =46rom draft-ietf-mmusic-sdp-new-23.txt: >>>> >>>> 8.2.2 Transport protocols ("proto") >>>> >>>> The "proto" field describes the transport >>> protocol used. This >>>> SHOULD >>>> reference a standards-track protocol RFC. >> This >>> memo registers three >>>> values: "RTP/AVP" is a reference to RTP [18] >>> used under the RTP >>>> Profile for Audio and Video Conferences with >>> Minimal Control [19] >>>> running over UDP/IP, "RTP/SAVP" is a >> reference >>> to the Secure >>>> Real-time Transport Protocol [22], and "udp" >>> indicates an >>>> unspecified >>>> protocol over UDP. >>>> >>>> If other RTP profiles are defined in the >>> future, their "proto" name >>>> SHOULD be specified in the same manner. For >>> example, an RTP profile >>>> whose short name is "XYZ" would be denoted by >> a >>> "proto" field of >>>> "RTP/XYZ". >>>> >>>> New transport protocols SHOULD be registered >>> with IANA. >>>> Registrations MUST reference an RFC >> describing >>> the protocol. Such >>>> an >>>> RFC MAY be Experimental or Informational, >>> although it is preferable >>>> if it is Standards-Track. Registrations MUST >>> also define the rules >>>> by which their "fmt" namespace is managed >> (see >>> below). >>>> >>>> The registration is not that difficult, and you >>> also have the >>>> possibility to use the FMT space for something >>> protocol related, like >>>> supported mode, or whatever. >>>> >>>> >>>> One last point is that we should also gather >>> further input on this >>>> topic from the MMUSIC WG. >>>> >>>> >>>> Cheers >>>> >>>> Magnus Westerlund >>>> >>>> Multimedia Technologies, Ericsson Research >>> EAB/TVA/A >>>> >>> >> > ---------------------------------------------------------------------- >>>> Ericsson AB | Phone +46 8 4048287 >>>> Torshamsgatan 23 | Fax +46 8 7575550 >>>> S-164 80 Stockholm, Sweden | mailto: >>> magnus.westerlund@ericsson.com >>>> >>>> _______________________________________________ >>>> Speechsc mailing list >>>> Speechsc@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/speechsc >>>> >>> David R. Oran >>> Cisco Fellow >>> Cisco Systems >>> 7 Ladyslipper Lane >>> Acton, MA 01720 USA >>> Tel: +1 978 264 2048 >>> Email: oran@cisco.com >>> >>> _______________________________________________ >>> Speechsc mailing list >>> Speechsc@ietf.org >>> https://www1.ietf.org/mailman/listinfo/speechsc >>> >> >> >> >> =09 >> __________________________________ >> Do you Yahoo!? >> All your favorites on one personal page =96 Try My >> Yahoo! >> http://my.yahoo.com >> >> _______________________________________________ >> Speechsc mailing list >> Speechsc@ietf.org >> https://www1.ietf.org/mailman/listinfo/speechsc >> > > > > =09 > __________________________________ > Do you Yahoo!? > The all-new My Yahoo! - Get yours free! > http://my.yahoo.com > > David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran@cisco.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Fri Feb 11 11:01:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10454 for ; Fri, 11 Feb 2005 11:01:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzdYg-00022N-24 for speechsc-web-archive@ietf.org; Fri, 11 Feb 2005 11:22:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Czd3l-0002Ch-3L; Fri, 11 Feb 2005 10:50:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzcuO-0007L7-Ji for speechsc@megatron.ietf.org; Fri, 11 Feb 2005 10:40:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08725 for ; Fri, 11 Feb 2005 10:40:38 -0500 (EST) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzdEM-0001Tl-BC for speechsc@ietf.org; Fri, 11 Feb 2005 11:01:36 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j1BFeLh5014222 for ; Fri, 11 Feb 2005 16:40:21 +0100 (MET) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 11 Feb 2005 16:40:47 +0100 Received: from [147.214.237.66] (vmclient-50 [147.214.237.66]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id DT1R43FD; Fri, 11 Feb 2005 16:40:21 +0100 Message-ID: <420CD1E4.2010606@ericsson.com> Date: Fri, 11 Feb 2005 16:40:20 +0100 X-Sybari-Trust: 91acd0c9 b8ec86c7 67c955a6 00000139 From: Magnus Westerlund User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Burnett Subject: Re: [Speechsc] IANA considerations for group feedback References: <20050210231351.867.qmail@web14124.mail.yahoo.com> In-Reply-To: <20050210231351.867.qmail@web14124.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Feb 2005 15:40:47.0596 (UTC) FILETIME=[0E75DAC0:01C51050] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: speechsc@ietf.org, David R Oran 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Dan Burnett wrote: > Oops. I think I misunderstood the email trail. > > I will *not* do what I described below. Instead, I'll > just register application/mrcpv2 as a MIME type and we > can change "control" to "application" in the m= line. > Now, I got confused. My preference when it comes do indicating the MRCPv2 control session within SDP when performing the SIP negotiation would be to have identified as a protocol. To do that would require your specification to register, something like "TCP/MRCPV2" for the SDP "proto" field. That registration needs to define what is done with the FMT part of the "m=" line. You can define that it isn't used. If it is desired to have also TLS or SCTP, corresponding proto identifiers can be registered. Such a registration should also define that you will use the COMEDIA way of setting up the TCP connections in the case of TCP and TLS. When it comes to SCTP it becomes more advanced and you will be on more fresh ground. Or have you received feedback indicate that using the "TCP" proto and then a application/mrcpv2 would be better alternative? There has been some ongoing debate on this topic, for example regarding MSRP, which however has a more complex addressing scheme. So I think we should take this discussion to MMUSIC. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Fri Feb 11 12:23:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16986 for ; Fri, 11 Feb 2005 12:23:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzeqQ-00046L-It for speechsc-web-archive@ietf.org; Fri, 11 Feb 2005 12:44:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzeRY-0004c4-BC; Fri, 11 Feb 2005 12:19:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzeKZ-00020u-Pm for speechsc@megatron.ietf.org; Fri, 11 Feb 2005 12:11:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16174 for ; Fri, 11 Feb 2005 12:11:45 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Czeen-0003ot-Mi for speechsc@ietf.org; Fri, 11 Feb 2005 12:32:44 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 11 Feb 2005 09:11:03 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.88,195,1102320000"; d="scan'208"; a="161151423:sNHT577007288" Received: from vtg-um-e2k1.sj21ad.cisco.com (vtg-um-e2k1.cisco.com [171.70.93.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j1BHAdYO000360; Fri, 11 Feb 2005 09:10:39 -0800 (PST) Received: from [10.32.131.112] ([10.32.131.112]) by vtg-um-e2k1.sj21ad.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 11 Feb 2005 09:10:34 -0800 Message-ID: <420CE709.7050603@cisco.com> Date: Fri, 11 Feb 2005 09:10:33 -0800 From: Sarvi Shanmugham Organization: Cisco Systems Inc. User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: [Speechsc] IANA considerations for group feedback References: <20050210231351.867.qmail@web14124.mail.yahoo.com> <420CD1E4.2010606@ericsson.com> In-Reply-To: <420CD1E4.2010606@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Feb 2005 17:10:34.0093 (UTC) FILETIME=[991011D0:01C5105C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Cc: speechsc@ietf.org, David R Oran 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Hi Magnus/Dave, Here is my plan. m= = "application" = "TCP/MRCPv2" / "TLS/MRCPv2" / "SCTP/MRCPv2" I believe the field together with some attributes would have been a nice way to address multiple resource type identifiers and their resource channel allocation, all managed by a single m-line. Similar to have we do RTP payload type mapping/denotiation. Instead, we have taken the route of addressing that using separate m-lines for each resource. So as of the next draft, I will be leaving the field as unused. If people feel strongly about using my above suggestion about attempting to combine them into a single m-line. I could write it up separately for your review. I think "TCP/MRCPv2" and "TLS/MRCPv2" and their usage are covered in this specification, and the description is based on the COMEDIA draft. Please check to see if I have left something out in my use of the COMEDIA approach. So they will be registered in this specification. I am not sure if "SCTP/MRCPv2" needs to be very different from the COMEDIA draft in terms of the SDP used. Based on that, I will decide whether to leave SCTP out of this draft and write up a separate one on how MRCPv2 will use SCTP and have it register "SCTP/MRCPv2" separatetly. What do yall think. Sarvi Magnus Westerlund wrote: > Dan Burnett wrote: > >> Oops. I think I misunderstood the email trail. >> >> I will *not* do what I described below. Instead, I'll >> just register application/mrcpv2 as a MIME type and we >> can change "control" to "application" in the m= line. >> > > Now, I got confused. > > My preference when it comes do indicating the MRCPv2 control session > within SDP when performing the SIP negotiation would be to have > identified as a protocol. To do that would require your specification > to register, something like "TCP/MRCPV2" for the SDP "proto" field. > That registration needs to define what is done with the FMT part of > the "m=" line. You can define that it isn't used. If it is desired to > have also TLS or SCTP, corresponding proto identifiers can be > registered. Such a registration should also define that you will use > the COMEDIA way of setting up the TCP connections in the case of TCP > and TLS. When it comes to SCTP it becomes more advanced and you will > be on more fresh ground. > > Or have you received feedback indicate that using the "TCP" proto and > then a application/mrcpv2 would be better alternative? > > There has been some ongoing debate on this topic, for example > regarding MSRP, which however has a more complex addressing scheme. So > I think we should take this discussion to MMUSIC. > > Cheers > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Mon Feb 14 19:33:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07972 for ; Mon, 14 Feb 2005 19:33:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0qv1-0003qS-Oa for speechsc-web-archive@ietf.org; Mon, 14 Feb 2005 19:50:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0qX2-0000j4-4t; Mon, 14 Feb 2005 19:25:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0qPD-0007CX-Tf for speechsc@megatron.ietf.org; Mon, 14 Feb 2005 19:17:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06071 for ; Mon, 14 Feb 2005 19:17:24 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0qfq-0001fK-1G for speechsc@ietf.org; Mon, 14 Feb 2005 19:34:42 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 14 Feb 2005 16:12:45 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from vtg-um-e2k1.sj21ad.cisco.com (vtg-um-e2k1.cisco.com [171.70.93.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j1F0CTYO002824; Mon, 14 Feb 2005 16:12:30 -0800 (PST) Received: from [10.32.131.112] ([10.32.131.112]) by vtg-um-e2k1.sj21ad.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 14 Feb 2005 16:12:24 -0800 Message-ID: <42113E68.5040001@cisco.com> Date: Mon, 14 Feb 2005 16:12:24 -0800 From: Sarvi Shanmugham Organization: Cisco Systems Inc. User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Burger Subject: Re: [Speechsc] VoiceXML weight attribute References: In-Reply-To: X-OriginalArrivalTime: 15 Feb 2005 00:12:24.0500 (UTC) FILETIME=[067AEF40:01C512F3] X-Spam-Score: 1.0 (+) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: speechsc@ietf.org 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="===============0615183858==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 This is a multi-part message in MIME format. --===============0615183858== Content-Type: multipart/alternative; boundary="------------080205090004030500090005" This is a multi-part message in MIME format. --------------080205090004030500090005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The W3C grammar spec contains a weight attribute. Which should address the need well. I am not sure if it makes sense to add a weight header field to a DEFINE-GRAMMAR method as weights seems to make more sense where it is being refered/used by other grammars. I mean, where a higher level grammar refers to these individual grammars and assigns relative weights to them. Does it make sense to "define" a grammar with a fixed weight. Doesn't it actually more sense to specify weight a set of grammars is being used in a RECOGNIZE? I would lean towards not adding a weight header for this purpose in MRCPv2 when the W3C grammar spec addresses this problem.. Sarvi Eric Burger wrote: >Any thoughts on this? > > > >>-----Original Message----- >>From: Jeff Kusnitz [mailto:jk@us.ibm.com] >>Sent: Thursday, January 20, 2005 4:31 PM >>To: speechsc@ietf.org >>Subject: [Speechsc] VoiceXML weight attribute >> >> >>In the VoiceXML 2.0, the tag has been extended to include a >>weight attribute to allow developers to bias grammars >>(section 3.1.1.3). >>The current DEFINE-GRAMMAR request doesn't have a "weight" >>header though, >>so it's not possible for a VoiceXML browser to do anything with the >>'s weight attribute. Is this an oversight? Is it >>too late to >>add "weight" to the DEFINE-GRAMMAR request? >> >>Thanks, >>Jeff >> >>_______________________________________________ >>Speechsc mailing list >>Speechsc@ietf.org >>https://www1.ietf.org/mailman/listinfo/speechsc >> >> >> > >_______________________________________________ >Speechsc mailing list >Speechsc@ietf.org >https://www1.ietf.org/mailman/listinfo/speechsc > > > --------------080205090004030500090005 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The W3C grammar spec contains a weight attribute. Which should address the need well.

I am not sure if it makes sense to add a weight header field to a DEFINE-GRAMMAR method as weights seems to make more sense where it is being refered/used by other grammars. I mean, where a higher level grammar refers to these individual grammars and assigns relative weights to them.

Does it make sense to "define" a grammar with a fixed weight. Doesn't it actually more sense to specify weight a set of grammars is being used in a RECOGNIZE?

I would lean towards not adding a weight header for this purpose in MRCPv2 when the W3C grammar spec addresses this problem..

Sarvi
Eric Burger wrote: 
Any thoughts on this?

  
-----Original Message-----
From: Jeff Kusnitz [mailto:jk@us.ibm.com]
Sent: Thursday, January 20, 2005 4:31 PM
To: speechsc@ietf.org
Subject: [Speechsc] VoiceXML <grammar> weight attribute


In the VoiceXML 2.0, the <grammar> tag has been extended to include a 
weight attribute to allow developers to bias grammars 
(section 3.1.1.3). 
The current DEFINE-GRAMMAR request doesn't have a "weight" 
header though, 
so it's not possible for a VoiceXML browser to do anything with the 
<grammar>'s weight attribute.  Is this an oversight?  Is it 
too late to 
add "weight" to the DEFINE-GRAMMAR request?

Thanks,
Jeff

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc

    

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc

--------------080205090004030500090005-- --===============0615183858== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc --===============0615183858==-- From speechsc-bounces@ietf.org Mon Feb 14 20:58:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14383 for ; Mon, 14 Feb 2005 20:58:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0sJl-0006bt-B0 for speechsc-web-archive@ietf.org; Mon, 14 Feb 2005 21:20:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0rxb-0001m8-Ea; Mon, 14 Feb 2005 20:57:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0rwV-0001ay-6I for speechsc@megatron.ietf.org; Mon, 14 Feb 2005 20:55:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14248 for ; Mon, 14 Feb 2005 20:55:57 -0500 (EST) Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0sHR-0006Yo-Oc for speechsc@ietf.org; Mon, 14 Feb 2005 21:17:38 -0500 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j1F1tQ0D034984 for ; Mon, 14 Feb 2005 20:55:26 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1F1tQiW319732 for ; Mon, 14 Feb 2005 18:55:26 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1F1tQA3019118 for ; Mon, 14 Feb 2005 18:55:26 -0700 Received: from d03nm120.boulder.ibm.com (d03nm120.boulder.ibm.com [9.17.195.146]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1F1tQD2019115; Mon, 14 Feb 2005 18:55:26 -0700 In-Reply-To: <42113E68.5040001@cisco.com> To: Sarvi Shanmugham Subject: [Speechsc] VoiceXML weight attribute MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_M4_01112005 Beta 3NP January 11, 2005 From: Jeff Kusnitz Message-ID: Date: Mon, 14 Feb 2005 17:55:24 -0800 X-MIMETrack: Serialize by Router on D03NM120/03/M/IBM(Release 6.53HF294 | January 28, 2005) at 02/14/2005 18:55:25, Serialize complete at 02/14/2005 18:55:25 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: speechsc@ietf.org, Eric Burger 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 I tend to disagree. The SRGS "weight" attribute can only be used on an . For a VoiceXML browser to handle the weight attribute, it would probably have to combine all of the grammars for a given turn into a single grammar along with their respective weights. In principle that would work take care of the weights, but it would cause problems for prioritization (section 8.5.1 - recognizer data) - grammar prioritization would become rule prioritization, which is probably too much to ask of reco engines and grammar compilers. Thanks, Jeff speechsc-bounces@ietf.org wrote on 02/14/2005 04:12:24 PM: > The W3C grammar spec contains a weight attribute. Which should > address the need well. > > I am not sure if it makes sense to add a weight header field to a > DEFINE-GRAMMAR method as weights seems to make more sense where it > is being refered/used by other grammars. I mean, where a higher > level grammar refers to these individual grammars and assigns > relative weights to them. > > Does it make sense to "define" a grammar with a fixed weight. > Doesn't it actually more sense to specify weight a set of grammars > is being used in a RECOGNIZE? > > I would lean towards not adding a weight header for this purpose in > MRCPv2 when the W3C grammar spec addresses this problem.. > > Sarvi > Eric Burger wrote: > Any thoughts on this? > > > -----Original Message----- > From: Jeff Kusnitz [mailto:jk@us.ibm.com] > Sent: Thursday, January 20, 2005 4:31 PM > To: speechsc@ietf.org > Subject: [Speechsc] VoiceXML weight attribute > > > In the VoiceXML 2.0, the tag has been extended to include a > weight attribute to allow developers to bias grammars > (section 3.1.1.3). > The current DEFINE-GRAMMAR request doesn't have a "weight" > header though, > so it's not possible for a VoiceXML browser to do anything with the > 's weight attribute. Is this an oversight? Is it > too late to > add "weight" to the DEFINE-GRAMMAR request? > > Thanks, > Jeff > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > > > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Tue Feb 15 02:11:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18081 for ; Tue, 15 Feb 2005 02:11:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0xCx-0004gz-Fz for speechsc-web-archive@ietf.org; Tue, 15 Feb 2005 02:33:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0wp5-0000Ol-54; Tue, 15 Feb 2005 02:08:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0woQ-0000I4-26 for speechsc@megatron.ietf.org; Tue, 15 Feb 2005 02:07:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14579 for ; Tue, 15 Feb 2005 02:07:56 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0x9M-0004bd-3G for speechsc@ietf.org; Tue, 15 Feb 2005 02:29:36 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 14 Feb 2005 23:09:12 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,85,1107763200"; d="scan'208,217"; a="161502944:sNHT45829652" Received: from vtg-um-e2k1.sj21ad.cisco.com (vtg-um-e2k1.cisco.com [171.70.93.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j1F77KYO029705; Mon, 14 Feb 2005 23:07:20 -0800 (PST) Received: from [10.21.89.33] ([10.21.89.33]) by vtg-um-e2k1.sj21ad.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 14 Feb 2005 23:07:13 -0800 Message-ID: <42119FA1.5070700@cisco.com> Date: Mon, 14 Feb 2005 23:07:13 -0800 From: Sarvi Shanmugham Organization: Cisco Systems Inc. User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Kusnitz Subject: Re: [Speechsc] VoiceXML weight attribute References: In-Reply-To: X-OriginalArrivalTime: 15 Feb 2005 07:07:14.0007 (UTC) FILETIME=[F9C84E70:01C5132C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Cc: speechsc@ietf.org, Eric Burger 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="===============0592564597==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 This is a multi-part message in MIME format. --===============0592564597== Content-Type: multipart/alternative; boundary="------------050705090008050005060301" This is a multi-part message in MIME format. --------------050705090008050005060301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit What doesn't seem to make sense is to attribute a particular weight to a grammar in the DEFINE-GRAMMAR method. Which means that the weight would be associated with the grammar for life of that session, irrespective of what other grammars(with their weights) might be refered in the RECOGNIZE command along with this grammar. Is this the behaviour you are expecting. Sarvi Jeff Kusnitz wrote: >I tend to disagree. The SRGS "weight" attribute can only be used on an >. For a VoiceXML browser to handle the weight attribute, it would >probably have to combine all of the grammars for a given turn into a >single grammar along with their respective weights. In principle that >would work take care of the weights, but it would cause problems for >prioritization (section 8.5.1 - recognizer data) - grammar prioritization >would become rule prioritization, which is probably too much to ask of >reco engines and grammar compilers. > >Thanks, >Jeff > >speechsc-bounces@ietf.org wrote on 02/14/2005 04:12:24 PM: > > > >>The W3C grammar spec contains a weight attribute. Which should >>address the need well. >> >>I am not sure if it makes sense to add a weight header field to a >>DEFINE-GRAMMAR method as weights seems to make more sense where it >>is being refered/used by other grammars. I mean, where a higher >>level grammar refers to these individual grammars and assigns >>relative weights to them. >> >>Does it make sense to "define" a grammar with a fixed weight. >>Doesn't it actually more sense to specify weight a set of grammars >>is being used in a RECOGNIZE? >> >>I would lean towards not adding a weight header for this purpose in >>MRCPv2 when the W3C grammar spec addresses this problem.. >> >>Sarvi >>Eric Burger wrote: >>Any thoughts on this? >> >> >>-----Original Message----- >>From: Jeff Kusnitz [mailto:jk@us.ibm.com] >>Sent: Thursday, January 20, 2005 4:31 PM >>To: speechsc@ietf.org >>Subject: [Speechsc] VoiceXML weight attribute >> >> >>In the VoiceXML 2.0, the tag has been extended to include a >>weight attribute to allow developers to bias grammars >>(section 3.1.1.3). >>The current DEFINE-GRAMMAR request doesn't have a "weight" >>header though, >>so it's not possible for a VoiceXML browser to do anything with the >>'s weight attribute. Is this an oversight? Is it >>too late to >>add "weight" to the DEFINE-GRAMMAR request? >> >>Thanks, >>Jeff >> >>_______________________________________________ >>Speechsc mailing list >>Speechsc@ietf.org >>https://www1.ietf.org/mailman/listinfo/speechsc >> >> >> >>_______________________________________________ >>Speechsc mailing list >>Speechsc@ietf.org >>https://www1.ietf.org/mailman/listinfo/speechsc >> >> >>_______________________________________________ >>Speechsc mailing list >>Speechsc@ietf.org >>https://www1.ietf.org/mailman/listinfo/speechsc >> >> > > > --------------050705090008050005060301 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit What doesn't seem to make sense is to attribute a particular weight to a grammar in the DEFINE-GRAMMAR method. Which means that the weight would be associated with the grammar for life of that session, irrespective of what other grammars(with their weights) might be refered in the RECOGNIZE command along with this grammar.

Is this the behaviour you are expecting.

Sarvi
Jeff Kusnitz wrote: 
I tend to disagree.  The SRGS "weight" attribute can only be used on an 
<item>.  For a VoiceXML browser to handle the weight attribute, it would 
probably have to combine all of the grammars for a given turn into a 
single grammar along with their respective weights.  In principle that 
would work take care of the weights, but it would cause problems for 
prioritization (section 8.5.1 - recognizer data) - grammar prioritization 
would become rule prioritization, which is probably too much to ask of 
reco engines and grammar compilers.

Thanks,
Jeff

speechsc-bounces@ietf.org wrote on 02/14/2005 04:12:24 PM:

  
The W3C grammar spec contains a weight attribute. Which should 
address the need well.

I am not sure if it makes sense to add a weight header field to a 
DEFINE-GRAMMAR method as weights seems to make more sense where it 
is being refered/used by other grammars. I mean, where a higher 
level grammar refers to these individual grammars and assigns 
relative weights to them. 

Does it make sense to "define" a grammar with a fixed weight. 
Doesn't it actually more sense to specify weight a set of grammars 
is being used in a RECOGNIZE?

I would lean towards not adding a weight header for this purpose in 
MRCPv2 when the W3C grammar spec addresses this problem..

Sarvi
Eric Burger wrote: 
Any thoughts on this?


-----Original Message-----
From: Jeff Kusnitz [mailto:jk@us.ibm.com]
Sent: Thursday, January 20, 2005 4:31 PM
To: speechsc@ietf.org
Subject: [Speechsc] VoiceXML <grammar> weight attribute


In the VoiceXML 2.0, the <grammar> tag has been extended to include a 
weight attribute to allow developers to bias grammars 
(section 3.1.1.3). 
The current DEFINE-GRAMMAR request doesn't have a "weight" 
header though, 
so it's not possible for a VoiceXML browser to do anything with the 
<grammar>'s weight attribute.  Is this an oversight?  Is it 
too late to 
add "weight" to the DEFINE-GRAMMAR request?

Thanks,
Jeff

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc



_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc


_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc

--------------050705090008050005060301-- --===============0592564597== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc --===============0592564597==-- From speechsc-bounces@ietf.org Fri Feb 18 11:22:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00722 for ; Fri, 18 Feb 2005 11:22:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2BF2-0008FJ-0J for speechsc-web-archive@ietf.org; Fri, 18 Feb 2005 11:44:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D29sx-0005LQ-Gj; Fri, 18 Feb 2005 10:17:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D29lz-0001qq-PB for speechsc@megatron.ietf.org; Fri, 18 Feb 2005 10:10:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12718 for ; Fri, 18 Feb 2005 10:10:26 -0500 (EST) Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2A7f-0002uD-VG for speechsc@ietf.org; Fri, 18 Feb 2005 10:32:52 -0500 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j1IF9tua463620 for ; Fri, 18 Feb 2005 10:09:55 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay05.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1IF9tOu204330 for ; Fri, 18 Feb 2005 08:09:55 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1IF9sAb022202 for ; Fri, 18 Feb 2005 08:09:54 -0700 Received: from d03nm120.boulder.ibm.com (d03nm120.boulder.ibm.com [9.17.195.146]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1IF9snD022177; Fri, 18 Feb 2005 08:09:54 -0700 In-Reply-To: <42119FA1.5070700@cisco.com> To: Sarvi Shanmugham Subject: Re: [Speechsc] VoiceXML weight attribute MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_M4_01112005 Beta 3NP January 11, 2005 From: Jeff Kusnitz Message-ID: Date: Fri, 18 Feb 2005 07:09:51 -0800 X-MIMETrack: Serialize by Router on D03NM120/03/M/IBM(Release 6.53HF294 | January 28, 2005) at 02/18/2005 08:09:54, Serialize complete at 02/18/2005 08:09:54 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: speechsc@ietf.org, Eric Burger 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 That's a good point - I was thinking that in a typical VoiceXML app a grammar would never change so it wouldn't matter whether the weight was associated with the DEFINE-GRAMMAR or RECOGNIZE request, but that's wrong. An external grammar can be referenced from many places in the same VoiceXML code, with different weights each time. In terms of how to include weight information along with grammars on a RECOGNIZE request, how does a multipart document sound - something like this: ... Content-Type: multipart/mixed; boundary="break" --break Content-Type: text/uri-list Content-Length: 176 Grammar-Weight: 0.5 http://www.example.com/Directory-Name-List.grxml --break Content-Type: text/uri-list Content-Length: 176 Grammar-Weight: 0.2 http://www.example.com/Department-List.grxml http://www.example.com/TAC-Contact-List.grxml --break What do you think? Thanks, Jeff Sarvi Shanmugham wrote on 02/14/2005 11:07:13 PM: > What doesn't seem to make sense is to attribute a particular weight > to a grammar in the DEFINE-GRAMMAR method. Which means that the > weight would be associated with the grammar for life of that > session, irrespective of what other grammars(with their weights) > might be refered in the RECOGNIZE command along with this grammar. > > Is this the behaviour you are expecting. > > Sarvi > Jeff Kusnitz wrote: > I tend to disagree. The SRGS "weight" attribute can only be used on an > . For a VoiceXML browser to handle the weight attribute, it would > probably have to combine all of the grammars for a given turn into a > single grammar along with their respective weights. In principle that > would work take care of the weights, but it would cause problems for > prioritization (section 8.5.1 - recognizer data) - grammar prioritization > would become rule prioritization, which is probably too much to ask of > reco engines and grammar compilers. > > Thanks, > Jeff > > speechsc-bounces@ietf.org wrote on 02/14/2005 04:12:24 PM: > > > The W3C grammar spec contains a weight attribute. Which should > address the need well. > > I am not sure if it makes sense to add a weight header field to a > DEFINE-GRAMMAR method as weights seems to make more sense where it > is being refered/used by other grammars. I mean, where a higher > level grammar refers to these individual grammars and assigns > relative weights to them. > > Does it make sense to "define" a grammar with a fixed weight. > Doesn't it actually more sense to specify weight a set of grammars > is being used in a RECOGNIZE? > > I would lean towards not adding a weight header for this purpose in > MRCPv2 when the W3C grammar spec addresses this problem.. > > Sarvi > Eric Burger wrote: > Any thoughts on this? > > > -----Original Message----- > From: Jeff Kusnitz [mailto:jk@us.ibm.com] > Sent: Thursday, January 20, 2005 4:31 PM > To: speechsc@ietf.org > Subject: [Speechsc] VoiceXML weight attribute > > > In the VoiceXML 2.0, the tag has been extended to include a > weight attribute to allow developers to bias grammars > (section 3.1.1.3). > The current DEFINE-GRAMMAR request doesn't have a "weight" > header though, > so it's not possible for a VoiceXML browser to do anything with the > 's weight attribute. Is this an oversight? Is it > too late to > add "weight" to the DEFINE-GRAMMAR request? > > Thanks, > Jeff > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > > > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > > > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Fri Feb 18 14:25:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28512 for ; Fri, 18 Feb 2005 14:25:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2E6K-0006k6-Ji for speechsc-web-archive@ietf.org; Fri, 18 Feb 2005 14:47:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2DSO-0008MN-De; Fri, 18 Feb 2005 14:06:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2DQ6-0006jN-2r for speechsc@megatron.ietf.org; Fri, 18 Feb 2005 14:04:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24607 for ; Fri, 18 Feb 2005 14:04:04 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2Dlm-0005pw-DN for speechsc@ietf.org; Fri, 18 Feb 2005 14:26:32 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 18 Feb 2005 11:14:02 -0800 Received: from vtg-um-e2k1.sj21ad.cisco.com (vtg-um-e2k1.cisco.com [171.70.93.55]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j1IJ3TwN015030; Fri, 18 Feb 2005 11:03:29 -0800 (PST) Received: from [10.32.131.112] ([10.32.131.112]) by vtg-um-e2k1.sj21ad.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 18 Feb 2005 11:03:23 -0800 Message-ID: <42163BF7.1000502@cisco.com> Date: Fri, 18 Feb 2005 11:03:19 -0800 From: Sarvi Shanmugham User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Kusnitz Subject: Re: [Speechsc] VoiceXML weight attribute References: In-Reply-To: X-OriginalArrivalTime: 18 Feb 2005 19:03:23.0804 (UTC) FILETIME=[85043DC0:01C515EC] X-Spam-Score: 1.0 (+) X-Scan-Signature: 4ec3642ae9025e273a4a263d640f3300 Cc: speechsc@ietf.org, Eric Burger 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="===============1801996148==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 1.0 (+) X-Scan-Signature: 916029c14bdb340aa234d3ec4cd24f52 This is a multi-part message in MIME format. --===============1801996148== Content-Type: multipart/alternative; boundary="------------050105060409040002040809" This is a multi-part message in MIME format. --------------050105060409040002040809 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit This would require rewriting the multi-part mime ABNF specification. Wouldn't it? How about adding a new header, say One-Of-URI-Rule-Id. One-Of-URI-Rule-Id This header field MAY be specified in the RECOGNIZE command carrying a single URI or grammar block in its mime body. This header refers to a specific rule-id in the grammar specified in the mime-body as the list of grammars to activate. This rule-id MUST be a rule-id and the listed items MUST ALL BE grammar-uri-references and MAY NOT be grammar token. This is considered equivalent to specifying a tex/uri mime type with a list of grammar URI, but has the additional benefit of being able to provide weights for the individual grammar URIs. one-of-uri-tule-id = "One-Of-URI-Rule-Id" ":" token ; token is defined in ABNF Usage example: Example 1: C->S:MRCP/2.0 479 RECOGNIZE 543257 Channel-Identifier: 32AECB23433801@speechrecog Confidence-Threshold: 0.9 Fetch-Timeout:20 One-Of-URI-Rule-Id:rule_list Content-Type: application/srgs+xml Content-Length: 176 What do you think. Sarvi Jeff Kusnitz wrote: >That's a good point - I was thinking that in a typical VoiceXML app a >grammar would never change so it wouldn't matter whether the weight was >associated with the DEFINE-GRAMMAR or RECOGNIZE request, but that's wrong. > An external grammar can be referenced from many places in the same >VoiceXML code, with different weights each time. > >In terms of how to include weight information along with grammars on a >RECOGNIZE request, how does a multipart document sound - something like >this: > > ... > Content-Type: multipart/mixed; boundary="break" > > --break > Content-Type: text/uri-list > Content-Length: 176 > Grammar-Weight: 0.5 > http://www.example.com/Directory-Name-List.grxml > > --break > Content-Type: text/uri-list > Content-Length: 176 > Grammar-Weight: 0.2 > http://www.example.com/Department-List.grxml > http://www.example.com/TAC-Contact-List.grxml > > --break > >What do you think? > >Thanks, >Jeff > > >Sarvi Shanmugham wrote on 02/14/2005 11:07:13 PM: > > > >>What doesn't seem to make sense is to attribute a particular weight >>to a grammar in the DEFINE-GRAMMAR method. Which means that the >>weight would be associated with the grammar for life of that >>session, irrespective of what other grammars(with their weights) >>might be refered in the RECOGNIZE command along with this grammar. >> >>Is this the behaviour you are expecting. >> >>Sarvi >>Jeff Kusnitz wrote: >>I tend to disagree. The SRGS "weight" attribute can only be used on an >>. For a VoiceXML browser to handle the weight attribute, it would >> >> > > > >>probably have to combine all of the grammars for a given turn into a >>single grammar along with their respective weights. In principle that >>would work take care of the weights, but it would cause problems for >>prioritization (section 8.5.1 - recognizer data) - grammar >> >> >prioritization > > >>would become rule prioritization, which is probably too much to ask of >>reco engines and grammar compilers. >> >>Thanks, >>Jeff >> >>speechsc-bounces@ietf.org wrote on 02/14/2005 04:12:24 PM: >> >> >>The W3C grammar spec contains a weight attribute. Which should >>address the need well. >> >>I am not sure if it makes sense to add a weight header field to a >>DEFINE-GRAMMAR method as weights seems to make more sense where it >>is being refered/used by other grammars. I mean, where a higher >>level grammar refers to these individual grammars and assigns >>relative weights to them. >> >>Does it make sense to "define" a grammar with a fixed weight. >>Doesn't it actually more sense to specify weight a set of grammars >>is being used in a RECOGNIZE? >> >>I would lean towards not adding a weight header for this purpose in >>MRCPv2 when the W3C grammar spec addresses this problem.. >> >>Sarvi >>Eric Burger wrote: >>Any thoughts on this? >> >> >>-----Original Message----- >>From: Jeff Kusnitz [mailto:jk@us.ibm.com] >>Sent: Thursday, January 20, 2005 4:31 PM >>To: speechsc@ietf.org >>Subject: [Speechsc] VoiceXML weight attribute >> >> >>In the VoiceXML 2.0, the tag has been extended to include a >>weight attribute to allow developers to bias grammars >>(section 3.1.1.3). >>The current DEFINE-GRAMMAR request doesn't have a "weight" >>header though, >>so it's not possible for a VoiceXML browser to do anything with the >>'s weight attribute. Is this an oversight? Is it >>too late to >>add "weight" to the DEFINE-GRAMMAR request? >> >>Thanks, >>Jeff >> >>_______________________________________________ >>Speechsc mailing list >>Speechsc@ietf.org >>https://www1.ietf.org/mailman/listinfo/speechsc >> >> >> >>_______________________________________________ >>Speechsc mailing list >>Speechsc@ietf.org >>https://www1.ietf.org/mailman/listinfo/speechsc >> >> >>_______________________________________________ >>Speechsc mailing list >>Speechsc@ietf.org >>https://www1.ietf.org/mailman/listinfo/speechsc >> >> >> >> >> > > > --------------050105060409040002040809 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit This would require rewriting the multi-part mime ABNF specification. Wouldn't it?


How about adding a new header, say One-Of-URI-Rule-Id.

One-Of-URI-Rule-Id
This header field MAY be specified in the RECOGNIZE command carrying a single URI or grammar block in its mime body. This header refers to a specific rule-id in the grammar specified in the mime-body as the list of grammars to activate. This rule-id MUST be a <one-of> rule-id and the listed items MUST ALL BE grammar-uri-references and MAY NOT be grammar token.  This  is considered equivalent  to specifying a  tex/uri mime type with a list of grammar URI, but has the additional benefit of  being able to provide  weights  for  the individual  grammar URIs.

           one-of-uri-tule-id =     "One-Of-URI-Rule-Id"    ":"      token     ; token is defined in ABNF
     
Usage example:

Example 1:
C->S:MRCP/2.0 479 RECOGNIZE 543257
         Channel-Identifier: 32AECB23433801@speechrecog
         Confidence-Threshold: 0.9
         Fetch-Timeout:20
         One-Of-URI-Rule-Id:rule_list
         Content-Type: application/srgs+xml
         Content-Length: 176

         <?xml version="1.0"? version="1.0" mode="voice" root="basicCmd">
         <rule id="rule_list" scope="public">
             <one-of>
                 <item weight=10>
                     <ruleref uri="http://grammar.example.com/world-cities.grxml#canada"/>
                </item>
                <item weight=1.5>
                    <ruleref uri="http://grammar.example.com/world-cities.grxml#america"/>
                </item>
               <item weight=0.5>
                    <ruleref uri="http://grammar.example.com/world-cities.grxml#india"/>
               </item>
           </one-of>
        </rule>


What do you think.

Sarvi

Jeff Kusnitz wrote: 
That's a good point - I was thinking that in a typical VoiceXML app a 
grammar would never change so it wouldn't matter whether the weight was 
associated with the DEFINE-GRAMMAR or RECOGNIZE request, but that's wrong. 
 An external grammar can be referenced from many places in the same 
VoiceXML code, with different weights each time.

In terms of how to include weight information along with grammars on a 
RECOGNIZE request, how does a multipart document sound - something like 
this:

        ...
        Content-Type: multipart/mixed; boundary="break" 
 
        --break 
        Content-Type: text/uri-list 
        Content-Length: 176 
        Grammar-Weight: 0.5
        http://www.example.com/Directory-Name-List.grxml 
 
        --break 
        Content-Type: text/uri-list 
        Content-Length: 176 
        Grammar-Weight: 0.2
        http://www.example.com/Department-List.grxml 
        http://www.example.com/TAC-Contact-List.grxml 
 
        --break 

What do you think?

Thanks,
Jeff


Sarvi Shanmugham <sarvi@cisco.com> wrote on 02/14/2005 11:07:13 PM:

  
What doesn't seem to make sense is to attribute a particular weight 
to a grammar in the DEFINE-GRAMMAR method. Which means that the 
weight would be associated with the grammar for life of that 
session, irrespective of what other grammars(with their weights) 
might be refered in the RECOGNIZE command along with this grammar.

Is this the behaviour you are expecting.

Sarvi
Jeff Kusnitz wrote: 
I tend to disagree.  The SRGS "weight" attribute can only be used on an 
<item>.  For a VoiceXML browser to handle the weight attribute, it would 
    

  
probably have to combine all of the grammars for a given turn into a 
single grammar along with their respective weights.  In principle that 
would work take care of the weights, but it would cause problems for 
prioritization (section 8.5.1 - recognizer data) - grammar 
    
prioritization 
  
would become rule prioritization, which is probably too much to ask of 
reco engines and grammar compilers.

Thanks,
Jeff

speechsc-bounces@ietf.org wrote on 02/14/2005 04:12:24 PM:


The W3C grammar spec contains a weight attribute. Which should 
address the need well.

I am not sure if it makes sense to add a weight header field to a 
DEFINE-GRAMMAR method as weights seems to make more sense where it 
is being refered/used by other grammars. I mean, where a higher 
level grammar refers to these individual grammars and assigns 
relative weights to them. 

Does it make sense to "define" a grammar with a fixed weight. 
Doesn't it actually more sense to specify weight a set of grammars 
is being used in a RECOGNIZE?

I would lean towards not adding a weight header for this purpose in 
MRCPv2 when the W3C grammar spec addresses this problem..

Sarvi
Eric Burger wrote: 
Any thoughts on this?


-----Original Message-----
From: Jeff Kusnitz [mailto:jk@us.ibm.com]
Sent: Thursday, January 20, 2005 4:31 PM
To: speechsc@ietf.org
Subject: [Speechsc] VoiceXML <grammar> weight attribute


In the VoiceXML 2.0, the <grammar> tag has been extended to include a 
weight attribute to allow developers to bias grammars 
(section 3.1.1.3). 
The current DEFINE-GRAMMAR request doesn't have a "weight" 
header though, 
so it's not possible for a VoiceXML browser to do anything with the 
<grammar>'s weight attribute.  Is this an oversight?  Is it 
too late to 
add "weight" to the DEFINE-GRAMMAR request?

Thanks,
Jeff

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc



_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc


_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc

--------------050105060409040002040809-- --===============1801996148== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc --===============1801996148==-- From speechsc-bounces@ietf.org Wed Feb 23 20:43:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18889 for ; Wed, 23 Feb 2005 20:43:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D48Oy-0002pN-UK for speechsc-web-archive@ietf.org; Wed, 23 Feb 2005 21:06:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D44Sd-0000pg-2V; Wed, 23 Feb 2005 16:54:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D44SX-0000pS-S7 for speechsc@megatron.ietf.org; Wed, 23 Feb 2005 16:54:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23455 for ; Wed, 23 Feb 2005 16:54:11 -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.33) id 1D44pF-0003TF-96 for speechsc@ietf.org; Wed, 23 Feb 2005 17:17:46 -0500 Received: from daburkew2k (ppp-107.net-207.magic.fr [62.210.222.107]) by mail.voxpilot.com (Postfix) with ESMTP id 3734821403F; Wed, 23 Feb 2005 21:53:58 +0000 (GMT) Message-ID: <0a6501c519fa$8ca63b70$0a01a8c0@db01.voxpilot.com> From: "Dave Burke" To: "Sarvi Shanmugham" , "Jeff Kusnitz" References: <42163BF7.1000502@cisco.com> Subject: Re: [Speechsc] VoiceXML weight attribute Date: Wed, 23 Feb 2005 22:53:49 -0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 1.1 (+) X-Scan-Signature: d4673ea769cc9931269061744af205ce Cc: speechsc@ietf.org, Eric Burger 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="===============0519529413==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 7f3077fcbbd2d4a1504dfa044ebcf773 This is a multi-part message in MIME format. --===============0519529413== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0A62_01C519FA.89FFD390" This is a multi-part message in MIME format. ------=_NextPart_000_0A62_01C519FA.89FFD390 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Interesting approach. The One-Of-URI-Rule-ID header seems superfluous = though. In other words, the MRCP spec could just have a short = "Implementation Note" describing a way of assigning weights to = individual grammars by using a simple, valid, SRGS grammar with weighted = alternatives. However, this approach doesn't allow session: grammars to = be included. Yet another possibility (he writes with trepidation) would be to = introduce a URI parameter, e.g. Content-Type: text/uri-list=20 Content-Length: 176=20 =20 session:help@root-level.store;weight=3D1 http://www.example.com/Directory-Name-List.grxml;weight=3D2 -- Dave ----- Original Message -----=20 From: Sarvi Shanmugham=20 To: Jeff Kusnitz=20 Cc: speechsc@ietf.org ; Eric Burger=20 Sent: Friday, February 18, 2005 7:03 PM Subject: Re: [Speechsc] VoiceXML weight attribute This would require rewriting the multi-part mime ABNF specification. = Wouldn't it? How about adding a new header, say One-Of-URI-Rule-Id. One-Of-URI-Rule-Id This header field MAY be specified in the RECOGNIZE command carrying a = single URI or grammar block in its mime body. This header refers to a = specific rule-id in the grammar specified in the mime-body as the list = of grammars to activate. This rule-id MUST be a rule-id and the = listed items MUST ALL BE grammar-uri-references and MAY NOT be grammar = token. This is considered equivalent to specifying a tex/uri mime = type with a list of grammar URI, but has the additional benefit of = being able to provide weights for the individual grammar URIs. one-of-uri-tule-id =3D "One-Of-URI-Rule-Id" ":" = token ; token is defined in ABNF =20 Usage example: Example 1: C->S:MRCP/2.0 479 RECOGNIZE 543257=20 Channel-Identifier: 32AECB23433801@speechrecog=20 Confidence-Threshold: 0.9=20 Fetch-Timeout:20 One-Of-URI-Rule-Id:rule_list Content-Type: application/srgs+xml=20 Content-Length: 176=20 What do you think. Sarvi Jeff Kusnitz wrote:=20 That's a good point - I was thinking that in a typical VoiceXML app a=20 grammar would never change so it wouldn't matter whether the weight was=20 associated with the DEFINE-GRAMMAR or RECOGNIZE request, but that's = wrong.=20 An external grammar can be referenced from many places in the same=20 VoiceXML code, with different weights each time. In terms of how to include weight information along with grammars on a=20 RECOGNIZE request, how does a multipart document sound - something like=20 this: ... Content-Type: multipart/mixed; boundary=3D"break"=20 =20 --break=20 Content-Type: text/uri-list=20 Content-Length: 176=20 Grammar-Weight: 0.5 http://www.example.com/Directory-Name-List.grxml=20 =20 --break=20 Content-Type: text/uri-list=20 Content-Length: 176=20 Grammar-Weight: 0.2 http://www.example.com/Department-List.grxml=20 http://www.example.com/TAC-Contact-List.grxml=20 =20 --break=20 What do you think? Thanks, Jeff Sarvi Shanmugham wrote on 02/14/2005 11:07:13 PM: =20 What doesn't seem to make sense is to attribute a particular weight=20 to a grammar in the DEFINE-GRAMMAR method. Which means that the=20 weight would be associated with the grammar for life of that=20 session, irrespective of what other grammars(with their weights)=20 might be refered in the RECOGNIZE command along with this grammar. Is this the behaviour you are expecting. Sarvi Jeff Kusnitz wrote:=20 I tend to disagree. The SRGS "weight" attribute can only be used on an=20 . For a VoiceXML browser to handle the weight attribute, it would = =20 =20 probably have to combine all of the grammars for a given turn into a=20 single grammar along with their respective weights. In principle that=20 would work take care of the weights, but it would cause problems for=20 prioritization (section 8.5.1 - recognizer data) - grammar=20 =20 prioritization=20 =20 would become rule prioritization, which is probably too much to ask of=20 reco engines and grammar compilers. Thanks, Jeff speechsc-bounces@ietf.org wrote on 02/14/2005 04:12:24 PM: The W3C grammar spec contains a weight attribute. Which should=20 address the need well. I am not sure if it makes sense to add a weight header field to a=20 DEFINE-GRAMMAR method as weights seems to make more sense where it=20 is being refered/used by other grammars. I mean, where a higher=20 level grammar refers to these individual grammars and assigns=20 relative weights to them.=20 Does it make sense to "define" a grammar with a fixed weight.=20 Doesn't it actually more sense to specify weight a set of grammars=20 is being used in a RECOGNIZE? I would lean towards not adding a weight header for this purpose in=20 MRCPv2 when the W3C grammar spec addresses this problem.. Sarvi Eric Burger wrote:=20 Any thoughts on this? -----Original Message----- From: Jeff Kusnitz [mailto:jk@us.ibm.com] Sent: Thursday, January 20, 2005 4:31 PM To: speechsc@ietf.org Subject: [Speechsc] VoiceXML weight attribute In the VoiceXML 2.0, the tag has been extended to include a=20 weight attribute to allow developers to bias grammars=20 (section 3.1.1.3).=20 The current DEFINE-GRAMMAR request doesn't have a "weight"=20 header though,=20 so it's not possible for a VoiceXML browser to do anything with the=20 's weight attribute. Is this an oversight? Is it=20 too late to=20 add "weight" to the DEFINE-GRAMMAR request? Thanks, Jeff _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 =20 -------------------------------------------------------------------------= ----- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc ------=_NextPart_000_0A62_01C519FA.89FFD390 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Interesting approach. The = One-Of-URI-Rule-ID header=20 seems superfluous though. In other words, the MRCP spec could just have = a short=20 "Implementation Note" describing a way of assigning weights to = individual=20 grammars by using a simple, valid, SRGS grammar with weighted = alternatives.=20 However, this approach doesn't allow = session:=20 grammars to be included.
 
Yet another possibility (he writes with = trepidation) would be to introduce a URI parameter, e.g.
 
 Content-Type:=20 text/uri-list 
 Content-Length:=20 176 
         
&n= bsp;session:help@root-level.store;weight=3D1
 http= ://www.example.com/Directory-Name-List.grxml;weight=3D2
-- Dave
----- Original Message -----
From:=20 Sarvi = Shanmugham=20
Cc: speechsc@ietf.org ; Eric=20 Burger
Sent: Friday, February 18, 2005 = 7:03=20 PM
Subject: Re: [Speechsc] = VoiceXML=20 <grammar> weight attribute

This would require = rewriting the=20 multi-part mime ABNF specification. Wouldn't it?


How about = adding a=20 new header, say One-Of-URI-Rule-Id.

One-Of-URI-Rule-Id
This = header=20 field MAY be specified in the RECOGNIZE command carrying a single URI = or=20 grammar block in its mime body. This header refers to a specific = rule-id in=20 the grammar specified in the mime-body as the list of grammars to = activate.=20 This rule-id MUST be a <one-of> rule-id and the listed items = MUST ALL BE=20 grammar-uri-references and MAY NOT be grammar token.  This  = is=20 considered equivalent  to specifying a  tex/uri mime type = with a=20 list of grammar URI, but has the additional benefit of  being = able to=20 provide  weights  for  the individual  grammar=20 URIs.

          =20 one-of-uri-tule-id =3D    =20 "One-Of-URI-Rule-Id"    = ":"     =20 token     ; token is defined in=20 ABNF
     
Usage = example:

Example=20 1:
C->S:MRCP/2.0 479 RECOGNIZE 543257=20
         = Channel-Identifier:=20 32AECB23433801@speechrecog=20
         = Confidence-Threshold: 0.9=20
        =20 Fetch-Timeout:20
        =20 = One-Of-URI-Rule-Id:rule_list
       = ; =20 Content-Type: application/srgs+xml=20
         Content-Length: = 176=20

         <?xml=20 version=3D"1.0"? version=3D"1.0" mode=3D"voice"=20 = root=3D"basicCmd">
        = =20 <rule id=3D"rule_list"=20 = scope=3D"public">
        &= nbsp;   =20 = <one-of>
         &= nbsp;      =20 <item=20 = weight=3D10>
         =            =20 <ruleref uri=3D"http://grammar.example.c= om/world-cities.grxml#canada"/>
   =              = = </item>
         &n= bsp;     =20 <item=20 = weight=3D1.5>
         = ;          =20 <ruleref uri=3D"http://grammar.example.c= om/world-cities.grxml#america"/>
   = ;            = =20 = </item>
         &n= bsp;    =20 <item=20 = weight=3D0.5>
         = ;          =20 <ruleref uri=3D"http://grammar.example.c= om/world-cities.grxml#india"/>
   &= nbsp;          =20 = </item>
         &n= bsp;=20 </one-of>
       =20 </rule>


What do you think.

Sarvi

Jeff = Kusnitz=20 wrote:=20 
That's a good point - I was thinking that =
in a typical VoiceXML app a=20
grammar would never change so it wouldn't matter whether the weight was=20
associated with the DEFINE-GRAMMAR or RECOGNIZE request, but that's =
wrong.=20
 An external grammar can be referenced from many places in the same=20
VoiceXML code, with different weights each time.

In terms of how to include weight information along with grammars on a=20
RECOGNIZE request, how does a multipart document sound - something like=20
this:

        ...
        Content-Type: multipart/mixed; boundary=3D"break"=20
=20
        --break=20
        Content-Type: text/uri-list=20
        Content-Length: 176=20
        Grammar-Weight: 0.5
        http://www.exam=
ple.com/Directory-Name-List.grxml=20
=20
        --break=20
        Content-Type: text/uri-list=20
        Content-Length: 176=20
        Grammar-Weight: 0.2
        http://www.example.=
com/Department-List.grxml=20
        http://www.example=
.com/TAC-Contact-List.grxml=20
=20
        --break=20

What do you think?

Thanks,
Jeff


Sarvi Shanmugham <sarvi@cisco.com> wrote on =
02/14/2005 11:07:13 PM:

  
What doesn't seem to make =
sense is to attribute a particular weight=20
to a grammar in the DEFINE-GRAMMAR method. Which means that the=20
weight would be associated with the grammar for life of that=20
session, irrespective of what other grammars(with their weights)=20
might be refered in the RECOGNIZE command along with this grammar.

Is this the behaviour you are expecting.

Sarvi
Jeff Kusnitz wrote:=20
I tend to disagree.  The SRGS "weight" attribute can only be used on an=20
<item>.  For a VoiceXML browser to handle the weight attribute, it =
would=20
    

  
probably have to combine =
all of the grammars for a given turn into a=20
single grammar along with their respective weights.  In principle that=20
would work take care of the weights, but it would cause problems for=20
prioritization (section 8.5.1 - recognizer data) - grammar=20
    
prioritization=20
  
would become rule =
prioritization, which is probably too much to ask of=20
reco engines and grammar compilers.

Thanks,
Jeff

speechsc-bounces@ietf.org =
wrote on 02/14/2005 04:12:24 PM:


The W3C grammar spec contains a weight attribute. Which should=20
address the need well.

I am not sure if it makes sense to add a weight header field to a=20
DEFINE-GRAMMAR method as weights seems to make more sense where it=20
is being refered/used by other grammars. I mean, where a higher=20
level grammar refers to these individual grammars and assigns=20
relative weights to them.=20

Does it make sense to "define" a grammar with a fixed weight.=20
Doesn't it actually more sense to specify weight a set of grammars=20
is being used in a RECOGNIZE?

I would lean towards not adding a weight header for this purpose in=20
MRCPv2 when the W3C grammar spec addresses this problem..

Sarvi
Eric Burger wrote:=20
Any thoughts on this?


-----Original Message-----
From: Jeff Kusnitz [mailto:jk@us.ibm.com]
Sent: Thursday, January 20, 2005 4:31 PM
To: speechsc@ietf.org
Subject: [Speechsc] VoiceXML <grammar> weight attribute


In the VoiceXML 2.0, the <grammar> tag has been extended to =
include a=20
weight attribute to allow developers to bias grammars=20
(section 3.1.1.3).=20
The current DEFINE-GRAMMAR request doesn't have a "weight"=20
header though,=20
so it's not possible for a VoiceXML browser to do anything with the=20
<grammar>'s weight attribute.  Is this an oversight?  Is it=20
too late to=20
add "weight" to the DEFINE-GRAMMAR request?

Thanks,
Jeff

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.iet=
f.org/mailman/listinfo/speechsc



_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.iet=
f.org/mailman/listinfo/speechsc


_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.iet=
f.org/mailman/listinfo/speechsc

_______________________________________________
Speechsc = mailing=20 = list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speec= hsc
------=_NextPart_000_0A62_01C519FA.89FFD390-- --===============0519529413== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc --===============0519529413==-- From speechsc-bounces@ietf.org Wed Feb 23 21:14:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28998 for ; Wed, 23 Feb 2005 21:14:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D48t5-00061p-2l for speechsc-web-archive@ietf.org; Wed, 23 Feb 2005 21:38:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kmU-0006JO-Sd; Tue, 22 Feb 2005 19:53:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3Raw-0007AS-RZ for speechsc@megatron.ietf.org; Mon, 21 Feb 2005 23:24:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02346 for ; Mon, 21 Feb 2005 23:24:15 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3RxG-0001hH-C6 for speechsc@ietf.org; Mon, 21 Feb 2005 23:47:27 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 21 Feb 2005 20:23:59 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from vtg-um-e2k1.sj21ad.cisco.com (vtg-um-e2k1.cisco.com [171.70.93.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j1M4NgYO023542; Mon, 21 Feb 2005 20:23:42 -0800 (PST) Received: from [10.82.240.71] ([10.82.240.71]) by vtg-um-e2k1.sj21ad.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 21 Feb 2005 20:23:37 -0800 Message-ID: <421AB3C6.4040208@cisco.com> Date: Mon, 21 Feb 2005 20:23:34 -0800 From: Sarvi Shanmugham User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Burnett , "David R. Oran" , Eric Burger , speechsc@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Feb 2005 04:23:37.0248 (UTC) FILETIME=[476E0200:01C51896] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Subject: [Speechsc] draft mrcpv2 -06 is out 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Hi, The -06 version of the draft was submitted last night. This addresses the following. 1. Baggia Paolo's review comments. 2. Klaus's feedback on NLSML addressed. 3. Jeff Kusnitz's concern for supporting grammar weights. - As described in the email discussions. 4. Some ABNF cleanup 5. The Secutiry considerations section 6. The IANA considerations section. - SCTP and SCTP+TLS SDP media type is not supported in this draft, and is defered to a separate specification. - All other necessary registrations have been addressed. Thanks, Sarvi _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Feb 23 21:43:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10864 for ; Wed, 23 Feb 2005 21:43:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D49LI-00011w-TS for speechsc-web-archive@ietf.org; Wed, 23 Feb 2005 22:07:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kkt-0005m0-Rj; Tue, 22 Feb 2005 19:51:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3hMU-0002Iy-MI; Tue, 22 Feb 2005 16:14:30 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22984; Tue, 22 Feb 2005 16:14:28 -0500 (EST) Message-Id: <200502222114.QAA22984@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 22 Feb 2005 16:14:28 -0500 Cc: speechsc@ietf.org Subject: [Speechsc] I-D ACTION:draft-ietf-speechsc-mrcpv2-06.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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Speech Services Control Working Group of the IETF. Title : Media Resource Control Protocol Version 2(MRCPv2) Author(s) : S. Shanmugham, D. Burnett Filename : draft-ietf-speechsc-mrcpv2-06.txt Pages : 177 Date : 2005-2-22 This document describes a proposal for a Media Resource Control Protocol Version 2 (MRCPv2) and aims to meet the requirements specified in the SPEECHSC working group requirements document. It is based on the Media Resource Control Protocol (MRCP), also called MRCPv1 developed jointly by Cisco Systems, Inc., Nuance Communications, and Speechworks Inc. The MRCPv2 protocol will control media service resources like speech synthesizers, recognizers, signal generators, signal detectors, fax servers etc. over a network. This protocol depends on a session management protocol such as the Session Initiation Protocol (SIP) to establish a separate MRCPv2 control session between the client and the server. It also depends on SIP to establish the media pipe and associated parameters between the media source or sink and the media server. Once this is done, the MRCPv2 protocol exchange can happen over the control session established above allowing the client to command and control the media processing resources that may exist on the media server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speechsc-mrcpv2-06.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. 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-ietf-speechsc-mrcpv2-06.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-ietf-speechsc-mrcpv2-06.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-22160807.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-speechsc-mrcpv2-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-speechsc-mrcpv2-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-22160807.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc --NextPart-- From speechsc-bounces@ietf.org Wed Feb 23 22:07:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19322 for ; Wed, 23 Feb 2005 22:07:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D49i0-0003Un-Ej for speechsc-web-archive@ietf.org; Wed, 23 Feb 2005 22:30:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3knq-0006tV-82; Tue, 22 Feb 2005 19:54:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3a2v-0005zI-2F for speechsc@megatron.ietf.org; Tue, 22 Feb 2005 08:25:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28918 for ; Tue, 22 Feb 2005 08:25:41 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3aPI-0004nc-Up for speechsc@ietf.org; Tue, 22 Feb 2005 08:48:58 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 22 Feb 2005 05:36:25 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j1MDP7ZV005308; Tue, 22 Feb 2005 05:25:08 -0800 (PST) Received: from [10.32.245.150] (stealth-10-32-245-150.cisco.com [10.32.245.150]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j1MDJYYA024136; Tue, 22 Feb 2005 05:19:35 -0800 In-Reply-To: <421AB3C6.4040208@cisco.com> References: <421AB3C6.4040208@cisco.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <90cb5a76da167e5b16daa7b69d7e3d06@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Date: Tue, 22 Feb 2005 08:25:02 -0500 To: Sarvi Shanmugham X-Mailer: Apple Mail (2.619.2) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1109078378.59483"; x:"432200"; a:"rsa-sha1"; b:"nofws:1000"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"nJ4SyPWKP/bXQCNQ0zPOebY7fOclkegzwuQrgY5qbVyZkbV2acJpuOHK9j7Ix5DVQxfPuyM6" "SpZaW9HYC7BleevD4ojlQh7z8tuJPobWKHeF4TKch1/PaVwAxTzM9iy3McH3VZADY9OYvHPbooK" "rrl1ZknFWqphgOgx841JA74w="; c:"From: David R Oran "; c:"Subject: Re: draft mrcpv2 -06 is out"; c:"Date: Tue, 22 Feb 2005 08:25:02 -0500" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: speechsc@ietf.org, Eric Burger Subject: [Speechsc] Re: draft mrcpv2 -06 is out 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Great Sarvi. Thanks. Note folks that we WILL be having a SPEECHSC meeting at this IETF. It is currently scheduled for 1530-1630 on TUESDAY. I do not expect it to be moved. Formal agenda will be forthcoming, but there will be two major agenda items: a) MRCP draft update status and final drive to WGLC b) discussion on IESG blockage of the requirements draft based on security issues with SI/SV. Looking forward to seeing as many of you that can make it! Dave. On Feb 21, 2005, at 11:23 PM, Sarvi Shanmugham wrote: > > > Hi, > The -06 version of the draft was submitted last night. This > addresses the following. > > 1. Baggia Paolo's review comments. > 2. Klaus's feedback on NLSML addressed. > 3. Jeff Kusnitz's concern for supporting grammar weights. > - As described in the email discussions. > 4. Some ABNF cleanup > 5. The Secutiry considerations section > 6. The IANA considerations section. > - SCTP and SCTP+TLS SDP media type is not supported in this > draft, and is defered to a separate specification. > - All other necessary registrations have been addressed. > > Thanks, > Sarvi > > David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran@cisco.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Fri Feb 25 05:35:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27252 for ; Fri, 25 Feb 2005 05:35:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4coZ-0005EY-9s for speechsc-web-archive@ietf.org; Fri, 25 Feb 2005 05:35:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4ckP-0002qI-9N; Fri, 25 Feb 2005 05:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4ckH-0002pT-V3 for speechsc@megatron.ietf.org; Fri, 25 Feb 2005 05:30:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26881 for ; Fri, 25 Feb 2005 05:30:50 -0500 (EST) Received: from dns1.tilab.com ([163.162.42.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4ckN-00059z-HE for speechsc@ietf.org; Fri, 25 Feb 2005 05:31:00 -0500 Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0ICG0039DQF92T@dns1.cselt.it> for speechsc@ietf.org; Fri, 25 Feb 2005 11:28:21 +0100 (MET) Received: from EXC05A.cselt.it ([163.162.36.249]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Fri, 25 Feb 2005 11:33:22 +0100 Date: Fri, 25 Feb 2005 11:30:42 +0100 From: Baggia Paolo To: speechsc@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [mrcpv2] A few Loquendo's comments on draft-ietf-speechsc-mrcpv2-05.txt - part I thread-index: AcT4wSQ1iAE0K/anQtOhTM2LFzDJPgAAAWUABX9KU+AAKWWRMAK8veLgAA20WeA= Content-Class: urn:content-classes:message X-OriginalArrivalTime: 25 Feb 2005 10:33:22.0046 (UTC) FILETIME=[6DD6C9E0:01C51B25] X-Spam-Score: 0.0 (/) X-Scan-Signature: 578c2c9d0cb01ffe6e1ca36540edd070 Content-Transfer-Encoding: quoted-printable Cc: Manzone Vittorio , Bergallo Patrizio , Baggia Paolo Subject: [Speechsc] Loquendo's comments on draft-ietf-speechsc-mrcpv2-06.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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 Content-Transfer-Encoding: quoted-printable Dear Sarvi/Eric/SpeechSC people, This is the second part of Loquendo's contribution and unfortunatelly it is after the 06 is being published, but we were not aware it was going to be released. I apologize. I checked that all the points we mentioned are still there in 06, especially for ABNF definition (see D. below). E. and F. are trouble from our point of view. Paolo =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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D C. SRGS examples with minor troubles - the Content-Type are fine: application/srgs+xml for XML format and application/srgs for ABNF format - the file extension should be either .grxml or .gram everything is fine - required attributes described in http://www.w3.org/TR/2004/REC-speech-grammar-20040316/#S4.1 they are "xml:lang", "version", but also "xmlns".=20 There are 11 SRGS examples but only one declares the "xmlns" as required. - In example at page 71 =20 Robert =20 =20 the "lexicon" attribute is wrong, maybe it was "xml:lang", but in that case I'm not sure a double value it is allowed. Please let me know what do you think on it. I read RFC3066, SRGS 1.0 and XML spec. The same error is repeated in page 74,=20 - In the same example a "root" attribute would be fine, the spec leave it optional but it suggests to declare one, for instance root=3D"request" - In example at page 87. It is aligned with the XML example in the SRGS spec, Appendix J.1 http://www.w3.org/TR/2004/REC-speech-grammar-20040316/#AppJ.1 The only difference is that the content of the element was a link to Section 1.4 on Semantic Interpretation. One option is to eliminate the problem deleting from the example the ... . Another option is to cite the Semantic Interpretation spec and add few words on it. This spec is today Last Call WD (November 8) but it will become Candidate Rec in a few months. -------------------------------------------------------------- D. Problems with the ABNF definitions These comments may be very relevant for the consistency of the draft in the ABNF definitions. We report many small errors or missing definitions, but an in-depth and complete revision is expected. There may be some more that we were not able to=20 identify. d.0) On Section 5 "MRCPv2 Specification" - "header-extension" definition should be "extension-header" =3D=3D> DELETED FROM 06 - the definition of "message-length" in Section 5.1, but not into the Appendix A.1 - the major problem is that it is not clear from the definition what the number of bytes represent. In Section 5.2 it says: "The message-length field specifies the length of the message". Does the message include the "start-line"? Or it doesn't. For interoperability reasons, it should be very clear. =3D=3D> YOU CLARIFIED THIS ISSUE in Section 5.1 - by looking to some of the simple examples, last event of pag. 16: the first two lines include a white space before CRLF >>>> MRCP/2.0 81 543257 200 IN-PROGRESS=20 Channel-Identifier: 32AECB23433802@speechsynth=20 <<<< the Message Length of 81 does not match with any possible combination: - with start-line: 87 octects They are only examples, but the definition is now very clear. d.1) On generic-header (Section 6.1) - Channel-Identifier generic header field is said thats consist of 2 parts (separated by the '@' symbol).=20 "The first part is a 32 bit hexadecimal integer that is positive" but all the examples show a hexadecimal integer of 14 characters (i.e. 32AECB23433802) instead of 8. Perhaps it was meant to be "more than 32 bit hexadecimal" or the examples are wrong. - set-cookie and set-cookie2: ABNF definition of "generic-header"=20 in pag. 22 includes them, but the definition in pag. 158 does not - Accept-Charset is described in pag. 24, but it is not present in the definition of "generic-header" neither at pag. 22 and not at pag. 158 - Vendor-Specific-Parameters is defined in pag. 30 (6.1) as follows: vendor-specific =3D "Vendor-Specific-Parameters" ":"=20 vendor-specific-av-pair =20 *[";" vendor-specific-av-pair] CRLF =20 vendor-specific-av-pair =3D vendor-av-pair-name "=3D" =20 vendor-av-pair-value =20 the following three examples seem to contraddict the definition: Example: =20 com.cisco.paramxyz:256=20 com.cisco.paramabc:High=20 com.nuance.paramxyz:Low=20 There are two examples in Section 6.3 (pag. 31), the second is fine: Vendor-Specific-Parameters:com.mycorp.param1=3D"Company Name"; = com.mycorp.param2=3D"124324234@mycorp.com"=20 d.2) On synthesizer-method (Section 8.2) - in 8.1 and 8.2 (pag. 33) shows LOAD-LEXICON method, but 8.14 describes DEFINE-LEXICON method (pag. 53); LOAD-LEXICON method is referenced as column (G) in pag. 34-35 d.3) On synthesizer-header (Section 8.4) It is defined on pag. 39 as: fetch-timeout =3D "Fetch-Timeout" ":" 1*DIGIT CRLF=20 and it is defined on pag. 162 as: fetch-timeout =3D "Fetch-Timeout" ":" [1*DIGIT] CRLF =20 d.4) On recognizer-header (Section 9.4) - Fetch-Timeout: is defined as ("Fetch-Timeout" ":" 1*ALPHA CRLF) in = pag. 65 which differs from the definition ("Fetch-Timeout" ":" 1*DIGIT CRLF) in pag. 39 (for 8.4. Synthesizer Header Fields) and in pagg. 162 and = 165. By the way is it possible to have to definitions of the same keyword in A.1 ABNF Message Definitions - Cancel-If-Queue Recognizer header field in pag. 67 admits the queueing of RECOGNIZE methods and the Recognizer State Machine (page 55) = reflects it, but RECOGNIZE description in pag. 89 (9.9) states:=20 "If the resource is in the recognizing state, the RECOGNIZE request=20 MUST respond with a failure status." We see a contraddiction and we think that the queueing of RECOGNIZE commands is a complex feature that may have consequences on the interoperability of MRCPv2 applications. d.5) On recorder-method (Section 10.2) - START-INPUT-TIMERS in "recorder-method" is shown in pag. 102 (10.2) but it is not shown in the ABNF Message Definitions at pag. 167 d.6) On recorder-header (Section 10.4) - ver-buffer-utterance and start-input-timers header fields are shown in = "recorder-header" in pag. 103 (10.4), but not in pag. 167-168 - Trim-Length header field is only mentioned in STOP method (10.7, pag. = 108), but never defined elsewhere - Fetch-Timeout header field is not shown in "recorder-header", but it = is in the "Header Field where" table in pag. 103 and it is not described in 10.4. It is also missing from "recorder-header" definition in pag. 167-168 d.7) On verification-method (Section 11.2) - "verification-method" in pag. 112 (11.2) is called "verifier-method" in other places=20 - GET-INTERMEDIATE-RESULT method in "verification-method" is shown=20 in pag. 112 (11.2), but it is not shown in the ABNF Message=20 Definitions at pag. 166 (in "verifier-method") - STOP method (11.13) the default value if "Abort-Verification" header field is missing seems to be in contraddiction in second and third paragraph of Section 11.13 d.8) On verifier-event (section 11.3) - "verification-event" in pag. 113 (11.3) is called "verifier-event" in pag. 166 d.9) On verifier-header (section 11.4) - "verification-header" in pag. 113 (11.4) is called "verifier-header" in other places - Fetch-Timeout header field is not shown in "verification-header", but it is in the "Header Field where" table in pag. 113 and it is=20 not described in 11.4. It is also missing from "verifier-header" definition in pag. 166 - Verification-Mode header field the description in pag. 115-116 speaks of START-SESSION method only, but the table in pag. 114=20 includes also SET-PARAM and GET-PARAM methods - Adapt-Model header field the description in pag. 116 speaks of START-SESSION method only, but the table in pag. 114=20 includes also SET-PARAM and GET-PARAM methods - Save-Waveform header field the description in pag. 118 speaks of VERIFY method only, but the table in pag. 114=20 includes also SET-PARAM and GET-PARAM methods - Ver-Buffer-Utterance header field the description in pag. 119 speaks of VERIFY method only, but the table in pag. 114=20 includes also SET-PARAM and GET-PARAM methods -------------------------------------------------------------- E. Not clear if it is possible to negotiate the format of recognition results It seems that the only returned format is "NLSML", without possibility to ask for a different output format. -------------------------------------------------------------- F. LEXICON The LOAD-LEXICON/DEFINE-LEXICON method is present=20 in Section 8 "Speech Synthesizer Resource", but it is missing from Section 9. Some recognition engine will benefit of one or more general lexicons for ASR too. -------------------------------------------------------------- Best regards, Paolo Baggia, Loquendo Patrizio Bergallo, Loquendo Vittorio Manzone, 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=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=20 MailAdmin@tilab.com. Thank you =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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Mon Feb 28 15:33:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04070 for ; Mon, 28 Feb 2005 15:33:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5rb7-0008BS-JP for speechsc-web-archive@ietf.org; Mon, 28 Feb 2005 15:34:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5ra7-0002Tg-PE; Mon, 28 Feb 2005 15:33:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5ra6-0002Tb-NE for speechsc@megatron.ietf.org; Mon, 28 Feb 2005 15:33:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04057 for ; Mon, 28 Feb 2005 15:33:29 -0500 (EST) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5rau-0008BG-E4 for speechsc@ietf.org; Mon, 28 Feb 2005 15:34:21 -0500 Received: from nhmail2.needham.brooktrout.com (nhmail2.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j1SKT78A006988; Mon, 28 Feb 2005 15:29:07 -0500 (EST) Received: by nhmail2.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Feb 2005 15:25:14 -0500 Message-ID: From: Eric Burger To: Dan Burnett , ThomasGal@LumenVox.com Subject: Content-Id (was RE: [Speechsc] IANA considerations for group feed back) Date: Mon, 28 Feb 2005 15:25:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae Cc: speechsc@ietf.org 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 This is exactly what Content-Id is for. Good catch! > -----Original Message----- > From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org]On > Behalf Of Dan Burnett > Sent: Wednesday, February 09, 2005 9:54 AM > To: ThomasGal@LumenVox.com; 'Reifenrath, Klaus' > Cc: speechsc@ietf.org > Subject: RE: [Speechsc] IANA considerations for group feedback > > > It appears that the syntax for the URLs in this scheme > is intended to be identical to that for the "cid" > scheme (see "Content-Id"). Is there any way we can > make use of the existing "cid" scheme rather than > defining our own? > > By the way, RFC2111 (reference 15) was obsoleted by > RFC2392. > > --- Thomas Gal wrote: > > > I thought it was pretty well defined as being > > lexically: > > > > "session:uri". Beyond that it's persistence is only > > guaranteed for the > > session, and can be overwritten by using the same > > URI for another item. I > > don't think there's really anything else to > > define..... > > > > RFC 2396 ( and the obsoleted 1738) is about syntax > > of URLs so they don't > > really have bearing, unless you were referring to > > that as the issue....as > > for registration it seems to be pretty well covered > > in 2717 and 2718. 2717 > > explaining the registration process or dare I say > > protocol, and 2718 > > explaining the necessary rational for syntax of an > > extension URI scheme. > > > > SO is the question the exact format of the URI > > because the synatx in the > > MRCPv2 document is more or less standard down to > > some minor details? > > > > Otherwise the factors enumerated from the RFC for > > appropriatness with some > > comments: > > > > > > 2.1 Syntactic compatibility > > > > New URL schemes should follow the same syntactic > > conventions of > > existing schemes when appropriate. > > > > -Again I know that the only real differences are in > > quoted text and > > some minor details at the bottom of the syntax tree > > that are just > > simplifications of > > > > 2.1.1 Motivations for syntactic compatibility > > > > Why should new URL schemes share as much of the > > generic URI syntax > > (that makes sense to share) as possible? > > > > -Basically the reality here is that MRCP is a part > > of the grander > > scheme of VXML and the web itself and URLs will > > often be embedded in a > > diverse set of other types of resources so this > > justifies syntactic > > similarity quite well. > > > > > > 2.1.2 Improper use of "//" following ":" > > > > -We do have the authority directly following the > > slashes as > > specified. > > > > 2.1.3 Compatibility with relative URLs > > > > URL schemes should use the generic URL syntax if > > they are intended > > to > > be used with relative URLs. > > > > - We are using the generic URL syntax more or less > > > > 2.2 Is the scheme well defined? > > > > -grammars markup etc in our context we've specified > > in which > > messages this scheme can be used > > > > 2.2.1 Clear mapping from other name spaces > > > > -Doesn't really appear to be an issue > > > > 2.2.2 URL schemes associated with network protocols > > For such schemes, the specification should > > completely describe how > > URLs are > > translated into protocol actions in sufficient > > detail to make the > > access of the network resource unambiguous. > > > > > > -I think we've defined this pretty well > > > > 2.2.3 Definition of non-protocol URL schemes > > > > -This is a protocol URL > > > > 2.2.4 Definition of URL schemes not associated with > > data resources > > > > -These URLs are specifically associated with data > > in the cotext of > > the protocol > > > > 2.2.5 Character encoding > > > > -Section 5 says MRCPv2 is ISO 10646/UTF-8, and the > > MRCPv2 headers > > are limited to US-ASCII. SO this may be a little bit > > ambiguous and I would > > propose that we limit this to US-ASCII as well as > > these urls are for local > > reference, and human readability is not important. > > Really since these values > > appear in headers of the protocol they are more or > > less already definced to > > be US-ASCII. > > > > 2.2.6 Definition of operations > > > > -Yes this is very clear. > > > > 2.3 Demonstrated utility > > > > -Obviously it's nice to have a way to referrence > > intermediate > > objects in this protocol. I don't think anyone will > > dispute the utility. > > > > 2.4 Are there security considerations? > > > > -I would hope we don't need a security > > considerations section for > > the iana section :) > > > > I think we've pretty well covered it in the > > document, it may just need to be > > clarified or put into a second document. Certainly > > the notion of a session > > "scoped" uri could be helpful and applicable in > > other areas and protocols as > > well. > > > > - -Tom > > > > thomasgal@lumenvox.com > > > > > -----Original Message----- > > > From: speechsc-bounces@ietf.org > > > [mailto:speechsc-bounces@ietf.org] On Behalf Of > > Dan Burnett > > > Sent: Wednesday, January 26, 2005 10:18 AM > > > To: Reifenrath, Klaus > > > Cc: speechsc@ietf.org > > > Subject: RE: [Speechsc] IANA considerations for > > group feedback > > > > > > This is a good point. Unfortunately, I don't > > think we > > > defined this scheme sufficiently for me to write > > such > > > registration. Suggestions, anyone? > > > > > > -- dan > > > > > > --- "Reifenrath, Klaus" > > > wrote: > > > > > > > > > > > The URI scheme "session" requires IANA > > registration (see > > > > RFC2396,RFC1738). > > > > > > > > Klaus > > > > -----Original Message----- > > > > From: Reifenrath, Klaus > > > > [mailto:Klaus.Reifenrath@Scansoft.com] > > > > Sent: Montag, 24. Januar 2005 13:21 > > > > To: 'Dan Burnett' > > > > Cc: speechsc@ietf.org > > > > Subject: RE: [Speechsc] IANA considerations for > > group feedback > > > > > > > > > > > > Hi Dan, > > > > > > > > will you also write the IANA considerations for > > application/x-nlsml > > > > and the > > > > following SDP related entries? > > > > media type: > > > > - application/mrcpv2 > > > > - control > > > > NOTE: According to > > draft-ietf-mmusic-sdp-new-23.txt > > > (sections 8.2.1) > > > > the media type "control" is deprecated! > > > > attribute field names: > > > > - resource > > > > - channel > > > === message truncated === > > > ATTACHMENT part 2 application/x-pkcs7-signature > name=smime.p7s > > > > > > __________________________________ > Do you Yahoo!? > Yahoo! Mail - Easier than ever with enhanced search. Learn more. > http://info.mail.yahoo.com/mail_250 > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Mon Feb 28 15:50:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06093 for ; Mon, 28 Feb 2005 15:50:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5rqs-0000KF-RU for speechsc-web-archive@ietf.org; Mon, 28 Feb 2005 15:50:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5rZU-0002P2-SF; Mon, 28 Feb 2005 15:32:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5rZT-0002Ox-7B for speechsc@megatron.ietf.org; Mon, 28 Feb 2005 15:32:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03942 for ; Mon, 28 Feb 2005 15:32:49 -0500 (EST) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5raG-00089Q-QB for speechsc@ietf.org; Mon, 28 Feb 2005 15:33:41 -0500 Received: from nhmail2.needham.brooktrout.com (nhmail2.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j1SKT78A006991; Mon, 28 Feb 2005 15:29:07 -0500 (EST) Received: by nhmail2.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Feb 2005 15:25:14 -0500 Message-ID: From: Eric Burger To: Sarvi Shanmugham Subject: RE: [Speechsc] Vendor specific header names - Question Date: Mon, 28 Feb 2005 15:25:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: "IETF SPEECHSC \(E-mail\)" 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b There is no RFC on vendor trees. Just say what it is in MRCPv2. > -----Original Message----- > From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org]On > Behalf Of Sarvi Shanmugham > Sent: Tuesday, February 08, 2005 4:31 PM > To: IETF SPEECHSC (E-mail) > Subject: [Speechsc] Vendor specific header names - Question > > > > We are thinking of using a hierarchical naming convention for this > header field. > > com.cisco.headernameabc > com.ibm.headernamexyz > com.nuance.headernamexyz > > I know this naming convention is used in other places now, > like in java. > > But can't seem to find any reference to this naming > convention and how > it is managed. > > Can anyone throw in some pointers as to where I should look. > > Thanks, > Sarvi > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Mon Feb 28 16:09:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08142 for ; Mon, 28 Feb 2005 16:09:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5sA9-0000vU-Cu for speechsc-web-archive@ietf.org; Mon, 28 Feb 2005 16:10:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5s6B-0004vk-E4; Mon, 28 Feb 2005 16:06:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5s6A-0004vf-6G for speechsc@megatron.ietf.org; Mon, 28 Feb 2005 16:06:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07631; Mon, 28 Feb 2005 16:06:36 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5s6x-0000pf-S4; Mon, 28 Feb 2005 16:07:29 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 28 Feb 2005 13:18:56 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j1SL6PZV004984; Mon, 28 Feb 2005 13:06:25 -0800 (PST) Received: from [10.32.245.150] (stealth-10-32-245-150.cisco.com [10.32.245.150]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j1SL0V70019574; Mon, 28 Feb 2005 13:00:32 -0800 Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <81b66a94bcbe1ad7f39b714ed229b321@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Date: Mon, 28 Feb 2005 16:06:22 -0500 To: agenda@ietf.org X-Mailer: Apple Mail (2.619.2) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1109624432.372786"; x:"432200"; a:"rsa-sha1"; b:"nofws:391"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"O2GKZjKjBOJknKTj1BmJUqMXNEcTFs6NremTIbSeR42qeuPU4j+j5rKxP2LM44G4UhKBXn8e" "vy/bnWSxGA4an1l8NDedFIpN+Mn9h1fJr3CqQBRFs0/I8GdAls3gp4Zmd0erNPr75KMIrZIbmO1" "irvhX6RQlQGAmPcNn7HJseRg="; c:"From: David R Oran "; c:"Subject: SpeechSC WG Agenda for Minneapolis IETF "; c:"Date: Mon, 28 Feb 2005 16:06:22 -0500" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: "'speechsc@ietf.org'" Subject: [Speechsc] SpeechSC WG Agenda for Minneapolis IETF 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Speech Services Control Working Group (SPEECHSC) CHAIRS: Dave Oran Eric Burger Tuesday, 8 March 2005, 15:30-16:30 ================================ 05 min Intro and Agenda Bashing (Chairs) 25 min Push to Last call for MRCP (Shanmughan) draft-ietf-speechsc-mrcpv2-06.txt 20 min Discussion of security issues on requirements (Oran) draft-ietf-speechsc-reqts-06.txt 10 min Wrap up and action items (Chairs) _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc