From dburnett@voxeo.com Tue Jun 2 13:35:00 2009 Return-Path: X-Original-To: speechsc@core3.amsl.com Delivered-To: speechsc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 745343A7035 for ; Tue, 2 Jun 2009 13:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jm9NMpC2PaOj for ; Tue, 2 Jun 2009 13:34:59 -0700 (PDT) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with SMTP id 9D1EF3A6F53 for ; Tue, 2 Jun 2009 13:34:59 -0700 (PDT) Received: from [76.111.40.166] (account dburnett HELO [192.168.15.123]) by voxeo.com (CommuniGate Pro SMTP 5.2.3) with ESMTPSA id 45904607 for speechsc@ietf.org; Tue, 02 Jun 2009 20:34:46 +0000 Message-Id: <392E14E3-D376-41CA-BDB7-95D2785529A0@voxeo.com> From: Dan Burnett To: "IETF SPEECHSC (E-mail)" Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 2 Jun 2009 16:34:45 -0400 X-Mailer: Apple Mail (2.930.3) Subject: [Speechsc] changes in draft-19 X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 20:35:00 -0000 This draft only contains fixes to the NLSML schema files. There were no other changes. -- dan From root@core3.amsl.com Tue Jun 2 13:45:01 2009 Return-Path: X-Original-To: speechsc@ietf.org Delivered-To: speechsc@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D9EC03A6DFF; Tue, 2 Jun 2009 13:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090602204501.D9EC03A6DFF@core3.amsl.com> Date: Tue, 2 Jun 2009 13:45:01 -0700 (PDT) Cc: speechsc@ietf.org Subject: [Speechsc] I-D Action:draft-ietf-speechsc-mrcpv2-19.txt X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 20:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Speech Services Control Working Group of the IETF. Title : Media Resource Control Protocol Version 2 (MRCPv2) Author(s) : S. Shanmugham, D. Burnett Filename : draft-ietf-speechsc-mrcpv2-19.txt Pages : 215 Date : 2009-06-02 The MRCPv2 protocol allows client hosts to control media service resources such as speech synthesizers, recognizers, verifiers and identifiers residing in servers on the network. MRCPv2 is not a "stand-alone" protocol - it relies on other protocols, such as Session Initiation Protocol (SIP) to rendezvous MRCPv2 clients and servers and manage sessions between them, and the Session Description Protocol (SDP) to describe, discover and exchange capabilities. It also depends on SIP and SDP to establish the media sessions and associated parameters between the media source or sink and the media server. Once this is done, the MRCPv2 protocol exchange operates over the control session established above, allowing the client to control the media processing resources on the speech resource server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speechsc-mrcpv2-19.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-speechsc-mrcpv2-19.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-06-02133344.I-D@ietf.org> --NextPart-- From eburger@standardstrack.com Tue Jun 2 16:47:25 2009 Return-Path: X-Original-To: speechsc@core3.amsl.com Delivered-To: speechsc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72B0C3A6C64; Tue, 2 Jun 2009 16:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KiYGPKvmsX7P; Tue, 2 Jun 2009 16:47:24 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id 32CC93A6953; Tue, 2 Jun 2009 16:47:24 -0700 (PDT) Received: from 140.sub-97-130-95.myvzw.com ([97.130.95.140]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1MBdhI-0001SN-W7; Tue, 02 Jun 2009 16:47:15 -0700 Message-Id: From: Eric Burger To: apps-ads@tools.ietf.org Content-Type: multipart/signed; boundary=Apple-Mail-314--608735456; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 2 Jun 2009 19:47:16 -0400 X-Mailer: Apple Mail (2.935.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: speechsc@ietf.org, iesg-secretary@ietf.org Subject: [Speechsc] Shepherd Write-Up draft-ietf-speechsc-mrcpv2 X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 23:47:25 -0000 --Apple-Mail-314--608735456 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Document: Media Resource Control Protocol Version 2 (MRCPv2) draft-ietf-speechsc-mrcpv2-19 (Standards Track) (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Eric Burger is the document shepherd. I have personally reviewed this =20= version of the document. This doeucment is ready for forwarding to the =20= IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has had reviews by key WG members, as well as expert =20 review from GENART (Vijay Gurbani), applications (Ted Hardie), RAI =20 (Paul Kyzivat), and security (Vijay Gurbani), areas. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? Reviews listed above, as well as IANA, URL, and MIME types review. The =20= document incorporates and addresses all suggestions from Vijay, Ted, =20 Paul, and other IESG members. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, =20= or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. Some people unfamiliar with the history of MRCPv2 may question the use =20= of SIP for locating speech servers, asking why we do not use RTSP, =20 BEEP, or the MEDIACTRL Framework. RFC 4313, Speech Services Control =20 Requirements, not surprisingly, enumerates the protocol requirements =20 for MRCP. Some of these requirements include server location and =20 avoiding layer violations. SIP and RTSP meet the server location =20 requirements. However, the original MRCP experience demonstrated =20 severe protocol layering problems with RTSP. Thus, the industry =20 demonstrated RTSP is not appropriate for use as a MRCPv2 location or =20 substrate protocol. With respect to MEDIACTRL, MRCPv2 pre-dates the =20 effort by almost four years. In fact, the basis of the MEDIACTRL =20 Framework is, in fact, MRCPv2. At this time, given the years of =20 implementation experience with MRCPv2, the industry is unlikely to =20 accept major changes to the MRCPv2 protocol, unless there are clear =20 benefits to those changes. There was some discussion about whether MRCPv2 should fully specify =20 SRTP key exchange for SIP. Consensus in the work group and with the =20 individual who brought that up (Vijay Gurbani) was to leave that to a =20= SIP-related work group. Another issue is MRCPv2 uses set-cookie (RFC 2109) and set-cookie2 =20 (RFC 2965). RFC 2965 obsoletes RFC 2109, but does not define set-=20 cookie. After three years of implementation experience, the work group =20= prefers to go with a DOWNREF to RFC 2109 rather than change all extant =20= implementations. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is strong consensus with no dissent whatsoever in the work group =20= to publish. In addition, there are literally dozens of client, server, =20= open source and API implementations available. (1.f) Has anyone threatened an appeal or otherwise indicated =20 extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) None. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Checked with ID nits 2.11.11. There are warnings about what idnits =20 thinks is a FQDN but is really a reverse-order parameter registry =20 (com.example.mumble). (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The document identifies normative versus informative documents. All =20 normative references are RFCs. One DOWNREF is to RFC 2109 (see above). =20= Another nominal DOWNREF is to RFC 2483; that reference is to the text/=20= uri-list definition. MRCPv2 uses the same definition of text/uri-list =20= as found in the IANA media types registry. We could make this =20 reference Informative or be silent on the reference, as the MRCPv2 =20 reference is to the IANA registry. However, the work group believes it =20= to be useful to have a pointer to the definition of text/uri-list for =20= implementers to follow. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA considerations section meets the above requirements. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Yes. ABNF checked with Bill Fenner=92s tool. XML checked with XMLmind. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary The MRCPv2 protocol allows client hosts to control media service =20 resources such as speech synthesizers, recognizers, verifiers and =20 identifiers residing in servers on the network. MRCPv2 is not a =20 "stand-alone" protocol - it relies on a session management protocol =20 such as the Session Initiation Protocol (SIP) to establish the MRCPv2 =20= control session between the client and the server, and for rendezvous =20= and capability discovery. It also depends on SIP and SDP to establish =20= the media sessions and associated parameters between the media source =20= or sink and the media server. Once this is done, the MRCPv2 protocol =20= exchange operates over the control session established above, allowing =20= the client to control the media processing resources on the speech =20 resource server. Working Group Summary Nothing out of the ordinary happened in the WG to note. Document Quality There are over 20 interoperable implementations of clients, servers, =20 open source, and APIs based on this document. =20= --Apple-Mail-314--608735456 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGPTCCBjkw ggUhoAMCAQICEC+VK1RLWxrF8KJZDR9k8p8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQD Ey1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwODEz MDAwMDAwWhcNMDkwODEzMjM1OTU5WjCB4TE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsg LSBQRVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMg Q29tb2RvIExpbWl0ZWQxFDASBgNVBAMTC0VyaWMgQnVyZ2VyMSkwJwYJKoZIhvcNAQkBFhplYnVy Z2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMTF RRoA4LgOACMFph0aomRC/UpqoA5C/d6DUTOvTMrYSEqkjwnU4zxDtBcHlcB4AxKAov00MYsUvEU4 loz7BHjfDjv76AIkcwu33VYQbzGmarVnyaXsVb6f/cyRL3fPT0VOVO2tQAEEgwg//CX0jN8Kn2jH uXD/HEvko7cmpL3Pwevf3+DwB61v7ca79PpEZfn/WhaqRKA4uVNPj/JbieeaLo2v/0RJzrEElZK0 pHCqxiD3mQ8ossPkA9fUCSxLlbdMcPU3be5x8vt8Q8mYTXF5Z3d9RZmYrmNkvTQtdzVpfYWr/hgV Xqm9tByOOAR+hoN3FKbubR/OrAHL9yDAd4sCAwEAAaOCAhwwggIYMB8GA1UdIwQYMBaAFImCZ33E nSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRDWgutb7b8R/L7G3Y3D+molAA3VzAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRF bWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYq aHR0cDovL2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhho dHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJQYDVR0RBB4wHIEaZWJ1cmdlckBzdGFuZGFyZHN0cmFj ay5jb20wDQYJKoZIhvcNAQEFBQADggEBAGeBR7NPCvrY3GQoIi49JOuciatY2r4st905Jw1etp6J umFFWlaCBl11tFSclk/3S45B+lUv3SEvG4CEjUByPScprVmCqHR+y8BAQaB/CV+N1y14x3MbhJ+Z 8XDGKeUXuuyGd9w0l3/t/QPid6TRXQjQFrLPFs1IALuNpNiFMHEF/xFbMG1Z2vznR/gSPlePekoZ TqcExIDBNZTBebpZqwAXzPpedNNOclbMLFLWDMOAozVRpkfjI0eiFsk8SF1Ho1Gb9Bx8DeG4peE2 KRVOR9FFnZZgBpFjXYRcglsMOSKCY8HgE+NGvbbqbrMoBV/BlYyxRXwfti71RL9Zs2Cq1eQxggP8 MIID+AIBATCBwzCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkNH2TynzAJBgUrDgMCGgUAoIICDTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA2MDIyMzQ3MTdaMCMGCSqGSIb3 DQEJBDEWBBTcqn2y9hX3vZtezweSsdQKYCvpDzCB1AYJKwYBBAGCNxAEMYHGMIHDMIGuMQswCQYD VQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVU aGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhAv lStUS1saxfCiWQ0fZPKfMIHWBgsqhkiG9w0BCRACCzGBxqCBwzCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkN H2TynzANBgkqhkiG9w0BAQEFAASCAQCF1iH5+e8SLxVrhcctcebcGMJPPD1Bjc1MISY9qQJBCKaT ytfiIoqrPkb8WLxhDRafEZZ2SrnSKMANjVQjoTsqtjKvu5t0ly/VjVHrUhIOGlKUn/wGqCjKOkaI fEsPScF7M3DrsiJnixjKMjmvWB9ziiihxeDIT4+kPN2GjLBAfUIeHBZC4/BtJSMD93Qfq+NFEYBw C0LISxWawARJjp/UK9YKSfnED7FAqxCZ5UlR/zvdy5MEqQDdRAfUM3WHAHFb40rpU2AM07VcTUpW WSywyyXQZyCr11cnXYSFw2ENNaUjDlC0AQS953xK15Ya35OQvtY+6iEUrX6aDgKkh0qUAAAAAAAA --Apple-Mail-314--608735456-- From Christian.Groves@nteczone.com Tue Jun 9 19:59:23 2009 Return-Path: X-Original-To: speechsc@core3.amsl.com Delivered-To: speechsc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1A3A3A6BE5 for ; Tue, 9 Jun 2009 19:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.605 X-Spam-Level: X-Spam-Status: No, score=-2.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQp2ammI0vT0 for ; Tue, 9 Jun 2009 19:59:22 -0700 (PDT) Received: from ipmail04.adl2.internode.on.net (ipmail04.adl2.internode.on.net [203.16.214.57]) by core3.amsl.com (Postfix) with ESMTP id E91CD3A699C for ; Tue, 9 Jun 2009 19:59:21 -0700 (PDT) Received: from ppp118-208-247-62.lns10.mel6.internode.on.net (HELO [127.0.0.1]) ([118.208.247.62]) by ipmail04.adl2.internode.on.net with ESMTP; 10 Jun 2009 12:26:35 +0930 Message-ID: <4A2F20D4.3000409@nteczone.com> Date: Wed, 10 Jun 2009 12:56:20 +1000 From: Christian Groves User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: speechsc@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Speechsc] Question about Verification X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 02:59:23 -0000 Hello, I've been reviewing the verification section of draft-ietf-speechsc-mrcpv2-19 there appears to be some contradiction between the text and the syntax. i.e. Section 11.5.2.3. "Incremental" states: The first "" element MAY contain an "" element with the incremental scores of how well the last utterance matched the voiceprint. However section 16.3. "Verification Results Schema Definition" states: * */* * * <------- ???* .../ I don't know if I'm reading this correctly but to me section 11.5.2.3 doesn't say anything about incremental being used in subsequent voices. So I would assume that it would not be part of the restVoicePrintContent schema? Another example: Section 11.5.2.5. "Utterance-Length" This element MAY occur within either the "" or "" elements within the first "" element. However section 16.3 states: / * <----------------- ???* * <-----------???* / Again I don't know if I'm reading this correctly but the text for utterance says its applicable for the first voiceprint but the schema shows it only relevant for subsequent voiceprints??? Another example is: Section 11.5.2.8. "Adapted" which states: This element is found within the "" element within the verification results. However 16.3 states: /** * * / Again I'm confused as previous text says that certain elements are applicable to the first voiceprint but the text does not state this for the adapted element yet the schema shows it only belongs to the first Voiceprint. Can anyone shed some slight on this? Regards, Christian From Christian.Groves@nteczone.com Wed Jun 10 22:05:30 2009 Return-Path: X-Original-To: speechsc@core3.amsl.com Delivered-To: speechsc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 567073A6D1E for ; Wed, 10 Jun 2009 22:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.605 X-Spam-Level: X-Spam-Status: No, score=-2.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5x7Luv90eStw for ; Wed, 10 Jun 2009 22:05:29 -0700 (PDT) Received: from ipmail05.adl2.internode.on.net (ipmail05.adl2.internode.on.net [203.16.214.145]) by core3.amsl.com (Postfix) with ESMTP id 077BB3A67A7 for ; Wed, 10 Jun 2009 22:05:28 -0700 (PDT) Received: from ppp118-208-179-4.lns10.mel4.internode.on.net (HELO [127.0.0.1]) ([118.208.179.4]) by ipmail05.adl2.internode.on.net with ESMTP; 11 Jun 2009 14:33:59 +0930 Message-ID: <4A309038.2050809@nteczone.com> Date: Thu, 11 Jun 2009 15:03:52 +1000 From: Christian Groves User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: speechsc@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Speechsc] Question on Verification Result Device type X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 05:05:30 -0000 Hello, With regards to the Verification results I have a question regarding the "device". 11.5.2.6. Device This element is found within the incremental or cumulative element within the verification results. Its value indicates the apparent type of device used by the caller as determined by the verification resource. It can have the values of "cellular-phone", "electret- phone", "carbon-button-phone", or "unknown". I looked at the archives and did a web search on "electret phone" and "carbon button" phone but apart from learning about some microphone types it wasn't any clearer what these values represent. I saw some previous emails on softarmour/speechsc mailing lists talking about having a value such as "land-line" or adding definition for these. Has there been any further develops on these aspects? It would be good to have a definition to point to when asked about these code points. Regards, Christian From nik.waldron@kaz-group.com Thu Jun 11 13:58:58 2009 Return-Path: X-Original-To: speechsc@core3.amsl.com Delivered-To: speechsc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4CF73A68CB for ; Thu, 11 Jun 2009 13:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mium0E5kWwLn for ; Thu, 11 Jun 2009 13:58:58 -0700 (PDT) Received: from mail51.messagelabs.com (mail51.messagelabs.com [216.82.241.99]) by core3.amsl.com (Postfix) with SMTP id C33543A67EE for ; Thu, 11 Jun 2009 13:58:57 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: nik.waldron@kaz-group.com X-Msg-Ref: server-2.tower-51.messagelabs.com!1244753943!46717075!1 X-StarScan-Version: 6.0.0; banners=kaz-group.com,-,- X-Originating-IP: [203.28.13.56] Received: (qmail 7415 invoked from network); 11 Jun 2009 20:59:04 -0000 Received: from mail02.kaz-group.com (HELO mail02.kaz-group.com) (203.28.13.56) by server-2.tower-51.messagelabs.com with SMTP; 11 Jun 2009 20:59:04 -0000 Received: from AUKGHB01.Corporate.KAZ-Group.priv (aukghb01.corporate.kaz-group.priv) by mail02.kaz-group.com (Clearswift SMTPRS 5.2.5) with ESMTP id ; Fri, 12 Jun 2009 06:58:56 +1000 Date: Fri, 12 Jun 2009 06:59:41 +1000 MIME-Version: 1.0 To: Christian.Groves@nteczone.com From: Nik Waldron X-Mailer: Microsoft Outlook v 11.00.8217, MSOC v 2.00.4007.00 Message-ID: X-MIMETrack: Serialize by Router on AUKGHB01/KAZGROUP/AU(Release 6.5.2|June 01, 2004) at 06/12/2009 06:59:02 AM, Serialize complete at 06/12/2009 06:59:02 AM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: speechsc@ietf.org Subject: Re: [Speechsc] Question on Verification Result Device type X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 20:58:58 -0000 Hi Christian, I'm not an expert on MRCPv2 but as someone working on Verification implementation and having some familiarity with the field I think that this is due to the time at which MRCPv2 was originally drafted. At that time (a part of) the state of the art was an idea known as handset normalisation or HNorm. HNorm set about solving the problem that different handsets had very different log likelihood ratio scores. There were several variants on the solution, but basically several scores for different utterances against the same voiceprint, or scores for the same utterance against the different voice prints (or a combination) were used to normalise the score. In particular the microphone type (carbon button, or electret) were major categories for distorting scores, and compensating for the microphone type found to be effective. I guess that in order for the system to operate in an online way (updating the sets used for normalisation), it might be necessary for the results to be categorised by microphone type (if known). Others more familiar with the motivations for these fields may wish to correct me. Things have moved on a bit since then, however if you do a search (HNorm, TNorm or CNorm) you should be able to find the relevant papers. If the engine you are interested in does not support / use these types of normalisation or identify the categories then I'm sure 'unknown' will satisfy the specification. Best regards, NIK WALDRON This is an email from Fujitsu Australia Limited, ABN 19 001 011 427. It is confidential to the ordinary user of the email address to which it was addressed and may contain copyright and/or legally privileged information. No one else may read, print, store, copy or forward all or any of it or its attachments. If you receive this email in error, please return to sender. Thank you. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From eburger@standardstrack.com Fri Jun 12 02:52:41 2009 Return-Path: X-Original-To: speechsc@core3.amsl.com Delivered-To: speechsc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B81613A6A06 for ; Fri, 12 Jun 2009 02:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id el0RiPnz1yLl for ; Fri, 12 Jun 2009 02:52:40 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id BF5CE3A6864 for ; Fri, 12 Jun 2009 02:52:40 -0700 (PDT) Received: from [194.72.13.18] (helo=[172.24.1.14]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1MF3RD-0001RG-Vx; Fri, 12 Jun 2009 02:52:44 -0700 Message-Id: From: Eric Burger To: Nik Waldron In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-13-205190518; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 12 Jun 2009 10:52:42 +0100 References: X-Mailer: Apple Mail (2.935.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: speechsc@ietf.org Subject: Re: [Speechsc] Question on Verification Result Device type X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 09:52:41 -0000 --Apple-Mail-13-205190518 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Since these are terms of art, let's not change anything. On Jun 11, 2009, at 9:59 PM, Nik Waldron wrote: > Hi Christian, > > I'm not an expert on MRCPv2 but as someone working on Verification > implementation and having some familiarity with the field I think that > this is due to the time at which MRCPv2 was originally drafted. At > that > time (a part of) the state of the art was an idea known as handset > normalisation or HNorm. HNorm set about solving the problem that > different handsets had very different log likelihood ratio scores. > There > were several variants on the solution, but basically several scores > for > different utterances against the same voiceprint, or scores for the > same > utterance against the different voice prints (or a combination) were > used > to normalise the score. > > In particular the microphone type (carbon button, or electret) were > major > categories for distorting scores, and compensating for the > microphone type > found to be effective. I guess that in order for the system to > operate in > an online way (updating the sets used for normalisation), it might be > necessary for the results to be categorised by microphone type (if > known). > Others more familiar with the motivations for these fields may wish to > correct me. > > Things have moved on a bit since then, however if you do a search > (HNorm, > TNorm or CNorm) you should be able to find the relevant papers. If > the > engine you are interested in does not support / use these types of > normalisation or identify the categories then I'm sure 'unknown' will > satisfy the specification. > > Best regards, > > > > > NIK WALDRON > > > > This is an email from Fujitsu Australia Limited, ABN 19 001 011 427. > It is confidential to the ordinary user of the email address to > which it was addressed and may contain copyright and/or legally > privileged information. No one else may read, print, store, copy or > forward all or any of it or its attachments. If you receive this > email in error, please return to sender. Thank you. > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www.ietf.org/mailman/listinfo/speechsc > Supplemental web site: > <http://www.standardstrack.com/ietf/speechsc> --Apple-Mail-13-205190518 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGPTCCBjkw ggUhoAMCAQICEC+VK1RLWxrF8KJZDR9k8p8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQD Ey1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwODEz MDAwMDAwWhcNMDkwODEzMjM1OTU5WjCB4TE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsg LSBQRVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMg Q29tb2RvIExpbWl0ZWQxFDASBgNVBAMTC0VyaWMgQnVyZ2VyMSkwJwYJKoZIhvcNAQkBFhplYnVy Z2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMTF RRoA4LgOACMFph0aomRC/UpqoA5C/d6DUTOvTMrYSEqkjwnU4zxDtBcHlcB4AxKAov00MYsUvEU4 loz7BHjfDjv76AIkcwu33VYQbzGmarVnyaXsVb6f/cyRL3fPT0VOVO2tQAEEgwg//CX0jN8Kn2jH uXD/HEvko7cmpL3Pwevf3+DwB61v7ca79PpEZfn/WhaqRKA4uVNPj/JbieeaLo2v/0RJzrEElZK0 pHCqxiD3mQ8ossPkA9fUCSxLlbdMcPU3be5x8vt8Q8mYTXF5Z3d9RZmYrmNkvTQtdzVpfYWr/hgV Xqm9tByOOAR+hoN3FKbubR/OrAHL9yDAd4sCAwEAAaOCAhwwggIYMB8GA1UdIwQYMBaAFImCZ33E nSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRDWgutb7b8R/L7G3Y3D+molAA3VzAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRF bWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYq aHR0cDovL2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhho dHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJQYDVR0RBB4wHIEaZWJ1cmdlckBzdGFuZGFyZHN0cmFj ay5jb20wDQYJKoZIhvcNAQEFBQADggEBAGeBR7NPCvrY3GQoIi49JOuciatY2r4st905Jw1etp6J umFFWlaCBl11tFSclk/3S45B+lUv3SEvG4CEjUByPScprVmCqHR+y8BAQaB/CV+N1y14x3MbhJ+Z 8XDGKeUXuuyGd9w0l3/t/QPid6TRXQjQFrLPFs1IALuNpNiFMHEF/xFbMG1Z2vznR/gSPlePekoZ TqcExIDBNZTBebpZqwAXzPpedNNOclbMLFLWDMOAozVRpkfjI0eiFsk8SF1Ho1Gb9Bx8DeG4peE2 KRVOR9FFnZZgBpFjXYRcglsMOSKCY8HgE+NGvbbqbrMoBV/BlYyxRXwfti71RL9Zs2Cq1eQxggP8 MIID+AIBATCBwzCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkNH2TynzAJBgUrDgMCGgUAoIICDTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA2MTIwOTUyNDNaMCMGCSqGSIb3 DQEJBDEWBBQL+EiYesOc4J+K07oXKuymmxHm9zCB1AYJKwYBBAGCNxAEMYHGMIHDMIGuMQswCQYD VQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVU aGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhAv lStUS1saxfCiWQ0fZPKfMIHWBgsqhkiG9w0BCRACCzGBxqCBwzCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkN H2TynzANBgkqhkiG9w0BAQEFAASCAQC2Kmc6lv5L2wraWoAffA4NSWyBSJOMObZDJx47qdY/b0/K d9CqAEM6pvdNPWCxsXRyJpJJb7orzL9gAFOrpl9B2gR1SeBsSVzwozydVLNxPxQV26/sSsuyXtZ7 DP5Aoy8Nndinick6ldAkMxt6h+wefZsYUKi+eBZGjuuFrOlguYYgoTNhPWyEO8NyxqyyZaz3F4EW 7z2oDghtScIK7LTl34rdjfW24aFoz3LlrCbMlR4skpAIUyOr8wrISvtzSXgHZ70q/jKuWU3L6r5G KQBrSjm5ItJNummgTEAHJ8ukXwEOw47n3efiearH+7C06Wds/n2XTgaIi4kX/KXDxSMIAAAAAAAA --Apple-Mail-13-205190518-- From Christian.Groves@nteczone.com Fri Jun 12 03:09:02 2009 Return-Path: X-Original-To: speechsc@core3.amsl.com Delivered-To: speechsc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0689D3A68A6 for ; Fri, 12 Jun 2009 03:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.605 X-Spam-Level: X-Spam-Status: No, score=-2.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkBHk37Jptqq for ; Fri, 12 Jun 2009 03:09:01 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by core3.amsl.com (Postfix) with ESMTP id A92723A6403 for ; Fri, 12 Jun 2009 03:09:00 -0700 (PDT) Received: from ppp118-208-169-228.lns10.mel4.internode.on.net (HELO [127.0.0.1]) ([118.208.169.228]) by ipmail01.adl6.internode.on.net with ESMTP; 12 Jun 2009 19:39:06 +0930 Message-ID: <4A322939.6020503@nteczone.com> Date: Fri, 12 Jun 2009 20:08:57 +1000 From: Christian Groves User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Eric Burger References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: speechsc@ietf.org, Nik Waldron Subject: Re: [Speechsc] Question on Verification Result Device type X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 10:09:02 -0000 Hello Eric, I wasn't proposing to change anything. I just thought it would be good if they were described so that people new what they were. Nik gave some good background. Regards, Christian Eric Burger wrote: > Since these are terms of art, let's not change anything. > > On Jun 11, 2009, at 9:59 PM, Nik Waldron wrote: > >> Hi Christian, >> >> I'm not an expert on MRCPv2 but as someone working on Verification >> implementation and having some familiarity with the field I think that >> this is due to the time at which MRCPv2 was originally drafted. At that >> time (a part of) the state of the art was an idea known as handset >> normalisation or HNorm. HNorm set about solving the problem that >> different handsets had very different log likelihood ratio scores. >> There >> were several variants on the solution, but basically several scores for >> different utterances against the same voiceprint, or scores for the same >> utterance against the different voice prints (or a combination) were >> used >> to normalise the score. >> >> In particular the microphone type (carbon button, or electret) were >> major >> categories for distorting scores, and compensating for the microphone >> type >> found to be effective. I guess that in order for the system to >> operate in >> an online way (updating the sets used for normalisation), it might be >> necessary for the results to be categorised by microphone type (if >> known). >> Others more familiar with the motivations for these fields may wish to >> correct me. >> >> Things have moved on a bit since then, however if you do a search >> (HNorm, >> TNorm or CNorm) you should be able to find the relevant papers. If the >> engine you are interested in does not support / use these types of >> normalisation or identify the categories then I'm sure 'unknown' will >> satisfy the specification. >> >> Best regards, >> >> >> >> >> NIK WALDRON >> >> >> >> This is an email from Fujitsu Australia Limited, ABN 19 001 011 427. >> It is confidential to the ordinary user of the email address to which >> it was addressed and may contain copyright and/or legally privileged >> information. No one else may read, print, store, copy or forward all >> or any of it or its attachments. If you receive this email in error, >> please return to sender. Thank you. >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit http://www.messagelabs.com/email >> ______________________________________________________________________ >> _______________________________________________ >> Speechsc mailing list >> Speechsc@ietf.org >> https://www.ietf.org/mailman/listinfo/speechsc >> Supplemental web site: >> <http://www.standardstrack.com/ietf/speechsc> >