From mailman-bounces@ietf.org Sat Jan 1 06:47: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 GAA12744 for ; Sat, 1 Jan 2005 06:47:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CkhvD-0007pu-3i for speechsc-web-archive@ietf.org; Sat, 01 Jan 2005 06:59:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CkgMM-0004im-WD for speechsc-web-archive@ietf.org; Sat, 01 Jan 2005 05:19:47 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: speechsc-web-archive@ietf.org X-No-Archive: yes Message-ID: Date: Sat, 01 Jan 2005 05:06:35 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for speechsc-web-archive@ietf.org: List Password // URL ---- -------- speechsc@ietf.org mHtT https://www1.ietf.org/mailman/options/speechsc/speechsc-web-archive%40ietf.org From yttlmksbacunt@yahoo.com Mon Jan 3 06:01:43 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 GAA15688; Mon, 3 Jan 2005 06:01:42 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClQAC-00010C-MR; Mon, 03 Jan 2005 06:14:18 -0500 Received: from [211.203.123.6] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1ClPxy-0001J6-M7; Mon, 03 Jan 2005 06:01:39 -0500 Received: from [50.156.66.239] (helo=..dearriba.com) by smtp2.cistron.nl with esmtp ( 3.35 #1 ()) id 413LFL-0035PT-44 Message-ID: <74428583144732.R37423@.noc..gr> Sender: freeradius-devel-yttlmksbacunt@yahoo.com X-Mailman-Version: 2.0.1 Date: Mon, 03 Jan 2005 06:51:04 -0400 From: "Ali Carney" To: speechsc-web-archive@ietf.org Cc: spirits-archive@ietf.org, srg@ietf.org, ssion@ietf.org, ssm@ietf.org, ssm-admin@ietf.org, ssm-archive@ietf.org Subject: Somaa, Via-gra are Che.ap Here Speechsc-web-archive X-Spam-Score: 3.8 (+++) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Wide range of medss available to choose in our stores. Saveee uup to 7o % Viiagraa, Ciallis, Vallium, Xanaax and many moore.. http://058.kuolocl.com/c/ Happy New Year reIUN7QgexvmP9D946H1Yzmve97KM5oBjyVYHUn8MHL From OXHUGP@hotmail.com Wed Jan 5 06:34: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 GAA23551; Wed, 5 Jan 2005 06:34:51 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cm9dl-0001ef-BS; Wed, 05 Jan 2005 06:47:51 -0500 Received: from 102.red-82-198-44.user.auna.net ([82.198.44.102]) by mx2.foretec.com with smtp (Exim 4.24) id 1Cm9R8-0006U3-1J; Wed, 05 Jan 2005 06:34:46 -0500 Received: from [32.184.32.104] (helo=..dearriba.com) by smtp2.cistron.nl with esmtp ( 3.35 #1 ()) id 452LFL-0055PT-88 Message-ID: <67961013144732.R37432@.noc..gr> Sender: freeradius-devel-OXHUGP@hotmail.com X-Mailman-Version: 2.0.1 Date: Wed, 05 Jan 2005 12:28:20 +0100 From: "Maribel Houser" To: speechsc-web-archive@ietf.org Cc: spirits-archive@ietf.org, srg@ietf.org, ssion@ietf.org Subject: Viicodin are Cheeap Heere Speechsc-web-archive X-Spam-Score: 2.6 (++) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Huge offer for Viicodin, Viagraa, Vallium and lots moreee... savee up to 7o% meds on our stores. Visit uss today http://coolhealth.info/in.php?aid=56 Happy New Year 8X6nMyg9uJnSraUoafc5fxwYlufYembEV5JUwQKvdOZQOahWtNUBZqif0iXM2m9AFqGAE From RBDTWWP@hotmail.com Wed Jan 12 02:08: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 CAA23164; Wed, 12 Jan 2005 02:08:40 -0500 (EST) Received: from 82-135-136-15.ip.takas.lt ([82.135.136.15]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CocqP-000575-1i; Wed, 12 Jan 2005 02:23:07 -0500 Received: from [158.11.102.93] (helo=..dearriba.com) by smtp2.cistron.nl with esmtp ( 3.35 #1 ()) id 058LFL-0010PT-55 Message-ID: <52983453144732.R37466@.noc..gr> Sender: freeradius-devel-RBDTWWP@hotmail.com X-Mailman-Version: 2.0.1 Date: Wed, 12 Jan 2005 12:04:37 +0500 From: "Lucien Ayala" To: speechsc-web-archive@ietf.org, spirits-archive@ietf.org, srg@ietf.org, ssion@ietf.org, ssm@ietf.org, ssm-admin@ietf.org, ssm-archive@ietf.org, ssm-request@ietf.org Subject: Viicodin are Selling Heree NmoiM X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Huge offer for Viicodin, Viagraa, Vallium and lots moreee... savee up to 7o% meds on our stores. Visit uss today http://coolhealth.info/in.php?aid=56 Happy New Year bUW40tvhrVL7jHhhRIx1pJ2CXlTtpKk49pg4ERwk5Q4TycbCpow9NvMIIb3eojx4twu2DQ From speechsc-bounces@ietf.org Thu Jan 20 17:21: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 RAA18390 for ; Thu, 20 Jan 2005 17:21:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Crkvr-0006D5-VY for speechsc-web-archive@ietf.org; Thu, 20 Jan 2005 17:37:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrkN1-0005f9-Ud; Thu, 20 Jan 2005 17:01:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrjuM-00008E-Q1 for speechsc@megatron.ietf.org; Thu, 20 Jan 2005 16:32: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 QAA08554 for ; Thu, 20 Jan 2005 16:32:00 -0500 (EST) Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrkA5-0002x8-AQ for speechsc@ietf.org; Thu, 20 Jan 2005 16:48:19 -0500 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j0KLVTul738794 for ; Thu, 20 Jan 2005 16:31:29 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay01.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j0KLVSla290716 for ; Thu, 20 Jan 2005 14:31:28 -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 j0KLVSab023081 for ; Thu, 20 Jan 2005 14:31:28 -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 j0KLVSqg023058 for ; Thu, 20 Jan 2005 14:31:28 -0700 To: speechsc@ietf.org Subject: [Speechsc] VoiceXML weight attribute MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_M2_07222004 Beta 2NP July 22, 2004 From: Jeff Kusnitz Message-ID: Date: Thu, 20 Jan 2005 13:31:21 -0800 X-MIMETrack: Serialize by Router on D03NM120/03/M/IBM(Release 6.51HF678 | November 11, 2004) at 01/20/2005 14:31:28, Serialize complete at 01/20/2005 14:31:28 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 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: 1ac7cc0a4cd376402b85bc1961a86ac2 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 From speechsc-bounces@ietf.org Fri Jan 21 14:04: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 OAA06446 for ; Fri, 21 Jan 2005 14:04:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs4Kx-0004hC-OS for speechsc-web-archive@ietf.org; Fri, 21 Jan 2005 14:20:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs3xO-0007gY-5o; Fri, 21 Jan 2005 13:56:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs3sd-0006ga-Cb for speechsc@megatron.ietf.org; Fri, 21 Jan 2005 13:51: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 NAA05501 for ; Fri, 21 Jan 2005 13:51:34 -0500 (EST) Received: from web14124.mail.yahoo.com ([66.163.171.115]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cs48Z-0004Kz-6W for speechsc@ietf.org; Fri, 21 Jan 2005 14:08:03 -0500 Received: (qmail 56637 invoked by uid 60001); 21 Jan 2005 18:51: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=wQ1Zyd+rYll+rhV4Nsibrg+MmXr9uu1lldOYrGXIrRPpgGCKa/9QZDxD7UnSzR1FcKCJME6hU1NkQKZLu9631Lh3RIJjsgU9M8ygTkNWah/SLKVOONhBwJVT5eORTui+/GD/Hxk4pI40TV8mpxTUrbep9faUbG9CsC+E+6mgruw= ; Message-ID: <20050121185133.56635.qmail@web14124.mail.yahoo.com> Received: from [63.193.248.104] by web14124.mail.yahoo.com via HTTP; Fri, 21 Jan 2005 10:51:33 PST Date: Fri, 21 Jan 2005 10:51:33 -0800 (PST) From: Dan Burnett To: speechsc@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 3.0 (+++) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Subject: [Speechsc] IANA considerations for group feedback 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: 5ebbf074524e58e662bc8209a6235027 Group, In the course of reviewing the draft in order to write the IANA Considerations sections, I've identified the following value spaces for which one might consider requesting IANA to maintain a registry. For each one, I've made a suggestion as to whether or not we should create an IANA registration, and if so, what policy (see [1] for explanations) should be used for assignment. The default policy in the document for all remaining value spaces will be that there must be a new version of MRCP for any changes to occur. I would like to hear if there are any opinions on these, particularly if they differ from my suggestions. I would also like particularly to hear feedback on 2 and 5, below, since my suggested assignment protocol may be quite restrictive with respect to vendor extensions. 1. Name space: resource types (sec. 4.2) IANA registry?: no Comment: This is a core part of the spec and requires significant understanding and industry consensus. The introduction of a new resource should require approval of a working group and not just one expert. 2. Name space: extension methods (sec. 5.1) IANA registry?: yes Assignment protocol: IETF Review Comment: It should be possible to extend the set of methods without creating a whole new version of MRCP. Or should it? If not, why do we permit it in the spec? 3. Name space: request state (sec. 5.2) IANA registry?: no Comment: This is unlikely to change. If there were a need to change this it would probably require a re-think of the entire protocol. 4. Name space: status codes (sec. 5.2) IANA registry?: yes Assignment protocol: Specification Required with Expert Review Comment: This is the sort of thing that might need to be adjusted based on further implementation experience by the industry. It should not require a re-write of the spec, but any additions would need to be reviewed for sanity and documented for portability. By the way, I would recommend that we include a small number of codes specifically for experimental use (see [2]). 5. Name space: extension events (sec. 5.3) IANA registry?: yes Assignment protocol: IETF Review Comment: It should be possible to extend the set of events without creating a whole new version of MRCP. Or should it? If not, why do we permit it in the spec? 6. Name space: extension headers (sec. 6.1) IANA registry?: yes Assignment protocol: IETF Review Comment: It should be possible to extend the set of headers without creating a whole new version of MRCP. Or should it? If not, why do we permit it in the spec? 7. Name space: vendor-specific headers (sec. 6.1) IANA registry?: no Comment: Such parameters are already clearly identified by the "Vendor-Specific-Parameters" prefix and thus the contents are well-known to be vendor-specific. 8. Name space: parameter list (sec. 6.2/6.3) IANA registry?: yes Assignment protocol: IETF Review Comment: This one I'm not sure about. It's similar to 2 and 5, above, but the draft does not currently provide a slot for such extensions (i.e. the list is currently closed). I think the permissability of extensions here should match that for 2 and 5, whether we permit extensions for all (without a new MRCP spec) or whether we prohibit all extenions (and require a new MRCP spec for changes). 9. Name space: completion cause (for each resource) IANA registry?: no Comment: Although I think there might be some use in having a registry for each, it seems like overkill to do it. I could be persuaded otherwise, however. -- Dan [1] http://www.ietf.org/internet-drafts/draft-narten-iana-considerations-rfc2434bis-01.txt [2] ftp://ftp.rfc-editor.org/in-notes/bcp/bcp82.txt __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Fri Jan 21 15:46:19 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 PAA17458 for ; Fri, 21 Jan 2005 15:46:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs5vd-0008Dc-Je for speechsc-web-archive@ietf.org; Fri, 21 Jan 2005 16:02:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs5Ti-0004MT-DT; Fri, 21 Jan 2005 15:33:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs5Qx-0002Ko-OE for speechsc@megatron.ietf.org; Fri, 21 Jan 2005 15:31: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 PAA16038 for ; Fri, 21 Jan 2005 15:31:05 -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 1Cs5gr-0007bA-W2 for speechsc@ietf.org; Fri, 21 Jan 2005 15:47:36 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 21 Jan 2005 13:38:35 +0000 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-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0LKUCl2016829; Fri, 21 Jan 2005 12:30:13 -0800 (PST) Received: from [128.107.139.169] ([128.107.139.169]) by vtg-um-e2k1.sj21ad.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 21 Jan 2005 12:30:25 -0800 Message-ID: <41F16675.7050801@cisco.com> Date: Fri, 21 Jan 2005 12:30:45 -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: <20050121185133.56635.qmail@web14124.mail.yahoo.com> In-Reply-To: <20050121185133.56635.qmail@web14124.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jan 2005 20:30:25.0747 (UTC) FILETIME=[09F88230:01C4FFF8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f 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: 2bf730a014b318fd3efd65b39b48818c Content-Transfer-Encoding: 7bit comments line. Dan Burnett wrote: >Group, > >In the course of reviewing the draft in order to write >the IANA Considerations sections, I've identified the >following value spaces for which one might consider >requesting IANA to maintain a registry. For each one, >I've made a suggestion as to whether or not we should >create an IANA registration, and if so, what policy >(see [1] for explanations) should be used for >assignment. The default policy in the document for >all remaining value spaces will be that there must be >a new version of MRCP for any changes to occur. > >I would like to hear if there are any opinions on >these, particularly if they differ from my >suggestions. >I would also like particularly to hear feedback on 2 >and 5, below, since my suggested assignment protocol >may be quite restrictive with respect to vendor >extensions. > >1. Name space: resource types (sec. 4.2) >IANA registry?: no >Comment: This is a core part of the spec and requires >significant understanding and industry consensus. The >introduction of a new resource should require approval >of a working group and not just one expert. > > I believe this was one the items to be registered with the IANA. Registering with the IANA by itself does not make it any more easy or difficult to add new resource types. The idea behind the MRCP framework, its resource types and the way the protocol is modeled is that future RFCs can propose to add more resources definitions extensions to handle such resources. New resources may be added into the framework in the future by defining a new RFC thats specifies the working of that resource as long as it does not change the framework or existing resources. Only if the existing resources and their working are being changed or upgraded in the future would a new RFC to override this be needed. So I believe this needs to be registered. >2. Name space: extension methods (sec. 5.1) >IANA registry?: yes >Assignment protocol: IETF Review >Comment: It should be possible to extend the set of >methods without creating a whole new version of MRCP. >Or should it? If not, why do we permit it in the >spec? > > Yes. New extenion methods can be poposed through additiona RFCs as long as they don't change the behaviour of the existing methods and headers. If existing functionality is being changed, I believe you would need a new version of MRCP RFC to supercede this one. >3. Name space: request state (sec. 5.2) >IANA registry?: no >Comment: This is unlikely to change. If there were a >need to change this it would probably require a >re-think of the entire protocol. > > agreed. >4. Name space: status codes (sec. 5.2) >IANA registry?: yes >Assignment protocol: Specification Required with >Expert Review >Comment: This is the sort of thing that might need to >be adjusted based on further implementation experience >by the industry. It should not require a re-write of >the spec, but any additions would need to be reviewed >for sanity and documented for portability. By the >way, I would recommend that we include a small number >of codes specifically for experimental use (see [2]). > > agreed. >5. Name space: extension events (sec. 5.3) >IANA registry?: yes >Assignment protocol: IETF Review >Comment: It should be possible to extend the set of >events without creating a whole new version of MRCP. >Or should it? If not, why do we permit it in the >spec? > > Agreed. This the same as extending methods. I think methods and events should be in the same namespace to avoid conflicting choices for method names and event names. >6. Name space: extension headers (sec. 6.1) >IANA registry?: yes >Assignment protocol: IETF Review >Comment: It should be possible to extend the set of >headers without creating a whole new version of MRCP. >Or should it? If not, why do we permit it in the >spec? > > > Agreed. >7. Name space: vendor-specific headers (sec. 6.1) >IANA registry?: no >Comment: Such parameters are already clearly >identified by the "Vendor-Specific-Parameters" prefix >and thus the contents are well-known to be >vendor-specific. > > The question then is how is the server or client to recognize which vendors resource it is and hence what parameters it supports? >8. Name space: parameter list (sec. 6.2/6.3) >IANA registry?: yes >Assignment protocol: IETF Review >Comment: This one I'm not sure about. It's similar to >2 and 5, above, but the draft does not currently >provide a slot for such extensions (i.e. the list is >currently closed). I think the permissability of >extensions here should match that for 2 and 5, whether >we permit extensions for all (without a new MRCP spec) >or whether we prohibit all extenions (and require a >new MRCP spec for changes). > > Yes this should also be extensible. >9. Name space: completion cause (for each resource) >IANA registry?: no >Comment: Although I think there might be some use in >having a registry for each, it seems like overkill to >do it. I could be persuaded otherwise, however. > > The meaning of Completion Cause resource specific. Hence I think future resources, if any, would define their own list of values. So I agree with the above. 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. Thanks, Sarvi >-- Dan > >[1] >http://www.ietf.org/internet-drafts/draft-narten-iana-considerations-rfc2434bis-01.txt >[2] ftp://ftp.rfc-editor.org/in-notes/bcp/bcp82.txt > > > > >__________________________________ >Do you Yahoo!? >Take Yahoo! Mail with you! Get it on your mobile phone. >http://mobile.yahoo.com/maildemo > >_______________________________________________ >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 Jan 21 19:41: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 TAA10174 for ; Fri, 21 Jan 2005 19:41:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs9aw-0007Ze-3v for speechsc-web-archive@ietf.org; Fri, 21 Jan 2005 19:57:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs9Fq-0004WW-Kt; Fri, 21 Jan 2005 19:35:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs9Ci-0003P9-GF for speechsc@megatron.ietf.org; Fri, 21 Jan 2005 19:32: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 TAA09750 for ; Fri, 21 Jan 2005 19:32:37 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs9Sh-0007Ok-Cz for speechsc@ietf.org; Fri, 21 Jan 2005 19:49:11 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 21 Jan 2005 16:33: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 j0M0W61M020259; Fri, 21 Jan 2005 16:32:07 -0800 (PST) Received: from [128.107.139.169] ([128.107.139.169]) by vtg-um-e2k1.sj21ad.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 21 Jan 2005 16:32:01 -0800 Message-ID: <41F19F01.2040008@cisco.com> Date: Fri, 21 Jan 2005 16:32:01 -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: <20050121185133.56635.qmail@web14124.mail.yahoo.com> In-Reply-To: <20050121185133.56635.qmail@web14124.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jan 2005 00:32:01.0099 (UTC) FILETIME=[C9DFB1B0:01C50019] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 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: 995b2e24d23b953c94bac5288c432399 Content-Transfer-Encoding: 7bit After reviewing the IANA considerations guidelines, the protocol for additional values should be as follows. see inline. Dan Burnett wrote: >Group, > >In the course of reviewing the draft in order to write >the IANA Considerations sections, I've identified the >following value spaces for which one might consider >requesting IANA to maintain a registry. For each one, >I've made a suggestion as to whether or not we should >create an IANA registration, and if so, what policy >(see [1] for explanations) should be used for >assignment. The default policy in the document for >all remaining value spaces will be that there must be >a new version of MRCP for any changes to occur. > >I would like to hear if there are any opinions on >these, particularly if they differ from my >suggestions. >I would also like particularly to hear feedback on 2 >and 5, below, since my suggested assignment protocol >may be quite restrictive with respect to vendor >extensions. > >1. Name space: resource types (sec. 4.2) >IANA registry?: no >Comment: This is a core part of the spec and requires >significant understanding and industry consensus. The >introduction of a new resource should require approval >of a working group and not just one expert. > > Assignment Protocol: Specification Required >2. Name space: extension methods (sec. 5.1) >IANA registry?: yes >Assignment protocol: IETF Review > > Assignment Protocol: Specification Required >Comment: It should be possible to extend the set of >methods without creating a whole new version of MRCP. >Or should it? If not, why do we permit it in the >spec? > >3. Name space: request state (sec. 5.2) >IANA registry?: no >Comment: This is unlikely to change. If there were a >need to change this it would probably require a >re-think of the entire protocol. > >4. Name space: status codes (sec. 5.2) >IANA registry?: yes >Assignment protocol: Specification Required with >Expert Review >Comment: This is the sort of thing that might need to >be adjusted based on further implementation experience >by the industry. It should not require a re-write of >the spec, but any additions would need to be reviewed >for sanity and documented for portability. By the >way, I would recommend that we include a small number >of codes specifically for experimental use (see [2]). > >5. Name space: extension events (sec. 5.3) >IANA registry?: yes >Assignment protocol: IETF Review > > Assignment Protocol: Specification Required >Comment: It should be possible to extend the set of >events without creating a whole new version of MRCP. >Or should it? If not, why do we permit it in the >spec? > >6. Name space: extension headers (sec. 6.1) >IANA registry?: yes >Assignment protocol: IETF Review > > Assignment Protocol: Specification Required >Comment: It should be possible to extend the set of >headers without creating a whole new version of MRCP. >Or should it? If not, why do we permit it in the >spec? > >7. Name space: vendor-specific headers (sec. 6.1) >IANA registry?: no >Comment: Such parameters are already clearly >identified by the "Vendor-Specific-Parameters" prefix >and thus the contents are well-known to be >vendor-specific. > > Yes. Assignment Protocol: Hierarchical allocation Example: Object Identifiers. >8. Name space: parameter list (sec. 6.2/6.3) >IANA registry?: yes >Assignment protocol: IETF Review > > Assignment Protocol: Specification Required >Comment: This one I'm not sure about. It's similar to >2 and 5, above, but the draft does not currently >provide a slot for such extensions (i.e. the list is >currently closed). I think the permissability of >extensions here should match that for 2 and 5, whether >we permit extensions for all (without a new MRCP spec) >or whether we prohibit all extenions (and require a >new MRCP spec for changes). > >9. Name space: completion cause (for each resource) >IANA registry?: no >Comment: Although I think there might be some use in >having a registry for each, it seems like overkill to >do it. I could be persuaded otherwise, however. > > 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. Assignment Protocol: Hierarchical allocation Example: Object Identifiers. Thanks, Sarvi >-- Dan > >[1] >http://www.ietf.org/internet-drafts/draft-narten-iana-considerations-rfc2434bis-01.txt >[2] ftp://ftp.rfc-editor.org/in-notes/bcp/bcp82.txt > > > > >__________________________________ >Do you Yahoo!? >Take Yahoo! Mail with you! Get it on your mobile phone. >http://mobile.yahoo.com/maildemo > >_______________________________________________ >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 Jan 24 07:25: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 HAA02570 for ; Mon, 24 Jan 2005 07:25:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct3Xv-0000yF-9u for speechsc-web-archive@ietf.org; Mon, 24 Jan 2005 07:42:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct3GR-0005zm-Ug; Mon, 24 Jan 2005 07:24:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct3E5-0005l4-Va for speechsc@megatron.ietf.org; Mon, 24 Jan 2005 07:21: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 HAA02394 for ; Mon, 24 Jan 2005 07:21:48 -0500 (EST) Received: from mx1.scansoft.com ([198.71.64.81]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct3Ua-0000tD-W4 for speechsc@ietf.org; Mon, 24 Jan 2005 07:38:53 -0500 Received: from pb-exchcon.pb.scansoft.com ([10.1.4.73]) by mx1.scansoft.com with InterScan Messaging Security Suite; Mon, 24 Jan 2005 07:31:21 -0500 Received: by pb-exchcon.pb.scansoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Jan 2005 07:21:11 -0500 Message-ID: From: "Reifenrath, Klaus" To: "'Dan Burnett'" Subject: RE: [Speechsc] IANA considerations for group feedback Date: Mon, 24 Jan 2005 07:21:09 -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: 87a3f533bb300b99e2a18357f3c1563d 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: 29dc808194f5fb921c09d0040806d6eb 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 protocol identifier (probably need to be coordinated with the MMUSIC group): - SCTP - TLS At the last F2F meeting in San Diego we discussed caller preference-based SIP routing, which most likely would require some more IANA registrations. Best regards, Klaus -----Original Message----- From: Dan Burnett [mailto:dan_burnett2000@yahoo.com] Sent: Freitag, 21. Januar 2005 19:52 To: speechsc@ietf.org Subject: [Speechsc] IANA considerations for group feedback Group, In the course of reviewing the draft in order to write the IANA Considerations sections, I've identified the following value spaces for which one might consider requesting IANA to maintain a registry. For each one, I've made a suggestion as to whether or not we should create an IANA registration, and if so, what policy (see [1] for explanations) should be used for assignment. The default policy in the document for all remaining value spaces will be that there must be a new version of MRCP for any changes to occur. I would like to hear if there are any opinions on these, particularly if they differ from my suggestions. I would also like particularly to hear feedback on 2 and 5, below, since my suggested assignment protocol may be quite restrictive with respect to vendor extensions. 1. Name space: resource types (sec. 4.2) IANA registry?: no Comment: This is a core part of the spec and requires significant understanding and industry consensus. The introduction of a new resource should require approval of a working group and not just one expert. 2. Name space: extension methods (sec. 5.1) IANA registry?: yes Assignment protocol: IETF Review Comment: It should be possible to extend the set of methods without creating a whole new version of MRCP. Or should it? If not, why do we permit it in the spec? 3. Name space: request state (sec. 5.2) IANA registry?: no Comment: This is unlikely to change. If there were a need to change this it would probably require a re-think of the entire protocol. 4. Name space: status codes (sec. 5.2) IANA registry?: yes Assignment protocol: Specification Required with Expert Review Comment: This is the sort of thing that might need to be adjusted based on further implementation experience by the industry. It should not require a re-write of the spec, but any additions would need to be reviewed for sanity and documented for portability. By the way, I would recommend that we include a small number of codes specifically for experimental use (see [2]). 5. Name space: extension events (sec. 5.3) IANA registry?: yes Assignment protocol: IETF Review Comment: It should be possible to extend the set of events without creating a whole new version of MRCP. Or should it? If not, why do we permit it in the spec? 6. Name space: extension headers (sec. 6.1) IANA registry?: yes Assignment protocol: IETF Review Comment: It should be possible to extend the set of headers without creating a whole new version of MRCP. Or should it? If not, why do we permit it in the spec? 7. Name space: vendor-specific headers (sec. 6.1) IANA registry?: no Comment: Such parameters are already clearly identified by the "Vendor-Specific-Parameters" prefix and thus the contents are well-known to be vendor-specific. 8. Name space: parameter list (sec. 6.2/6.3) IANA registry?: yes Assignment protocol: IETF Review Comment: This one I'm not sure about. It's similar to 2 and 5, above, but the draft does not currently provide a slot for such extensions (i.e. the list is currently closed). I think the permissability of extensions here should match that for 2 and 5, whether we permit extensions for all (without a new MRCP spec) or whether we prohibit all extenions (and require a new MRCP spec for changes). 9. Name space: completion cause (for each resource) IANA registry?: no Comment: Although I think there might be some use in having a registry for each, it seems like overkill to do it. I could be persuaded otherwise, however. -- Dan [1] http://www.ietf.org/internet-drafts/draft-narten-iana-considerations-rfc2434 bis-01.txt [2] ftp://ftp.rfc-editor.org/in-notes/bcp/bcp82.txt __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo _______________________________________________ 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 Jan 24 10:59: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 KAA24433 for ; Mon, 24 Jan 2005 10:59:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct6tI-0000r5-GB for speechsc-web-archive@ietf.org; Mon, 24 Jan 2005 11:16:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct6X8-0003BY-En; Mon, 24 Jan 2005 10:53:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct6Vq-0002sx-Qn for speechsc@megatron.ietf.org; Mon, 24 Jan 2005 10:52:22 -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 KAA23855 for ; Mon, 24 Jan 2005 10:52:19 -0500 (EST) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct6mM-0000bY-QH for speechsc@ietf.org; Mon, 24 Jan 2005 11:09:27 -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 j0OFgQao011183; Mon, 24 Jan 2005 10:42:26 -0500 (EST) Received: by nhmail2.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Jan 2005 10:38:51 -0500 Message-ID: From: Ken Robbins To: Dan Burnett Subject: RE: [Speechsc] IANA considerations for group feedback Date: Mon, 24 Jan 2005 10:38:49 -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: a3f7094ccc62748c06b21fcf44c073ee 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: 0bb031f3a6fb29f760794ac9bf1997ae Dan, Should the treatment of the related MIME types be part of your value space discussion or do you already have this covered? I've included a list of MIME types that I found in the draft, with my comments added: application/mrcpv2 IANA application required. application/synthesis+ssml application/srgs+xml application/srgs W3C Voice Browser Working Group has already applied for these, but they are not yet listed as registered by IANA. application/sml Appears on page 139. Is this a typo? application/x-nlsml Not IANA registered. Do "x-" subtypes need to be? application/octets Not IANA registered. Note that octet-stream is registered. Do we mean octets or octet-stream? Ken Robbins Brooktrout Technology, Inc. -----Original Message----- From: Sarvi Shanmugham [mailto:sarvi@cisco.com] Sent: Friday, January 21, 2005 3:31 PM To: Dan Burnett Cc: speechsc@ietf.org Subject: Re: [Speechsc] IANA considerations for group feedback comments line. Dan Burnett wrote: >Group, > >In the course of reviewing the draft in order to write >the IANA Considerations sections, I've identified the >following value spaces for which one might consider >requesting IANA to maintain a registry. For each one, >I've made a suggestion as to whether or not we should >create an IANA registration, and if so, what policy >(see [1] for explanations) should be used for >assignment. The default policy in the document for >all remaining value spaces will be that there must be >a new version of MRCP for any changes to occur. > >I would like to hear if there are any opinions on >these, particularly if they differ from my >suggestions. >I would also like particularly to hear feedback on 2 >and 5, below, since my suggested assignment protocol >may be quite restrictive with respect to vendor >extensions. > >1. Name space: resource types (sec. 4.2) >IANA registry?: no >Comment: This is a core part of the spec and requires >significant understanding and industry consensus. The >introduction of a new resource should require approval >of a working group and not just one expert. > > I believe this was one the items to be registered with the IANA. Registering with the IANA by itself does not make it any more easy or difficult to add new resource types. The idea behind the MRCP framework, its resource types and the way the protocol is modeled is that future RFCs can propose to add more resources definitions extensions to handle such resources. New resources may be added into the framework in the future by defining a new RFC thats specifies the working of that resource as long as it does not change the framework or existing resources. Only if the existing resources and their working are being changed or upgraded in the future would a new RFC to override this be needed. So I believe this needs to be registered. >2. Name space: extension methods (sec. 5.1) >IANA registry?: yes >Assignment protocol: IETF Review >Comment: It should be possible to extend the set of >methods without creating a whole new version of MRCP. >Or should it? If not, why do we permit it in the >spec? > > Yes. New extenion methods can be poposed through additiona RFCs as long as they don't change the behaviour of the existing methods and headers. If existing functionality is being changed, I believe you would need a new version of MRCP RFC to supercede this one. >3. Name space: request state (sec. 5.2) >IANA registry?: no >Comment: This is unlikely to change. If there were a >need to change this it would probably require a >re-think of the entire protocol. > > agreed. >4. Name space: status codes (sec. 5.2) >IANA registry?: yes >Assignment protocol: Specification Required with >Expert Review >Comment: This is the sort of thing that might need to >be adjusted based on further implementation experience >by the industry. It should not require a re-write of >the spec, but any additions would need to be reviewed >for sanity and documented for portability. By the >way, I would recommend that we include a small number >of codes specifically for experimental use (see [2]). > > agreed. >5. Name space: extension events (sec. 5.3) >IANA registry?: yes >Assignment protocol: IETF Review >Comment: It should be possible to extend the set of >events without creating a whole new version of MRCP. >Or should it? If not, why do we permit it in the >spec? > > Agreed. This the same as extending methods. I think methods and events should be in the same namespace to avoid conflicting choices for method names and event names. >6. Name space: extension headers (sec. 6.1) >IANA registry?: yes >Assignment protocol: IETF Review >Comment: It should be possible to extend the set of >headers without creating a whole new version of MRCP. >Or should it? If not, why do we permit it in the >spec? > > > Agreed. >7. Name space: vendor-specific headers (sec. 6.1) >IANA registry?: no >Comment: Such parameters are already clearly >identified by the "Vendor-Specific-Parameters" prefix >and thus the contents are well-known to be >vendor-specific. > > The question then is how is the server or client to recognize which vendors resource it is and hence what parameters it supports? >8. Name space: parameter list (sec. 6.2/6.3) >IANA registry?: yes >Assignment protocol: IETF Review >Comment: This one I'm not sure about. It's similar to >2 and 5, above, but the draft does not currently >provide a slot for such extensions (i.e. the list is >currently closed). I think the permissability of >extensions here should match that for 2 and 5, whether >we permit extensions for all (without a new MRCP spec) >or whether we prohibit all extenions (and require a >new MRCP spec for changes). > > Yes this should also be extensible. >9. Name space: completion cause (for each resource) >IANA registry?: no >Comment: Although I think there might be some use in >having a registry for each, it seems like overkill to >do it. I could be persuaded otherwise, however. > > The meaning of Completion Cause resource specific. Hence I think future resources, if any, would define their own list of values. So I agree with the above. 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. Thanks, Sarvi >-- Dan > >[1] >http://www.ietf.org/internet-drafts/draft-narten-iana-considerations-rfc243 4bis-01.txt >[2] ftp://ftp.rfc-editor.org/in-notes/bcp/bcp82.txt > > > > >__________________________________ >Do you Yahoo!? >Take Yahoo! Mail with you! Get it on your mobile phone. >http://mobile.yahoo.com/maildemo > >_______________________________________________ >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 Mon Jan 24 11:39:59 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 LAA28280 for ; Mon, 24 Jan 2005 11:39:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct7WW-0002Tt-1q for speechsc-web-archive@ietf.org; Mon, 24 Jan 2005 11:57:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct793-0004Sm-U6; Mon, 24 Jan 2005 11:32:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct71e-0000FG-87 for speechsc@megatron.ietf.org; Mon, 24 Jan 2005 11:25: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 LAA27189 for ; Mon, 24 Jan 2005 11:25:11 -0500 (EST) Received: from mx2.scansoft.com ([198.71.64.82]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct7IA-0001u6-4S for speechsc@ietf.org; Mon, 24 Jan 2005 11:42:19 -0500 Received: from pb-exchcon.pb.scansoft.com ([10.1.4.73]) by mx2.scansoft.com with InterScan Messaging Security Suite; Mon, 24 Jan 2005 11:27:53 -0500 Received: by pb-exchcon.pb.scansoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Jan 2005 11:24:29 -0500 Message-ID: From: "Reifenrath, Klaus" To: "'Dan Burnett'" Subject: RE: [Speechsc] IANA considerations for group feedback Date: Mon, 24 Jan 2005 11:24:08 -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: 225414c974e0d6437992164e91287a51 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: 1449ead51a2ff026dcb23465f5379250 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 protocol identifier (probably need to be coordinated with the MMUSIC group): - SCTP - TLS At the last F2F meeting in San Diego we discussed caller preference-based SIP routing, which most likely would require some more IANA registrations. Best regards, Klaus -----Original Message----- From: Dan Burnett [mailto:dan_burnett2000@yahoo.com] Sent: Freitag, 21. Januar 2005 19:52 To: speechsc@ietf.org Subject: [Speechsc] IANA considerations for group feedback Group, In the course of reviewing the draft in order to write the IANA Considerations sections, I've identified the following value spaces for which one might consider requesting IANA to maintain a registry. For each one, I've made a suggestion as to whether or not we should create an IANA registration, and if so, what policy (see [1] for explanations) should be used for assignment. The default policy in the document for all remaining value spaces will be that there must be a new version of MRCP for any changes to occur. I would like to hear if there are any opinions on these, particularly if they differ from my suggestions. I would also like particularly to hear feedback on 2 and 5, below, since my suggested assignment protocol may be quite restrictive with respect to vendor extensions. 1. Name space: resource types (sec. 4.2) IANA registry?: no Comment: This is a core part of the spec and requires significant understanding and industry consensus. The introduction of a new resource should require approval of a working group and not just one expert. 2. Name space: extension methods (sec. 5.1) IANA registry?: yes Assignment protocol: IETF Review Comment: It should be possible to extend the set of methods without creating a whole new version of MRCP. Or should it? If not, why do we permit it in the spec? 3. Name space: request state (sec. 5.2) IANA registry?: no Comment: This is unlikely to change. If there were a need to change this it would probably require a re-think of the entire protocol. 4. Name space: status codes (sec. 5.2) IANA registry?: yes Assignment protocol: Specification Required with Expert Review Comment: This is the sort of thing that might need to be adjusted based on further implementation experience by the industry. It should not require a re-write of the spec, but any additions would need to be reviewed for sanity and documented for portability. By the way, I would recommend that we include a small number of codes specifically for experimental use (see [2]). 5. Name space: extension events (sec. 5.3) IANA registry?: yes Assignment protocol: IETF Review Comment: It should be possible to extend the set of events without creating a whole new version of MRCP. Or should it? If not, why do we permit it in the spec? 6. Name space: extension headers (sec. 6.1) IANA registry?: yes Assignment protocol: IETF Review Comment: It should be possible to extend the set of headers without creating a whole new version of MRCP. Or should it? If not, why do we permit it in the spec? 7. Name space: vendor-specific headers (sec. 6.1) IANA registry?: no Comment: Such parameters are already clearly identified by the "Vendor-Specific-Parameters" prefix and thus the contents are well-known to be vendor-specific. 8. Name space: parameter list (sec. 6.2/6.3) IANA registry?: yes Assignment protocol: IETF Review Comment: This one I'm not sure about. It's similar to 2 and 5, above, but the draft does not currently provide a slot for such extensions (i.e. the list is currently closed). I think the permissability of extensions here should match that for 2 and 5, whether we permit extensions for all (without a new MRCP spec) or whether we prohibit all extenions (and require a new MRCP spec for changes). 9. Name space: completion cause (for each resource) IANA registry?: no Comment: Although I think there might be some use in having a registry for each, it seems like overkill to do it. I could be persuaded otherwise, however. -- Dan [1] http://www.ietf.org/internet-drafts/draft-narten-iana-considerations-rfc2434 bis-01.txt [2] ftp://ftp.rfc-editor.org/in-notes/bcp/bcp82.txt __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo _______________________________________________ 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 Jan 25 10:47:33 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 KAA14392 for ; Tue, 25 Jan 2005 10:47:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtTBU-0005ly-UU for speechsc-web-archive@ietf.org; Tue, 25 Jan 2005 11:04:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtSt5-0001XN-F9; Tue, 25 Jan 2005 10:45:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtSqB-00015d-Pu for speechsc@megatron.ietf.org; Tue, 25 Jan 2005 10:42: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 KAA13974 for ; Tue, 25 Jan 2005 10:42:47 -0500 (EST) Received: from mail.lumenvox.com ([206.169.193.45] helo=lv-svr.lumenvox.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtT6s-0005cJ-SC for speechsc@ietf.org; Tue, 25 Jan 2005 11:00:07 -0500 Received: from PROGTHOMAS ([10.0.0.141]) by lv-svr.lumenvox.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 25 Jan 2005 07:38:01 -0800 From: "Thomas Gal" To: "'Ken Robbins'" , "'Dan Burnett'" Subject: RE: [Speechsc] IANA considerations for group feedback Date: Tue, 25 Jan 2005 07:42:08 -0800 Organization: LumenVox LLC MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: Thread-Index: AcUCLSnrisJ8ibFrRXWTnWplo8nEAQAxHNlQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Message-ID: X-OriginalArrivalTime: 25 Jan 2005 15:38:01.0187 (UTC) FILETIME=[DA401B30:01C502F3] X-Spam-Score: 0.0 (/) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 Content-Transfer-Encoding: 7bit Cc: speechsc@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ThomasGal@LumenVox.com 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: f0b5a4216bfa030ed8a6f68d1833f8ae Content-Transfer-Encoding: 7bit Inline -Tom thomasgal@lumenvox.com > application/sml > Appears on page 139. Is this a typo? > I think it's page 138 and it's a speak command so it's gotta be nlsml. > application/x-nlsml > Not IANA registered. Do "x-" subtypes need to be? > I think items prefaces with "x-" are specifically precluded from IANA as experimental by notation. I think this was a vestige of it's previous status(abandoned/incomplete) with the W3C, and should be just application/nlsml or something else along those lines. In fact it would be good to alleviate confusion with the W3C spec, as well as indicate that we've finalized it. > application/octets > Not IANA registered. Note that octet-stream is > registered. Do we mean octets or octet-stream? > I don't think we need to register octets or octet stream really as this is a functional "catch-all" in the spec meant to indicate anything specifically uninterrupted or opaque, like a recognizer context block. Even where we specify the message body as *OCTET it's not really just that but will end up being an actual mime-type which is supported by the recognizer. These should obviously all be specified, but octet is just a place holder here. As for the lexical usage in various parts of the grammar I don't think that's important from this perspective either. > Ken Robbins > Brooktrout Technology, Inc. > > > -----Original Message----- > From: Sarvi Shanmugham [mailto:sarvi@cisco.com] > Sent: Friday, January 21, 2005 3:31 PM > To: Dan Burnett > Cc: speechsc@ietf.org > Subject: Re: [Speechsc] IANA considerations for group feedback > > comments line. > Dan Burnett wrote: > > >Group, > > > >In the course of reviewing the draft in order to write the IANA > >Considerations sections, I've identified the following value > spaces for > >which one might consider requesting IANA to maintain a > registry. For > >each one, I've made a suggestion as to whether or not we > should create > >an IANA registration, and if so, what policy (see [1] for > explanations) > >should be used for assignment. The default policy in the > document for > >all remaining value spaces will be that there must be a new > version of > >MRCP for any changes to occur. > > > >I would like to hear if there are any opinions on these, > particularly > >if they differ from my suggestions. > >I would also like particularly to hear feedback on 2 and 5, below, > >since my suggested assignment protocol may be quite restrictive with > >respect to vendor extensions. > > > >1. Name space: resource types (sec. 4.2) IANA registry?: no > >Comment: This is a core part of the spec and requires significant > >understanding and industry consensus. The introduction of a new > >resource should require approval of a working group and not just one > >expert. > > > > > I believe this was one the items to be registered with the IANA. > Registering with the IANA by itself > does not make it any more easy or difficult to add new > resource types. > The idea behind the MRCP framework, its resource types and > the way the protocol is modeled is that future RFCs can > propose to add more resources definitions extensions to > handle such resources. > > New resources may be added into the framework in the future > by defining a new RFC thats specifies the working of that > resource as long as it does not change the framework or > existing resources. Only if the existing resources and their > working are being changed or upgraded in the future would a > new RFC to override this be needed. > > So I believe this needs to be registered. > > >2. Name space: extension methods (sec. 5.1) IANA registry?: yes > >Assignment protocol: IETF Review > >Comment: It should be possible to extend the set of methods without > >creating a whole new version of MRCP. > >Or should it? If not, why do we permit it in the spec? > > > > > Yes. New extenion methods can be poposed through additiona > RFCs as long as they don't change the behaviour of the > existing methods and headers. > If existing functionality is being changed, I believe you > would need a new version of MRCP RFC to supercede this one. > > >3. Name space: request state (sec. 5.2) IANA registry?: no > >Comment: This is unlikely to change. If there were a need to change > >this it would probably require a re-think of the entire protocol. > > > > > agreed. > > >4. Name space: status codes (sec. 5.2) > >IANA registry?: yes > >Assignment protocol: Specification Required with Expert Review > >Comment: This is the sort of thing that might need to be adjusted > >based on further implementation experience by the industry. > It should > >not require a re-write of the spec, but any additions would > need to be > >reviewed for sanity and documented for portability. By the way, I > >would recommend that we include a small number of codes specifically > >for experimental use (see [2]). > > > > > agreed. > > >5. Name space: extension events (sec. 5.3) IANA registry?: yes > >Assignment protocol: IETF Review > >Comment: It should be possible to extend the set of events without > >creating a whole new version of MRCP. > >Or should it? If not, why do we permit it in the spec? > > > > > Agreed. This the same as extending methods. I think methods > and events should be in the same namespace to avoid > conflicting choices for method names and event names. > > >6. Name space: extension headers (sec. 6.1) IANA registry?: yes > >Assignment protocol: IETF Review > >Comment: It should be possible to extend the set of headers without > >creating a whole new version of MRCP. > >Or should it? If not, why do we permit it in the spec? > > > > > > > Agreed. > > >7. Name space: vendor-specific headers (sec. 6.1) IANA registry?: no > >Comment: Such parameters are already clearly identified by the > >"Vendor-Specific-Parameters" prefix and thus the contents are > >well-known to be vendor-specific. > > > > > The question then is how is the server or client to recognize > which vendors resource it is and hence what parameters it supports? > > >8. Name space: parameter list (sec. 6.2/6.3) IANA registry?: yes > >Assignment protocol: IETF Review > >Comment: This one I'm not sure about. It's similar to > >2 and 5, above, but the draft does not currently provide a slot for > >such extensions (i.e. the list is currently closed). I think the > >permissability of extensions here should match that for 2 and 5, > >whether we permit extensions for all (without a new MRCP spec) or > >whether we prohibit all extenions (and require a new MRCP spec for > >changes). > > > > > Yes this should also be extensible. > > >9. Name space: completion cause (for each resource) IANA > registry?: no > >Comment: Although I think there might be some use in having > a registry > >for each, it seems like overkill to do it. I could be persuaded > >otherwise, however. > > > > > The meaning of Completion Cause resource specific. Hence I > think future resources, if any, would define their own list of values. > So I agree with the above. > > > 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. > > Thanks, > Sarvi > > >-- Dan > > > >[1] > >http://www.ietf.org/internet-drafts/draft-narten-iana-conside rations-rfc243 > 4bis-01.txt > >[2] ftp://ftp.rfc-editor.org/in-notes/bcp/bcp82.txt > > > > > > > > > >__________________________________ > >Do you Yahoo!? > >Take Yahoo! Mail with you! Get it on your mobile phone. > >http://mobile.yahoo.com/maildemo > > > >_______________________________________________ > >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 Jan 25 11:36: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 LAA18741 for ; Tue, 25 Jan 2005 11:36:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtTwi-0007cT-MU for speechsc-web-archive@ietf.org; Tue, 25 Jan 2005 11:53:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtTeh-0002Wt-4o; Tue, 25 Jan 2005 11:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtTY1-0001Lk-2X for speechsc@megatron.ietf.org; Tue, 25 Jan 2005 11:28:09 -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 LAA18094 for ; Tue, 25 Jan 2005 11:28:06 -0500 (EST) Received: from mail.lumenvox.com ([206.169.193.45] helo=lv-svr.lumenvox.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtToj-0007Ig-S9 for speechsc@ietf.org; Tue, 25 Jan 2005 11:45:27 -0500 Received: from PROGTHOMAS ([10.0.0.141]) by lv-svr.lumenvox.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 25 Jan 2005 08:23:25 -0800 From: "Thomas Gal" To: "'Reifenrath, Klaus'" , "'Dan Burnett'" Subject: RE: [Speechsc] IANA considerations for group feedback Date: Tue, 25 Jan 2005 08:27:32 -0800 Organization: LumenVox LLC MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: Thread-Index: AcUCD02fqnR6lPMSRoGimxtZlWLyIAA5bORg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Message-ID: X-OriginalArrivalTime: 25 Jan 2005 16:23:25.0046 (UTC) FILETIME=[31CC0160:01C502FA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Content-Transfer-Encoding: 7bit Cc: speechsc@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ThomasGal@LumenVox.com 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: 1449ead51a2ff026dcb23465f5379250 Content-Transfer-Encoding: 7bit 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 thomasgal@lumenvox.com > -----Original Message----- > From: speechsc-bounces@ietf.org > [mailto:speechsc-bounces@ietf.org] On Behalf Of Reifenrath, Klaus > Sent: Monday, January 24, 2005 4:21 AM > 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 > protocol identifier (probably need to be coordinated with the > MMUSIC group): > > - SCTP > - TLS > > At the last F2F meeting in San Diego we discussed caller > preference-based SIP routing, which most likely would require > some more IANA registrations. > > Best regards, > Klaus > > -----Original Message----- > From: Dan Burnett [mailto:dan_burnett2000@yahoo.com] > Sent: Freitag, 21. Januar 2005 19:52 > To: speechsc@ietf.org > Subject: [Speechsc] IANA considerations for group feedback > > > Group, > > In the course of reviewing the draft in order to write the > IANA Considerations sections, I've identified the following > value spaces for which one might consider requesting IANA to > maintain a registry. For each one, I've made a suggestion as > to whether or not we should create an IANA registration, and > if so, what policy (see [1] for explanations) should be used > for assignment. The default policy in the document for all > remaining value spaces will be that there must be a new > version of MRCP for any changes to occur. > > I would like to hear if there are any opinions on these, > particularly if they differ from my suggestions. > I would also like particularly to hear feedback on 2 and 5, > below, since my suggested assignment protocol may be quite > restrictive with respect to vendor extensions. > > 1. Name space: resource types (sec. 4.2) IANA registry?: no > Comment: This is a core part of the spec and requires > significant understanding and industry consensus. The > introduction of a new resource should require approval of a > working group and not just one expert. > > 2. Name space: extension methods (sec. 5.1) IANA registry?: > yes Assignment protocol: IETF Review > Comment: It should be possible to extend the set of methods > without creating a whole new version of MRCP. > Or should it? If not, why do we permit it in the spec? > > 3. Name space: request state (sec. 5.2) > IANA registry?: no > Comment: This is unlikely to change. If there were a need to > change this it would probably require a re-think of the > entire protocol. > > 4. Name space: status codes (sec. 5.2) > IANA registry?: yes > Assignment protocol: Specification Required with Expert Review > Comment: This is the sort of thing that might need to be > adjusted based on further implementation experience by the > industry. It should not require a re-write of the spec, but > any additions would need to be reviewed for sanity and > documented for portability. By the way, I would recommend > that we include a small number of codes specifically for > experimental use (see [2]). > > 5. Name space: extension events (sec. 5.3) IANA registry?: > yes Assignment protocol: IETF Review > Comment: It should be possible to extend the set of events > without creating a whole new version of MRCP. > Or should it? If not, why do we permit it in the spec? > > 6. Name space: extension headers (sec. 6.1) IANA registry?: > yes Assignment protocol: IETF Review > Comment: It should be possible to extend the set of headers > without creating a whole new version of MRCP. > Or should it? If not, why do we permit it in the spec? > > 7. Name space: vendor-specific headers (sec. 6.1) IANA registry?: no > Comment: Such parameters are already clearly identified by > the "Vendor-Specific-Parameters" prefix and thus the > contents are well-known to be vendor-specific. > > 8. Name space: parameter list (sec. 6.2/6.3) IANA registry?: > yes Assignment protocol: IETF Review > Comment: This one I'm not sure about. It's similar to > 2 and 5, above, but the draft does not currently provide a > slot for such extensions (i.e. the list is currently closed). > I think the permissability of extensions here should match > that for 2 and 5, whether we permit extensions for all > (without a new MRCP spec) or whether we prohibit all > extenions (and require a new MRCP spec for changes). > > 9. Name space: completion cause (for each resource) IANA registry?: no > Comment: Although I think there might be some use in having a > registry for each, it seems like overkill to do it. I could > be persuaded otherwise, however. > > -- Dan > > [1] > http://www.ietf.org/internet-drafts/draft-narten-iana-consider > ations-rfc2434 > bis-01.txt > [2] ftp://ftp.rfc-editor.org/in-notes/bcp/bcp82.txt > > > > > __________________________________ > Do you Yahoo!? > Take Yahoo! Mail with you! Get it on your mobile phone. > http://mobile.yahoo.com/maildemo > > _______________________________________________ > 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 Wed Jan 26 13:18:58 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 NAA25800 for ; Wed, 26 Jan 2005 13:18:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cts1o-0006g3-VO for speechsc-web-archive@ietf.org; Wed, 26 Jan 2005 13:36:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctrew-0002a5-Rl; Wed, 26 Jan 2005 13:12:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtrYn-0000kX-AE for speechsc@megatron.ietf.org; Wed, 26 Jan 2005 13:06:33 -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 NAA24552 for ; Wed, 26 Jan 2005 13:06:30 -0500 (EST) Received: from web14122.mail.yahoo.com ([66.163.171.113]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Ctrpk-0006Ie-5O for speechsc@ietf.org; Wed, 26 Jan 2005 13:24:05 -0500 Received: (qmail 41280 invoked by uid 60001); 26 Jan 2005 18:06: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=QkZQgKacNPv7RKdOtydWyHxrfmKu3pI79w4XQOoWVcU6sPRox7zgubUfCFFA/CgpnKLa9hQBvnGotrwILmU88cAyRH2PcT3/cYoaJblchZegmt7udQ4YKCSMz1Cx6WfNGW05/ThM87Ud6GIZ4i9AkFHfdxCoV0szGg4BqcKTgDw= ; Message-ID: <20050126180630.41278.qmail@web14122.mail.yahoo.com> Received: from [63.193.248.104] by web14122.mail.yahoo.com via HTTP; Wed, 26 Jan 2005 10:06:30 PST Date: Wed, 26 Jan 2005 10:06:30 -0800 (PST) From: Dan Burnett Subject: Re: [Speechsc] IANA considerations for group feedback To: Sarvi Shanmugham In-Reply-To: <41F19F01.2040008@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 3.0 (+++) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f 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: a1f9797ba297220533cb8c3f4bc709a8 I'm not sure I agree with all of your "Specification Required" Allocation policies, since they require only an RFC (possibly Informational) rather than a complete review. Did you by any chance mean to suggest "IETF Review", which includes a requirement for an RFC, or even "Standards Action", the most stringent requirement? Also, for the vendor specific parameters you suggested "Hierarchical Allocation". I agree with this and would recommend either "First Come First Served" or "Expert Review" for the top-level with delegation to the requester for anything below. Note that for vendor specific parameters, the draft says "The vendor-av-pair-name can be any Vendor specific field name and conforms to the XML vendor-specific attribute naming convention". Unfortunately, I doubt this is sufficiently precise for IANA. Can anyone suggest some more complete specification text for the various vendor-specific paramaters and IDs in the document? -- dan --- Sarvi Shanmugham wrote: > After reviewing the IANA considerations guidelines, > the protocol for > additional values should be as follows. see inline. > Dan Burnett wrote: > > >Group, > > > >In the course of reviewing the draft in order to > write > >the IANA Considerations sections, I've identified > the > >following value spaces for which one might consider > >requesting IANA to maintain a registry. For each > one, > >I've made a suggestion as to whether or not we > should > >create an IANA registration, and if so, what policy > >(see [1] for explanations) should be used for > >assignment. The default policy in the document for > >all remaining value spaces will be that there must > be > >a new version of MRCP for any changes to occur. > > > >I would like to hear if there are any opinions on > >these, particularly if they differ from my > >suggestions. > >I would also like particularly to hear feedback on > 2 > >and 5, below, since my suggested assignment > protocol > >may be quite restrictive with respect to vendor > >extensions. > > > >1. Name space: resource types (sec. 4.2) > >IANA registry?: no > >Comment: This is a core part of the spec and > requires > >significant understanding and industry consensus. > The > >introduction of a new resource should require > approval > >of a working group and not just one expert. > > > > > > Assignment Protocol: Specification Required > > > >2. Name space: extension methods (sec. 5.1) > >IANA registry?: yes > >Assignment protocol: IETF Review > > > > > Assignment Protocol: Specification Required > > >Comment: It should be possible to extend the set of > >methods without creating a whole new version of > MRCP. > >Or should it? If not, why do we permit it in the > >spec? > > > >3. Name space: request state (sec. 5.2) > >IANA registry?: no > >Comment: This is unlikely to change. If there were > a > >need to change this it would probably require a > >re-think of the entire protocol. > > > >4. Name space: status codes (sec. 5.2) > >IANA registry?: yes > >Assignment protocol: Specification Required with > >Expert Review > >Comment: This is the sort of thing that might need > to > >be adjusted based on further implementation > experience > >by the industry. It should not require a re-write > of > >the spec, but any additions would need to be > reviewed > >for sanity and documented for portability. By the > >way, I would recommend that we include a small > number > >of codes specifically for experimental use (see > [2]). > > > >5. Name space: extension events (sec. 5.3) > >IANA registry?: yes > >Assignment protocol: IETF Review > > > > > > Assignment Protocol: Specification Required > > >Comment: It should be possible to extend the set of > >events without creating a whole new version of > MRCP. > >Or should it? If not, why do we permit it in the > >spec? > > > >6. Name space: extension headers (sec. 6.1) > >IANA registry?: yes > >Assignment protocol: IETF Review > > > > > > Assignment Protocol: Specification Required > > >Comment: It should be possible to extend the set of > >headers without creating a whole new version of > MRCP. > >Or should it? If not, why do we permit it in the > >spec? > > > >7. Name space: vendor-specific headers (sec. 6.1) > >IANA registry?: no > >Comment: Such parameters are already clearly > >identified by the "Vendor-Specific-Parameters" > prefix > >and thus the contents are well-known to be > >vendor-specific. > > > > > Yes. > Assignment Protocol: Hierarchical allocation > Example: Object Identifiers. > > > >8. Name space: parameter list (sec. 6.2/6.3) > >IANA registry?: yes > >Assignment protocol: IETF Review > > > > > > Assignment Protocol: Specification Required > > >Comment: This one I'm not sure about. It's similar > to > >2 and 5, above, but the draft does not currently > >provide a slot for such extensions (i.e. the list > is > >currently closed). I think the permissability of > >extensions here should match that for 2 and 5, > whether > >we permit extensions for all (without a new MRCP > spec) > >or whether we prohibit all extenions (and require a > >new MRCP spec for changes). > > > >9. Name space: completion cause (for each resource) > >IANA registry?: no > >Comment: Although I think there might be some use > in > >having a registry for each, it seems like overkill > to > >do it. I could be persuaded otherwise, however. > > > > > > > > > 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. > > Assignment Protocol: Hierarchical allocation > Example: Object Identifiers. > > > > Thanks, > Sarvi > > >-- Dan > > > >[1] > >http://www.ietf.org/internet-drafts/draft-narten-iana-considerations-rfc2434bis-01.txt > >[2] ftp://ftp.rfc-editor.org/in-notes/bcp/bcp82.txt > > > > > > > > > >__________________________________ > >Do you Yahoo!? > >Take Yahoo! Mail with you! Get it on your mobile > phone. > >http://mobile.yahoo.com/maildemo > > > >_______________________________________________ > >Speechsc mailing list > >Speechsc@ietf.org > >https://www1.ietf.org/mailman/listinfo/speechsc > > > > > > > === message truncated === __________________________________ 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 Wed Jan 26 13:33: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 NAA27233 for ; Wed, 26 Jan 2005 13:33:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtsFg-0007AH-7e for speechsc-web-archive@ietf.org; Wed, 26 Jan 2005 13:50:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtrvW-0007pi-H5; Wed, 26 Jan 2005 13:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctrh2-0003Ee-8s for speechsc@megatron.ietf.org; Wed, 26 Jan 2005 13:15:04 -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 NAA25493 for ; Wed, 26 Jan 2005 13:15:01 -0500 (EST) Received: from web14125.mail.yahoo.com ([66.163.171.116]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Ctrxy-0006aD-S2 for speechsc@ietf.org; Wed, 26 Jan 2005 13:32:36 -0500 Received: (qmail 43319 invoked by uid 60001); 26 Jan 2005 18:15:01 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=r42T6GueFGnOrDA3FZ5ZtHw9WVjk3QTTEfcdvJLSNkAvQCRiU5qC6PslVzIgD7vD9Hw/xMD99Jpy/9y44plhke+Vt8mh9QGplsXdciStaPqFIuqioF8IDHcrqocg2Ss25g+i/OCYBtV3HCTEJNG4OEK3Cio3cnGUs1hn0sZ+mV4= ; Message-ID: <20050126181501.43317.qmail@web14125.mail.yahoo.com> Received: from [63.193.248.104] by web14125.mail.yahoo.com via HTTP; Wed, 26 Jan 2005 10:15:01 PST Date: Wed, 26 Jan 2005 10:15:01 -0800 (PST) From: Dan Burnett Subject: RE: [Speechsc] IANA considerations for group feedback To: "Reifenrath, Klaus" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 3.0 (+++) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 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: df9edf1223802dd4cf213867a3af6121 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. 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? -- dan --- "Reifenrath, Klaus" wrote: > 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 > protocol identifier (probably need to be coordinated > with the MMUSIC group): > > - SCTP > - TLS > > At the last F2F meeting in San Diego we discussed > caller preference-based > SIP routing, which most likely would require some > more IANA registrations. > > Best regards, > Klaus > > -----Original Message----- > From: Dan Burnett [mailto:dan_burnett2000@yahoo.com] > Sent: Freitag, 21. Januar 2005 19:52 > To: speechsc@ietf.org > Subject: [Speechsc] IANA considerations for group > feedback > > > Group, > > In the course of reviewing the draft in order to > write > the IANA Considerations sections, I've identified > the > following value spaces for which one might consider > requesting IANA to maintain a registry. For each > one, > I've made a suggestion as to whether or not we > should > create an IANA registration, and if so, what policy > (see [1] for explanations) should be used for > assignment. The default policy in the document for > all remaining value spaces will be that there must > be > a new version of MRCP for any changes to occur. > > I would like to hear if there are any opinions on > these, particularly if they differ from my > suggestions. > I would also like particularly to hear feedback on 2 > and 5, below, since my suggested assignment protocol > may be quite restrictive with respect to vendor > extensions. > > 1. Name space: resource types (sec. 4.2) > IANA registry?: no > Comment: This is a core part of the spec and > requires > significant understanding and industry consensus. > The > introduction of a new resource should require > approval > of a working group and not just one expert. > > 2. Name space: extension methods (sec. 5.1) > IANA registry?: yes > Assignment protocol: IETF Review > Comment: It should be possible to extend the set of > methods without creating a whole new version of > MRCP. > Or should it? If not, why do we permit it in the > spec? > > 3. Name space: request state (sec. 5.2) > IANA registry?: no > Comment: This is unlikely to change. If there were > a > need to change this it would probably require a > re-think of the entire protocol. > > 4. Name space: status codes (sec. 5.2) > IANA registry?: yes > Assignment protocol: Specification Required with > Expert Review > Comment: This is the sort of thing that might need > to > be adjusted based on further implementation > experience > by the industry. It should not require a re-write > of > the spec, but any additions would need to be > reviewed > for sanity and documented for portability. By the > way, I would recommend that we include a small > number > of codes specifically for experimental use (see > [2]). > > 5. Name space: extension events (sec. 5.3) > IANA registry?: yes > Assignment protocol: IETF Review > Comment: It should be possible to extend the set of > events without creating a whole new version of MRCP. > > Or should it? If not, why do we permit it in the > spec? > > 6. Name space: extension headers (sec. 6.1) > IANA registry?: yes > Assignment protocol: IETF Review > Comment: It should be possible to extend the set of > headers without creating a whole new version of > MRCP. > Or should it? If not, why do we permit it in the > spec? > > 7. Name space: vendor-specific headers (sec. 6.1) > IANA registry?: no > Comment: Such parameters are already clearly > identified by the "Vendor-Specific-Parameters" > prefix > and thus the contents are well-known to be > vendor-specific. > > 8. Name space: parameter list (sec. 6.2/6.3) > IANA registry?: yes > Assignment protocol: IETF Review > Comment: This one I'm not sure about. It's similar > to > 2 and 5, above, but the draft does not currently > provide a slot for such extensions (i.e. the list is > currently closed). I think the permissability of > extensions here should match that for 2 and 5, > whether > we permit extensions for all (without a new MRCP > spec) > or whether we prohibit all extenions (and require a > new MRCP spec for changes). > > 9. Name space: completion cause (for each resource) > IANA registry?: no > Comment: Although I think there might be some use in > having a registry for each, it seems like overkill > to > do it. I could be persuaded otherwise, however. > > -- Dan > > [1] > http://www.ietf.org/internet-drafts/draft-narten-iana-considerations-rfc2434 > bis-01.txt > [2] ftp://ftp.rfc-editor.org/in-notes/bcp/bcp82.txt > > > > > __________________________________ > Do you Yahoo!? > Take Yahoo! Mail with you! Get it on your mobile > phone. > http://mobile.yahoo.com/maildemo > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Jan 26 13:36: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 NAA27532 for ; Wed, 26 Jan 2005 13:36:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtsIw-0007G2-QY for speechsc-web-archive@ietf.org; Wed, 26 Jan 2005 13:54:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctrvo-00081b-8r; Wed, 26 Jan 2005 13:30:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctrjt-0003aY-GK for speechsc@megatron.ietf.org; Wed, 26 Jan 2005 13:18: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 NAA25713 for ; Wed, 26 Jan 2005 13:17:58 -0500 (EST) Received: from web14122.mail.yahoo.com ([66.163.171.113]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cts0r-0006dS-4H for speechsc@ietf.org; Wed, 26 Jan 2005 13:35:33 -0500 Received: (qmail 43729 invoked by uid 60001); 26 Jan 2005 18:18:00 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=olyG1UGlEnrX+ljCHbehrv98LeVuVaGldWlA1hPDHDdsMFnk6yxRwDTZT4FMQs8dkef0yU2ZkjqKsgED05VUcCzf7s7n/BbJPGPsB38VdfukwTLvdFirMUGSogcPVXbqqhJ9tJC/vXxFceNJ9Nb/Z75Gmr1SCppEOMtRIyeYcQI= ; Message-ID: <20050126181800.43727.qmail@web14122.mail.yahoo.com> Received: from [63.193.248.104] by web14122.mail.yahoo.com via HTTP; Wed, 26 Jan 2005 10:17:59 PST Date: Wed, 26 Jan 2005 10:17:59 -0800 (PST) From: Dan Burnett Subject: RE: [Speechsc] IANA considerations for group feedback To: "Reifenrath, Klaus" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 3.0 (+++) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 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: ff0adf256e4dd459cc25215cfa732ac1 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 > protocol identifier (probably need to be coordinated > with the MMUSIC group): > > - SCTP > - TLS > > At the last F2F meeting in San Diego we discussed > caller preference-based > SIP routing, which most likely would require some > more IANA registrations. > > Best regards, > Klaus > > -----Original Message----- > From: Dan Burnett [mailto:dan_burnett2000@yahoo.com] > Sent: Freitag, 21. Januar 2005 19:52 > To: speechsc@ietf.org > Subject: [Speechsc] IANA considerations for group > feedback > > > Group, > > In the course of reviewing the draft in order to > write > the IANA Considerations sections, I've identified > the > following value spaces for which one might consider > requesting IANA to maintain a registry. For each > one, > I've made a suggestion as to whether or not we > should > create an IANA registration, and if so, what policy > (see [1] for explanations) should be used for > assignment. The default policy in the document for > all remaining value spaces will be that there must > be > a new version of MRCP for any changes to occur. > > I would like to hear if there are any opinions on > these, particularly if they differ from my > suggestions. > I would also like particularly to hear feedback on 2 > and 5, below, since my suggested assignment protocol > may be quite restrictive with respect to vendor > extensions. > > 1. Name space: resource types (sec. 4.2) > IANA registry?: no > Comment: This is a core part of the spec and > requires > significant understanding and industry consensus. > The > introduction of a new resource should require > approval > of a working group and not just one expert. > > 2. Name space: extension methods (sec. 5.1) > IANA registry?: yes > Assignment protocol: IETF Review > Comment: It should be possible to extend the set of > methods without creating a whole new version of > MRCP. > Or should it? If not, why do we permit it in the > spec? > > 3. Name space: request state (sec. 5.2) > IANA registry?: no > Comment: This is unlikely to change. If there were > a > need to change this it would probably require a > re-think of the entire protocol. > > 4. Name space: status codes (sec. 5.2) > IANA registry?: yes > Assignment protocol: Specification Required with > Expert Review > Comment: This is the sort of thing that might need > to > be adjusted based on further implementation > experience > by the industry. It should not require a re-write > of > the spec, but any additions would need to be > reviewed > for sanity and documented for portability. By the > way, I would recommend that we include a small > number > of codes specifically for experimental use (see > [2]). > > 5. Name space: extension events (sec. 5.3) > IANA registry?: yes > Assignment protocol: IETF Review > Comment: It should be possible to extend the set of > events without creating a whole new version of MRCP. > > Or should it? If not, why do we permit it in the > spec? > > 6. Name space: extension headers (sec. 6.1) > IANA registry?: yes > Assignment protocol: IETF Review > Comment: It should be possible to extend the set of > headers without creating a whole new version of > MRCP. > Or should it? If not, why do we permit it in the > spec? > > 7. Name space: vendor-specific headers (sec. 6.1) > IANA registry?: no > Comment: Such parameters are already clearly > identified by the "Vendor-Specific-Parameters" > prefix > and thus the contents are well-known to be > vendor-specific. > > 8. Name space: parameter list (sec. 6.2/6.3) > IANA registry?: yes > Assignment protocol: IETF Review > Comment: This one I'm not sure about. It's similar > to > 2 and 5, above, but the draft does not currently > provide a slot for such extensions (i.e. the list is > currently closed). I think the permissability of > extensions here should match that for 2 and 5, > whether > we permit extensions for all (without a new MRCP > spec) > or whether we prohibit all extenions (and require a > new MRCP spec for changes). > > 9. Name space: completion cause (for each resource) > IANA registry?: no > Comment: Although I think there might be some use in > having a registry for each, it seems like overkill > to > do it. I could be persuaded otherwise, however. > > -- Dan > > [1] > http://www.ietf.org/internet-drafts/draft-narten-iana-considerations-rfc2434 > bis-01.txt > [2] ftp://ftp.rfc-editor.org/in-notes/bcp/bcp82.txt > > > > > __________________________________ > Do you Yahoo!? > Take Yahoo! Mail with you! Get it on your mobile > phone. > http://mobile.yahoo.com/maildemo > > _______________________________________________ > 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 > __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. 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 Jan 26 13:38: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 NAA27625 for ; Wed, 26 Jan 2005 13:38:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtsKR-0007II-6c for speechsc-web-archive@ietf.org; Wed, 26 Jan 2005 13:55:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctrxa-0000Od-GO; Wed, 26 Jan 2005 13:32:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtrmJ-0004Jn-44 for speechsc@megatron.ietf.org; Wed, 26 Jan 2005 13:20:31 -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 NAA25955 for ; Wed, 26 Jan 2005 13:20:27 -0500 (EST) Received: from web14121.mail.yahoo.com ([66.163.171.112]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cts3F-0006iO-Nc for speechsc@ietf.org; Wed, 26 Jan 2005 13:38:03 -0500 Received: (qmail 15652 invoked by uid 60001); 26 Jan 2005 18:20:28 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=s9jo0yk/KF0AEcuwm1/8Uxbaxt6iNCKHCUuYdrb0IA37AK73GDUMq6YOdcIXz4HsfQTnWd/NdWZGy5XVB7YkI1iVMN7sx8PFrrlDc2kr9rigOinVNzvQAk6CfleVd4MS/MPpJ9r3rKtVxjAorndpb9ID1VZe3R9U3GYvUh+a4Lc= ; Message-ID: <20050126182028.15650.qmail@web14121.mail.yahoo.com> Received: from [63.193.248.104] by web14121.mail.yahoo.com via HTTP; Wed, 26 Jan 2005 10:20:28 PST Date: Wed, 26 Jan 2005 10:20:28 -0800 (PST) From: Dan Burnett Subject: RE: [Speechsc] IANA considerations for group feedback To: ThomasGal@LumenVox.com, "'Ken Robbins'" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 3.0 (+++) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 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: e367d58950869b6582535ddf5a673488 application/sml is supposed to be application/synthesis+xml. It was a typo that originally should have been application/ssml. --- Thomas Gal wrote: > Inline > > -Tom > > thomasgal@lumenvox.com > > > application/sml > > Appears on page 139. Is this a typo? > > > > I think it's page 138 and it's a speak command so > it's gotta be > nlsml. > > > application/x-nlsml > > Not IANA registered. Do "x-" subtypes need to > be? > > > > I think items prefaces with "x-" are specifically > precluded from > IANA as experimental by notation. I think this was a > vestige of it's > previous status(abandoned/incomplete) with the W3C, > and should be just > application/nlsml or something else along those > lines. In fact it would be > good to alleviate confusion with the W3C spec, as > well as indicate that > we've finalized it. > > > application/octets > > Not IANA registered. Note that octet-stream > is > > registered. Do we mean octets or octet-stream? > > > > I don't think we need to register octets or octet > stream really as > this is a functional "catch-all" in the spec meant > to indicate anything > specifically uninterrupted or opaque, like a > recognizer context block. Even > where we specify the message body as *OCTET it's not > really just that but > will end up being an actual mime-type which is > supported by the recognizer. > These should obviously all be specified, but octet > is just a place holder > here. As for the lexical usage in various parts of > the grammar I don't think > that's important from this perspective either. > > > > > Ken Robbins > > Brooktrout Technology, Inc. > > > > > > -----Original Message----- > > From: Sarvi Shanmugham [mailto:sarvi@cisco.com] > > Sent: Friday, January 21, 2005 3:31 PM > > To: Dan Burnett > > Cc: speechsc@ietf.org > > Subject: Re: [Speechsc] IANA considerations for > group feedback > > > > comments line. > > Dan Burnett wrote: > > > > >Group, > > > > > >In the course of reviewing the draft in order to > write the IANA > > >Considerations sections, I've identified the > following value > > spaces for > > >which one might consider requesting IANA to > maintain a > > registry. For > > >each one, I've made a suggestion as to whether or > not we > > should create > > >an IANA registration, and if so, what policy (see > [1] for > > explanations) > > >should be used for assignment. The default > policy in the > > document for > > >all remaining value spaces will be that there > must be a new > > version of > > >MRCP for any changes to occur. > > > > > >I would like to hear if there are any opinions on > these, > > particularly > > >if they differ from my suggestions. > > >I would also like particularly to hear feedback > on 2 and 5, below, > > >since my suggested assignment protocol may be > quite restrictive with > > >respect to vendor extensions. > > > > > >1. Name space: resource types (sec. 4.2) IANA > registry?: no > > >Comment: This is a core part of the spec and > requires significant > > >understanding and industry consensus. The > introduction of a new > > >resource should require approval of a working > group and not just one > > >expert. > > > > > > > > I believe this was one the items to be registered > with the IANA. > > Registering with the IANA by itself > > does not make it any more easy or difficult to add > new > > resource types. > > The idea behind the MRCP framework, its resource > types and > > the way the protocol is modeled is that future > RFCs can > > propose to add more resources definitions > extensions to > > handle such resources. > > > > New resources may be added into the framework in > the future > > by defining a new RFC thats specifies the working > of that > > resource as long as it does not change the > framework or > > existing resources. Only if the existing > resources and their > > working are being changed or upgraded in the > future would a > > new RFC to override this be needed. > > > > So I believe this needs to be registered. > > > > >2. Name space: extension methods (sec. 5.1) IANA > registry?: yes > > >Assignment protocol: IETF Review > > >Comment: It should be possible to extend the set > of methods without > > >creating a whole new version of MRCP. > > >Or should it? If not, why do we permit it in the > spec? > > > > > > > > Yes. New extenion methods can be poposed through > additiona > > RFCs as long as they don't change the behaviour of > the > > existing methods and headers. > > If existing functionality is being changed, I > believe you > > would need a new version of MRCP RFC to supercede > this one. > > > > >3. Name space: request state (sec. 5.2) IANA > registry?: no > > >Comment: This is unlikely to change. If there > were a need to change > > >this it would probably require a re-think of the > entire protocol. > > > > > > > > agreed. > > > > >4. Name space: status codes (sec. 5.2) > > >IANA registry?: yes > > >Assignment protocol: Specification Required with > Expert Review > > >Comment: This is the sort of thing that might > need to be adjusted > > >based on further implementation experience by the > industry. > > It should > > >not require a re-write of the spec, but any > additions would > > need to be > > >reviewed for sanity and documented for > portability. By the way, I > > >would recommend that we include a small number of > codes specifically > > >for experimental use (see [2]). > > > > > > > > agreed. > > > > >5. Name space: extension events (sec. 5.3) IANA > registry?: yes > > >Assignment protocol: IETF Review > > >Comment: It should be possible to extend the set > of events without > > >creating a whole new version of MRCP. > > >Or should it? If not, why do we permit it in the > spec? > === message truncated === __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Jan 26 13:43: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 NAA28002 for ; Wed, 26 Jan 2005 13:43:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtsPR-0007Pb-Ac for speechsc-web-archive@ietf.org; Wed, 26 Jan 2005 14:00:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctrxs-0000af-F7; Wed, 26 Jan 2005 13:32:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctrt5-0006X7-Bk for speechsc@megatron.ietf.org; Wed, 26 Jan 2005 13:27:31 -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 NAA26595 for ; Wed, 26 Jan 2005 13:27:28 -0500 (EST) Received: from web14121.mail.yahoo.com ([66.163.171.112]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CtsA2-0006vW-Vr for speechsc@ietf.org; Wed, 26 Jan 2005 13:45:03 -0500 Received: (qmail 16754 invoked by uid 60001); 26 Jan 2005 18:27: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=jN3jzRhR4R0hxvPKP35uPr+dr8E3fzkIJaBiJoiNJJLl38V+3F8yfHxlG4PB4L34OoLfeN8vn00H5YQjwaxDn/0DGuKCRfUA6dNcIerC/5QUVnXPbpFzdn/gUgF4a9VBQFykKJReBDh4JW7YPMQ0BEzlHK/tKGq1lq1m11BD77s= ; Message-ID: <20050126182729.16752.qmail@web14121.mail.yahoo.com> Received: from [63.193.248.104] by web14121.mail.yahoo.com via HTTP; Wed, 26 Jan 2005 10:27:29 PST Date: Wed, 26 Jan 2005 10:27:29 -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: 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 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? -- 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 > > thomasgal@lumenvox.com > > > -----Original Message----- > > From: speechsc-bounces@ietf.org > > [mailto:speechsc-bounces@ietf.org] On Behalf Of > Reifenrath, Klaus > > Sent: Monday, January 24, 2005 4:21 AM > > 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 > > protocol identifier (probably need to be > coordinated with the > > MMUSIC group): > > > > - SCTP > > - TLS > > > > At the last F2F meeting in San Diego we discussed > caller > > preference-based SIP routing, which most likely > would require > > some more IANA registrations. > > > > Best regards, > > Klaus > > > > -----Original Message----- > > From: Dan Burnett > [mailto:dan_burnett2000@yahoo.com] > > Sent: Freitag, 21. Januar 2005 19:52 > > To: speechsc@ietf.org > > Subject: [Speechsc] IANA considerations for group > feedback > > > > > > Group, > > > > In the course of reviewing the draft in order to > write the > > IANA Considerations sections, I've identified the > following > > value spaces for which one might consider > requesting IANA to > > maintain a registry. For each one, I've made a > suggestion as > > to whether or not we should create an IANA > registration, and > > if so, what policy (see [1] for explanations) > should be used > > for assignment. The default policy in the > document for all > > remaining value spaces will be that there must be > a new > > version of MRCP for any changes to occur. > > > > I would like to hear if there are any opinions on > these, > > particularly if they differ from my suggestions. > > I would also like particularly to hear feedback on > 2 and 5, > > below, since my suggested assignment protocol may > be quite > > restrictive with respect to vendor extensions. > > > > 1. Name space: resource types (sec. 4.2) IANA > registry?: no > > Comment: This is a core part of the spec and > requires > > significant understanding and industry consensus. > The > > introduction of a new resource should require > approval of a > > working group and not just one expert. > > > > 2. Name space: extension methods (sec. 5.1) IANA > registry?: > > yes Assignment protocol: IETF Review > > Comment: It should be possible to extend the set > of methods > > without creating a whole new version of MRCP. > > Or should it? If not, why do we permit it in the > spec? > > > > 3. Name space: request state (sec. 5.2) > > IANA registry?: no > > Comment: This is unlikely to change. If there > were a need to > > change this it would probably require a re-think > of the > > entire protocol. > > > > 4. Name space: status codes (sec. 5.2) > > IANA registry?: yes > > Assignment protocol: Specification Required with > Expert Review > > Comment: This is the sort of thing that might > need to be > > adjusted based on further implementation > experience by the > > industry. It should not require a re-write of the > spec, but > > any additions would need to be reviewed for sanity > and > > documented for portability. By the way, I would > recommend > > that we include a small number of codes > specifically for > > experimental use (see [2]). > > > > 5. Name space: extension events (sec. 5.3) IANA > registry?: > > yes Assignment protocol: IETF Review > > Comment: It should be possible to extend the set > of events > > without creating a whole new version of MRCP. > > Or should it? If not, why do we permit it in the > spec? > > > > 6. Name space: extension headers (sec. 6.1) IANA > registry?: > > yes Assignment protocol: IETF Review > > Comment: It should be possible to extend the set > of headers > > without creating a whole new version of MRCP. > > Or should it? If not, why do we permit it in the > spec? > > > > 7. Name space: vendor-specific headers (sec. 6.1) > IANA registry?: no > > Comment: Such parameters are already clearly > identified by > > the "Vendor-Specific-Parameters" prefix and thus > the > > contents are well-known to be vendor-specific. > > > > 8. Name space: parameter list (sec. 6.2/6.3) IANA > registry?: > > yes Assignment protocol: IETF Review > > Comment: This one I'm not sure about. It's > similar to > > 2 and 5, above, but the draft does not currently > provide a > > slot for such extensions (i.e. the list is > currently closed). > > I think the permissability of extensions here > should match > > that for 2 and 5, whether we permit extensions for > all > > (without a new MRCP spec) or whether we prohibit > all > > extenions (and require a new MRCP spec for > changes). > > > > 9. Name space: completion cause (for each > resource) IANA registry?: no > > Comment: Although I think there might be some use > in having a > > registry for each, it seems like overkill to do > it. I could > > be persuaded otherwise, however. > > > > -- Dan > > > > [1] > > > http://www.ietf.org/internet-drafts/draft-narten-iana-consider > > ations-rfc2434 > > bis-01.txt > > [2] > ftp://ftp.rfc-editor.org/in-notes/bcp/bcp82.txt > === message truncated === __________________________________ 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 Jan 26 13:51: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 NAA29112 for ; Wed, 26 Jan 2005 13:51:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtsXP-0007ks-CE for speechsc-web-archive@ietf.org; Wed, 26 Jan 2005 14:09:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtsBU-00055T-UC; Wed, 26 Jan 2005 13:46:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cts00-0001BC-LO for speechsc@megatron.ietf.org; Wed, 26 Jan 2005 13:34:41 -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 NAA27377 for ; Wed, 26 Jan 2005 13:34:37 -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 1CtsGx-0007CL-UT for speechsc@ietf.org; Wed, 26 Jan 2005 13:52:13 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 26 Jan 2005 11:43:08 +0000 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-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0QIY6l2028537; Wed, 26 Jan 2005 10:34:06 -0800 (PST) Received: from [128.107.139.169] ([128.107.139.169]) by vtg-um-e2k1.sj21ad.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Jan 2005 10:33:59 -0800 Message-ID: <41F7E296.1060106@cisco.com> Date: Wed, 26 Jan 2005 10:33:58 -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: <20050126180630.41278.qmail@web14122.mail.yahoo.com> In-Reply-To: <20050126180630.41278.qmail@web14122.mail.yahoo.com> X-OriginalArrivalTime: 26 Jan 2005 18:33:59.0021 (UTC) FILETIME=[999F79D0:01C503D5] X-Spam-Score: 0.5 (/) X-Scan-Signature: 6e5958278d089090169a903f246b3f39 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="===============1019179062==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 9ef34681c09171229a7cb90dad7dd8e0 This is a multi-part message in MIME format. --===============1019179062== Content-Type: multipart/alternative; boundary="------------040502010107000402050800" This is a multi-part message in MIME format. --------------040502010107000402050800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dan Burnett wrote: >I'm not sure I agree with all of your "Specification >Required" Allocation policies, since they require only >an RFC (possibly Informational) rather than a complete >review. Did you by any chance mean to suggest "IETF >Review", which includes a requirement for an RFC, or >even "Standards Action", the most stringent >requirement? > > Requiring an RFC is what I meant. Also this should not be just an Informational RFC. Which leaves us with the a Standards track RFC document. >Also, for the vendor specific parameters you suggested >"Hierarchical Allocation". I agree with this and >would recommend either "First Come First Served" or >"Expert Review" for the top-level with delegation to >the requester for anything below. > > ok Sarvi >Note that for vendor specific parameters, the draft >says "The vendor-av-pair-name can be any Vendor >specific field name and conforms to the XML >vendor-specific attribute naming convention". >Unfortunately, I doubt this is sufficiently precise >for IANA. Can anyone suggest some more complete >specification text for the various vendor-specific >paramaters and IDs in the document? > >-- dan > >--- Sarvi Shanmugham wrote: > > > >>After reviewing the IANA considerations guidelines, >>the protocol for >>additional values should be as follows. see inline. >>Dan Burnett wrote: >> >> >> >>>Group, >>> >>>In the course of reviewing the draft in order to >>> >>> >>write >> >> >>>the IANA Considerations sections, I've identified >>> >>> >>the >> >> >>>following value spaces for which one might consider >>>requesting IANA to maintain a registry. For each >>> >>> >>one, >> >> >>>I've made a suggestion as to whether or not we >>> >>> >>should >> >> >>>create an IANA registration, and if so, what policy >>>(see [1] for explanations) should be used for >>>assignment. The default policy in the document for >>>all remaining value spaces will be that there must >>> >>> >>be >> >> >>>a new version of MRCP for any changes to occur. >>> >>>I would like to hear if there are any opinions on >>>these, particularly if they differ from my >>>suggestions. >>>I would also like particularly to hear feedback on >>> >>> >>2 >> >> >>>and 5, below, since my suggested assignment >>> >>> >>protocol >> >> >>>may be quite restrictive with respect to vendor >>>extensions. >>> >>>1. Name space: resource types (sec. 4.2) >>>IANA registry?: no >>>Comment: This is a core part of the spec and >>> >>> >>requires >> >> >>>significant understanding and industry consensus. >>> >>> >>The >> >> >>>introduction of a new resource should require >>> >>> >>approval >> >> >>>of a working group and not just one expert. >>> >>> >>> >>> >>Assignment Protocol: Specification Required >> >> >> >> >>>2. Name space: extension methods (sec. 5.1) >>>IANA registry?: yes >>>Assignment protocol: IETF Review >>> >>> >>> >>> >>Assignment Protocol: Specification Required >> >> >> >>>Comment: It should be possible to extend the set of >>>methods without creating a whole new version of >>> >>> >>MRCP. >> >> >>>Or should it? If not, why do we permit it in the >>>spec? >>> >>>3. Name space: request state (sec. 5.2) >>>IANA registry?: no >>>Comment: This is unlikely to change. If there were >>> >>> >>a >> >> >>>need to change this it would probably require a >>>re-think of the entire protocol. >>> >>>4. Name space: status codes (sec. 5.2) >>>IANA registry?: yes >>>Assignment protocol: Specification Required with >>>Expert Review >>>Comment: This is the sort of thing that might need >>> >>> >>to >> >> >>>be adjusted based on further implementation >>> >>> >>experience >> >> >>>by the industry. It should not require a re-write >>> >>> >>of >> >> >>>the spec, but any additions would need to be >>> >>> >>reviewed >> >> >>>for sanity and documented for portability. By the >>>way, I would recommend that we include a small >>> >>> >>number >> >> >>>of codes specifically for experimental use (see >>> >>> >>[2]). >> >> >>>5. Name space: extension events (sec. 5.3) >>>IANA registry?: yes >>>Assignment protocol: IETF Review >>> >>> >>> >>> >>Assignment Protocol: Specification Required >> >> >> >>>Comment: It should be possible to extend the set of >>>events without creating a whole new version of >>> >>> >>MRCP. >> >> >>>Or should it? If not, why do we permit it in the >>>spec? >>> >>>6. Name space: extension headers (sec. 6.1) >>>IANA registry?: yes >>>Assignment protocol: IETF Review >>> >>> >>> >>> >>Assignment Protocol: Specification Required >> >> >> >>>Comment: It should be possible to extend the set of >>>headers without creating a whole new version of >>> >>> >>MRCP. >> >> >>>Or should it? If not, why do we permit it in the >>>spec? >>> >>>7. Name space: vendor-specific headers (sec. 6.1) >>>IANA registry?: no >>>Comment: Such parameters are already clearly >>>identified by the "Vendor-Specific-Parameters" >>> >>> >>prefix >> >> >>>and thus the contents are well-known to be >>>vendor-specific. >>> >>> >>> >>> >>Yes. >>Assignment Protocol: Hierarchical allocation >>Example: Object Identifiers. >> >> >> >> >>>8. Name space: parameter list (sec. 6.2/6.3) >>>IANA registry?: yes >>>Assignment protocol: IETF Review >>> >>> >>> >>> >>Assignment Protocol: Specification Required >> >> >> >>>Comment: This one I'm not sure about. It's similar >>> >>> >>to >> >> >>>2 and 5, above, but the draft does not currently >>>provide a slot for such extensions (i.e. the list >>> >>> >>is >> >> >>>currently closed). I think the permissability of >>>extensions here should match that for 2 and 5, >>> >>> >>whether >> >> >>>we permit extensions for all (without a new MRCP >>> >>> >>spec) >> >> >>>or whether we prohibit all extenions (and require a >>>new MRCP spec for changes). >>> >>>9. Name space: completion cause (for each resource) >>>IANA registry?: no >>>Comment: Although I think there might be some use >>> >>> >>in >> >> >>>having a registry for each, it seems like overkill >>> >>> >>to >> >> >>>do it. I could be persuaded otherwise, however. >>> >>> >>> >>> >> >> >>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. >> >>Assignment Protocol: Hierarchical allocation >>Example: Object Identifiers. >> >> >> >>Thanks, >>Sarvi >> >> >> >>>-- Dan >>> >>>[1] >>> >>> >>http://www.ietf.org/internet-drafts/draft-narten-iana-considerations-rfc2434bis-01.txt >> >> >>>[2] ftp://ftp.rfc-editor.org/in-notes/bcp/bcp82.txt >>> >>> >>> >>> >>>__________________________________ >>>Do you Yahoo!? >>>Take Yahoo! Mail with you! Get it on your mobile >>> >>> >>phone. >> >> >>>http://mobile.yahoo.com/maildemo >>> >>>_______________________________________________ >>>Speechsc mailing list >>>Speechsc@ietf.org >>>https://www1.ietf.org/mailman/listinfo/speechsc >>> >>> >>> >>> >>> >=== message truncated === > > > > >__________________________________ >Do you Yahoo!? >The all-new My Yahoo! - Get yours free! >http://my.yahoo.com > > > > --------------040502010107000402050800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dan Burnett wrote: 
I'm not sure I agree with all of your "Specification
Required" Allocation policies, since they require only
an RFC (possibly Informational) rather than a complete
review.  Did you by any chance mean to suggest "IETF
Review", which includes a requirement for an RFC, or
even "Standards Action", the most stringent
requirement?
Requiring an RFC is what I meant. Also this should not be just an Informational RFC.  Which  leaves us with the a Standards track RFC document. 
Also, for the vendor specific parameters you suggested
"Hierarchical Allocation".  I agree with this and
would recommend either "First Come First Served" or
"Expert Review" for the top-level with delegation to
the requester for anything below.
ok

Sarvi
Note that for vendor specific parameters, the draft
says "The vendor-av-pair-name can be any Vendor
specific field name and conforms to the XML
vendor-specific attribute naming convention". 
Unfortunately, I doubt this is sufficiently precise
for IANA.  Can anyone suggest some more complete
specification text for the various vendor-specific
paramaters and IDs in the document?

-- dan

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

  
After reviewing the IANA considerations guidelines, 
the protocol for 
additional values should be as follows. see inline.
Dan Burnett wrote:

    
Group,

In the course of reviewing the draft in order to
      
write
    
the IANA Considerations sections, I've identified
      
the
    
following value spaces for which one might consider
requesting IANA to maintain a registry.  For each
      
one,
    
I've made a suggestion as to whether or not we
      
should
    
create an IANA registration, and if so, what policy
(see [1] for explanations) should be used for
assignment.  The default policy in the document for
all remaining value spaces will be that there must
      
be
    
a new version of MRCP for any changes to occur.

I would like to hear if there are any opinions on
these, particularly if they differ from my
suggestions.
I would also like particularly to hear feedback on
      
2
    
and 5, below, since my suggested assignment
      
protocol
    
may be quite restrictive with respect to vendor
extensions.

1. Name space: resource types (sec. 4.2)
IANA registry?: no
Comment: This is a core part of the spec and
      
requires
    
significant understanding and industry consensus.
      
The
    
introduction of a new resource should require
      
approval
    
of a working group and not just one expert.
 

      
Assignment Protocol: Specification Required


    
2. Name space: extension methods (sec. 5.1)
IANA registry?: yes
Assignment protocol: IETF Review
 

      
Assignment Protocol: Specification Required

    
Comment: It should be possible to extend the set of
methods without creating a whole new version of
      
MRCP. 
    
Or should it?  If not, why do we permit it in the
spec?

3. Name space: request state (sec. 5.2)
IANA registry?: no
Comment: This is unlikely to change.  If there were
      
a
    
need to change this it would probably require a
re-think of the entire protocol.

4. Name space: status codes (sec. 5.2)
IANA registry?: yes
Assignment protocol: Specification Required with
Expert Review
Comment:  This is the sort of thing that might need
      
to
    
be adjusted based on further implementation
      
experience
    
by the industry.  It should not require a re-write
      
of
    
the spec, but any additions would need to be
      
reviewed
    
for sanity and documented for portability.  By the
way, I would recommend that we include a small
      
number
    
of codes specifically for experimental use (see
      
[2]).
    
5. Name space: extension events (sec. 5.3)
IANA registry?: yes
Assignment protocol: IETF Review
 

      
Assignment Protocol: Specification Required

    
Comment: It should be possible to extend the set of
events without creating a whole new version of
      
MRCP. 
    
Or should it?  If not, why do we permit it in the
spec?

6. Name space: extension headers (sec. 6.1)
IANA registry?: yes
Assignment protocol: IETF Review
 

      
Assignment Protocol: Specification Required

    
Comment: It should be possible to extend the set of
headers without creating a whole new version of
      
MRCP. 
    
Or should it?  If not, why do we permit it in the
spec?

7. Name space: vendor-specific headers (sec. 6.1)
IANA registry?: no
Comment: Such parameters are already clearly
identified by the "Vendor-Specific-Parameters"
      
prefix
    
and thus the  contents are well-known to be
vendor-specific.
 

      
Yes.
Assignment Protocol: Hierarchical allocation
Example: Object Identifiers.


    
8. Name space: parameter list (sec. 6.2/6.3)
IANA registry?: yes
Assignment protocol: IETF Review
 

      
Assignment Protocol: Specification Required

    
Comment: This one I'm not sure about.  It's similar
      
to
    
2 and 5, above, but the draft does not currently
provide a slot for such extensions (i.e. the list
      
is
    
currently closed).  I think the permissability of
extensions here should match that for 2 and 5,
      
whether
    
we permit extensions for all (without a new MRCP
      
spec)
    
or whether we prohibit all extenions (and require a
new MRCP spec for changes).

9. Name space: completion cause (for each resource)
IANA registry?: no
Comment: Although I think there might be some use
      
in
    
having a registry for each, it seems like overkill
      
to
    
do it.  I could be persuaded otherwise, however.
 

      


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.

Assignment Protocol: Hierarchical allocation
Example: Object Identifiers.



Thanks,
Sarvi

    
-- Dan

[1]
      
http://www.ietf.org/internet-drafts/draft-narten-iana-considerations-rfc2434bis-01.txt
    
[2] ftp://ftp.rfc-editor.org/in-notes/bcp/bcp82.txt



		
__________________________________ 
Do you Yahoo!? 
Take Yahoo! Mail with you! Get it on your mobile
      
phone. 
    
http://mobile.yahoo.com/maildemo 

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

 

      
=== message truncated ===



		
__________________________________ 
Do you Yahoo!? 
The all-new My Yahoo! - Get yours free! 
http://my.yahoo.com

--------------040502010107000402050800-- --===============1019179062== 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 --===============1019179062==-- From speechsc-bounces@ietf.org Wed Jan 26 14:43: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 OAA05116 for ; Wed, 26 Jan 2005 14:43:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CttLW-0000qg-Mz for speechsc-web-archive@ietf.org; Wed, 26 Jan 2005 15:00:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctsuf-0000KJ-Kp; Wed, 26 Jan 2005 14:33:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtsrX-00087n-6t for speechsc@megatron.ietf.org; Wed, 26 Jan 2005 14:30:00 -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 OAA02873 for ; Wed, 26 Jan 2005 14:29:57 -0500 (EST) Received: from mail.lumenvox.com ([206.169.193.45] helo=lv-svr.lumenvox.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctt8U-0000UW-Uw for speechsc@ietf.org; Wed, 26 Jan 2005 14:47:32 -0500 Received: from PROGTHOMAS ([10.0.0.141]) by lv-svr.lumenvox.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Jan 2005 11:23:19 -0800 From: "Thomas Gal" To: "'Dan Burnett'" , "'Reifenrath, Klaus'" Subject: RE: [Speechsc] IANA considerations for group feedback Date: Wed, 26 Jan 2005 11:27:30 -0800 Organization: LumenVox LLC MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <20050126181800.43727.qmail@web14122.mail.yahoo.com> Thread-Index: AcUD1Xqdo2Juaq0zSyG52Mod7nWDLwAAlsNQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Message-ID: X-OriginalArrivalTime: 26 Jan 2005 19:23:19.0187 (UTC) FILETIME=[7E04F630:01C503DC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2fe944273194be3112d13b31c91e6941 Cc: speechsc@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ThomasGal@LumenVox.com List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0852725893==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6379955759c38e2371a49573a0932fc7 This is a multi-part message in MIME format. --===============0852725893== Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_007E_01C5039A.054FF420" This is a multi-part message in MIME format. ------=_NextPart_000_007E_01C5039A.054FF420 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 > > protocol identifier (probably need to be coordinated with > the MMUSIC > > group): > > > > - SCTP > > - TLS > > > > At the last F2F meeting in San Diego we discussed caller > > preference-based SIP routing, which most likely would require some > > more IANA registrations. > > > > Best regards, > > Klaus > > > > -----Original Message----- > > From: Dan Burnett [mailto:dan_burnett2000@yahoo.com] > > Sent: Freitag, 21. Januar 2005 19:52 > > To: speechsc@ietf.org > > Subject: [Speechsc] IANA considerations for group feedback > > > > > > Group, > > > > In the course of reviewing the draft in order to write the IANA > > Considerations sections, I've identified the following value spaces > > for which one might consider requesting IANA to maintain a > registry. > > For each one, I've made a suggestion as to whether or not we should > > create an IANA registration, and if so, what policy (see [1] for > > explanations) should be used for assignment. The default policy in > > the document for all remaining value spaces will be that > there must be > > a new version of MRCP for any changes to occur. > > > > I would like to hear if there are any opinions on these, > particularly > > if they differ from my suggestions. > > I would also like particularly to hear feedback on 2 and 5, below, > > since my suggested assignment protocol may be quite > restrictive with > > respect to vendor extensions. > > > > 1. Name space: resource types (sec. 4.2) IANA registry?: no > > Comment: This is a core part of the spec and requires significant > > understanding and industry consensus. > > The > > introduction of a new resource should require approval of a working > > group and not just one expert. > > > > 2. Name space: extension methods (sec. 5.1) IANA registry?: yes > > Assignment protocol: IETF Review > > Comment: It should be possible to extend the set of methods without > > creating a whole new version of MRCP. > > Or should it? If not, why do we permit it in the spec? > > > > 3. Name space: request state (sec. 5.2) IANA registry?: no > > Comment: This is unlikely to change. If there were a need > to change > > this it would probably require a re-think of the entire protocol. > > > > 4. Name space: status codes (sec. 5.2) IANA registry?: yes > Assignment > > protocol: Specification Required with Expert Review > > Comment: This is the sort of thing that might need to be adjusted > > based on further implementation experience by the industry. > It should > > not require a re-write of the spec, but any additions would > need to be > > reviewed for sanity and documented for portability. By the way, I > > would recommend that we include a small number of codes > specifically > > for experimental use (see [2]). > > > > 5. Name space: extension events (sec. 5.3) IANA registry?: yes > > Assignment protocol: IETF Review > > Comment: It should be possible to extend the set of events without > > creating a whole new version of MRCP. > > > > Or should it? If not, why do we permit it in the spec? > > > > 6. Name space: extension headers (sec. 6.1) IANA registry?: yes > > Assignment protocol: IETF Review > > Comment: It should be possible to extend the set of headers without > > creating a whole new version of MRCP. > > Or should it? If not, why do we permit it in the spec? > > > > 7. Name space: vendor-specific headers (sec. 6.1) IANA registry?: no > > Comment: Such parameters are already clearly identified by the > > "Vendor-Specific-Parameters" > > prefix > > and thus the contents are well-known to be vendor-specific. > > > > 8. Name space: parameter list (sec. 6.2/6.3) IANA registry?: yes > > Assignment protocol: IETF Review > > Comment: This one I'm not sure about. It's similar to > > 2 and 5, above, but the draft does not currently provide a slot for > > such extensions (i.e. the list is currently closed). I think the > > permissability of extensions here should match that for 2 and 5, > > whether we permit extensions for all (without a new MRCP > > spec) > > or whether we prohibit all extenions (and require a new > MRCP spec for > > changes). > > > > 9. Name space: completion cause (for each resource) IANA > registry?: no > > Comment: Although I think there might be some use in having > a registry > > for each, it seems like overkill to do it. I could be persuaded > > otherwise, however. > > > > -- Dan > > > > [1] > > > http://www.ietf.org/internet-drafts/draft-narten-iana-consider > ations-rfc2434 > > bis-01.txt > > [2] ftp://ftp.rfc-editor.org/in-notes/bcp/bcp82.txt > > > > > > > > > > __________________________________ > > Do you Yahoo!? > > Take Yahoo! Mail with you! Get it on your mobile phone. > > http://mobile.yahoo.com/maildemo > > > > _______________________________________________ > > 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 > > > > > > > __________________________________ > Do you Yahoo!? > Read only the mail you want - Yahoo! Mail SpamGuard. > http://promotions.yahoo.com/new_mail > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > ------=_NextPart_000_007E_01C5039A.054FF420 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMBDCCBL8w ggKnoAMCAQICAwDQ9DANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNDEyMDEyMTI1MzBaFw0w NTEyMDEyMTI1MzBaMDwxEzARBgNVBAMTClRob21hcyBHYWwxJTAjBgkqhkiG9w0BCQEWFnRob21h c2dhbEBsdW1lbnZveC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDR7eXh1399 BXAlOs1kGnSeVSRasyxQd1eRcRle/mNHGMJ3COpMB3bkd8vRIqW9CuPTzjnHrCbLSbduJRoQNNjc p6Df0TkAvMDNxk6tGtEfrKk71WJ0btokYb1cxAXb7A2GHEWXVnSu+nvQ68n+/T6pJzOeesqS2cDI n79lw8owwxQixgYDKUz+nC2a+A0a2wktL+E9lXFJgCSE2CL9w9dCO5w2NeqqiPBLTxe3aiDkoRSk yvBX1tCT5s486pkko/sAko8eY/ZXE1IrAKn6U8Wr2mHUmDhcVNaRGe0w12yS/WRC+YW3/S3a1T4b Tpgb5hRiK/IbV8f/0aSDLn4GaFnLAgMBAAGjgYwwgYkwDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwIQYDVR0RBBowGIEWdGhvbWFzZ2FsQGx1bWVudm94LmNvbTAN BgkqhkiG9w0BAQQFAAOCAgEAdI6mD6HejUJaFjEPtruQpOOUat6eLetY94CoPmYiIqSoYSwBt6+m 7nJl5fGJcfUaugez/AJzMBC8Nfphtr0yw5O8EYUtvfWxtpY272eR9evAzFk2l8ZzvzGLphXuSlfK RCMLQcPN+fEnX66yu6wseF5/Z1nZnjn9TtQQ2xlZjFAKkU4L2oczvfaadOVuB1iUMx4Sbr49ukhc sRjQ4F1VS0lf/INqhL3SHGOaLDD7nWoaZM35jP/8zNHrWGr4Jait0epazMLFen4LSEJH6hsbKxVv VGVef8KczVK4f5qVX8BlediiLCH7DZkT/uY4YB/2NPr3bHZnZmmff7vYp7cIsLiUYaD565f9Isbc eHjihQarb+bDMcm8qlkaYPc6pt1t9cUgLMi0YbyjCzi5PQFX8BIjPvRYAM9iOJdjO9lIyEZnpb2S fclvuhRupYIOJC6bTIVa2qXuzNfkCRtWG7RwIu+bfLuHiIfyh/c2P66140q278zz/euPHTQSr6A7 uGhpwYTfkzO4btn7FPA8bE9hnz82Wd9dGBcQc7yTEmN11+hEGS3Ie+q2jCuOP4jONgGTKAPRFsXG 86aZr12DVZHcDrh7zt71sBwD2AMCaMuLZpClWlIFwCX0wryt2Qr9/IjvcM2hn2kHu3kIusy/UOU5 FU3SYYCpevzG7qhvoAbrIkowggc9MIIFJaADAgECAgEAMA0GCSqGSIb3DQEBBAUAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0Eg Q2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3Jn MB4XDTAzMDMzMDEyMjk0OVoXDTMzMDMyOTEyMjk0OVoweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwG A1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0 aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcwggIiMA0GCSqGSIb3DQEB AQUAA4ICDwAwggIKAoICAQDOIsDiRn3sNigHUJbyoDNAjEvxO2Y/MeVrAjbb1nz28YiPTnc2BUGV +QnwEs9GhnNgt25+6MBYZK7NsK1FFwxj+mcK6NbSvz7nmMTwTPrgA7s1XWwh3p4g2brNZjI3cvr3 CPXHzVjJjucOXuo+/hyhFAoVbIaEW2RmKnqpS1N59Yiie+4vCmErjbJ+TValE+zq2pKerERBHlhg ZQVm+MBEvcuU90J+C/dlaJhRBfDzBZEEHRsXguzIV7vDa3qI8bByzCVbIJHsFgISjzLpFxhI0McF LgIwQrglnAVrP6o6p+tTSPfo0rYHmNwbxjR/f8kcgnoFWCsIW/M4oqsXXWbJmNeeEIui0t10mvdx DHJg381vmDOdljR2PiR6krAOlR5v5qBFOEeq10HtSrcS9tcbg4oPLtgJtlnXqgT/0pN9aC7di0ur WLovjeqVp6DDVIml+9uLUSKdssO+Eb4skYaLlnitINOKLxo/xtBRZYchsRkBZX9FHIf1fNBBTE8p mCH9Mx91DARR+hl329QUHO6Bwx31mLdpBpEi3QBQzIExrBIHezjaaFvmK9R+yV+t6OtyTPMB5Usg v5qmV8qRAAGLoXUhN7VjDWc+Rk9wIGfOxdZZ2wLg8NLLzbpit5BB6N0g5Cm8ZClCyCLceJr/Q+yY GwlRS1pawnHxxMtzqeWhCwIDAQABo4IBzjCCAcowHQYDVR0OBBYEFBa1MhvUx/Pg5o7zvdKwOu6y ORjRMIGjBgNVHSMEgZswgZiAFBa1MhvUx/Pg5o7zvdKwOu6yORjRoX2kezB5MRAwDgYDVQQKEwdS b290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQg U2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZ4IBADAP BgNVHRMBAf8EBTADAQH/MDIGA1UdHwQrMCkwJ6AloCOGIWh0dHBzOi8vd3d3LmNhY2VydC5vcmcv cmV2b2tlLmNybDAwBglghkgBhvhCAQQEIxYhaHR0cHM6Ly93d3cuY2FjZXJ0Lm9yZy9yZXZva2Uu Y3JsMDQGCWCGSAGG+EIBCAQnFiVodHRwOi8vd3d3LmNhY2VydC5vcmcvaW5kZXgucGhwP2lkPTEw MFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVh ZCBvdmVyIHRvIGh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzANBgkqhkiG9w0BAQQFAAOCAgEAKMfunIIC ulyAEso1Ch2Bb4lqmczyaA9/p+GNWJU+vfIGw5BarLVg9plDAaOIcJydYp2kh69nWA0wNjvmrUjT y3QChnE+4isDaPE0YkBGO1PqKPSs+2aVU4pNXf072WDXynlpO7FlkqbGgYJcnM3rTQGKpd8RVaoV yh83wIKYcGHbanyWo44uVD5PIamQ79yCv9zoRa1NkHMIPJRlsASZdn/ivMJqFaqXBDck2B6UTm0O Ub7WxI/Klm33Q9/oMGUnO3u7Q0NjxEP3suxozOEZjiL7mOF7Wj4BNzuLCLCi85VOGsubzZqx27Jw 8C1K29iw429FSDMS//48MipU98T3ivCII8JH/mR6ccDRHqZjsAd+pC/TAY/cnyu2xgipD5NIJfwS /Z9C3PPEPvZXsNfdadEGdzQKS9LKoP8cxozJFr7EzDI3aHNfCPtR90lTNgUKlQJM8nkaEPbYOnWc 8x3xog1wZ4Ybsxb1L+Wk63mG+T0LwnMLpZmsb/xnuOUvC6YYJI170Ug1KRhArJNg4ZaGULR6WdiP IQufz4KRxju/a9wHkbmXViOqtmyUxkgGPOTOTqrk9i8J3FNvLvx06zpjmcKmrIm8p7JEoA2KEONs 8iTL+pufcEcu3hSL1LIgCZaiZPEkHNyhNZwVstS8VS59BvWcDlX0WtaT2natJXNMxUMxggOcMIID mAIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5v cmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDAND0MAkGBSsOAwIaBQCgggHwMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA1MDEyNjE5MjcyOVowIwYJKoZIhvcNAQkEMRYEFCObWL7U Qrn512hsOWWkkxEBPshtMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG SIb3DQIFMIGRBgkrBgEEAYI3EAQxgYMwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMV aHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5 MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwDQ9DCBkwYLKoZIhvcNAQkQAgsx gYOggYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3Jn MSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBw b3J0QGNhY2VydC5vcmcCAwDQ9DANBgkqhkiG9w0BAQEFAASCAQB3Y4HNA+X3/8nl4rQtml2sI1m6 hGUKC6H38De0TLDgoykXQWL4LXzBujEurpGentyi3J6XYsFHuOHCzhgp6+nU+RRgL+4sRC+QlnAs CtAGPsDj61m4aVsVl+4IyXuJS8yf/GYCsmofMX4ctIXcGrmFp+1fSxoi90ROqmsAmGHnC/wqK0Q2 cuuMQfNKYo6j8j9z3UMG5DK2sOfysvbVUJ+/yYH3NJk/nF6SE26t/2EnhpH/mo72AaIQ/fLbH+hS 4e0y7BxnOzRdRSj2ddWcUORBo1Gs1QVXgTVcbYapVPDTuOa/tFoZ7QoiNfX9qEh8scs5iFx2RCU6 X1MsSKX/u3VhAAAAAAAA ------=_NextPart_000_007E_01C5039A.054FF420-- --===============0852725893== 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 --===============0852725893==-- From speechsc-bounces@ietf.org Wed Jan 26 15:02: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 PAA07515 for ; Wed, 26 Jan 2005 15:02:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cttdc-0001a9-T7 for speechsc-web-archive@ietf.org; Wed, 26 Jan 2005 15:19:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CttHO-00067l-My; Wed, 26 Jan 2005 14:56:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctt9M-0003gR-3P for speechsc@megatron.ietf.org; Wed, 26 Jan 2005 14:48: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 OAA05642 for ; Wed, 26 Jan 2005 14:48:22 -0500 (EST) Received: from mail.lumenvox.com ([206.169.193.45] helo=lv-svr.lumenvox.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CttQJ-0000y3-Bj for speechsc@ietf.org; Wed, 26 Jan 2005 15:05:56 -0500 Received: from PROGTHOMAS ([10.0.0.141]) by lv-svr.lumenvox.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Jan 2005 11:43:38 -0800 From: "Thomas Gal" To: "'Dan Burnett'" , "'Reifenrath, Klaus'" Subject: RE: [Speechsc] IANA considerations for group feedback Date: Wed, 26 Jan 2005 11:47:47 -0800 Organization: LumenVox LLC MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <20050126181501.43317.qmail@web14125.mail.yahoo.com> Thread-Index: AcUD1PZLMojavJoiSDmAMImVnQSCTgACJ3RQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Message-ID: X-OriginalArrivalTime: 26 Jan 2005 19:43:38.0921 (UTC) FILETIME=[55099990:01C503DF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: speechsc@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ThomasGal@LumenVox.com 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: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit 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 From speechsc-bounces@ietf.org Wed Jan 26 19:54: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 TAA09801 for ; Wed, 26 Jan 2005 19:54:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtyCf-0001mc-BI for speechsc-web-archive@ietf.org; Wed, 26 Jan 2005 20:12:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctxt2-0003dF-H7; Wed, 26 Jan 2005 19:51:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctxq0-0002wi-47 for speechsc@megatron.ietf.org; Wed, 26 Jan 2005 19:48: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 TAA09312 for ; Wed, 26 Jan 2005 19:48:40 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cty70-0001dB-Fs for speechsc@ietf.org; Wed, 26 Jan 2005 20:06:19 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 26 Jan 2005 16:48:13 -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-3.cisco.com (8.12.10/8.12.6) with ESMTP id j0R0m9RO006992; Wed, 26 Jan 2005 16:48:09 -0800 (PST) Received: from [128.107.139.169] ([128.107.139.169]) by vtg-um-e2k1.sj21ad.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Jan 2005 16:48:04 -0800 Message-ID: <41F83A43.2060902@cisco.com> Date: Wed, 26 Jan 2005 16:48:03 -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: <20050126182729.16752.qmail@web14121.mail.yahoo.com> In-Reply-To: <20050126182729.16752.qmail@web14121.mail.yahoo.com> X-OriginalArrivalTime: 27 Jan 2005 00:48:04.0057 (UTC) FILETIME=[DBE82C90:01C50409] X-Spam-Score: 0.5 (/) X-Scan-Signature: dc60ea982e94509a7a8f1634aa16db79 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="===============0912284838==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 667ab3155b58f6148f26cdbf27b4043b This is a multi-part message in MIME format. --===============0912284838== Content-Type: multipart/alternative; boundary="------------070701080805080302090904" This is a multi-part message in MIME format. --------------070701080805080302090904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit We have included a version of the NLSML specification within this MRCPv2 specification with the permission from the W3C. So I think it is appropriate that we regsiter application/nlsml with this specification, as this will be the first public standard/specification of NLSML. The W3C, will ofcourse evolve the spec in the future, and this should not pose a problem. Thx, Sarvi 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? > >-- 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 >> >>thomasgal@lumenvox.com >> >> >> >>>-----Original Message----- >>>From: speechsc-bounces@ietf.org >>>[mailto:speechsc-bounces@ietf.org] On Behalf Of >>> >>> >>Reifenrath, Klaus >> >> >>>Sent: Monday, January 24, 2005 4:21 AM >>>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 >>>protocol identifier (probably need to be >>> >>> >>coordinated with the >> >> >>>MMUSIC group): >>> >>>- SCTP >>>- TLS >>> >>>At the last F2F meeting in San Diego we discussed >>> >>> >>caller >> >> >>>preference-based SIP routing, which most likely >>> >>> >>would require >> >> >>>some more IANA registrations. >>> >>>Best regards, >>>Klaus >>> >>>-----Original Message----- >>>From: Dan Burnett >>> >>> >>[mailto:dan_burnett2000@yahoo.com] >> >> >>>Sent: Freitag, 21. Januar 2005 19:52 >>>To: speechsc@ietf.org >>>Subject: [Speechsc] IANA considerations for group >>> >>> >>feedback >> >> >>>Group, >>> >>>In the course of reviewing the draft in order to >>> >>> >>write the >> >> >>>IANA Considerations sections, I've identified the >>> >>> >>following >> >> >>>value spaces for which one might consider >>> >>> >>requesting IANA to >> >> >>>maintain a registry. For each one, I've made a >>> >>> >>suggestion as >> >> >>>to whether or not we should create an IANA >>> >>> >>registration, and >> >> >>>if so, what policy (see [1] for explanations) >>> >>> >>should be used >> >> >>>for assignment. The default policy in the >>> >>> >>document for all >> >> >>>remaining value spaces will be that there must be >>> >>> >>a new >> >> >>>version of MRCP for any changes to occur. >>> >>>I would like to hear if there are any opinions on >>> >>> >>these, >> >> >>>particularly if they differ from my suggestions. >>>I would also like particularly to hear feedback on >>> >>> >>2 and 5, >> >> >>>below, since my suggested assignment protocol may >>> >>> >>be quite >> >> >>>restrictive with respect to vendor extensions. >>> >>>1. Name space: resource types (sec. 4.2) IANA >>> >>> >>registry?: no >> >> >>>Comment: This is a core part of the spec and >>> >>> >>requires >> >> >>>significant understanding and industry consensus. >>> >>> >>The >> >> >>>introduction of a new resource should require >>> >>> >>approval of a >> >> >>>working group and not just one expert. >>> >>>2. Name space: extension methods (sec. 5.1) IANA >>> >>> >>registry?: >> >> >>>yes Assignment protocol: IETF Review >>>Comment: It should be possible to extend the set >>> >>> >>of methods >> >> >>>without creating a whole new version of MRCP. >>>Or should it? If not, why do we permit it in the >>> >>> >>spec? >> >> >>>3. Name space: request state (sec. 5.2) >>>IANA registry?: no >>>Comment: This is unlikely to change. If there >>> >>> >>were a need to >> >> >>>change this it would probably require a re-think >>> >>> >>of the >> >> >>>entire protocol. >>> >>>4. Name space: status codes (sec. 5.2) >>>IANA registry?: yes >>>Assignment protocol: Specification Required with >>> >>> >>Expert Review >> >> >>>Comment: This is the sort of thing that might >>> >>> >>need to be >> >> >>>adjusted based on further implementation >>> >>> >>experience by the >> >> >>>industry. It should not require a re-write of the >>> >>> >>spec, but >> >> >>>any additions would need to be reviewed for sanity >>> >>> >>and >> >> >>>documented for portability. By the way, I would >>> >>> >>recommend >> >> >>>that we include a small number of codes >>> >>> >>specifically for >> >> >>>experimental use (see [2]). >>> >>>5. Name space: extension events (sec. 5.3) IANA >>> >>> >>registry?: >> >> >>>yes Assignment protocol: IETF Review >>>Comment: It should be possible to extend the set >>> >>> >>of events >> >> >>>without creating a whole new version of MRCP. >>>Or should it? If not, why do we permit it in the >>> >>> >>spec? >> >> >>>6. Name space: extension headers (sec. 6.1) IANA >>> >>> >>registry?: >> >> >>>yes Assignment protocol: IETF Review >>>Comment: It should be possible to extend the set >>> >>> >>of headers >> >> >>>without creating a whole new version of MRCP. >>>Or should it? If not, why do we permit it in the >>> >>> >>spec? >> >> >>>7. Name space: vendor-specific headers (sec. 6.1) >>> >>> >>IANA registry?: no >> >> >>>Comment: Such parameters are already clearly >>> >>> >>identified by >> >> >>>the "Vendor-Specific-Parameters" prefix and thus >>> >>> >>the >> >> >>>contents are well-known to be vendor-specific. >>> >>>8. Name space: parameter list (sec. 6.2/6.3) IANA >>> >>> >>registry?: >> >> >>>yes Assignment protocol: IETF Review >>>Comment: This one I'm not sure about. It's >>> >>> >>similar to >> >> >>>2 and 5, above, but the draft does not currently >>> >>> >>provide a >> >> >>>slot for such extensions (i.e. the list is >>> >>> >>currently closed). >> >> >>> I think the permissability of extensions here >>> >>> >>should match >> >> >>>that for 2 and 5, whether we permit extensions for >>> >>> >>all >> >> >>>(without a new MRCP spec) or whether we prohibit >>> >>> >>all >> >> >>>extenions (and require a new MRCP spec for >>> >>> >>changes). >> >> >>>9. Name space: completion cause (for each >>> >>> >>resource) IANA registry?: no >> >> >>>Comment: Although I think there might be some use >>> >>> >>in having a >> >> >>>registry for each, it seems like overkill to do >>> >>> >>it. I could >> >> >>>be persuaded otherwise, however. >>> >>>-- Dan >>> >>>[1] >>> >>> >>> >http://www.ietf.org/internet-drafts/draft-narten-iana-consider > > >>>ations-rfc2434 >>>bis-01.txt >>>[2] >>> >>> >>ftp://ftp.rfc-editor.org/in-notes/bcp/bcp82.txt >> >> >> >=== message truncated === > > > > >__________________________________ >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 > > > --------------070701080805080302090904 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit We have included a version of the NLSML specification within this MRCPv2 specification with the  permission from the W3C.
So I think it is appropriate that we regsiter application/nlsml with this specification, as this will be the first public standard/specification of NLSML.

The W3C, will ofcourse evolve the spec in the future, and this should not pose a problem.

Thx,
Sarvi
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?

-- dan
p.s. now I know why Eric and Dave wanted someone else
to volunteer :)


--- Thomas Gal <ThomasGal@LumenVox.com> 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

thomasgal@lumenvox.com  

    
-----Original Message-----
From: speechsc-bounces@ietf.org 
[mailto:speechsc-bounces@ietf.org] On Behalf Of
      
Reifenrath, Klaus
    
Sent: Monday, January 24, 2005 4:21 AM
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
protocol identifier (probably need to be
      
coordinated with the 
    
MMUSIC group):

- SCTP
- TLS

At the last F2F meeting in San Diego we discussed
      
caller 
    
preference-based SIP routing, which most likely
      
would require 
    
some more IANA registrations.
 
Best regards,
Klaus

-----Original Message-----
From: Dan Burnett
      
[mailto:dan_burnett2000@yahoo.com]
    
Sent: Freitag, 21. Januar 2005 19:52
To: speechsc@ietf.org
Subject: [Speechsc] IANA considerations for group
      
feedback
    
Group,

In the course of reviewing the draft in order to
      
write the 
    
IANA Considerations sections, I've identified the
      
following 
    
value spaces for which one might consider
      
requesting IANA to 
    
maintain a registry.  For each one, I've made a
      
suggestion as 
    
to whether or not we should create an IANA
      
registration, and 
    
if so, what policy (see [1] for explanations)
      
should be used 
    
for assignment.  The default policy in the
      
document for all 
    
remaining value spaces will be that there must be
      
a new 
    
version of MRCP for any changes to occur.

I would like to hear if there are any opinions on
      
these, 
    
particularly if they differ from my suggestions.
I would also like particularly to hear feedback on
      
2 and 5, 
    
below, since my suggested assignment protocol may
      
be quite 
    
restrictive with respect to vendor extensions.

1. Name space: resource types (sec. 4.2) IANA
      
registry?: no
    
Comment: This is a core part of the spec and
      
requires 
    
significant understanding and industry consensus.
      
The 
    
introduction of a new resource should require
      
approval of a 
    
working group and not just one expert.

2. Name space: extension methods (sec. 5.1) IANA
      
registry?: 
    
yes Assignment protocol: IETF Review
Comment: It should be possible to extend the set
      
of methods 
    
without creating a whole new version of MRCP. 
Or should it?  If not, why do we permit it in the
      
spec?
    
3. Name space: request state (sec. 5.2)
IANA registry?: no
Comment: This is unlikely to change.  If there
      
were a need to 
    
change this it would probably require a re-think
      
of the 
    
entire protocol.

4. Name space: status codes (sec. 5.2)
IANA registry?: yes
Assignment protocol: Specification Required with
      
Expert Review
    
Comment:  This is the sort of thing that might
      
need to be 
    
adjusted based on further implementation
      
experience by the 
    
industry.  It should not require a re-write of the
      
spec, but 
    
any additions would need to be reviewed for sanity
      
and 
    
documented for portability.  By the way, I would
      
recommend 
    
that we include a small number of codes
      
specifically for 
    
experimental use (see [2]).

5. Name space: extension events (sec. 5.3) IANA
      
registry?: 
    
yes Assignment protocol: IETF Review
Comment: It should be possible to extend the set
      
of events 
    
without creating a whole new version of MRCP. 
Or should it?  If not, why do we permit it in the
      
spec?
    
6. Name space: extension headers (sec. 6.1) IANA
      
registry?: 
    
yes Assignment protocol: IETF Review
Comment: It should be possible to extend the set
      
of headers 
    
without creating a whole new version of MRCP. 
Or should it?  If not, why do we permit it in the
      
spec?
    
7. Name space: vendor-specific headers (sec. 6.1)
      
IANA registry?: no
    
Comment: Such parameters are already clearly
      
identified by 
    
the "Vendor-Specific-Parameters" prefix and thus
      
the  
    
contents are well-known to be vendor-specific.

8. Name space: parameter list (sec. 6.2/6.3) IANA
      
registry?: 
    
yes Assignment protocol: IETF Review
Comment: This one I'm not sure about.  It's
      
similar to
    
2 and 5, above, but the draft does not currently
      
provide a 
    
slot for such extensions (i.e. the list is
      
currently closed). 
    
 I think the permissability of extensions here
      
should match 
    
that for 2 and 5, whether we permit extensions for
      
all 
    
(without a new MRCP spec) or whether we prohibit
      
all 
    
extenions (and require a new MRCP spec for
      
changes).
    
9. Name space: completion cause (for each
      
resource) IANA registry?: no
    
Comment: Although I think there might be some use
      
in having a 
    
registry for each, it seems like overkill to do
      
it.  I could 
    
be persuaded otherwise, however.

-- Dan

[1]

      
http://www.ietf.org/internet-drafts/draft-narten-iana-consider
  
ations-rfc2434
bis-01.txt
[2]
      
ftp://ftp.rfc-editor.org/in-notes/bcp/bcp82.txt

    
=== message truncated ===



		
__________________________________ 
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

--------------070701080805080302090904-- --===============0912284838== 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 --===============0912284838==-- From speechsc-bounces@ietf.org Wed Jan 26 20:08: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 UAA10891 for ; Wed, 26 Jan 2005 20:08:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtyQ4-00024T-Q8 for speechsc-web-archive@ietf.org; Wed, 26 Jan 2005 20:26:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cty1N-0004qk-UG; Wed, 26 Jan 2005 20:00:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtxvJ-00042K-DA for speechsc@megatron.ietf.org; Wed, 26 Jan 2005 19:54: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 TAA09773 for ; Wed, 26 Jan 2005 19:54:09 -0500 (EST) Received: from mail.lumenvox.com ([206.169.193.45] helo=lv-svr.lumenvox.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtyCJ-0001ll-JL for speechsc@ietf.org; Wed, 26 Jan 2005 20:11:48 -0500 Received: from PROGTHOMAS ([10.0.0.141]) by lv-svr.lumenvox.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Jan 2005 16:49:28 -0800 From: "Thomas Gal" To: "'Sarvi Shanmugham'" Subject: RE: [Speechsc] IANA considerations for group feedback Date: Wed, 26 Jan 2005 16:53:40 -0800 Organization: LumenVox LLC MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <41F83A43.2060902@cisco.com> Thread-Index: AcUECUpw0V6rTDi2St+G1Ec78bswEwAARpTA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Message-ID: X-OriginalArrivalTime: 27 Jan 2005 00:49:28.0125 (UTC) FILETIME=[0E03EED0:01C5040A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: speechsc@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ThomasGal@LumenVox.com 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: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit So you're saying it's not been deprecated [in favor of EMMA]? -Tom thomasgal@lumenvox.com > The W3C, will ofcourse evolve the spec in the future, and > this should not pose a problem. > > Thx, > Sarvi _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Jan 26 23:52: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 XAA00343 for ; Wed, 26 Jan 2005 23:52:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cu1v1-00077o-BL for speechsc-web-archive@ietf.org; Thu, 27 Jan 2005 00:10:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu1ci-0005wa-3V; Wed, 26 Jan 2005 23:51:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu1bO-0005LY-IH for speechsc@megatron.ietf.org; Wed, 26 Jan 2005 23:49: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 XAA00052 for ; Wed, 26 Jan 2005 23:49:51 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cu1sR-00071u-2u for speechsc@ietf.org; Thu, 27 Jan 2005 00:07:32 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 26 Jan 2005 20:49:26 -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 j0R4nJ1M000366; Wed, 26 Jan 2005 20:49:20 -0800 (PST) Received: from [10.21.122.157] ([10.21.122.157]) by vtg-um-e2k1.sj21ad.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Jan 2005 20:49:14 -0800 Message-ID: <41F872CA.9070704@cisco.com> Date: Wed, 26 Jan 2005 20:49:14 -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: ThomasGal@LumenVox.com Subject: Re: [Speechsc] IANA considerations for group feedback References: In-Reply-To: X-OriginalArrivalTime: 27 Jan 2005 04:49:14.0849 (UTC) FILETIME=[8D2BCD10:01C5042B] X-Spam-Score: 1.0 (+) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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="===============1490964589==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 1.0 (+) X-Scan-Signature: 386e0819b1192672467565a524848168 This is a multi-part message in MIME format. --===============1490964589== Content-Type: multipart/alternative; boundary="------------060802030903020205010800" This is a multi-part message in MIME format. --------------060802030903020205010800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I meant to say W3C "will have the option to" evolve. Sarvi Thomas Gal wrote: >So you're saying it's not been deprecated [in favor of EMMA]? > >-Tom > >thomasgal@lumenvox.com > > > > >>The W3C, will ofcourse evolve the spec in the future, and >>this should not pose a problem. >> >>Thx, >>Sarvi >> >> > > > --------------060802030903020205010800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I meant to say W3C "will have the option to" evolve.

Sarvi
Thomas Gal wrote: 
So you're saying it's not been deprecated [in favor of EMMA]?

-Tom

thomasgal@lumenvox.com  


  
The W3C, will ofcourse evolve the spec in the future, and 
this should not pose a problem.

Thx,
Sarvi

--------------060802030903020205010800-- --===============1490964589== 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 --===============1490964589==-- From speechsc-bounces@ietf.org Thu Jan 27 03:14: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 DAA00410 for ; Thu, 27 Jan 2005 03:14:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cu54r-0002yJ-0K for speechsc-web-archive@ietf.org; Thu, 27 Jan 2005 03:32:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu4mH-0000CE-WE; Thu, 27 Jan 2005 03:13:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu4a5-0005tu-Dj for speechsc@megatron.ietf.org; Thu, 27 Jan 2005 03:00: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 DAA29396 for ; Thu, 27 Jan 2005 03:00:43 -0500 (EST) Received: from mx1.scansoft.com ([198.71.64.81]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cu4r9-0002eR-IB for speechsc@ietf.org; Thu, 27 Jan 2005 03:18:24 -0500 Received: from pb-exchcon.pb.scansoft.com ([10.1.4.73]) by mx1.scansoft.com with InterScan Messaging Security Suite; Thu, 27 Jan 2005 03:10:23 -0500 Received: by pb-exchcon.pb.scansoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Jan 2005 03:00:08 -0500 Message-ID: From: "Reifenrath, Klaus" To: "'ThomasGal@LumenVox.com'" , "'Dan Burnett'" Subject: RE: [Speechsc] IANA considerations for group feedback Date: Thu, 27 Jan 2005 02:59:54 -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: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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: 082a9cbf4d599f360ac7f815372a6a15 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 From speechsc-bounces@ietf.org Thu Jan 27 13:18: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 NAA08390 for ; Thu, 27 Jan 2005 13:18:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuEVT-0002Wv-3F for speechsc-web-archive@ietf.org; Thu, 27 Jan 2005 13:36:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuDzM-0004Mb-NI; Thu, 27 Jan 2005 13:03:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuDtt-0002zw-4V for speechsc@megatron.ietf.org; Thu, 27 Jan 2005 12:57:49 -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 MAA06871 for ; Thu, 27 Jan 2005 12:57:45 -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 1CuEB3-00024I-AH for speechsc@ietf.org; Thu, 27 Jan 2005 13:15:33 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-2.cisco.com with ESMTP; 27 Jan 2005 10:03:27 -0800 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 j0RHvE1M002268; Thu, 27 Jan 2005 09:57:15 -0800 (PST) Received: from [128.107.139.169] ([128.107.139.169]) by vtg-um-e2k1.sj21ad.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 27 Jan 2005 09:57:11 -0800 Message-ID: <41F92B76.7080601@cisco.com> Date: Thu, 27 Jan 2005 09:57:10 -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: "Reifenrath, Klaus" Subject: Re: [Speechsc] IANA considerations for group feedback References: In-Reply-To: X-OriginalArrivalTime: 27 Jan 2005 17:57:11.0084 (UTC) FILETIME=[A000C6C0:01C50499] X-Spam-Score: 0.5 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: "'ThomasGal@LumenVox.com'" , 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="===============1416958275==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 This is a multi-part message in MIME format. --===============1416958275== Content-Type: multipart/alternative; boundary="------------080707080808000508020009" This is a multi-part message in MIME format. --------------080707080808000508020009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 > > > --------------080707080808000508020009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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

--------------080707080808000508020009-- --===============1416958275== 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 --===============1416958275==-- From speechsc-bounces@ietf.org Thu Jan 27 13:49: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 NAA11803 for ; Thu, 27 Jan 2005 13:48:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuEyc-0003OS-Cj for speechsc-web-archive@ietf.org; Thu, 27 Jan 2005 14:06:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuEeN-0001Qt-9A; Thu, 27 Jan 2005 13:45:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuEXM-0007oO-Bj for speechsc@megatron.ietf.org; Thu, 27 Jan 2005 13:38:36 -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 NAA10102 for ; Thu, 27 Jan 2005 13:38:32 -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 1CuEoW-0002zy-Qs for speechsc@ietf.org; Thu, 27 Jan 2005 13:56:21 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 27 Jan 2005 10:46:14 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== 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 j0RIc2Nt015644; Thu, 27 Jan 2005 10:38:02 -0800 (PST) Received: from [64.134.126.222] (sjc-vpn6-256.cisco.com [10.21.121.0]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j0RIXs1n000846; Thu, 27 Jan 2005 10:33:54 -0800 In-Reply-To: <20050126182729.16752.qmail@web14121.mail.yahoo.com> References: <20050126182729.16752.qmail@web14121.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <57EACC9A-7092-11D9-A5E2-000A95C73842@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [Speechsc] IANA considerations for group feedback Date: Thu, 27 Jan 2005 13:36:22 -0500 To: Dan Burnett X-Mailer: Apple Mail (2.619) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1106850845.667416"; x:"432200"; a:"rsa-sha1"; b:"nofws:6019"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"Pdmn/sMSFhHIRuf4Vbfml83ZWzA5wEADlT+dUIRmnuA1JRdWrRv40IO1P5EfMswvbavFMkbb" "dxCjsFAQp2xybuMUDy32U0DYaRuNuV+kynMTXqKd99ChwxiLiNtk1nHQUze0J9iBaxG5eOyJLpp" "6dvuyNrFvyGIbHu2bsFVtb4Q="; c:"From: David R Oran "; c:"Subject: Re: [Speechsc] IANA considerations for group feedback"; c:"Date: Thu, 27 Jan 2005 13:36: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: 162d87dc0b780d17da9b1934777fd451 Content-Transfer-Encoding: 7bit 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: 0.0 (/) X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b Content-Transfer-Encoding: 7bit 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 >> >> thomasgal@lumenvox.com >> >>> -----Original Message----- >>> From: speechsc-bounces@ietf.org >>> [mailto:speechsc-bounces@ietf.org] On Behalf Of >> Reifenrath, Klaus >>> Sent: Monday, January 24, 2005 4:21 AM >>> 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 >>> protocol identifier (probably need to be >> coordinated with the >>> MMUSIC group): >>> >>> - SCTP >>> - TLS >>> >>> At the last F2F meeting in San Diego we discussed >> caller >>> preference-based SIP routing, which most likely >> would require >>> some more IANA registrations. >>> >>> Best regards, >>> Klaus >>> >>> -----Original Message----- >>> From: Dan Burnett >> [mailto:dan_burnett2000@yahoo.com] >>> Sent: Freitag, 21. Januar 2005 19:52 >>> To: speechsc@ietf.org >>> Subject: [Speechsc] IANA considerations for group >> feedback >>> >>> >>> Group, >>> >>> In the course of reviewing the draft in order to >> write the >>> IANA Considerations sections, I've identified the >> following >>> value spaces for which one might consider >> requesting IANA to >>> maintain a registry. For each one, I've made a >> suggestion as >>> to whether or not we should create an IANA >> registration, and >>> if so, what policy (see [1] for explanations) >> should be used >>> for assignment. The default policy in the >> document for all >>> remaining value spaces will be that there must be >> a new >>> version of MRCP for any changes to occur. >>> >>> I would like to hear if there are any opinions on >> these, >>> particularly if they differ from my suggestions. >>> I would also like particularly to hear feedback on >> 2 and 5, >>> below, since my suggested assignment protocol may >> be quite >>> restrictive with respect to vendor extensions. >>> >>> 1. Name space: resource types (sec. 4.2) IANA >> registry?: no >>> Comment: This is a core part of the spec and >> requires >>> significant understanding and industry consensus. >> The >>> introduction of a new resource should require >> approval of a >>> working group and not just one expert. >>> >>> 2. Name space: extension methods (sec. 5.1) IANA >> registry?: >>> yes Assignment protocol: IETF Review >>> Comment: It should be possible to extend the set >> of methods >>> without creating a whole new version of MRCP. >>> Or should it? If not, why do we permit it in the >> spec? >>> >>> 3. Name space: request state (sec. 5.2) >>> IANA registry?: no >>> Comment: This is unlikely to change. If there >> were a need to >>> change this it would probably require a re-think >> of the >>> entire protocol. >>> >>> 4. Name space: status codes (sec. 5.2) >>> IANA registry?: yes >>> Assignment protocol: Specification Required with >> Expert Review >>> Comment: This is the sort of thing that might >> need to be >>> adjusted based on further implementation >> experience by the >>> industry. It should not require a re-write of the >> spec, but >>> any additions would need to be reviewed for sanity >> and >>> documented for portability. By the way, I would >> recommend >>> that we include a small number of codes >> specifically for >>> experimental use (see [2]). >>> >>> 5. Name space: extension events (sec. 5.3) IANA >> registry?: >>> yes Assignment protocol: IETF Review >>> Comment: It should be possible to extend the set >> of events >>> without creating a whole new version of MRCP. >>> Or should it? If not, why do we permit it in the >> spec? >>> >>> 6. Name space: extension headers (sec. 6.1) IANA >> registry?: >>> yes Assignment protocol: IETF Review >>> Comment: It should be possible to extend the set >> of headers >>> without creating a whole new version of MRCP. >>> Or should it? If not, why do we permit it in the >> spec? >>> >>> 7. Name space: vendor-specific headers (sec. 6.1) >> IANA registry?: no >>> Comment: Such parameters are already clearly >> identified by >>> the "Vendor-Specific-Parameters" prefix and thus >> the >>> contents are well-known to be vendor-specific. >>> >>> 8. Name space: parameter list (sec. 6.2/6.3) IANA >> registry?: >>> yes Assignment protocol: IETF Review >>> Comment: This one I'm not sure about. It's >> similar to >>> 2 and 5, above, but the draft does not currently >> provide a >>> slot for such extensions (i.e. the list is >> currently closed). >>> I think the permissability of extensions here >> should match >>> that for 2 and 5, whether we permit extensions for >> all >>> (without a new MRCP spec) or whether we prohibit >> all >>> extenions (and require a new MRCP spec for >> changes). >>> >>> 9. Name space: completion cause (for each >> resource) IANA registry?: no >>> Comment: Although I think there might be some use >> in having a >>> registry for each, it seems like overkill to do >> it. I could >>> be persuaded otherwise, however. >>> >>> -- Dan >>> >>> [1] >>> >> > http://www.ietf.org/internet-drafts/draft-narten-iana-consider >>> ations-rfc2434 >>> bis-01.txt >>> [2] >> ftp://ftp.rfc-editor.org/in-notes/bcp/bcp82.txt >> > === message truncated === > > > > > __________________________________ > 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 > 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 Jan 27 13:52:10 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 NAA12211 for ; Thu, 27 Jan 2005 13:52:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuF1g-0003TD-A4 for speechsc-web-archive@ietf.org; Thu, 27 Jan 2005 14:09:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuEew-0001yz-2l; Thu, 27 Jan 2005 13:46:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuEYt-0008Px-Nl for speechsc@megatron.ietf.org; Thu, 27 Jan 2005 13:40:11 -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 NAA10320 for ; Thu, 27 Jan 2005 13:40:07 -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 1CuEq4-00033R-9I for speechsc@ietf.org; Thu, 27 Jan 2005 13:57:56 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 27 Jan 2005 11:48:51 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== 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 j0RIdZl2028347; Thu, 27 Jan 2005 10:39:35 -0800 (PST) Received: from [64.134.126.222] (sjc-vpn6-256.cisco.com [10.21.121.0]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j0RIZZMA000877; Thu, 27 Jan 2005 10:35:35 -0800 In-Reply-To: <41F92B76.7080601@cisco.com> References: <41F92B76.7080601@cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <90CF1A56-7092-11D9-A5E2-000A95C73842@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [Speechsc] IANA considerations for group feedback Date: Thu, 27 Jan 2005 13:37:58 -0500 To: Sarvi Shanmugham X-Mailer: Apple Mail (2.619) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1106850939.87847"; x:"432200"; a:"rsa-sha1"; b:"nofws:2339"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"DGr5imQKd9gfT95HBGwI7IqYqig3KOY5usZSqqnaN9ndr0qmIJOfHz1Ib4YYchDsRjkyMDfH" "u5cyd2eUPKC0hNkzOQLZEkwUC91bbyurREWGiSfm8WRJN/GpGyMmbk72ncB4GFtHPVJG0L/qP3g" "Mf53hVuLCB0iD8qosBZd9yiY="; c:"From: David R Oran "; c:"Subject: Re: [Speechsc] IANA considerations for group feedback"; c:"Date: Thu, 27 Jan 2005 13:37:58 -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: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7bit 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: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit 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 From speechsc-bounces@ietf.org Thu Jan 27 16:40: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 QAA02586 for ; Thu, 27 Jan 2005 16:40:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuHem-0000yo-It for speechsc-web-archive@ietf.org; Thu, 27 Jan 2005 16:58:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuHH9-0003JH-3j; Thu, 27 Jan 2005 16:34:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuGt3-0002rk-MH; Thu, 27 Jan 2005 16:09:09 -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 QAA25577; Thu, 27 Jan 2005 16:09:07 -0500 (EST) Received: from mail.lumenvox.com ([206.169.193.45] helo=lv-svr.lumenvox.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuHAF-00076L-Mx; Thu, 27 Jan 2005 16:26:56 -0500 Received: from PROGTHOMAS ([10.0.0.141]) by lv-svr.lumenvox.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 27 Jan 2005 13:04:17 -0800 From: "Thomas Gal" To: "'Sarvi Shanmugham'" , "'Reifenrath, Klaus'" Subject: RE: [Speechsc] IANA considerations for group feedback Date: Thu, 27 Jan 2005 13:08:30 -0800 Organization: LumenVox LLC MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcUEmQ1T8171hj7nSxqgDz7VFnK1NwAGqlWg In-Reply-To: <41F92B76.7080601@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Message-ID: X-OriginalArrivalTime: 27 Jan 2005 21:04:17.0390 (UTC) FILETIME=[C36720E0:01C504B3] X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 Cc: Thomas Gal , mmusic@ietf.org, speechsc@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ThomasGal@LumenVox.com List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0382187961==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af This is a multi-part message in MIME format. --===============0382187961== Content-Type: multipart/signed; boundary="----=_NextPart_000_0017_01C50471.4B26D9A0"; micalg=SHA1; protocol="application/x-pkcs7-signature" This is a multi-part message in MIME format. ------=_NextPart_000_0017_01C50471.4B26D9A0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit 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 > > > > > ------=_NextPart_000_0017_01C50471.4B26D9A0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMBDCCBL8w ggKnoAMCAQICAwDQ9DANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNDEyMDEyMTI1MzBaFw0w NTEyMDEyMTI1MzBaMDwxEzARBgNVBAMTClRob21hcyBHYWwxJTAjBgkqhkiG9w0BCQEWFnRob21h c2dhbEBsdW1lbnZveC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDR7eXh1399 BXAlOs1kGnSeVSRasyxQd1eRcRle/mNHGMJ3COpMB3bkd8vRIqW9CuPTzjnHrCbLSbduJRoQNNjc p6Df0TkAvMDNxk6tGtEfrKk71WJ0btokYb1cxAXb7A2GHEWXVnSu+nvQ68n+/T6pJzOeesqS2cDI n79lw8owwxQixgYDKUz+nC2a+A0a2wktL+E9lXFJgCSE2CL9w9dCO5w2NeqqiPBLTxe3aiDkoRSk yvBX1tCT5s486pkko/sAko8eY/ZXE1IrAKn6U8Wr2mHUmDhcVNaRGe0w12yS/WRC+YW3/S3a1T4b Tpgb5hRiK/IbV8f/0aSDLn4GaFnLAgMBAAGjgYwwgYkwDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwIQYDVR0RBBowGIEWdGhvbWFzZ2FsQGx1bWVudm94LmNvbTAN BgkqhkiG9w0BAQQFAAOCAgEAdI6mD6HejUJaFjEPtruQpOOUat6eLetY94CoPmYiIqSoYSwBt6+m 7nJl5fGJcfUaugez/AJzMBC8Nfphtr0yw5O8EYUtvfWxtpY272eR9evAzFk2l8ZzvzGLphXuSlfK RCMLQcPN+fEnX66yu6wseF5/Z1nZnjn9TtQQ2xlZjFAKkU4L2oczvfaadOVuB1iUMx4Sbr49ukhc sRjQ4F1VS0lf/INqhL3SHGOaLDD7nWoaZM35jP/8zNHrWGr4Jait0epazMLFen4LSEJH6hsbKxVv VGVef8KczVK4f5qVX8BlediiLCH7DZkT/uY4YB/2NPr3bHZnZmmff7vYp7cIsLiUYaD565f9Isbc eHjihQarb+bDMcm8qlkaYPc6pt1t9cUgLMi0YbyjCzi5PQFX8BIjPvRYAM9iOJdjO9lIyEZnpb2S fclvuhRupYIOJC6bTIVa2qXuzNfkCRtWG7RwIu+bfLuHiIfyh/c2P66140q278zz/euPHTQSr6A7 uGhpwYTfkzO4btn7FPA8bE9hnz82Wd9dGBcQc7yTEmN11+hEGS3Ie+q2jCuOP4jONgGTKAPRFsXG 86aZr12DVZHcDrh7zt71sBwD2AMCaMuLZpClWlIFwCX0wryt2Qr9/IjvcM2hn2kHu3kIusy/UOU5 FU3SYYCpevzG7qhvoAbrIkowggc9MIIFJaADAgECAgEAMA0GCSqGSIb3DQEBBAUAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0Eg Q2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3Jn MB4XDTAzMDMzMDEyMjk0OVoXDTMzMDMyOTEyMjk0OVoweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwG A1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0 aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcwggIiMA0GCSqGSIb3DQEB AQUAA4ICDwAwggIKAoICAQDOIsDiRn3sNigHUJbyoDNAjEvxO2Y/MeVrAjbb1nz28YiPTnc2BUGV +QnwEs9GhnNgt25+6MBYZK7NsK1FFwxj+mcK6NbSvz7nmMTwTPrgA7s1XWwh3p4g2brNZjI3cvr3 CPXHzVjJjucOXuo+/hyhFAoVbIaEW2RmKnqpS1N59Yiie+4vCmErjbJ+TValE+zq2pKerERBHlhg ZQVm+MBEvcuU90J+C/dlaJhRBfDzBZEEHRsXguzIV7vDa3qI8bByzCVbIJHsFgISjzLpFxhI0McF LgIwQrglnAVrP6o6p+tTSPfo0rYHmNwbxjR/f8kcgnoFWCsIW/M4oqsXXWbJmNeeEIui0t10mvdx DHJg381vmDOdljR2PiR6krAOlR5v5qBFOEeq10HtSrcS9tcbg4oPLtgJtlnXqgT/0pN9aC7di0ur WLovjeqVp6DDVIml+9uLUSKdssO+Eb4skYaLlnitINOKLxo/xtBRZYchsRkBZX9FHIf1fNBBTE8p mCH9Mx91DARR+hl329QUHO6Bwx31mLdpBpEi3QBQzIExrBIHezjaaFvmK9R+yV+t6OtyTPMB5Usg v5qmV8qRAAGLoXUhN7VjDWc+Rk9wIGfOxdZZ2wLg8NLLzbpit5BB6N0g5Cm8ZClCyCLceJr/Q+yY GwlRS1pawnHxxMtzqeWhCwIDAQABo4IBzjCCAcowHQYDVR0OBBYEFBa1MhvUx/Pg5o7zvdKwOu6y ORjRMIGjBgNVHSMEgZswgZiAFBa1MhvUx/Pg5o7zvdKwOu6yORjRoX2kezB5MRAwDgYDVQQKEwdS b290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQg U2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZ4IBADAP BgNVHRMBAf8EBTADAQH/MDIGA1UdHwQrMCkwJ6AloCOGIWh0dHBzOi8vd3d3LmNhY2VydC5vcmcv cmV2b2tlLmNybDAwBglghkgBhvhCAQQEIxYhaHR0cHM6Ly93d3cuY2FjZXJ0Lm9yZy9yZXZva2Uu Y3JsMDQGCWCGSAGG+EIBCAQnFiVodHRwOi8vd3d3LmNhY2VydC5vcmcvaW5kZXgucGhwP2lkPTEw MFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVh ZCBvdmVyIHRvIGh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzANBgkqhkiG9w0BAQQFAAOCAgEAKMfunIIC ulyAEso1Ch2Bb4lqmczyaA9/p+GNWJU+vfIGw5BarLVg9plDAaOIcJydYp2kh69nWA0wNjvmrUjT y3QChnE+4isDaPE0YkBGO1PqKPSs+2aVU4pNXf072WDXynlpO7FlkqbGgYJcnM3rTQGKpd8RVaoV yh83wIKYcGHbanyWo44uVD5PIamQ79yCv9zoRa1NkHMIPJRlsASZdn/ivMJqFaqXBDck2B6UTm0O Ub7WxI/Klm33Q9/oMGUnO3u7Q0NjxEP3suxozOEZjiL7mOF7Wj4BNzuLCLCi85VOGsubzZqx27Jw 8C1K29iw429FSDMS//48MipU98T3ivCII8JH/mR6ccDRHqZjsAd+pC/TAY/cnyu2xgipD5NIJfwS /Z9C3PPEPvZXsNfdadEGdzQKS9LKoP8cxozJFr7EzDI3aHNfCPtR90lTNgUKlQJM8nkaEPbYOnWc 8x3xog1wZ4Ybsxb1L+Wk63mG+T0LwnMLpZmsb/xnuOUvC6YYJI170Ug1KRhArJNg4ZaGULR6WdiP IQufz4KRxju/a9wHkbmXViOqtmyUxkgGPOTOTqrk9i8J3FNvLvx06zpjmcKmrIm8p7JEoA2KEONs 8iTL+pufcEcu3hSL1LIgCZaiZPEkHNyhNZwVstS8VS59BvWcDlX0WtaT2natJXNMxUMxggOcMIID mAIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5v cmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDAND0MAkGBSsOAwIaBQCgggHwMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA1MDEyNzIxMDgyOFowIwYJKoZIhvcNAQkEMRYEFEJ8D8tZ zJOEMfavnCo7ma+TRyGCMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG SIb3DQIFMIGRBgkrBgEEAYI3EAQxgYMwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMV aHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5 MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwDQ9DCBkwYLKoZIhvcNAQkQAgsx gYOggYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3Jn MSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBw b3J0QGNhY2VydC5vcmcCAwDQ9DANBgkqhkiG9w0BAQEFAASCAQAPkoNoz92afzxvDMCKsh+MxWBe LstOmwKYopADbO6OLEgcxzamJH8tWduRFdmSRtIjzRuZrgYoT4pDdhpwszCJY7tDyPBQZYnbDRE2 L0SlE2FYaSn6sbtJO3I6OUN/8k652UMUnwOqMR2DuwcRqLWurr56yeb1X1O0PXm4dYoD9ZmiEiMG 84kCyJBMTxAftKhMJhfOBGjINHgRCOd+27Gyr1I1xOXEjD/wIAIFDrVRKCiqY2aszK85ezgs8nS4 Nfeylr0yij9KJXsvR/5ZbvDyKUwgTIIxMJ2h3dAAh3SloXQZJpcQzvF8A2hRZaf3nwjE43u0odde owHaZUp5fejiAAAAAAAA ------=_NextPart_000_0017_01C50471.4B26D9A0-- --===============0382187961== 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 --===============0382187961==-- From speechsc-bounces@ietf.org Thu Jan 27 16:42:45 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 QAA02737 for ; Thu, 27 Jan 2005 16:42:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuHgl-00012H-Fb for speechsc-web-archive@ietf.org; Thu, 27 Jan 2005 17:00:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuHIJ-0005Gi-7B; Thu, 27 Jan 2005 16:35:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuH52-0002vq-Ki for speechsc@megatron.ietf.org; Thu, 27 Jan 2005 16:21:33 -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 QAA28287 for ; Thu, 27 Jan 2005 16:21:29 -0500 (EST) Received: from mail.lumenvox.com ([206.169.193.45] helo=lv-svr.lumenvox.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuHME-000834-49 for speechsc@ietf.org; Thu, 27 Jan 2005 16:39:18 -0500 Received: from PROGTHOMAS ([10.0.0.141]) by lv-svr.lumenvox.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 27 Jan 2005 13:16:46 -0800 From: "Thomas Gal" To: "'David R Oran'" , "'Dan Burnett'" Subject: RE: [Speechsc] IANA considerations for group feedback Date: Thu, 27 Jan 2005 13:20:59 -0800 Organization: LumenVox LLC MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcUEnsGj6WDazLcQQjWI5XhxwSphSwADIeDg In-Reply-To: <57EACC9A-7092-11D9-A5E2-000A95C73842@cisco.com> Message-ID: X-OriginalArrivalTime: 27 Jan 2005 21:16:46.0968 (UTC) FILETIME=[822FA780:01C504B5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 83867a50fd8f547996ccdaf89af24437 Content-Transfer-Encoding: 7bit Cc: Thomas Gal , speechsc@ietf.org, "'Reifenrath, Klaus'" X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ThomasGal@LumenVox.com 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: be922d419820e291bde1362184dc32fd Content-Transfer-Encoding: 7bit YOU DON'T REGISTER SOMETHING WITH AN "X-", IT'S JUST SYNTAX FOR UNREGISTERED ITEMS. RFC 2045: "Private values (starting with "X-") may be defined bilaterally between two cooperating agents without outside registration or standardization. Such values cannot be registered or standardized." And RFC 2048: "Proposed media types are not formally registered and must not be used; the "x-" prefix specified in RFC 2045 can be used until registration is complete." Does that clear it up? I also personally want to note that I think putting forth a suggestion like below which embodies "pass the buck" and doesn't make a decision is always a BAD idea. Even worse "to get it through xxxx" should never be the justification for a decision in any case, because it has no bearing on what we're here to do. Especially for a standards body whose purpose is to evaluate competing proposals to make a choice for the best. Especially as in this case where there was a clear answer that appears to have been glossed over for whatever reason. -Tom thomasgal@lumenvox.com > > 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 > >> > >> thomasgal@lumenvox.com > >> > >>> -----Original Message----- > >>> From: speechsc-bounces@ietf.org > >>> [mailto:speechsc-bounces@ietf.org] On Behalf Of > >> Reifenrath, Klaus > >>> Sent: Monday, January 24, 2005 4:21 AM > >>> 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 > >>> protocol identifier (probably need to be > >> coordinated with the > >>> MMUSIC group): > >>> > >>> - SCTP > >>> - TLS > >>> > >>> At the last F2F meeting in San Diego we discussed > >> caller > >>> preference-based SIP routing, which most likely > >> would require > >>> some more IANA registrations. > >>> > >>> Best regards, > >>> Klaus > >>> > >>> -----Original Message----- > >>> From: Dan Burnett > >> [mailto:dan_burnett2000@yahoo.com] > >>> Sent: Freitag, 21. Januar 2005 19:52 > >>> To: speechsc@ietf.org > >>> Subject: [Speechsc] IANA considerations for group > >> feedback > >>> > >>> > >>> Group, > >>> > >>> In the course of reviewing the draft in order to > >> write the > >>> IANA Considerations sections, I've identified the > >> following > >>> value spaces for which one might consider > >> requesting IANA to > >>> maintain a registry. For each one, I've made a > >> suggestion as > >>> to whether or not we should create an IANA > >> registration, and > >>> if so, what policy (see [1] for explanations) > >> should be used > >>> for assignment. The default policy in the > >> document for all > >>> remaining value spaces will be that there must be > >> a new > >>> version of MRCP for any changes to occur. > >>> > >>> I would like to hear if there are any opinions on > >> these, > >>> particularly if they differ from my suggestions. > >>> I would also like particularly to hear feedback on > >> 2 and 5, > >>> below, since my suggested assignment protocol may > >> be quite > >>> restrictive with respect to vendor extensions. > >>> > >>> 1. Name space: resource types (sec. 4.2) IANA > >> registry?: no > >>> Comment: This is a core part of the spec and > >> requires > >>> significant understanding and industry consensus. > >> The > >>> introduction of a new resource should require > >> approval of a > >>> working group and not just one expert. > >>> > >>> 2. Name space: extension methods (sec. 5.1) IANA > >> registry?: > >>> yes Assignment protocol: IETF Review > >>> Comment: It should be possible to extend the set > >> of methods > >>> without creating a whole new version of MRCP. > >>> Or should it? If not, why do we permit it in the > >> spec? > >>> > >>> 3. Name space: request state (sec. 5.2) > >>> IANA registry?: no > >>> Comment: This is unlikely to change. If there > >> were a need to > >>> change this it would probably require a re-think > >> of the > >>> entire protocol. > >>> > >>> 4. Name space: status codes (sec. 5.2) > >>> IANA registry?: yes > >>> Assignment protocol: Specification Required with > >> Expert Review > >>> Comment: This is the sort of thing that might > >> need to be > >>> adjusted based on further implementation > >> experience by the > >>> industry. It should not require a re-write of the > >> spec, but > >>> any additions would need to be reviewed for sanity > >> and > >>> documented for portability. By the way, I would > >> recommend > >>> that we include a small number of codes > >> specifically for > >>> experimental use (see [2]). > >>> > >>> 5. Name space: extension events (sec. 5.3) IANA > >> registry?: > >>> yes Assignment protocol: IETF Review > >>> Comment: It should be possible to extend the set > >> of events > >>> without creating a whole new version of MRCP. > >>> Or should it? If not, why do we permit it in the > >> spec? > >>> > >>> 6. Name space: extension headers (sec. 6.1) IANA > >> registry?: > >>> yes Assignment protocol: IETF Review > >>> Comment: It should be possible to extend the set > >> of headers > >>> without creating a whole new version of MRCP. > >>> Or should it? If not, why do we permit it in the > >> spec? > >>> > >>> 7. Name space: vendor-specific headers (sec. 6.1) > >> IANA registry?: no > >>> Comment: Such parameters are already clearly > >> identified by > >>> the "Vendor-Specific-Parameters" prefix and thus > >> the > >>> contents are well-known to be vendor-specific. > >>> > >>> 8. Name space: parameter list (sec. 6.2/6.3) IANA > >> registry?: > >>> yes Assignment protocol: IETF Review > >>> Comment: This one I'm not sure about. It's > >> similar to > >>> 2 and 5, above, but the draft does not currently > >> provide a > >>> slot for such extensions (i.e. the list is > >> currently closed). > >>> I think the permissability of extensions here > >> should match > >>> that for 2 and 5, whether we permit extensions for > >> all > >>> (without a new MRCP spec) or whether we prohibit > >> all > >>> extenions (and require a new MRCP spec for > >> changes). > >>> > >>> 9. Name space: completion cause (for each > >> resource) IANA registry?: no > >>> Comment: Although I think there might be some use > >> in having a > >>> registry for each, it seems like overkill to do > >> it. I could > >>> be persuaded otherwise, however. > >>> > >>> -- Dan > >>> > >>> [1] > >>> > >> > > http://www.ietf.org/internet-drafts/draft-narten-iana-consider > >>> ations-rfc2434 > >>> bis-01.txt > >>> [2] > >> ftp://ftp.rfc-editor.org/in-notes/bcp/bcp82.txt > >> > > === message truncated === > > > > > > > > > > __________________________________ > > 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 > > > 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