RFC4313 日本語訳
4313 Requirements for Distributed Control of Automatic Speech Recognition (ASR), Speaker Identification/Speaker Verification(SI/SV), and Text-to-Speech (TTS) Resources. D. Oran. December 2005. (Format: TXT=46875 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Oran Request for Comments: 4313 Cisco Systems, Inc. Category: Informational December 2005
コメントを求めるワーキンググループD.オランの要求をネットワークでつないでください: 4313年のシスコシステムズInc.カテゴリ: 情報の2005年12月
Requirements for Distributed Control of
Automatic Speech Recognition (ASR),
Speaker Identification/Speaker Verification (SI/SV), and
Text-to-Speech (TTS) Resources
自動音声認識(ASR)、話者識別/話者照合(SI/SV)、およびテキストからスピーチ(TTS)へのリソースの分散制御のための要件
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document outlines the needs and requirements for a protocol to control distributed speech processing of audio streams. By speech processing, this document specifically means automatic speech recognition (ASR), speaker recognition -- which includes both speaker identification (SI) and speaker verification (SV) -- and text-to-speech (TTS). Other IETF protocols, such as SIP and Real Time Streaming Protocol (RTSP), address rendezvous and control for generalized media streams. However, speech processing presents additional requirements that none of the extant IETF protocols address.
このドキュメントは必要性とプロトコルがオーディオストリームの分配されたスピーチ処理を制御するという要件について概説します。スピーチ処理で、このドキュメントは自動音声認識(ASR)、話者認識、およびテキストからスピーチ(TTS)を明確に意味します。(話者認識は話者識別(SI)と話者照合(SV)の両方を含んでいます)。 SIPやレアルTime Streamingプロトコルなどの他のIETFプロトコル(RTSP)は一般化されたメディアストリームのためのランデブーとコントロールを扱います。しかしながら、スピーチ処理は実在のIETFプロトコルアドレスについてなにもに追加要件にそれを提示します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Document Conventions .......................................3
2. SPEECHSC Framework ..............................................4
2.1. TTS Example ................................................5
2.2. Automatic Speech Recognition Example .......................6
2.3. Speaker Identification example .............................6
3. General Requirements ............................................7
3.1. Reuse Existing Protocols ...................................7
3.2. Maintain Existing Protocol Integrity .......................7
3.3. Avoid Duplicating Existing Protocols .......................7
3.4. Efficiency .................................................8
3.5. Invocation of Services .....................................8
3.6. Location and Load Balancing ................................8
1. 序論…3 1.1. コンベンションを記録してください…3 2. SPEECHSCフレームワーク…4 2.1. TTSの例…5 2.2. 自動音声認識の例…6 2.3. 議長Identificationの例…6 3. 一般要件…7 3.1. 既存のプロトコルを再利用してください…7 3.2. 既存のプロトコル保全を維持してください…7 3.3. 既存のプロトコルをコピーするのを避けてください…7 3.4. 効率…8 3.5. サービスの実施…8 3.6. 位置とロードバランシング…8
Oran Informational [Page 1] RFC 4313 Speech Services Control Requirements December 2005
オランの情報[1ページ]のRFC4313スピーチサービスは要件2005年12月に制御されます。
3.7. Multiple Services ..........................................8
3.8. Multiple Media Sessions ....................................8
3.9. Users with Disabilities ....................................9
3.10. Identification of Process That Produced Media or
Control Output ............................................9
4. TTS Requirements ................................................9
4.1. Requesting Text Playback ...................................9
4.2. Text Formats ...............................................9
4.2.1. Plain Text ..........................................9
4.2.2. SSML ................................................9
4.2.3. Text in Control Channel ............................10
4.2.4. Document Type Indication ...........................10
4.3. Control Channel ...........................................10
4.4. Media Origination/Termination by Control Elements .........10
4.5. Playback Controls .........................................10
4.6. Session Parameters ........................................11
4.7. Speech Markers ............................................11
5. ASR Requirements ...............................................11
5.1. Requesting Automatic Speech Recognition ...................11
5.2. XML .......................................................11
5.3. Grammar Requirements ......................................12
5.3.1. Grammar Specification ..............................12
5.3.2. Explicit Indication of Grammar Format ..............12
5.3.3. Grammar Sharing ....................................12
5.4. Session Parameters ........................................12
5.5. Input Capture .............................................12
6. Speaker Identification and Verification Requirements ...........13
6.1. Requesting SI/SV ..........................................13
6.2. Identifiers for SI/SV .....................................13
6.3. State for Multiple Utterances .............................13
6.4. Input Capture .............................................13
6.5. SI/SV Functional Extensibility ............................13
7. Duplexing and Parallel Operation Requirements ..................13
7.1. Full Duplex Operation .....................................14
7.2. Multiple Services in Parallel .............................14
7.3. Combination of Services ...................................14
8. Additional Considerations (Non-Normative) ......................14
9. Security Considerations ........................................15
9.1. SPEECHSC Protocol Security ................................15
9.2. Client and Server Implementation and Deployment ...........16
9.3. Use of SPEECHSC for Security Functions ....................16
10. Acknowledgements ..............................................17
11. References ....................................................18
11.1. Normative References .....................................18
11.2. Informative References ...................................18
3.7. 複数のサービス…8 3.8. マルチメディアセッション…8 3.9. 障害をもっているユーザ…9 3.10. メディアを製作したプロセスかコントロール出力の識別…9 4. TTS要件…9 4.1. テキスト再生を要求します…9 4.2. テキスト形式…9 4.2.1. プレーンテキスト…9 4.2.2. SSML…9 4.2.3. 制御チャンネルによるテキスト…10 4.2.4. タイプ指示を記録してください…10 4.3. チャンネルを監督してください…10 4.4. 制御要素に従ったメディア創作/終了…10 4.5. 再生は制御されます…10 4.6. セッションパラメタ…11 4.7. スピーチマーカー…11 5. ASR要件…11 5.1. 自動音声認識を要求します…11 5.2. XML…11 5.3. 文法要件…12 5.3.1. 文法仕様…12 5.3.2. 文法形式の明白なしるし…12 5.3.3. 文法共有…12 5.4. セッションパラメタ…12 5.5. 捕獲を入力してください…12 6. 話者識別と検証要件…13 6.1. SI/SVを要求します…13 6.2. SI/SVのための識別子…13 6.3. 複数の発声のための状態…13 6.4. 捕獲を入力してください…13 6.5. SI/SVの機能的な伸展性…13 7. 合併法と並列操作要件…13 7.1. 全二重操作…14 7.2. 平行な複数のサービス…14 7.3. サービスの組み合わせ…14 8. 追加問題(非標準の)…14 9. セキュリティ問題…15 9.1. SPEECHSCはセキュリティについて議定書の中で述べます…15 9.2. クライアント、サーバ実装、および展開…16 9.3. SPEECHSCのセキュリティの使用は機能します…16 10. 承認…17 11. 参照…18 11.1. 標準の参照…18 11.2. 有益な参照…18
Oran Informational [Page 2] RFC 4313 Speech Services Control Requirements December 2005
オランの情報[2ページ]のRFC4313スピーチサービスは要件2005年12月に制御されます。
1. Introduction
1. 序論
There are multiple IETF protocols for establishment and termination of media sessions (SIP [6]), low-level media control (Media Gateway Control Protocol (MGCP) [7] and Media Gateway Controller (MEGACO) [8]), and media record and playback (RTSP [9]). This document focuses on requirements for one or more protocols to support the control of network elements that perform Automated Speech Recognition (ASR), speaker identification or verification (SI/SV), and rendering text into audio, also known as Text-to-Speech (TTS). Many multimedia applications can benefit from having automatic speech recognition (ASR) and text-to-speech (TTS) processing available as a distributed, network resource. This requirements document limits its focus to the distributed control of ASR, SI/SV, and TTS servers.
メディアセッションの設立と終了のための複数のIETFプロトコルがある、(SIP[6])、低レベルであるメディアが制御される、(メディアゲートウェイControlプロトコル(MGCP)[7]とメディアゲートウェイController(MEGACO)[8])、メディア記録、および再生、(RTSP[9])。 このドキュメントは1つ以上のプロトコルがAutomated Speech Recognitionを実行するネットワーク要素(ASR)、話者識別または検証(SI/SV)のコントロール、およびまた、Textからスピーチ(TTS)として知られているオーディオへのレンダリングテキストをサポートするという要件に焦点を合わせます。 多くのマルチメディア応用がaとして利用可能な処理が配布した自動音声認識(ASR)とテキストからスピーチ(TTS)を持つのから利益を得ることができます、ネットワーク資源。 この要件ドキュメントは焦点をASR、SI/SV、およびTTSサーバの分散制御に制限します。
There is a broad range of systems that can benefit from a unified approach to control of TTS, ASR, and SI/SV. These include environments such as Voice over IP (VoIP) gateways to the Public Switched Telephone Network (PSTN), IP telephones, media servers, and wireless mobile devices that obtain speech services via servers on the network.
制御するために統一されたアプローチの利益を得ることができるTTS、ASR、およびSI/SVの広範囲なシステムがあります。 これらはネットワークのサーバでスピーチサービスを得るPublic Switched Telephone Network(PSTN)へのボイス・オーバー IP(VoIP)ゲートウェイや、IP電話や、メディアサーバや、ワイヤレスのモバイル機器などの環境を含んでいます。
To date, there are a number of proprietary ASR and TTS APIs, as well as two IETF documents that address this problem [13], [14]. However, there are serious deficiencies to the existing documents. In particular, they mix the semantics of existing protocols yet are close enough to other protocols as to be confusing to the implementer.
これまで、多くの独占ASRとTTS APIがあります、この問題が[13]であると扱う2通のIETFドキュメントと同様に、[14]。 しかしながら、既存のドキュメントへの重大な欠乏があります。 implementerに混乱させることに関して、他のプロトコルには、彼らが、特に、既存のプロトコルの意味論を混ぜますが、十分近くにいます。
This document sets forth requirements for protocols to support distributed speech processing of audio streams. For simplicity, and to remove confusion with existing protocol proposals, this document presents the requirements as being for a "framework" that addresses the distributed control of speech resources. It refers to such a framework as "SPEECHSC", for Speech Services Control.
このドキュメントはプロトコルが分配されたスピーチがオーディオストリームの処理であるとサポートするという要件について詳しく説明します。簡単さ、既存のプロトコル提案への混乱を取り除くために、このドキュメントはスピーチリソースの分散制御を扱う「フレームワーク」のためにあるとして要件を提示します。 それはスピーチサービスコントロールのための"SPEECHSC"のようなフレームワークについて言及します。
1.1. Document Conventions
1.1. ドキュメントコンベンション
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [3].
本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[3]で説明されるように解釈されることであるべきですか?
Oran Informational [Page 3] RFC 4313 Speech Services Control Requirements December 2005
オランの情報[3ページ]のRFC4313スピーチサービスは要件2005年12月に制御されます。
2. SPEECHSC Framework
2. SPEECHSCフレームワーク
Figure 1 below shows the SPEECHSC framework for speech processing.
以下の図1はスピーチ処理のためにSPEECHSCフレームワークを示しています。
+-------------+
| Application |
| Server |\
+-------------+ \ SPEECHSC
SIP, VoiceXML, / \
etc. / \
+------------+ / \ +-------------+
| Media |/ SPEECHSC \---| ASR, SI/SV, |
| Processing |-------------------------| and/or TTS |
RTP | Entity | RTP | Server |
=====| |=========================| |
+------------+ +-------------+
+-------------+ | アプリケーション| | サーバ|\ +-------------+ SPEECHSCがちびちび飲む\、/\VoiceXMLなど / \ +------------+ / \ +-------------+ | メディア|/SPEECHSC\---| ASR、SI/SV| | 処理|-------------------------| そして/または、TTS| RTP| 実体| RTP| サーバ| =====| |=========================| | +------------+ +-------------+
Figure 1: SPEECHSC Framework
図1: SPEECHSCフレームワーク
The "Media Processing Entity" is a network element that processes media. It may be a pure media handler, or it may also have an associated SIP user agent, VoiceXML browser, or other control entity. The "ASR, SI/SV, and/or TTS Server" is a network element that performs the back-end speech processing. It may generate an RTP stream as output based on text input (TTS) or return recognition results in response to an RTP stream as input (ASR, SI/SV). The "Application Server" is a network element that instructs the Media Processing Entity on what transformations to make to the media stream. Those instructions may be established via a session protocol such as SIP, or provided via a client/server exchange such as VoiceXML. The framework allows either the Media Processing Entity or the Application Server to control the ASR or TTS Server using SPEECHSC as a control protocol, which accounts for the SPEECHSC protocol appearing twice in the diagram.
「実体を処理するメディア」はメディアを処理するネットワーク要素です。 それには、それは純粋なメディア操作者であるかもしれませんかまた、関連SIPユーザエージェント、VoiceXMLブラウザ、または他のコントロール実体があるかもしれません。 「ASR、SI/SV、そして/または、TTSサーバ」はバックエンドスピーチ処理を実行するネットワーク要素です。 出力が入力されるようにRTPストリームに対応して入力(TTS)かリターン認識結果をテキストに基礎づけたので(ASR、SI/SV)、それはRTPストリームを生成するかもしれません。 「アプリケーション・サーバー」はどんな変換をメディアストリームにしたらよいかに関してメディアProcessing Entityを命令するネットワーク要素です。 それらの指示をSIPなどのセッションプロトコルで確立するか、またはVoiceXMLなどのクライアント/サーバ交換で提供するかもしれません。 フレームワークは、ダイヤグラムで二度現れながらSPEECHSCのためのアカウントが議定書の中で述べる制御プロトコルとしてSPEECHSCを使用することでASRかTTS Serverを制御するためにProcessing EntityかApplication Serverをメディアに許容します。
Physical embodiments of the entities can reside in one physical instance per entity, or some combination of entities. For example, a VoiceXML [11] gateway may combine the ASR and TTS functions on the same platform as the Media Processing Entity. Note that VoiceXML gateways themselves are outside the scope of this protocol. Likewise, one can combine the Application Server and Media Processing Entity, as would be the case in an interactive voice response (IVR) platform.
実体の物理的な具体化は1実体あたり1つの物理的なインスタンス、または実体の何らかの組み合わせであることができます。 例えば、VoiceXML[11]ゲートウェイはメディアProcessing Entityと同じプラットホームでASRとTTS機能を結合するかもしれません。 このプロトコルの範囲の外にVoiceXMLゲートウェイ自体があることに注意してください。 同様に、1つはApplication ServerとメディアProcessing Entityを結合できます、対話的な声の応答(IVR)プラットホームの中でそうであるように。
One can also decompose the Media Processing Entity into an entity that controls media endpoints and entities that process media directly. Such would be the case with a decomposed gateway using MGCP or MEGACO. However, this decomposition is again orthogonal to
また、1つはメディア終点を制御する実体と直接メディアを処理する実体にメディアProcessing Entityを分解できます。 分解しているゲートウェイがMGCPかMEGACOを使用しているケースはそのようなものでしょう。しかしながら、この分解は再び、直交しています。
Oran Informational [Page 4] RFC 4313 Speech Services Control Requirements December 2005
オランの情報[4ページ]のRFC4313スピーチサービスは要件2005年12月に制御されます。
the scope of SPEECHSC. The following subsections provide a number of example use cases of the SPEECHSC, one each for TTS, ASR, and SI/SV. They are intended to be illustrative only, and not to imply any restriction on the scope of the framework or to limit the decomposition or configuration to that shown in the example.
SPEECHSCの範囲。 以下の小区分はTTS、ASR、およびSI/SVのためにそれぞれSPEECHSC、1に関するケースを多くの例の使用に供給します。 それらが説明に役立つことを意図する、唯一、フレームワークの範囲の上で少しの制限も含意しないか、または分解か構成を例に示されたそれに制限します。
2.1. TTS Example
2.1. TTSの例
This example illustrates a simple usage of SPEECHSC to provide a Text-to-Speech service for playing announcements to a user on a phone with no display for textual error messages. The example scenario is shown below in Figure 2. In the figure, the VoIP gateway acts as both the Media Processing Entity and the Application Server of the SPEECHSC framework in Figure 1.
この例は、電話で原文のエラーメッセージのためのディスプレイなしでユーザに発表をプレーするためのTextからスピーチに対するサービスを提供するためにSPEECHSCの簡単な使用法を例証します。 例のシナリオは図2に以下に示されます。 図では、VoIPゲートウェイは両方のメディアとして図1のSPEECHSCフレームワークのProcessing EntityとApplication Serverを機能させます。
+---------+
_| SIP |
_/ | Server |
+-----------+ SIP/ +---------+
| | _/
+-------+ | VoIP |_/
| POTS |___| Gateway | RTP +---------+
| Phone | | (SIP UA) |=========| |
+-------+ | |\_ | SPEECHSC|
+-----------+ \ | TTS |
\__ | Server |
SPEECHSC | |
\_| |
+---------+
+---------+ _| 一口| _/ | サーバ| +-----------+ 一口/+---------+ | | _/ +-------+ | VoIP|_/ | ポット|___| ゲートウェイ| RTP+---------+ | 電話| | (一口Ua) |=========| | +-------+ | |\_ | SPEECHSC| +-----------+ \ | TTS| \__ | サーバ| SPEECHSC| | \_| | +---------+
Figure 2: Text-to-Speech Example of SPEECHSC
図2: テキストからスピーチへのSPEECHSCに関する例
The Plain Old Telephone Service (POTS) phone on the left attempts to make a phone call. The VoIP gateway, acting as a SIP UA, tries to establish a SIP session to complete the call, but gets an error, such as a SIP "486 Busy Here" response. Without SPEECHSC, the gateway would most likely just output a busy signal to the POTS phone. However, with SPEECHSC access to a TTS server, it can provide a spoken error message. The VoIP gateway therefore constructs a text error string using information from the SIP messages, such as "Your call to 978-555-1212 did not go through because the called party was busy". It then can use SPEECHSC to establish an association with a SPEECHSC server, open an RTP stream between itself and the server, and issue a TTS request for the error message, which will be played to the user on the POTS phone.
左のPlain Old Telephone Service(POTS)電話は、電話をかけるのを試みます。 VoIPゲートウェイは、SIP UAとして機能して、呼び出しを終了するためにSIPセッションを確立しようとしますが、誤りを得ます、SIPのように「486はここで」 応答と忙しくします。 SPEECHSCがなければ、ゲートウェイはたぶんPOTS電話への話中音をただ出力するでしょう。 しかしながら、TTSサーバへのSPEECHSCアクセスに、それは話されたエラーメッセージを提供できます。 したがって、VoIPゲートウェイはSIPメッセージからの情報を使用することでテキスト誤りストリングを構成します、「被呼者が忙しかったので、978-555-1212へのあなたの呼び出しは通られませんでした」などのように。 次に、それは、POTS電話でSPEECHSCサーバとの協会を証明するのにSPEECHSCを使用して、それ自体とサーバの間のRTPストリームを開いて、エラーメッセージに関するTTS要求を出すことができます。(エラーメッセージはユーザにプレーされるでしょう)。
Oran Informational [Page 5] RFC 4313 Speech Services Control Requirements December 2005
オランの情報[5ページ]のRFC4313スピーチサービスは要件2005年12月に制御されます。
2.2. Automatic Speech Recognition Example
2.2. 自動音声認識の例
This example illustrates a VXML-enabled media processing entity and associated application server using the SPEECHSC framework to supply an ASR-based user interface through an Interactive Voice Response (IVR) system. The example scenario is shown below in Figure 3. The VXML-client corresponds to the "media processing entity", while the IVR application server corresponds to the "application server" of the SPEECHSC framework of Figure 1.
この例は、Interactive Voice Response(IVR)システムを通してASRベースのユーザーインタフェースを供給するのにSPEECHSCフレームワークを使用することで実体を処理するVXMLによって可能にされたメディアと関連アプリケーション・サーバーを例証します。 例のシナリオは図3に以下に示されます。 VXML-クライアントは「実体を処理するメディア」に文通します、IVRアプリケーション・サーバーは図1のSPEECHSCフレームワークの「アプリケーション・サーバー」に対応していますが。
+------------+
| IVR |
_|Application |
VXML_/ +------------+
+-----------+ __/
| |_/ +------------+
PSTN Trunk | VoIP | SPEECHSC| |
=============| Gateway |---------| SPEECHSC |
|(VXML voice| | ASR |
| browser) |=========| Server |
+-----------+ RTP +------------+
+------------+ | IVR| _|アプリケーション| VXML_/+------------+ +-----------+ __/ | |_/ +------------+ PSTNトランク| VoIP| SPEECHSC| | =============| ゲートウェイ|---------| SPEECHSC| |(VXMLは|声に出します| ASR| | ブラウザ) |=========| サーバ| +-----------+ RTP+------------+
Figure 3: Automatic Speech Recognition Example
図3: 自動音声認識の例
In this example, users call into the service in order to obtain stock quotes. The VoIP gateway answers their PSTN call. An IVR application feeds VXML scripts to the gateway to drive the user interaction. The VXML interpreter on the gateway directs the user's media stream to the SPEECHSC ASR server and uses SPEECHSC to control the ASR server.
この例では、ユーザは、株価を得るためにサービスにちょっと立ち寄ります。 それらのPSTNが呼ぶVoIPゲートウェイ答え。 IVRアプリケーションは、ユーザ相互作用を運転するためにVXMLスクリプトをゲートウェイに提供します。 ゲートウェイの上のVXMLインタプリタは、ユーザのメディアストリームをSPEECHSC ASRサーバに向けて、ASRサーバを制御するのにSPEECHSCを使用します。
When, for example, the user speaks the name of a stock in response to an IVR prompt, the SPEECHSC ASR server attempts recognition of the name, and returns the results to the VXML gateway. The VXML gateway, following standard VXML mechanisms, informs the IVR Application of the recognized result. The IVR Application can then do the appropriate information lookup. The answer, of course, can be sent back to the user using text-to-speech. This example does not show this scenario, but it would work analogously to the scenario shown in section Section 2.1.
例えば、ユーザがIVRプロンプトに対応してストックの名前を話すとき、SPEECHSC ASRサーバは、名前の認識を試みて、VXMLゲートウェイに結果を返します。 VXMLゲートウェイ(次の標準のVXMLメカニズム)は認識された結果についてIVR Applicationに知らせます。 そして、IVR Applicationは適切な情報ルックアップができます。 もちろんテキストからスピーチを使用することで答えをユーザに送り返すことができます。 この例はこのシナリオを示しませんが、それは類似してセクションセクション2.1に示されたシナリオに取り組むでしょう。
2.3. Speaker Identification example
2.3. 議長Identificationの例
This example illustrates using speaker identification to allow voice-actuated login to an IP phone. The example scenario is shown below in Figure 4. In the figure, the IP Phone acts as both the "Media Processing Entity" and the "Application Server" of the SPEECHSC framework in Figure 1.
この例は、声で作動させられたログインをIP電話に許すのに話者識別を使用することで例証します。 例のシナリオは図4に以下に示されます。 図では、IP電話は「実体を処理するメディア」と図1のSPEECHSCフレームワークの「アプリケーション・サーバー」の両方として機能します。
Oran Informational [Page 6] RFC 4313 Speech Services Control Requirements December 2005
オランの情報[6ページ]のRFC4313スピーチサービスは要件2005年12月に制御されます。
+-----------+ +---------+ | | RTP | | | IP |=========| SPEECHSC| | Phone | | TTS | | |_________| Server | | | SPEECHSC| | +-----------+ +---------+
+-----------+ +---------+ | | RTP| | | IP|=========| SPEECHSC| | 電話| | TTS| | |_________| サーバ| | | SPEECHSC| | +-----------+ +---------+
Figure 4: Speaker Identification Example
図4: 話者識別の例
In this example, a user speaks into a SIP phone in order to get "logged in" to that phone to make and receive phone calls using his identity and preferences. The IP phone uses the SPEECHSC framework to set up an RTP stream between the phone and the SPEECHSC SI/SV server and to request verification. The SV server verifies the user's identity and returns the result, including the necessary login credentials, to the phone via SPEECHSC. The IP Phone may use the identity directly to identify the user in outgoing calls, to fetch the user's preferences from a configuration server, or to request authorization from an Authentication, Authorization, and Accounting (AAA) server, in any combination. Since this example uses SPEECHSC to perform a security-related function, be sure to note the associated material in Section 9.
この例では、ユーザは、彼のアイデンティティと好みを使用することで電話をかけて、受けるためにその電話に「ログインされること」を得るためにSIP電話に話します。 IP電話は、電話とSPEECHSC SI/SVサーバの間のRTPストリームをセットアップして、検証を要求するのにSPEECHSCフレームワークを使用します。 SVサーバは、ユーザのアイデンティティについて確かめて、結果を返します、必要なログイン資格証明書を含んでいて、SPEECHSCを通した電話に。 IP電話は発信電話でユーザを特定するか、構成サーバからユーザの好みをとって来るか、またはAuthentication、Authorization、およびAccounting(AAA)サーバから承認を要求するのに直接アイデンティティを使用するかもしれません、どんな組み合わせでも。 この例がセキュリティ関連の機能を実行するのにSPEECHSCを使用するので、セクション9で関連物質に必ず注意してください。
3. General Requirements
3. 一般要件
3.1. Reuse Existing Protocols
3.1. 既存のプロトコルを再利用してください。
To the extent feasible, the SPEECHSC framework SHOULD use existing protocols.
可能な範囲まで、SPEECHSCフレームワークSHOULDは既存のプロトコルを使用します。
3.2. Maintain Existing Protocol Integrity
3.2. 既存のプロトコル保全を維持してください。
In meeting the requirement of Section 3.1, the SPEECHSC framework MUST NOT redefine the semantics of an existing protocol. Said differently, we will not break existing protocols or cause backward-compatibility problems.
セクション3.1に関する必要条件を満たすには、SPEECHSCフレームワークは既存のプロトコルの意味論を再定義してはいけません。 異なって言われていて、私たちは既存のプロトコルか原因を破って、後方の互換性の問題にするつもりではありません。
3.3. Avoid Duplicating Existing Protocols
3.3. 既存のプロトコルをコピーするのを避けてください。
To the extent feasible, SPEECHSC SHOULD NOT duplicate the functionality of existing protocols. For example, network announcements using SIP [12] and RTSP [9] already define how to request playback of audio. The focus of SPEECHSC is new functionality not addressed by existing protocols or extending existing protocols within the strictures of the requirement in
可能な範囲に、SPEECHSC SHOULD NOTは既存のプロトコルの機能性をコピーします。 例えば、SIP[12]とRTSP[9]を使用するネットワーク発表が既にオーディオの再生を要求する方法を定義します。 SPEECHSCの焦点は中で要件の狭窄の中で既存のプロトコルによって扱われないか、または既存のプロトコルを広げない新しい機能性です。
Oran Informational [Page 7] RFC 4313 Speech Services Control Requirements December 2005
オランの情報[7ページ]のRFC4313スピーチサービスは要件2005年12月に制御されます。
Section 3.2. Where an existing protocol can be gracefully extended to support SPEECHSC requirements, such extensions are acceptable alternatives for meeting the requirements.
セクション3.2。 SPEECHSCに要件をサポートするために優雅に既存のプロトコルを広げることができるところでは、そのような拡大は、条件を満たすための受け入れられる代案です。
As a corollary to this, the SPEECHSC should not require a separate protocol to perform functions that could be easily added into the SPEECHSC protocol (like redirecting media streams, or discovering capabilities), unless it is similarly easy to embed that protocol directly into the SPEECHSC framework.
これへの推論として、SPEECHSCは容易にSPEECHSCプロトコル(メディアストリームを向け直すか、または能力を発見するような)に追加されるかもしれない機能を実行するために別々のプロトコルを必要とするはずがありません、直接SPEECHSCフレームワークにそのプロトコルを埋め込むのが同様に簡単でない場合。
3.4. Efficiency
3.4. 効率
The SPEECHSC framework SHOULD employ protocol elements known to result in efficient operation. Techniques to be considered include:
SPEECHSCフレームワークSHOULDは効率的な操作をもたらすのが知られているプロトコル要素を使います。 考えられるテクニックは:
o Re-use of transport connections across sessions o Piggybacking of responses on requests in the reverse direction o Caching of state across requests
o 要求の向こう側の状態の反対の方向o Cachingによる要求の応答のセッションo Piggybackingの向こう側の輸送の接続の再使用
3.5. Invocation of Services
3.5. サービスの実施
The SPEECHSC framework MUST be compliant with the IAB Open Pluggable Edge Services (OPES) [4] framework. The applicability of the SPEECHSC protocol will therefore be specified as occurring between clients and servers at least one of which is operating directly on behalf of the user requesting the service.
SPEECHSCフレームワークはIABオープンPluggable Edge Services(作品)[4]フレームワークで対応するに違いありません。 したがって、SPEECHSCプロトコルの適用性は少なくともそれの1つがサービスを要求するユーザを代表して直営しているクライアントとサーバの間に起こると指定されるでしょう。
3.6. Location and Load Balancing
3.6. 位置とロードバランシング
To the extent feasible, the SPEECHSC framework SHOULD exploit existing schemes for supporting service location and load balancing, such as the Service Location Protocol [13] or DNS SRV records [14]. Where such facilities are not deemed adequate, the SPEECHSC framework MAY define additional load balancing techniques.
可能な範囲に、SPEECHSCフレームワークSHOULDはサービスが位置とロードバランシングであるとサポートすることの既存の体系を利用します、Service Locationプロトコル[13]やDNS SRV記録[14]のように。 そのような施設が適切であることは考えられないところでは、SPEECHSCフレームワークが追加ロードバランシングのテクニックを定義するかもしれません。
3.7. Multiple Services
3.7. 複数のサービス
The SPEECHSC framework MUST permit multiple services to operate on a single media stream so that either the same or different servers may be performing speech recognition, speaker identification or verification, etc., in parallel.
SPEECHSCフレームワークは、同じであるか異なったサーバが音声認識や話者識別や検証などを実行できるように、複数のサービスがただ一つのメディアストリームを作動させることを許可しなければなりません、平行で。
3.8. Multiple Media Sessions
3.8. マルチメディアセッション
The SPEECHSC framework MUST allow a 1:N mapping between session and RTP channels. For example, a single session may include an outbound RTP channel for TTS, an inbound for ASR, and a different inbound for SI/SV (e.g., if processed by different elements on the Media Resource
セッションとRTPの間でチャンネルを写像して、SPEECHSCフレームワークは1:Nを許容しなければなりません。 例えば、ただ一つのセッションがTTSの外国行きのRTPチャンネルを含むかもしれない、ASRにおける本国行き、a異なる、SI/SVにおける本国行き、(例えば、メディアResourceの異なった要素で、処理されます。
Oran Informational [Page 8] RFC 4313 Speech Services Control Requirements December 2005
オランの情報[8ページ]のRFC4313スピーチサービスは要件2005年12月に制御されます。
Element). Note: All of these can be described via SDP, so if SDP is utilized for media channel description, this requirement is met "for free".
要素) 以下に注意してください。 SDPを通してこれらのすべてについて説明できるので、SDPがメディアに利用されるなら、チャンネル記述、この必要条件は「ただで」満たされます。
3.9. Users with Disabilities
3.9. 障害をもっているユーザ
The SPEECHSC framework must have sufficient capabilities to address the critical needs of people with disabilities. In particular, the set of requirements set forth in RFC 3351 [5] MUST be taken into account by the framework. It is also important that implementers of SPEECHSC clients and servers be cognizant that some interaction modalities of SPEECHSC may be inconvenient or simply inappropriate for disabled users. Hearing-impaired individuals may find TTS of limited utility. Speech-impaired users may be unable to make use of ASR or SI/SV capabilities. Therefore, systems employing SPEECHSC MUST provide alternative interaction modes or avoid the use of speech processing entirely.
SPEECHSCフレームワークには、障害で人々の決定的な必要性を扱うことができるくらいの能力がなければなりません。 特に、フレームワークでRFC3351[5]に詳しく説明された要件のセットを考慮に入れなければなりません。 また、SPEECHSCクライアントとサーバのimplementersは認識力があるのも、重要です。SPEECHSCのいくつかの相互作用様式が、不便であるか、または障害があるユーザには、単に不適当であるかもしれません。 聴覚障害の個人は限られたユーティリティのTTSを見つけるかもしれません。 スピーチによって損なわれたユーザはASRかSI/SV能力を利用できないかもしれません。 したがって、SPEECHSC MUSTを使うシステムが、代替の相互作用モードを提供するか、またはスピーチ処理の使用を完全に避けます。
3.10. Identification of Process That Produced Media or Control Output
3.10. メディアを製作したプロセスかコントロール出力の識別
The client of a SPEECHSC operation SHOULD be able to ascertain via the SPEECHSC framework what speech process produced the output. For example, an RTP stream containing the spoken output of TTS should be identifiable as TTS output, and the recognized utterance of ASR should be identifiable as having been produced by ASR processing.
クライアント、a SPEECHSC操作SHOULDでは、どんなスピーチプロセスが出力を起こしたかをSPEECHSCフレームワークで確かめることができてください。 例えば、TTSの話された出力を含むRTPストリームはTTS出力として身元保証可能であるべきです、そして、ASRの認識された発声はASR処理で生産されたとして身元保証可能であるべきです。
4. TTS Requirements
4. TTS要件
4.1. Requesting Text Playback
4.1. テキスト再生を要求します。
The SPEECHSC framework MUST allow a Media Processing Entity or Application Server, using a control protocol, to request the TTS Server to play back text as voice in an RTP stream.
SPEECHSCフレームワークはメディアProcessing EntityかApplication Serverを許容しなければなりません、RTPストリームにおける声としてテキストを再生するようTTS Serverに要求するのに制御プロトコルを使用して。
4.2. Text Formats
4.2. テキスト形式
4.2.1. Plain Text
4.2.1. プレーンテキスト
The SPEECHSC framework MAY assume that all TTS servers are capable of reading plain text. For reading plain text, framework MUST allow the language and voicing to be indicated via session parameters. For finer control over such properties, see [1].
SPEECHSCフレームワークは、すべてのTTSサーバがプレーンテキストを読むことができると仮定するかもしれません。 読書プレーンテキストのために、フレームワークは、言語とヴォイシングがセッションパラメタで示されるのを許容しなければなりません。 そのような特性の、よりよいコントロールに関しては、[1]を見てください。
4.2.2. SSML
4.2.2. SSML
The SPEECHSC framework MUST support Speech Synthesis Markup Language (SSML)[1] <speak> basics, and SHOULD support other SSML tags. The framework assumes all TTS servers are capable of reading SSML
SPEECHSCフレームワークは<が話すSpeech Synthesis Markup Language(SSML)[1]に>基礎をサポートしなければなりません、そして、SHOULDは他のSSMLタグを支えます。 フレームワークは、すべてのTTSサーバがSSMLを読むことができると仮定します。
Oran Informational [Page 9] RFC 4313 Speech Services Control Requirements December 2005
オランの情報[9ページ]のRFC4313スピーチサービスは要件2005年12月に制御されます。
formatted text. Internationalization of TTS in the SPEECHSC framework, including multi-lingual output within a single utterance, is accomplished via SSML xml:lang tags.
フォーマット済みのテキスト。 ただ一つの発声の中に多言語出力を含むSPEECHSCフレームワークにおける、TTSの国際化はSSML xmlを通して達成されます: langタグ。
4.2.3. Text in Control Channel
4.2.3. 制御チャンネルによるテキスト
The SPEECHSC framework assumes all TTS servers accept text over the SPEECHSC connection for reading over the RTP connection. The framework assumes the server can accept text either "by value" (embedded in the protocol) or "by reference" (e.g., by de-referencing a Uniform Resource Identifier (URI) embedded in the protocol).
SPEECHSCフレームワークは、すべてのTTSサーバがRTP接続を読み通すためのSPEECHSC接続の上にテキストを受け入れると仮定します。 フレームワークは、サーバがどちらか「値」によるテキスト(プロトコルに埋め込まれている)か「参照」(例えば、プロトコルに埋め込まれたUniform Resource Identifier(URI)に反-参照をつけるのによる)を受け入れることができると仮定します。
4.2.4. Document Type Indication
4.2.4. ドキュメントタイプ指示
A document type specifies the syntax in which the text to be read is encoded. The SPEECHSC framework MUST be capable of explicitly indicating the document type of the text to be processed, as opposed to forcing the server to infer the content by other means.
ドキュメントタイプは読まれるテキストがコード化される構文を指定します。 SPEECHSCフレームワークは処理されるために明らかにテキストのドキュメントタイプを示すことができなければなりません、サーバに他の手段で内容を推論させることと対照的に。
4.3. Control Channel
4.3. 制御チャンネル
The SPEECHSC framework MUST be capable of establishing the control channel between the client and server on a per-session basis, where a session is loosely defined to be associated with a single "call" or "dialog". The protocol SHOULD be capable of maintaining a long-lived control channel for multiple sessions serially, and MAY be capable of shorter time horizons as well, including as short as for the processing of a single utterance.
SPEECHSCフレームワークは1セッションあたり1個のベースのクライアントとサーバの間の制御チャンネルを確立できなければなりません。そこでは、セッションが、単一の「呼び出し」か「対話」に関連しているように緩く定義されます。 プロトコルSHOULDも順次、複数のセッションのための長命の制御チャンネルを維持できて、また、より短い時間地平線ができるかもしれません、ただ一つの発声の処理のように同じくらい急に包含して。
4.4. Media Origination/Termination by Control Elements
4.4. 制御要素に従ったメディア創作/終了
The SPEECHSC framework MUST NOT require the controlling element (application server, media processing entity) to accept or originate media streams. Media streams MAY source & sink from the controlled element (ASR, TTS, etc.).
SPEECHSCフレームワークは、制御要素(ASR、TTSなど)からメディアストリームメディアストリーム5月のソースと流し台を受け入れるか、または溯源するために、制御素子(アプリケーション・サーバー、実体を処理するメディア)を必要としてはいけません。
4.5. Playback Controls
4.5. 再生コントロール
The SPEECHSC framework MUST support "VCR controls" for controlling the playout of streaming media output from SPEECHSC processing, and MUST allow for servers with varying capabilities to accommodate such controls. The protocol SHOULD allow clients to state what controls they wish to use, and for servers to report which ones they honor. These capabilities include:
SPEECHSCフレームワークは、SPEECHSC処理からストリーミング・メディア出力の再生を制御するための「VCRコントロール」をサポートしなければならなくて、そのようなコントロールを収容する異なった能力があるサーバを考慮しなければなりません。 それらがどんなコントロールを使用したがっているかを述べて、サーバがそれらが光栄に思うものを報告するように、プロトコルSHOULDはクライアントを許容します。 これらの能力は:
Oran Informational [Page 10] RFC 4313 Speech Services Control Requirements December 2005
オランの情報[10ページ]のRFC4313スピーチサービスは要件2005年12月に制御されます。
o The ability to jump in time to the location of a specific marker.
o The ability to jump in time, forwards or backwards, by a specified
amount of time. Valid time units MUST include seconds, words,
paragraphs, sentences, and markers.
o The ability to increase and decrease playout speed.
o The ability to fast-forward and fast-rewind the audio, where
snippets of audio are played as the server moves forwards or
backwards in time.
o The ability to pause and resume playout.
o The ability to increase and decrease playout volume.
o 時間内に. ○ 指定された時間までに時間内に、前方または後方までジャンプする能力を特定のマーカーの位置まで跳ぶ能力。 有効なタイム・ユニットは秒、単語、パラグラフ、文、およびマーカーを含まなければなりません。○ 再生速度○ オーディオの切れ端がサーバとしてプレーされるオーディオを早送りして、速く、巻き戻す能力を増減させる能力は時間○ 再生○ 再生ボリュームを増減させる能力をポーズして、再開する能力で前方か後方に移行します。
These controls SHOULD be made easily available to users through the client user interface and through per-user customization capabilities of the client. This is particularly important for hearing-impaired users, who will likely desire settings and control regimes different from those that would be acceptable for non-impaired users.
これらはSHOULDを制御します。容易にユーザにとってクライアントユーザーインタフェースを通してクライアントの1ユーザあたりの改造能力を通して利用可能に作られてください。 聴覚障害のユーザには、これは特に重要です。(そのユーザは、おそらく非損なわれたユーザにとって、許容できるものと異なった設定とコントロール政権を望むでしょう)。
4.6. Session Parameters
4.6. セッションパラメタ
The SPEECHSC framework MUST support the specification of session parameters, such as language, prosody, and voicing.
SPEECHSCフレームワークは言語や、音律や、ヴォイシングなどのセッションパラメタの仕様をサポートしなければなりません。
4.7. Speech Markers
4.7. スピーチマーカー
The SPEECHSC framework MUST accommodate speech markers, with capability at least as flexible as that provided in SSML [1]. The framework MUST further provide an efficient mechanism for reporting that a marker has been reached during playout.
少なくともそんなに提供されるとしてのフレキシブルな同じくらい能力がSSML[1]にある状態で、SPEECHSCフレームワークはスピーチマーカーを収容しなければなりません。 マーカーが再生の間連絡されていると報告するのにフレームワークはさらに効率的なメカニズムを提供しなければなりません。
5. ASR Requirements
5. ASR要件
5.1. Requesting Automatic Speech Recognition
5.1. 自動音声認識を要求します。
The SPEECHSC framework MUST allow a Media Processing Entity or Application Server to request the ASR Server to perform automatic speech recognition on an RTP stream, returning the results over SPEECHSC.
メディアProcessing EntityかApplication Serverが、SPEECHSCフレームワークからRTPストリームに自動音声認識を実行するようASR Serverに要求できなければなりません、SPEECHSCの上に結果を返して。
5.2. XML
5.2. XML
The SPEECHSC framework assumes that all ASR servers support the VoiceXML speech recognition grammar specification (SRGS) for speech recognition [2].
SPEECHSCフレームワークは、すべてのASRサーバが、音声認識[2]のためにVoiceXML音声認識文法仕様が(SRGS)であるとサポートすると仮定します。
Oran Informational [Page 11] RFC 4313 Speech Services Control Requirements December 2005
オランの情報[11ページ]のRFC4313スピーチサービスは要件2005年12月に制御されます。
5.3. Grammar Requirements
5.3. 文法要件
5.3.1. Grammar Specification
5.3.1. 文法仕様
The SPEECHSC framework assumes all ASR servers are capable of accepting grammar specifications either "by value" (embedded in the protocol) or "by reference" (e.g., by de-referencing a URI embedded in the protocol). The latter MUST allow the indication of a grammar already known to, or otherwise "built in" to, the server. The framework and protocol further SHOULD exploit the ability to store and later retrieve by reference large grammars that were originally supplied by the client.
SPEECHSCフレームワークは、すべてのASRサーバが「値」(プロトコルに埋め込まれている)か「参照」(例えば、プロトコルに埋め込まれたURIに反-参照をつけるのによる)のどちらかという文法仕様を受け入れることができると仮定します。 サーバは、既に、知られて、別の方法で「建てられます」。クライアントによって供給されて、後者は元々、フレームワークと一層のプロトコルSHOULDが店に能力を開発して、後で参照でそれが大きい文法であったのを検索するという文法のしるしを許容しなければなりません。
5.3.2. Explicit Indication of Grammar Format
5.3.2. 文法形式の明白なしるし
The SPEECHSC framework protocol MUST be able to explicitly convey the grammar format in which the grammar is encoded and MUST be extensible to allow for conveying new grammar formats as they are defined.
SPEECHSCフレームワークプロトコルは、明らかに、文法がコード化される文法形式を伝えることができなければならなくて、それらが定義されるので新しい文法形式を伝えると考慮するのにおいて広げることができるに違いありません。
5.3.3. Grammar Sharing
5.3.3. 文法共有
The SPEECHSC framework SHOULD exploit sharing grammars across sessions for servers that are capable of doing so. This supports applications with large grammars for which it is unrealistic to dynamically load. An example is a city-country grammar for a weather service.
SPEECHSCフレームワークSHOULDはそうすることができるサーバのためのセッションの向こう側に共有文法を利用します。 これはダイナミックにロードするのが非現実的である大きい文法でアプリケーションをサポートします。 例は天気測候事業のための都市国の文法です。
5.4. Session Parameters
5.4. セッションパラメタ
The SPEECHSC framework MUST accommodate at a minimum all of the protocol parameters currently defined in Media Resource Control Protocol (MRCP) [10] In addition, there SHOULD be a capability to reset parameters within a session.
SPEECHSCフレームワークは現在、最小限でプロトコルパラメタのすべてを収容しなければなりません。[10] さらに、そして、そこのメディアResource Controlプロトコル(MRCP)では、セッション以内にリセットする能力がパラメタであったならSHOULDを定義しました。
5.5. Input Capture
5.5. 入力捕獲
The SPEECHSC framework MUST support a method directing the ASR Server to capture the input media stream for later analysis and tuning of the ASR engine.
SPEECHSCフレームワークはメソッドがASRエンジンの後で解析するために入力メディアストリームを得るようASR Serverに指示して、チューニングであるとサポートしなければなりません。
Oran Informational [Page 12] RFC 4313 Speech Services Control Requirements December 2005
オランの情報[12ページ]のRFC4313スピーチサービスは要件2005年12月に制御されます。
6. Speaker Identification and Verification Requirements
6. 話者識別と検証要件
6.1. Requesting SI/SV
6.1. SI/SVを要求します。
The SPEECHSC framework MUST allow a Media Processing Entity to request the SI/SV Server to perform speaker identification or verification on an RTP stream, returning the results over SPEECHSC.
メディアProcessing Entityは、SPEECHSCフレームワークからRTPストリームに話者識別か検証を実行するようSI/SV Serverに要求できなければなりません、SPEECHSCの上に結果を返して。
6.2. Identifiers for SI/SV
6.2. SI/SVのための識別子
The SPEECHSC framework MUST accommodate an identifier for each verification resource and permit control of that resource by ID, because voiceprint format and contents are vendor specific.
SPEECHSCフレームワークは、それぞれの検証リソースのために識別子に対応して、IDのそばでそのリソースのコントロールを可能にしなければなりません、声紋形式とコンテンツがベンダー特有であるので。
6.3. State for Multiple Utterances
6.3. 複数の発声のための状態
The SPEECHSC framework MUST work with SI/SV servers that maintain state to handle multi-utterance verification.
SPEECHSCフレームワークはマルチ発声検証を扱うために状態を維持するSI/SVサーバで働かなければなりません。
6.4. Input Capture
6.4. 入力捕獲
The SPEECHSC framework MUST support a method for capturing the input media stream for later analysis and tuning of the SI/SV engine. The framework may assume all servers are capable of doing so. In addition, the framework assumes that the captured stream contains enough timestamp context (e.g., the NTP time range from the RTP Control Protocol (RTCP) packets, which corresponds to the RTP timestamps of the captured input) to ascertain after the fact exactly when the verification was requested.
SPEECHSCフレームワークはSI/SVエンジンのメディアが後で解析するために流す入力を得て、チューニングのためにメソッドをサポートしなければなりません。 フレームワークは、すべてのサーバがそうすることができると仮定するかもしれません。 さらに、フレームワークは、捕らわれているストリームが事実の後に検証がちょうどいつ要求されたかを確かめることができるくらいのタイムスタンプ文脈(RTP Controlプロトコル(RTCP)パケットからの例えば捕らわれている入力に関するRTPタイムスタンプに対応するNTP時間範囲)を含むと仮定します。
6.5. SI/SV Functional Extensibility
6.5. SI/SVの機能的な伸展性
The SPEECHSC framework SHOULD be extensible to additional functions associated with SI/SV, such as prompting, utterance verification, and retraining.
SPEECHSCフレームワークSHOULD、うながすのや、発声検証や、再教育などのSI/SVに関連している追加機能に広げることができてください。
7. Duplexing and Parallel Operation Requirements
7. 合併法と並列操作要件
One very important requirement for an interactive speech-driven system is that user perception of the quality of the interaction depends strongly on the ability of the user to interrupt a prompt or rendered TTS with speech. Interrupting, or barging, the speech output requires more than energy detection from the user's direction. Many advanced systems halt the media towards the user by employing the ASR engine to decide if an utterance is likely to be real speech, as opposed to a cough, for example.
対話的なスピーチ駆動のシステムのための1つの非常に重要な要件は相互作用の品質のユーザ認知を強くユーザがスピーチで迅速であるかレンダリングされたTTSを中断する能力に依存するということです。 中断、またははしけ、スピーチ出力がユーザの方向からエネルギー検出以上を必要とします。 多くの高度なシステムが、発声が例えば、せきと対照的に本当のスピーチである傾向があるかどうか決めるのにASRエンジンを使うことによって、ユーザに向かってメディアを止めます。
Oran Informational [Page 13] RFC 4313 Speech Services Control Requirements December 2005
オランの情報[13ページ]のRFC4313スピーチサービスは要件2005年12月に制御されます。
7.1. Full Duplex Operation
7.1. 全二重操作
To achieve low latency between utterance detection and halting of playback, many implementations combine the speaking and ASR functions. The SPEECHSC framework MUST support such full-duplex implementations.
再生の発声検出と停止の間の低遅延を達成するために、多くの実装が話しとASR機能を結合します。 SPEECHSCフレームワークはそのような全二重実装をサポートしなければなりません。
7.2. Multiple Services in Parallel
7.2. 平行な複数のサービス
Good spoken user interfaces typically depend upon the ease with which the user can accomplish his or her task. When making use of speaker identification or verification technologies, user interface improvements often come from the combination of the different technologies: simultaneous identity claim and verification (on the same utterance), simultaneous knowledge and voice verification (using ASR and verification simultaneously). Using ASR and verification on the same utterance is in fact the only way to support rolling or dynamically-generated challenge phrases (e.g., "say 51723"). The SPEECHSC framework MUST support such parallel service implementations.
良い話されたユーザインタフェースはユーザがその人のタスクを達成できる容易さに通常よります。 話者識別か検証技術を利用するとき、ユーザーインタフェース改良は異なった技術の組み合わせからしばしば来ます: 同時のアイデンティティクレーム、検証(同じ発声での)、同時の知識、および声の検証(同時に、ASRと検証を使用します)。 事実上、同じ発声のときにASRと検証を使用するのは、回転しているかダイナミックに発生している挑戦が句であるとサポートする唯一の方法(例えば、「51723を言う」)です。 SPEECHSCフレームワークは、そのような平行なサービスが実装であるとサポートしなければなりません。
7.3. Combination of Services
7.3. サービスの組み合わせ
It is optionally of interest that the SPEECHSC framework support more complex remote combination and controls of speech engines:
SPEECHSCフレームワークがスピーチエンジンの、より複雑なリモート組み合わせとコントロールをサポートするのは、任意に興味があります:
o Combination in series of engines that may then act on the input or
output of ASR, TTS, or Speaker recognition engines. The control
MAY then extend beyond such engines to include other audio input
and output processing and natural language processing.
o Intermediate exchanges and coordination between engines.
o Remote specification of flows between engines.
o 連続的に次に入力に影響するかもしれないエンジンの組み合わせかASR、TTS、または議長認識エンジンの出力。 コントロールは広がるかもしれなくて、次に、そのようなエンジンを超えて広がって、エンジンエンジンの間の流れのo Remote仕様の間の他のオーディオ入出力、自然言語処理o Intermediate交換、およびコーディネートを含んでください。
These capabilities MAY benefit from service discovery mechanisms (e.g., engines, properties, and states discovery).
これらの能力はサービス発見メカニズム(例えば、エンジン、特性、および州の発見)の利益を得るかもしれません。
8. Additional Considerations (Non-Normative)
8. 追加問題(非標準)です。
The framework assumes that Session Description Protocol (SDP) will be used to describe media sessions and streams. The framework further assumes RTP carriage of media. However, since SDP can be used to describe other media transport schemes (e.g., ATM) these could be used if they provide the necessary elements (e.g., explicit timestamps).
フレームワークは、Session記述プロトコル(SDP)がメディアセッションとストリームについて説明するのに使用されると仮定します。フレームワークは、RTPがメディアのキャリッジであるとさらに仮定します。 しかしながら、他のメディア輸送体系(例えば、ATM)について説明するのにSDPを使用できるので、必要な要素(例えば、明白なタイムスタンプ)を提供するなら、これらは使用されるかもしれません。
Oran Informational [Page 14] RFC 4313 Speech Services Control Requirements December 2005
オランの情報[14ページ]のRFC4313スピーチサービスは要件2005年12月に制御されます。
The working group will not be defining distributed speech recognition (DSR) methods, as exemplified by the European Telecommunications Standards Institute (ETSI) Aurora project. The working group will not be recreating functionality available in other protocols, such as SIP or SDP.
ワーキンググループは分配された音声認識(DSR)メソッドを定義しないでしょう、ヨーロッパのTelecommunications Standards Institute(ETSI)オーロラプロジェクトによって例示されるように。 ワーキンググループはSIPかSDPなどの他のプロトコルで利用可能な機能性を休養させないでしょう。
TTS looks very much like playing back a file. Extending RTSP looks promising for when one requires VCR controls or markers in the text to be spoken. When one does not require VCR controls, SIP in a framework such as Network Announcements [12] works directly without modification.
TTSは、たいへんファイルを再生するように見えます。 RTSPを広げるのはものが、テキストのVCRコントロールかマーカーが話されるのを必要とする時の間、有望に見えます。 人がVCRコントロールを必要としないとき、Network Announcements[12]などのフレームワークにおけるSIPは直接変更なしで働いています。
ASR has an entirely different set of characteristics. For barge-in support, ASR requires real-time return of intermediate results. Barring the discovery of a good reuse model for an existing protocol, this will most likely become the focus of SPEECHSC.
ASRには、完全に異なったセットの特性があります。 中のはしけのサポートのために、ASRは中間結果のリアルタイムの復帰を必要とします。 既存のプロトコルのために良い再利用モデルの発見を禁じると、これはたぶんSPEECHSCの焦点になるでしょう。
9. Security Considerations
9. セキュリティ問題
Protocols relating to speech processing must take security and privacy into account. Many applications of speech technology deal with sensitive information, such as the use of Text-to-Speech to read financial information. Likewise, popular uses for automatic speech recognition include executing financial transactions and shopping.
スピーチ処理に関連するプロトコルはセキュリティとプライバシーを考慮に入れなければなりません。 スピーチ技術の多くのアプリケーションが、財務情報を読むためにTextからスピーチの使用などの機密情報に対処します。 同様に、自動音声認識のための一般的な使用は、金融取引を実行して、買い物をするのを含んでいます。
There are at least three aspects of speech processing security that intersect with the SPEECHSC requirements -- securing the SPEECHSC protocol itself, implementing and deploying the servers that run the protocol, and ensuring that utilization of the technology for providing security functions is appropriate. Each of these aspects in discussed in the following subsections. While some of these considerations are, strictly speaking, out of scope of the protocol itself, they will be carefully considered and accommodated during protocol design, and will be called out as part of the applicability statement accompanying the protocol specification(s). Privacy considerations are discussed as well.
SPEECHSCプロトコル自体を保証して、SPEECHSC要件と交差するスピーチ処理セキュリティの少なくとも3つの局面があります、そして、サーバがそれであると実装して、配布するのがプロトコルを実行します、そして、セキュリティ機能を提供するために技術のその利用を確実にするのは適切です。 以下の小区分で議論するところのそれぞれのこれらの局面。 厳密に言うと、プロトコル自体の範囲の外にこれらの問題のいくつかがある間、それらは、慎重に考えられて、プロトコルデザインの間、設備されて、プロトコル仕様に伴う適用性証明の一部として呼び出されるでしょう。 また、プライバシー問題について議論します。
9.1. SPEECHSC Protocol Security
9.1. SPEECHSCプロトコルセキュリティ
The SPEECHSC protocol MUST in all cases support authentication, authorization, and integrity, and SHOULD support confidentiality. For privacy-sensitive applications, the protocol MUST support confidentiality. We envision that rather than providing protocol-specific security mechanisms in SPEECHSC itself, the resulting protocol will employ security machinery of either a containing protocol or the transport on which it runs. For example, we will consider solutions such as using Transport Layer Security (TLS) for securing the control channel, and Secure Realtime Transport
SPEECHSCプロトコルはすべての場合で認証、承認、および保全をサポートしなければなりません、そして、SHOULDは秘密性をサポートします。 プライバシー敏感なアプリケーションのために、プロトコルは秘密性をサポートしなければなりません。 私たちはSPEECHSC自身のプロトコル特有のセキュリティー対策を提供するよりむしろそれを思い描いて、結果として起こるプロトコルはそれが稼働する含んでいるプロトコルか輸送のどちらかのセキュリティ機械を使うでしょう。 例えば、私たちは制御チャンネル、およびSecure Realtime Transportを固定するのに、Transport Layer Security(TLS)を使用などなどのソリューションを考えるつもりです。
Oran Informational [Page 15] RFC 4313 Speech Services Control Requirements December 2005
オランの情報[15ページ]のRFC4313スピーチサービスは要件2005年12月に制御されます。
Protocol (SRTP) for securing the media channel. Third-party dependencies necessitating transitive trust will be minimized or explicitly dealt with through the authentication and authorization aspects of the protocol design.
メディアチャンネルを固定するために(SRTP)について議定書の中で述べてください。 遷移的な信頼を必要とする第三者の依存が、最小にされるか、またはプロトコルデザインの認証と承認局面を通して明らかに対処されるでしょう。
9.2. Client and Server Implementation and Deployment
9.2. クライアント、サーバ実装、および展開
Given the possibly sensitive nature of the information carried, SPEECHSC clients and servers need to take steps to ensure confidentiality and integrity of the data and its transformations to and from spoken form. In addition to these general considerations, certain SPEECHSC functions, such as speaker verification and identification, employ voiceprints whose privacy, confidentiality, and integrity must be maintained. Similarly, the requirement to support input capture for analysis and tuning can represent a privacy vulnerability because user utterances are recorded and could be either revealed or replayed inappropriately. Implementers must take care to prevent the exploitation of any centralized voiceprint database and the recorded material from which such voiceprints may be derived. Specific actions that are recommended to minimize these threats include:
運ばれた情報、SPEECHSCクライアント、およびサーバのことによると敏感な本質を考えて、取る必要性は、フォームと、そして、話されたフォームからデータとその変換の秘密性と保全を確実にするために踏まれます。 これらの一般的な問題に加えて、あるSPEECHSCは機能します、話者照合や識別のように、プライバシー、秘密性、および保全を維持しなければならない雇用声紋。 同様に、不適当に分析とチューニングのための入力捕獲をサポートするという要件は、ユーザ発声が記録されているのでプライバシー脆弱性を表すことができて、明らかにしたか、または再演できました。 Implementersは、そのような声紋が引き出されるかもしれないどんな集結された声紋データベースと記録された材料の攻略も防ぐために注意しなければなりません。 これらの脅威を最小にすることが勧められる特定の動作は:
o End-to-end authentication, confidentiality, and integrity
protection (like TLS) of access to the database to minimize the
exposure to external attack.
o Database protection measures such as read/write access control and
local login authentication to minimize the exposure to insider
threats.
o Copies of the database, especially ones that are maintained at
off-site locations, need the same protection as the operational
database.
o 外部の攻撃読むか、または書くようなo Database保護方策に暴露を最小にするデータベースへのアクセスの終わりから終わりへの認証、秘密性、および保全保護(TLSのような)は、インサイダーの脅威に暴露を最小にするためにコントロールと地方のログイン認証にアクセスします。データベースのo Copies(特にオフサイト位置で維持されるもの)は操作上のデータベースと同じ保護を必要とします。
Inappropriate disclosure of this data does not as of the date of this document represent an exploitable threat, but quite possibly might in the future. Specific vulnerabilities that might become feasible are discussed in the next subsection. It is prudent to take measures such as encrypting the voiceprint database and permitting access only through programming interfaces enforcing adequate authorization machinery.
このデータの不適当な公開は、このドキュメントの日付現在利用可能の脅威を表しませんが、将来、全くことによると表すかもしれません。 次の小区分で可能になるかもしれない特定の脆弱性について議論します。 適切な承認機械を実施しながら声紋データベースを暗号化して、プログラミングインターフェースだけを通してアクセスを許可などなどの対策を実施するのは慎重です。
9.3. Use of SPEECHSC for Security Functions
9.3. SPEECHSCのセキュリティ機能の使用
Either speaker identification or verification can be used directly as an authentication technology. Authorization decisions can be coupled with speaker verification in a direct fashion through challenge-response protocols, or indirectly with speaker identification through the use of access control lists or other identity-based authorization mechanisms. When so employed, there are
直接認証技術として話者識別か検証のどちらかを使用できます。 承認決定がチャレンジレスポンスプロトコルを通したダイレクトファッションにおける話者照合に結びつけられるか、または間接的なアクセスコントロールリストか他のアイデンティティベースの承認メカニズムの使用による話者識別と共にあることができます。そのように使われると、あります。
Oran Informational [Page 16] RFC 4313 Speech Services Control Requirements December 2005
オランの情報[16ページ]のRFC4313スピーチサービスは要件2005年12月に制御されます。
additional security concerns that need to be addressed through the use of protocol security mechanisms for clients and servers. For example, the ability to manipulate the media stream of a speaker verification request could inappropriately permit or deny access based on impersonation, or simple garbling via noise injection, making it critical to properly secure both the control and data channels, as recommended above. The following issues specific to the use of SI/SV for authentication should be carefully considered:
追加担保はそのプロトコルセキュリティー対策のクライアントとサーバの使用で扱われるべき必要性に関係があります。 例えば、話者照合要求のメディアストリームを操る能力は、不適当にものまねに基づいてアクセスを可能にするか、拒絶する、または雑音注射で簡単な誤り伝えることを拒絶できるでしょう、両方がコントロールとデータ・チャンネルであると適切に機密保護するのを重要にして、上で推薦されるように。 SI/SVの認証の使用に特定の以下の問題は慎重に考えられるべきです:
1. Theft of voiceprints or the recorded samples used to construct
them represents a future threat against the use of speaker
identification/verification as a biometric authentication
technology. A plausible attack vector (not feasible today) is to
use the voiceprint information as parametric input to a
text-to-speech synthesis system that could mimic the user's voice
accurately enough to match the voiceprint. Since it is not very
difficult to surreptitiously record reasonably large corpuses of
voice samples, the ability to construct voiceprints for input to
this attack would render the security of voice-based biometric
authentication, even using advanced challenge-response
techniques, highly vulnerable. Users of speaker verification for
authentication should monitor technological developments in this
area closely for such future vulnerabilities (much as users of
other authentication technologies should monitor advances in
factoring as a way to break asymmetric keying systems).
2. As with other biometric authentication technologies, a downside
to the use of speech identification is that revocation is not
possible. Once compromised, the biometric information can be
used in identification and authentication to other independent
systems.
3. Enrollment procedures can be vulnerable to impersonation if not
protected both by protocol security mechanisms and some
independent proof of identity. (Proof of identity may not be
needed in systems that only need to verify continuity of identity
since enrollment, as opposed to association with a particular
individual.
1. 声紋かそれらを組み立てるのに使用される記録されたサンプルの窃盗はバイオメトリックな認証技術として話者識別/検証の使用に対して将来的な脅威を表します。 もっともらしい攻撃ベクトル(今日可能でない)はパラメトリック入力として声紋を合わせることができるくらい正確にユーザの声をまねることができたテキスト音声合成システムに声紋情報を使用することです。 こっそりと声のサンプルの合理的に大きいコーパスを記録するのがそれほど難しくないので、入力のためにこの攻撃に声紋を構成する能力は声のベースのバイオメトリックな認証のセキュリティをレンダリングするでしょう、高度なチャレンジレスポンスのテクニックを使用さえして、非常に被害を受け易いです。 認証のための話者照合のユーザはそのような将来の脆弱性のためにこの領域で密接に技術開発をモニターするべきです(他の認証技術のユーザがシステムを合わせながら非対称に壊れる方法としての因数分解における進歩をモニターするべきであるように)。 2. 他のバイオメトリックな認証技術のように、スピーチ識別の使用への下落傾向は取消しが可能でないということです。 いったん感染されると、識別と認証にバイオメトリックな情報を他の独立しているシステム3まで使用できます。 プロトコルセキュリティー対策とアイデンティティの何らかの独自の証拠によって保護されないなら、登録手順はものまねに被害を受け易い場合があります。 (身元の証拠は登録以来のアイデンティティの連続について確かめる必要があるだけであるシステムで必要でないかもしれません、特定の個人との仲間と対照的に。
Further discussion of the use of SI/SV as an authentication technology, and some recommendations concerning advantages and vulnerabilities, can be found in Chapter 5 of [15].
[15]の第5章で認証技術としてのSI/SVの使用のさらなる議論、および利点と脆弱性に関するいくつかの推薦を見つけることができます。
10. Acknowledgements
10. 承認
Eric Burger wrote the original version of these requirements and has continued to contribute actively throughout their development. He is a co-author in all but formal authorship, and is instead acknowledged here as it is preferable that working group co-chairs have non-conflicting roles with respect to the progression of documents.
エリックBurgerは、これらの要件のオリジナルバージョンを書いて、彼らの開発の間中活発に貢献し続けていました。 彼は、ほとんど正式な著述業における共著者であり、ドキュメントの進行に関してワーキンググループの共同議長には非闘争の役割があるのが、望ましいので、代わりにここで承認されます。
Oran Informational [Page 17] RFC 4313 Speech Services Control Requirements December 2005
オランの情報[17ページ]のRFC4313スピーチサービスは要件2005年12月に制御されます。
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[1] Walker, M., Burnett, D., and A. Hunt, "Speech Synthesis Markup
Language (SSML) Version 1.0", W3C
REC REC-speech-synthesis-20040907, September 2004.
[1] ウォーカーとM.とバーネット、D.とA.狩り、「音声合成マークアップ言語(SSML)バージョン1インチ、W3C REC RECスピーチ統合20040907、2004年9月。」
[2] McGlashan, S. and A. Hunt, "Speech Recognition Grammar
Specification Version 1.0", W3C REC REC-speech-grammar-20040316,
March 2004.
マックグラシャン、S.、およびA.が捜す[2]、「音声認識文法仕様バージョン1インチ、W3C REC RECスピーチ文法20040316、2004年3月。」
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[4] Floyd, S. and L. Daigle, "IAB Architectural and Policy
Considerations for Open Pluggable Edge Services", RFC 3238,
January 2002.
[4] フロイドとS.とL.Daigle、「開いているPluggable縁のサービスのためのIAB建築するのと方針問題」、RFC3238、2002年1月。
[5] Charlton, N., Gasson, M., Gybels, G., Spanner, M., and A. van
Wijk, "User Requirements for the Session Initiation Protocol
(SIP) in Support of Deaf, Hard of Hearing and Speech-impaired
Individuals", RFC 3351, August 2002.
[5] チャールトン、N.、Gasson、M.、Gybels、G.、Spanner、M.、およびA.はウェイク、「聴覚障害の、そして、耳が遠くてスピーチによって損なわれた個人を支持したセッション開始プロトコル(一口)のためのユーザ要件」をバンに積みます、RFC3351、2002年8月。
11.2. Informative References
11.2. 有益な参照
[6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[6] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[7] Andreasen, F. and B. Foster, "Media Gateway Control Protocol
(MGCP) Version 1.0", RFC 3435, January 2003.
[7] Andreasen、F.、およびB.フォスター、「メディアゲートウェイコントロールは2003年1月にバージョン1インチ、(MGCP)RFC3435について議定書の中で述べます」。
[8] Groves, C., Pantaleo, M., Ericsson, LM., Anderson, T., and T.
Taylor, "Gateway Control Protocol Version 1", RFC 3525,
June 2003.
[8] 木立とC.とPantaleoとM.、エリクソン(LM)とアンダーソン、T.とT.テイラー、「ゲートウェイ制御プロトコルバージョン1インチ、RFC3525、2003年6月。」
[9] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
1998年4月の[9]SchulzrinneとH.とラオ、A.とR.Lanphier、「リアルタイムのストリーミングのプロトコル(RTSP)」RFC2326。
[10] Shanmugham, S., Monaco, P., and B. Eberman, "MRCP: Media
Resource Control Protocol", Work in Progress.
[10]Shanmugham、S.、モナコ、P.、およびB.Eberman、「MRCP:」 「メディアリソース制御プロトコル」は進行中で働いています。
Oran Informational [Page 18] RFC 4313 Speech Services Control Requirements December 2005
オランの情報[18ページ]のRFC4313スピーチサービスは要件2005年12月に制御されます。
[11] World Wide Web Consortium, "Voice Extensible Markup Language
(VoiceXML) Version 2.0", W3C Working Draft , April 2002,
<http://www.w3.org/TR/2002/WD-voicexml20-20020424/>.
[11] ワールドワイドウェブコンソーシアム、「拡張マークアップ言語(VoiceXML)バージョン2インチ、W3C作業草案2002年4月、<http://www.w3.org/TR/2002/WD-voicexml20-20020424/>を声に出してください。」
[12] Burger, E., Ed., Van Dyke, J., and A. Spitzer, "Basic Network
Media Services with SIP", RFC 4240, December 2005.
[12] バーガー、E.、エド、ヴァンダイク、J.とA.スピッツァー、「一口との基本的なネットワークメディアサービス」RFC4240、12月2005日
[13] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service
Location Protocol, Version 2", RFC 2608, June 1999.
[13]GuttmanとE.とパーキンスとC.とVeizades、J.とM.日、「サービス位置のプロトコル、バージョン2インチ、RFC2608、1999年6月。」
[14] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[14]Gulbrandsen、A.、Vixie、P.、およびL.Esibov、「サービスの位置を指定するためのDNS RR(DNS SRV)」、RFC2782(2000年2月)。
[15] Committee on Authentication Technologies and Their Privacy
Implications, National Research Council, "Who Goes There?:
Authentication Through the Lens of Privacy", Computer Science
and Telecommunications Board (CSTB) , 2003,
<http://www.nap.edu/catalog/10656.html/ >.
[15] 認証技術とそれらのプライバシー含意の委員会、調査評議会、「影が行く?:」 「プライバシーのレンズを通した認証」、コンピュータサイエンス、およびテレコミュニケーションは(CSTB)、2003、<http://www.nap.edu/catalog/10656.html/>に入ります。
Author's Address
作者のアドレス
David R. Oran Cisco Systems, Inc. 7 Ladyslipper Lane Acton, MA USA
デヴィッドR.オランシスコシステムズInc.7Ladyslipper Lane MAアクトン(米国)
EMail: oran@cisco.com
メール: oran@cisco.com
Oran Informational [Page 19] RFC 4313 Speech Services Control Requirements December 2005
オランの情報[19ページ]のRFC4313スピーチサービスは要件2005年12月に制御されます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Oran Informational [Page 20]
オラン情報です。[20ページ]
一覧
スポンサーリンク
