Network Working Group N. Cook
Request for Comments: 5616 Cloudmark
Category: Informational August 2009
Streaming Internet Messaging Attachments
Abstract
抽象
This document describes a method for streaming multimedia attachments received by a resource- and/or network-constrained device from an IMAP server. It allows such clients, which often have limits in storage space and bandwidth, to play video and audio email content.
この文書は、IMAPサーバから資源及び/又はネットワーク制約デバイスによって受信されたマルチメディア添付ファイルをストリーミングするための方法を記載しています。それは多くの場合、ストレージ容量と帯域幅の制限があり、そのようなクライアントは、ビデオとオーディオの電子メールのコンテンツを再生することができます。
The document describes a profile for making use of the URLAUTH-authorized IMAP URLs (RFC 5092), the Network Announcement SIP Media Service (RFC 4240), and the Media Server Control Markup Language (RFC 5022).
文書はURLAUTH-認可IMAPのURL（RFC 5092）、ネットワークアナウンスSIPメディアサービス（RFC 4240）、およびメディアサーバ制御マークアップ言語（RFC 5022）を利用するためのプロファイルを記述する。
Status of This 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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Overview of Mechanism . . . . . . . . . . . . . . . . . . 3
3.2. Media Server Discovery . . . . . . . . . . . . . . . . . . 5
3.3. Client Use of GENURLAUTH Command . . . . . . . . . . . . . 7
3.4. Client Determination of Media Server Capabilities . . . . 9
3.5. Client Use of the Media Server Announcement Service . . . 10
3.6. Media Negotiation and Transcoding . . . . . . . . . . . . 11
3.7. Client Use of the Media Server MSCML IVR Service . . . . . 13
3.8. Media Server Use of IMAP Server . . . . . . . . . . . . . 17
3.9. Protocol Diagrams . . . . . . . . . . . . . . . . . . . . 18
3.9.1. Announcement Service Protocol Diagram . . . . . . . . 18
3.9.2. IVR Service Protocol Diagram . . . . . . . . . . . . . 19
4. Security Considerations . . . . . . . . . . . . . . . . . . . 21
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
6. Digital Rights Management (DRM) Issues . . . . . . . . . . . . 24
7. Deployment Considerations . . . . . . . . . . . . . . . . . . 24
8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 25
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.1. Normative References . . . . . . . . . . . . . . . . . . . 26
10.2. Informative References . . . . . . . . . . . . . . . . . . 28
Email clients on resource- and/or network-constrained devices, such as mobile phones, may have difficulties in retrieving and/or storing large attachments received in a message. For example, on a poor network link, the latency required to download the entire attachment before displaying any of it may not be acceptable to the user. Conversely, even on a high-speed network, the device may not have enough storage space to secure the attachment once retrieved.
携帯電話などの資源および/またはネットワークに制約のあるデバイス、上の電子メールクライアントは、取得および/またはメッセージで受信大きな添付ファイルを保存するのが困難であってもよいです。たとえば、貧弱なネットワークリンク上で、それのいずれかを表示する前に全体の添付ファイルをダウンロードするために必要な待ち時間は、ユーザにとって許容できない場合があります。逆に、偶数高速ネットワーク上で、デバイスは、一度取得した添付ファイルを確保するのに十分な記憶容量を有していなくてもよいです。
For certain media, such as audio and video, there is a solution: the media can be streamed to the device, using protocols such as RTP [RTP]. Streaming can be initiated and controlled using protocols such as SIP [SIP] and particularly the media server profiles as specified in RFC 4240 [NETANN] or MSCML [MSCML]. Streaming the media to the device addresses both the latency issue, since the client can start playing the media relatively quickly, and the storage issue, since the client does not need to store the media locally. A tradeoff is that the media cannot be viewed/played when the device is offline.
オーディオやビデオなどの特定のメディアについては、溶液がある：メディアは、RTP [RTP]などのプロトコルを使用して、デバイスにストリーミングすることができます。 RFC 4240で指定されるようにストリーミング[MSCML] [NETANN]またはMSCML例えばSIP [SIP]などのプロトコル、特にメディアサーバプロファイルを使用して開始し、制御することができます。クライアントがローカルメディアを格納する必要がないため、クライアントは、比較的速やかにメディアの再生を開始し、ストレージの問題ことができるため、デバイスアドレスの両方待ち時間の問題にメディアをストリーミング。トレードオフは、デバイスがオフラインのときにメディアが見ることができない/再生されます。
Examples of the types of media that would benefit from the ability to stream to the device include:
デバイスにストリーミングする能力から利益を得るメディアの種類の例としては：
o Voice or video mail messages received as an attachment
O音声やビデオメールメッセージが添付ファイルとして受信し
o Audio clips such as ring tones received as an attachment
そのような添付ファイルとして受信された着信音などのオーディオクリップO
o Video clips, such as movie trailers, received as an attachment
Oなど映画の予告編などのビデオクリップは、添付ファイルとして受信しました
The client may wish to present the user with the ability to use simple "VCR-style" controls such as pause, fast-forward, and rewind. In consideration of this, the document presents two alternatives for streaming media -- a simple mechanism that makes use of the announcement service of RFC 4240, and a more complex mechanism which allows VCR controls, based on MSCML (RFC 5022) [MSCML]. The choice of which mechanism to use is up to the client; for example, it may be based on limitations of the client or the configured media server. This document presents suggestions for determining which of these streaming services are available.
クライアントは、一時停止などの単純な「VCRスタイル」コントロール、早送りを使用し、巻き戻しする機能をユーザに提示することを望むかもしれません。 RFC 4240のアナウンスサービス、および[MSCML] MSCML（RFC 5022）に基づいて、VCRのコントロールを可能にする、より複雑なメカニズムを利用した簡単なメカニズム - このを考慮して、文書がメディアをストリーミングするための2つの選択肢を提示します。使用するメカニズムの選択はクライアント次第です。例えば、それは、クライアントまたは構成されたメディアサーバーの制限に基づいていてもよいです。この文書では、利用可能なこれらのストリーミングサービスのかを決定するための提案を提示します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119 [KEYWORDS]で説明されるように解釈されます。
In examples, "C:" and "S:" indicate lines sent by the client and server, respectively. If a single "C:" or "S:" label applies to multiple lines, then some of the line breaks between those lines are for editorial clarity only and may not be part of the actual protocol exchange.
実施例において、「C：」および「S：」は、それぞれ、クライアントとサーバによって送信されたラインを示します。シングル「C：」場合や「S：」ラベルは複数行に適用され、それらの行のみが編集上明確にするためであり、実際のプロトコル交換の一部ではないかもしれない間、その行の一部が壊れます。
The proposed mechanism for streaming media to messaging clients is a profile for making use of several existing mechanisms, namely:
メッセージングクライアントにメディアをストリーミングするための提案されたメカニズムは、すなわち、いくつかの既存のメカニズムを利用するためのプロファイルです。
o IMAP URLAUTH Extension [URLAUTH] - Providing the ability to generate an IMAP URL that allows access by external entities to specific message parts, e.g., an audio clip.
O IMAP URLAUTHエクステンション[URLAUTH] - 特定のメッセージ部分、例えば、オーディオクリップの外部エンティティによるアクセスを可能にするIMAP URLを生成する能力を提供します。
o URLFETCH Binary Extension [URLFETCH_BINARY] - Providing the ability to specify BINARY and BODYPARTSTRUCTURE arguments to the URLFETCH command.
O UrlFetchのバイナリ拡張子は[URLFETCH_BINARY] - UrlFetchのコマンドにBINARYとBODYPARTSTRUCTURE引数を指定する機能を提供します。
o Media Server Announcement Service (RFC 4240) [NETANN] - Providing the ability for a media server to stream media using a reference provided by the media server client in a URL.
O Media Serverのアナウンスサービス（RFC 4240）[NETANN] - URL内のメディアサーバークライアントによって提供された基準を使用してメディアをストリーミングするメディアサーバーの能力を提供します。
o Media Server Interactive Voice Response (IVR) Service (RFC 5022) [MSCML] - Providing the ability to stream media as above, but with VCR-style controls.
Oメディアサーバー対話型音声応答（IVR）サービス（RFC 5022）[MSCML] - 上記のようにメディアをストリーミングする機能を提供しますが、VCRスタイルのコントロールを持ちます。
The approach is shown in the following figure:
アプローチは、次の図に示します。
+--------------+
| |
| Email Client |^
| | \
+--------------+ \
^ ^ \
| \ \ (5)
| (1), \ \
| (2) \ \
| (3),\ \
| (6) \ \
| \ \
v v v
+--------------+ +----------------+
| | (4) | |
| IMAP Server |<----->| Media Server |
| | | |
+--------------+ +----------------+
Figure 1: Proposed Mechanism
図1：提案されたメカニズム
The proposed mechanism has the following steps:
提案されたメカニズムは、以下のステップがあります。
(1) The client determines from MIME headers of a particular message that a particular message part (attachment) should be streamed to the user. Note that no assumptions are made about how/when/if the client contacts the user of the client about this decision. User input may be required in order to initiate the proposed mechanism.
（1）クライアントが特定のメッセージ部（アタッチメント）は、ユーザにストリーミングされるべき特定のメッセージのMIMEヘッダから決定します。何の仮定がどのように/ /もしクライアントがこの決定についてのクライアントのユーザについて行われていないことに注意してください。ユーザ入力は、提案されたメカニズムを開始するために必要とされ得ます。
(2) The client constructs an IMAP URL referencing the message part, and uses the GENURLAUTH [URLAUTH] command to generate a URLAUTH-authorized IMAP URL.
（2）クライアントは、メッセージの一部を参照するIMAP URLを構築し、URLAUTH認定IMAP URLを生成するGENURLAUTH [URLAUTH]コマンドを使用します。
(3) The client connects to a SIP Media Server using the announcement service as specified in RFC 4240 [NETANN], or the IVR service as specified in RFC 5022 [MSCML], and passes the URLAUTH-authorized URL to the media server.
（3）クライアントは、RFC 4240で指定されるように[NETANN]アナウンスサービスを使用して、SIPメディアサーバに接続し、またはIVRサービスRFC 5022で指定されるように[MSCML]、およびメディアサーバにURLAUTH許可URLを渡します。
(4) The media server connects to the IMAP server specified in the referenced URL, and uses the IMAP URLFETCH [URLAUTH] command to retrieve the message part.
（4）メディア・サーバは、参照URLで指定されたIMAPサーバに接続し、IMAPのURLfetchは[URLAUTH]メッセージ部分を取得するためにコマンドを使用します。
(5) The media server streams the retrieved message part to the client using RTP [RTP].
（5）メディアサーバはRTP [RTP]を使用して、クライアントに検索されたメッセージの一部をストリーム。
(6) The media server or the client terminates the media streaming, or the streaming ends naturally. The SIP session is terminated by either client or server.
（6）メディアサーバーまたはクライアントは、メディアストリーミングを終了、またはストリーミングが自然に終了します。 SIPセッションは、クライアントまたはサーバのいずれかによって終了されます。
It should be noted that the proposed mechanism makes several assumptions about the mobile device, as well as available network services, namely:
すなわち、提案されたメカニズムは、モバイルデバイスに関するいくつかの仮定と同様に、利用可能なネットワークサービスを作ることに留意すべきです。
o The mobile device is provisioned with, or obtains via some dynamic mechanism (see Section 3.2), the location of a media server which supports either RFC 4240 [NETANN] and/or RFC 5022 [MSCML].
モバイルデバイスを用いてプロビジョニング、またはいくつかの動的な機構を介して取得されたO、RFC 4240 [NETANN]および/またはRFC 5022 [MSCML]のいずれかをサポートするメディアサーバの位置（セクション3.2を参照）。
o The media server(s) used by the mobile device support the IMAP URL [IMAPURL] scheme for the announcement and/or IVR services.
モバイルデバイスサポートアナウンス及び/又はIVRサービスのIMAPのURL [IMAPURLスキームによって使用されるメディア・サーバ（S）O。
o The IMAP server used by the mobile device supports generating anonymous IMAP URLs using the URLAUTH mechanism as well as the IMAP URLFETCH BINARY [URLFETCH_BINARY] extension.
Oモバイルデバイスによって使用されるIMAPサーバは匿名URLAUTHメカニズムを使用してIMAPのURLだけでなく、IMAPのURLfetch BINARY [URLFETCH_BINARY]拡張を生成サポート。
This section discusses possibilities for the automatic discovery of suitable media servers to perform streaming operations, and provides for such a mechanism using the IMAP METADATA [METADATA] extension.
このセクションでは、ストリーミング動作を実行するための適切なメディアサーバーの自動検出の可能性を説明し、そしてIMAP METADATA [METADATA]拡張を使用してこのようなメカニズムを提供します。
There are two possibilities for clients with regard to determining the hostname and port number information of a suitable media server:
適したメディアサーバーのホスト名とポート番号情報の決定に関して、クライアントのための二つの可能性があります。
1. No discovery of media servers is required: clients are configured with suitable media server information in an out-of-band manner.
1.メディアサーバーのいかなる発見は必要ありません：クライアントは、アウトオブバンド方式で、適切なメディアサーバーの情報で構成されています。
2. Discovery of media servers is required: clients use a discovery mechanism to determine a suitable media server that will be used for streaming multimedia message parts.
メディアサーバーの2発見が必要とされています。クライアントは、マルチメディアメッセージ部分をストリーミングするために使用される、適切なメディアサーバを決定するために検出メカニズムを使用します。
There are several scenarios where media server discovery would be a requirement for streaming to be successful:
メディアサーバーの発見が成功するためにストリーミングするための必要条件となり、いくつかのシナリオがあります。
o Client is not configured with the address of any media servers.
Oクライアントは、任意のメディアサーバーのアドレスで構成されていません。
o Client is configured with the address of one or more media servers, but the IMAP server is configured to only accept URLFETCH requests from specific media servers (for security or site policy reasons), and thus streaming would fail due to the media server not being able to retrieve the media from the IMAP server.
oクライアントは、1つ以上のメディアサーバのアドレスが設定されていますが、IMAPサーバにのみ（セキュリティまたはサイトポリシーの理由から）特定のメディアサーバーからのURLfetch要求を受け入れるように構成されているので、失敗していましストリーミングによるメディアサーバーがされていないとIMAPサーバからメディアを取り出すことができます。
There is also a scenario where media server discovery would improve the security of the streaming mechanism, by avoiding the use of completely anonymous URLs. For example, the client could discover a media server address that was an authorized user of the IMAP server for streaming purposes, which would allow the client to generate a URL, which was secure in that it could *only* be accessed by an entity that is trusted by the IMAP server to retrieve content. The issue of trust in media servers is discussed more fully in Section 4.
メディアサーバーの発見は完全に匿名のURLの使用を避けることにより、ストリーミング・メカニズムのセキュリティを改善するシナリオもあります。例えば、クライアントは、それは*だけ*そのエンティティによってアクセスすることができることで確保された、クライアントがURLを生成できるようになるストリーミングのために、IMAPサーバの正当なユーザであったメディアサーバのアドレスを発見することができコンテンツを取得するために、IMAPサーバーによって信頼されています。メディアサーバーの信頼性の問題は、第4章で詳しく説明されています。
This document describes using the IMAP METADATA [METADATA] extension, via the use of a server entry that provides the contact information for suitable media servers for use with the IMAP server. Media Server discovery is optional: clients are free to use pre-configured information about media servers, or to fall back to pre-configured information if they encounter IMAP servers that do not support either the METADATA extension or the proposed entry, or that do not provide a value for the entry.
この文書は、IMAPサーバとの使用に適したメディアサーバの連絡先情報を提供するサーバ・エントリの使用を介して、IMAPメタデータ[メタデータ]拡張を使用して記載されています。 Media Serverの発見はオプションです：クライアントは、メディアサーバーに関する事前構成された情報を使用して、またはそれらはメタデータ拡張や提案エントリのいずれかをサポートしていないIMAPサーバが発生した場合、バックあらかじめ設定された情報に落下する自由である、またはそれにはありませんエントリの値を提供します。
A METADATA entry with the name of "/shared/mediaServers" is used to store the locations of suitable media servers known to the IMAP server. The entry is formatted according to the formalSyntax specified in Section 8. This consists of a tuple of a URI and optional "stream" string, where the URI is surrounded by <> symbols, the URI and "stream" are separated using a colon ":", and tuples are separated using a ";".
「/共有/ mediaServers」の名前を持つメタデータエントリは、IMAPサーバに知られている、適切なメディアサーバーの場所を格納するために使用されます。エントリが第8これは、URIは、<>記号で囲まれているURIおよびオプションの「ストリーム」列のタプルから成りで指定formalSyntaxに従ってフォーマットされ、URIおよび「ストリーム」は「コロンを使用して分離されています： 『;」、およびタプルを使用して分離されています』。
The "stream" string (c.f. the "stream" access identifier from [ACCESSID]) is used to identify media servers capable of connecting to the IMAP server as users authorized to retrieve URLs constructed using the "stream" access identifier. It indicates that the client MUST create the content URI using the "stream" access identifier. See Section 3.3 for a description of how the client should make use of the access identifier when generating IMAP URLs.)
（[ACCESSID]から「ストリーム」アクセス識別子C.F.）「ストリーム」の文字列は、ユーザがURLを取得する権限を「ストリーム」アクセス識別子を使用して構成されたIMAPサーバに接続可能なメディアサーバーを識別するために使用されます。これは、クライアントが「ストリーム」アクセス識別子を使用してコンテンツURIを作成しなければならないことを示しています。 IMAP URLを生成するときに、クライアントがアクセス識別子を利用するべきかについての説明は、3.3節を参照してください。）
Example values of the /shared/mediaServers METADATA entry (N.B. Any line-wrapping below is for the purpose of clarity):
/共有/ mediaServersメタデータエントリの一例値（N.B.は、以下の任意の行折り返しを明確にする目的のためです）。
"<sip:ivr@ms.example.net:5060>:stream;<sip:annc@ ms1.example.net:5060>;<sips:ivr@ms2.example.net:5061>"
"<一口：ivr@ms.example.net：5060>：ストリーム; <一口：ANNC @ ms1.example.net:5060>; <一口：ivr@ms2.example.net：5061>"
"<sip:ivr@192.0.2.40:5060>;<sip:192.0.2.41:5060>;<sips:annc@ 192.0.2.42:5060>:stream"
"<一口：5060：ivr@192.0.2.40>; <一口：192.0.2.41：5060>; <一口：ANNCする@ 192.0.2.42:5060>:stream"
It should be noted that the URI specified in the ABNF (in Section 8) is generic, i.e., not restricted to SIP URIs; however, this document only specifies how to make use of SIP URIs. Additionally, the "userinfo" (known as the "service indicator" in RFC 4240 and RFC 4722) component of the URI is optional; if specified, it gives the client additional information about the media server capabilities. For example, a "userinfo" component of "annc" indicates that the media server supports RFC 4240, and "ivr" indicates support for RFC 4722. Section 3.4 further describes how clients should behave if the "userinfo" component is not present.
すなわち、SIP URIに限定されず、一般的なものでURI（セクション8）ABNFで指定されたことに留意すべきです。しかし、このドキュメントはSIP URIの使用を作成する方法を指定します。さらに、（RFC 4240及びRFC 4722の「サービスインジケータ」としても知られる）、「ユーザー情報」URIの構成要素は任意です。指定された場合、それは、メディアサーバ機能に関するクライアントの追加情報を提供します。たとえば、「ANNC」の「userinfoを」コンポーネントは、メディアサーバーがRFC 4240をサポートしていることを示し、「IVRは、」RFC 4722. 3.4のサポートは、さらに「userinfoを」コンポーネントが存在しない場合、クライアントがどのように振る舞うべきかを説明し示します。
Clients SHOULD parse the value of the /shared/mediaServers entry, and contact a media server using one of the returned URIs. The servers are returned in order of preference as suggested by the server; however, it is left to the client to decide if a different order is more appropriate when selecting the media server(s) to contact, as well as the selection of alternates under failure conditions.
クライアントは/共有/ mediaServersエントリの値を解析し、返されたURIのいずれかを使用して、メディアサーバーにお問い合わせください。サーバーによって示唆されているように、サーバは優先順に返されます。しかし、お問い合わせください、だけでなく、障害状態の下で交互に選択するために、メディアサーバ（複数可）を選択するときに異なる順序がより適切であるかどうかを判断するために、クライアントに残されています。
Administrators configuring the values of the /shared/mediaServers entry, who do not know the capabilities of the media servers being configured, SHOULD NOT include a "userinfo" component as part of the URI. In that case, the client will determine which service to use as specified in Section 3.4. Note that if a media server supports multiple services, a URI with the appropriate userinfo component SHOULD be configured for each service.
設定されているメディアサーバーの能力を知らない/共有/ mediaServersエントリの値を設定、管理者は、URIの一部として「userinfoを」コンポーネントを含めるべきではありません。その場合、クライアントは、3.4節で指定されるように使用するサービスを決定します。メディアサーバが複数のサービスをサポートしている場合は、適切なのUserInfoコンポーネントを持つURIは、各サービスのために設定する必要があることに注意してください。
Note that even though the media server address can be discovered dynamically, it is assumed that the necessary security arrangements between the client and the media server already exist. For example, the media server could use SIP digest authentication to provide access only to authenticated clients; in this case, it is assumed the username and password have already been set up. Likewise, if the client wants to authenticate the media server using, e.g., TLS and certificates, it is assumed the necessary arrangements (trust anchors and so on) already exist. In some deployments, the clients and media servers may even be willing to rely on the security of the underlying network, and omit authentication between the client and the media server entirely. See Section 4 for more details.
メディアサーバアドレスが動的に検出できたとしても、クライアントとメディアサーバとの間で必要な安全保障体制がすでに存在していることを前提としていることに注意してください。例えば、メディアサーバは、認証されたクライアントのみへのアクセスを提供するために、SIPダイジェスト認証を使用することができます。この場合には、ユーザ名とパスワードが既に設定されていると想定されます。クライアントが使用してメディアサーバーを認証したい場合は同様に、例えば、TLSおよび証明書は、必要な手配（ようにトラストアンカーとは）すでに存在していると想定されます。いくつかの展開では、クライアントとメディアサーバーでも、基盤となるネットワークのセキュリティに依存することをいとわない、と完全にクライアントとメディアサーバー間の認証を省略することができます。詳細は、4章を参照してください。
The decision to make use of streaming services for a message part will usually be predicated on the content type of the message part. Using the capabilities of the IMAP FETCH command, clients determine the MIME [MIME] Content-Type of particular message parts, and based on local policies or heuristics, they decide whether streaming for that message part will be attempted.
メッセージパーツのストリーミングサービスを利用するという決定は、通常、メッセージ部分のコンテンツタイプを前提されます。 IMAPの能力FETCHコマンドをを使用して、クライアントが特定のメッセージ部分のMIME [MIME]コンテンツタイプを決定し、ローカルポリシーや経験則に基づいて、彼らはそのメッセージ部分のためのストリーミングが試行されるかどうかを決定します。
Once the client has determined that a particular message part requires streaming, the client generates an IMAP URL that refers to the message part according to the method described in RFC 5092 [IMAPURL]. The client then begins the process of generating an URLAUTH URL by appending ";EXPIRE=<datetime>" and ";URLAUTH=<access>" to the initial URL.
クライアントが特定のメッセージ部分は、ストリーミングを必要とすることを決定すると、クライアントは、RFC 5092 [IMAPURL]に記載の方法に従って、メッセージ部分を指すIMAP URLを生成します。その後、クライアントは追加することによって、URLAUTHのURLを生成するプロセスを開始します「; EXPIRE = <日時>」と「; URLAUTH = <アクセス>」初期URLに。
The ";EXPIRE=<datetime>" parameter is optional; however, it SHOULD be used, since the use of anonymous URLAUTH-authorized URLs is a security risk (see Section 4), and it ensures that at some point in the future, permission to access that URL will cease. IMAP server implementors may choose to reject anonymous URLs that are considered insecure (for example, with an EXPIRE date too far in the future), as a matter of local security policy. To prevent this from causing interoperability problems, IMAP servers that implement this profile MUST NOT reject GENURLAUTH commands for anonymous URLs on the basis of the EXPIRE time, if that time is equal to, or less than, 1 hour in the future.
"; EXPIRE = <日時>" パラメータはオプションです。匿名URLAUTH許可するURLの使用は、セキュリティ上のリスク（第4節を参照）であり、それは将来のある時点で、そのURLにアクセスするための権限が停止することを保証しますので、しかし、それは、使用されるべきです。 （あまりにも遠い将来の日付を期限切れにして、例えば）IMAPサーバの実装は、ローカルセキュリティポリシーの問題として、安全ではないと考えられている匿名のURLを拒否することもできます。相互運用性の問題を引き起こしてからこれを防ぐために、このプロファイルを実装するIMAPサーバは、その時は、将来的に1時間に等しいか、それより小さい場合GENURLAUTHは、EXPIRE時間に基づいて匿名のURLのコマンド拒絶してはなりません。
The <access> portion of the URLAUTH URL MUST be 'stream' (see [ACCESSID]) if an out-of-band mechanism or the media server discovery mechanism discussed in Section 3.2 specifies that the media server is an authorized user of the IMAP server for the purposes of retrieving content via URLFETCH. Without specific prior knowledge of such a configuration (either through the discovery mechanism described in this document, or by an out-of-band mechanism), the client SHOULD use the 'stream' access identifier, which will cause streaming to fail if the media server is not an authorized user of the IMAP server for the purposes of streaming.
<アクセス> 3.2節で論じアウトオブバンド機構又はメディアサーバー発見メカニズムは、メディアサーバは、IMAPの正当なユーザであることを指定する場合URLAUTH URLの部分は、「ストリーム」（[ACCESSID]参照）でなければなりませんUrlFetchのを介してコンテンツを取得する目的のためのサーバー。 （この文書で説明発見機構を介して、またはアウトオブバンドメカニズムのいずれかによって）このような構成の具体的な事前の知識がないと、クライアントは、メディア場合に失敗するストリーミング原因となります「ストリーム」のアクセス識別子を使用してくださいサーバーは、ストリーミングの目的で、IMAPサーバの許可されたユーザではありません。
However, if the client wishes to take the risk associated with generating a URL that can be used by any media server (see Section 4), it MAY use 'anonymous' as the <access> portion of the URLAUTH URL passed to the GENURLAUTH command. For example, the client may have been pre-configured with the address of media servers in the local administrative domain (thus implying a level of trust in those media servers), without knowing whether those media servers have a pre-existing trust relationship with the IMAP server to be used (which may well be in a different administrative domain). See Section 4 for a full discussion of the security issues.
クライアントが（セクション4を参照）任意のメディアサーバーで使用可能なURLを生成することに関連するリスクを取ることを望む場合URLAUTH URLの<アクセス>の部分はGENURLAUTHコマンドに渡さしかし、それは匿名 'を使用してもよい（MAY） 。例えば、クライアントは、それらのメディアサーバーが持つ既存の信頼関係を持っているかどうかを知らなくても、（したがって、それらのメディアサーバーに信頼のレベルを意味している）ローカル管理ドメイン内のメディア・サーバのアドレスを事前に設定されている可能性があり使用するIMAPサーバ（ウェル異なる管理ドメインであってもよいです）。セキュリティ問題の完全な議論については、セクション4を参照してください。
The client uses the URL generated as a parameter to the GENURLAUTH command, using the INTERNAL authorization mechanism. The URL returned by a successful response to this command will then be passed to the media server. If no successful response to the GENURLAUTH command is received, then no further action will be possible with respect to streaming media to the client.
クライアントは、内部の認証メカニズムを使用して、GENURLAUTHコマンドのパラメータとして生成されたURLを使用しています。このコマンドに成功したレスポンスによって返されたURLは、メディアサーバに渡されます。 GENURLAUTHコマンドへの成功応答が受信されない場合、それ以上のアクションがクライアントにストリーミングメディアに関して可能になることはありません。
Examples:
例：
C: a122 UID FETCH 24356 (BODYSTRUCTURE)
S: * 26 FETCH (BODYSTRUCTURE (("TEXT" "PLAIN"
S: ("CHARSET" "US-ASCII") NIL
S: NIL "7BIT" 1152 23)("VIDEO" "MPEG"
NIL NIL "BASE64" 655350)) UID 24356)
S: a122 OK FETCH completed.
C: a123 GENURLAUTH "imap://joe@example.com/INBOX/;uid=24356/;
section=1.2;expire=2006-12-19T16:39:57-08:00;
urlauth=anonymous" INTERNAL
S: * GENURLAUTH "imap://joe@example.com/INBOX/;uid=24356/;
section=1.2;expire=2006-12-19T16:39:57-08:00;
urlauth=anonymous:
internal:238234982398239898a9898998798b987s87920"
S: a123 OK GENURLAUTH completed
C: a122 UID FETCH 24359 (BODYSTRUCTURE)
S: * 27 FETCH (BODYSTRUCTURE (("TEXT" "PLAIN"
S: ("CHARSET" "US-ASCII") NIL
S: NIL "7BIT" 1152 23)("AUDIO" "G729"
NIL NIL "BASE64" 87256)) UID 24359)
S: a122 OK FETCH completed.
C: a123 GENURLAUTH "imap://joe@example.com/INBOX/;uid=24359/;
section=1.3;expire=2006-12-19T16:39:57-08:00;
urlauth=stream" INTERNAL
S: * GENURLAUTH "imap://joe@example.com/INBOX/;uid=24359/;
section=1.3;expire=2006-12-20T18:31:45-08:00;
urlauth=stream:
internal:098230923409284092384092840293480239482"
S: a123 OK GENURLAUTH completed
Once an authorized IMAP URL has been generated, it is up to the client to pass that URL to a suitable media server that is capable of retrieving the URL via IMAP, and streaming the content to the client using the RTP [RTP] protocol.
許可されたIMAPのURLが生成されたら、それはIMAP経由でURLを取得し、RTP [RTP]プロトコルを使用してクライアントにコンテンツをストリーミングすることができ、適切なメディアサーバーにそのURLを渡すために、クライアント次第です。
This section specifies the behavior of clients that have not determined (either statically through configuration, or dynamically through a discovery process as discussed in Section 3.2), the capabilities of the media server with respect to the services (i.e., RFC 4240 or 5022) supported by that media server. Clients that have determined those capabilities should use the mechanisms described in Sections 3.5 or 3.7, as appropriate.
このセクションでは、サービスに関しては、メディアサーバの機能（すなわち、RFC 4240または5022）サポート、（3.2節で述べたように、静的な構成を通して、または動的に発見プロセスを通じてのいずれか）を決定していないクライアントの動作を指定しますそのメディアサーバーによって。これらの機能を決定したクライアントは、必要に応じて、セクション3.5または3.7に記載のメカニズムを使用しなければなりません。
If the client supports the MSCML IVR service, then it SHOULD attempt to contact the media server using the MSCML protocol by sending a SIP INVITE that has the service indicator "ivr".
クライアントはMSCML IVRサービスをサポートしている場合、それはそれはサービスインジケータ「IVR」を持って、SIP INVITEを送信することにより、MSCMLプロトコルを使用して、メディアサーバーに接続を試みる必要があります。
Assuming the media server responds to the INVITE without error, the client can carry on using the MSCML IVR service as specified in Section 3.7. If the media server responds with an error indicating that the "ivr" service is not supported, then if the client supports it, the client SHOULD attempt to contact the media server using the announcement service, as described in Section 3.5.
メディア・サーバがエラーなしでINVITEに応答と仮定すると、クライアントは、3.7節に指定されているMSCML IVRサービスを使用して運ぶことができます。メディアサーバーは、「IVR」サービスがサポートされていないことを示すエラーで応答した場合、クライアントはそれをサポートしていれば、その後、クライアントは、セクション3.5で説明したように、アナウンスメントサービスを使用して、メディアサーバーに接続を試みる必要があります。
The following example shows an example SIP INVITE using the "ivr" service indicator:
次の例は、例では、「IVR」サービスインジケータを使用して、SIP INVITEを示しています。
C: INVITE sip:ivr@ms2.example.com SIP/2.0 < SIP Header fields omitted for reasons of brevity >
C：INVITE SIP：ivr@ms2.example.com SIP / 2.0 <簡潔のために省略SIPヘッダフィールド>
Assuming the client or media server does not support use of the MSCML protocol, the media server announcement service is used, as described in RFC 4240 [NETANN]. This service allows the client to send a SIP INVITE to a special username ('annc') at the media server (the "announcement" user), supplying the URL obtained as per Section 3.3.
RFC 4240 [NETANN]で説明したようにMSCMLプロトコルの使用をサポートしていないクライアントまたはメディアサーバーを想定すると、メディアサーバーのアナウンスサービスは、使用されています。このサービスは、クライアントが3.3節ごとのようにして得られたURLを供給、メディアサーバ（「告知」のユーザー）で特別なユーザー名（「ANNC」）に、SIP INVITEを送信することができます。
The SIP INVITE is constructed as shown in the examples below; note that as per RFC 4240, the play parameter is mandatory and specifies the authorized IMAP URL to be played.
以下の実施例に示すように、SIP INVITEが構成されています。 RFC 4240に従って、プレイパラメータが必須であり、再生することが許可されたIMAPのURLを指定することに注意してください。
Examples of valid SIP INVITE URIs sent to the media server announcement service:
有効なSIPの例としては、URIは、メディアサーバーのアナウンスサービスに送信されたINVITE：
C: sip:annc@ms2.example.net; play=imap:%2F%2Fjoe@example.com%2FINBOX%2F%3Buid%3D24356%2F%3Bsection %3D1.2%3Bexpire%3D2006-12-19T16:39:57-08:00%3Burlauth%3Danonymous: internal:238234982398239898a9898998798b987s87920
C：SIP：annc@ms2.example.net。プレイ= IMAP：%2F%2Fjoe@example.com%2FINBOX%2F%3Buid%3D24356%2F%3Bsection％3D1.2％3Bexpire％3D2006-12-19T16：39：57から08：00％3Burlauth％3Danonymous：内部：238234982398239898a9898998798b987s87920
C: sip:annc@ms1.example.net; play=imap:%2F%2Ffred@ example.com%2FINBOX%2F%3Buid%3D24359%2F%3Bsection %3D1.3%3Bexpire%3D2006-12-20T18:31:45-08:00%3Burlauth%3Dstream: internal:098230923409284092384092840293480239482
C：SIP：annc@ms1.example.net。遊び= IMAP：％2F％2Ffred @ example.com％2FINBOX％2F％3Buid％3D24359％2F％3Bsection％3D1.3％3Bexpire％3D2006-12-20T18：31：45から08：00％3Burlauth％3Dstream：内部：098230923409284092384092840293480239482
Notice that many of the characters that are used as parameters of the IMAP URI are escaped, as otherwise they would change the meaning of the enclosing SIP URI, by being regarded as SIP URI parameters instead of IMAP URL parameters.
そうでない場合は、彼らが囲むSIP URIの意味が変わってしまうようIMAP URIのパラメータとして使用される文字の多くは、代わりにIMAPのURLパラメータのSIP URIパラメータと見なされることによって、エスケープされていることに注意してください。
If the client receives a 200 (OK) response, the media server has successfully retrieved the content from the IMAP server and the negotiated RTP stream will shortly begin.
クライアントは200（OK）応答を受信した場合、メディアサーバーはIMAPサーバからコンテンツを正常に取得しており、交渉さRTPストリームがまもなく開始されます。
There are many possible response codes; however, a response code of 404 received from the media server indicates that the content could not be found or could not be retrieved for some reason. For example, the media server may not support the use of IMAP URLs. At this point, there are several options to the client, such as using alternate media servers, or giving up in attempting to stream the required message part.
多くの可能な応答コードがあります。しかしながら、メディアサーバから受信した404の応答コードは、コンテンツが見つからなかったか、何らかの理由で取得できなかったことを示しています。例えば、メディアサーバはIMAP URLの使用をサポートしない場合があります。この時点では、そのような代替メディアサーバーを使用して、または必要なメッセージ部分をストリーミングしようとする中で諦めとしてクライアントにいくつかのオプションがあります。
This document uses standards and protocols from two traditionally separate application areas: Mobile Email (primarily IMAP) and Internet Telephony/Streaming (e.g., SIP/RTP). Since the document primarily addresses enhancing the capabilities of mobile email, it is felt worthwhile to give some examples of simple SIP/SDP exchanges and to discuss capabilities such as media negotiation (using SDP) and media transcoding.
モバイルメール（主にIMAP）及びインターネット電話/ストリーミング（例えば、SIP / RTP）：この文書では、2つの伝統的に独立したアプリケーション分野からの規格とプロトコルを使用しています。携帯メールの能力を増強する文書主アドレスので、単純なSIP / SDP交換のいくつかの例を与えるために、そのような（SDPを使用して）、メディア交渉と、メディアトランスコーディングなどの機能を議論する価値が感じられます。
In the below example, the client contacts the media server using the SIP INVITE command to contact the announcement service (see Section 3.5), advertising support for a range of audio and video codecs (using SDP [SDP]), and in response the media server advertises only a set of audio codecs. This process is identical for the IVR service, except that the IVR service does not use the SIP Request-URI to indicate the content to be played; instead, this is carried in a subsequent SIP INFO request.
以下の例では、アナウンスメントサービスに連絡するコマンドを、SIP INVITEを使用してクライアントの連絡先メディアサーバは、それに応答して、メディア（SDP [SDP]を使用）、オーディオおよびビデオコーデックの範囲のために、広告サポート（3.5節を参照してください）サーバーは、オーディオコーデックのセットのみをアドバタイズします。このプロセスは、IVRサービスは、再生するコンテンツを示すために、SIPリクエスト-URIを使用していないことを除いて、IVRサービスのために同じです。代わりに、これは、その後のSIP INFOリクエストで運ばれます。
The client and server now know from the SDP session description advertised by both client and server that communication must be using the subset of audio codecs supported by both client and server (in the example SDP session description below, it is clear that the server does not support any video codecs). The media server may perform transcoding (i.e., converting between codecs) on the media received from the IMAP server in order to satisfy the codecs supported by the client. For example, the media server may downgrade the video retrieved from the IMAP server to the audio component only.
クライアントとサーバが、今の通信は以下の例のSDPセッション記述では、クライアントとサーバーの両方でサポートされているオーディオコーデックのサブセットを（使用している必要があり、クライアントとサーバーの両方によってアドバタイズSDPセッション記述から知っている、サーバがないことは明らかです）任意のビデオコーデックをサポートしています。メディアサーバは、メディア上のトランスコーディング（すなわち、コーデック間の変換）を実行することができるクライアントによってサポートされるコーデックを満たすためにIMAPサーバから受信しました。例えば、メディアサーバは、オーディオコンポーネントにIMAPサーバから取得した映像をダウングレードしてもよいです。
For clients using the announcement service, the media server MUST return an error to the INVITE if it cannot find a common codec between the client, server and media, or it cannot transcode to a suitable codec. Similarly, for clients using the MSCML IVR service, the media server MUST return a suitable error response to the <playcollect> request.
それは、クライアント、サーバーとメディアの間で共通のコーデックを見つけることができない場合は告知サービスを使用してクライアントの場合、メディアサーバは、INVITEにエラーを返さなければならない、またはそれは、適切なコーデックにトランスコードすることはできません。同様に、MSCML IVRサービスを使用しているクライアントのために、メディアサーバは<playcollect>要求に適切なエラー応答を返さなければなりません。
Example SIP INVITE and SDP Media Negotiation
例SIPは、INVITEとSDPメディアネゴシエーション
C: INVITE sip:annc@ms2.example.com; play=imap:%2F%2Fjoe@example.com%2FINBOX%2F%3Buid%3D24356%2F%3B section%3D1.2%3Bexpire%3D2006-12-19T16:39:57-08:00%3Burlauth%3D anonymous:internal:238234982398239898a9898998798b987s87920 SIP/2.0 C: From: UserA <sip:UAA@example.com> C: To: NetAnn <sip:annc@ms2.example.com> C: Call-ID: 8204589102@example.com C: CSeq: 1 INVITE C: Contact: <sip:UAA@192.0.2.40> C: Content-Type: application/sdp C: Content-Length: 481 C: C: v=0 C: o=UserA 2890844526 2890844526 IN IP4 192.0.2.40 C: s=Session SDP C: c=IN IP4 192.0.2.40 C: t=3034423619 0 C: m=audio 9224 RTP/AVP 0 8 3 98 101 C: a=alt:1 1 : 01BB7F04 6CBC7A28 192.0.2.40 9224 C: a=fmtp:101 0-15 C: a=rtpmap:98 ilbc/8000 C: a=rtpmap:101 telephone-event/8000 C: a=recvonly C: m=video 9226 RTP/AVP 105 34 120 C: a=alt:1 1 : 01BCADB3 95DFFD80 192.0.2.40 9226 C: a=fmtp:105 profile=3;level=20 C: a=fmtp:34 CIF=2 QCIF=2 MAXBR=5120 C: a=rtpmap:105 h263-2000/90000 C: a=rtpmap:120 h263/90000 C: a=recvonly
C：SIP INVITE：annc@ms2.example.comを。 = IMAPを果たし：%2F%2Fjoe@example.com%2FINBOX%2F%3Buid%3D24356%2F%3Bセクション％3D1.2％3Bexpire％3D2006-12-19T16：39：57から08：00％3Burlauth％の3D匿名：内部：238234982398239898a9898998798b987s87920 SIP / 2.0 C：から：ユーザーA <SIP：UAA@example.com> C：TO：NetAnn <SIP：annc@ms2.example.com> C：コールID：8204589102@example.com C： CSeq：連絡先：：<SIP：UAA@192.0.2.40> C：のContent-Type：アプリケーション/ SDP C：のContent-Length：481 C：C：V = 0 C：IP4 192.0中のO =ユーザーA 2890844526 2890844526 Cを1 INVITE .2.40 C：S =セッションSDP C：C = IP4 192.0.2.40 C IN：T = 3034423619 0 C：M =オーディオ9224 RTP / AVP 0 8 3 98 101 C：= ALT：1~1：01BB7F04 6CBC7A28 192.0。 2.40 9224 C：=のfmtp：101 0-15 C：= rtpmap：98 iLBCの/ 8000 C：= rtpmap：101電話イベント/ 8000 C：A = recvonlyでC：M =ビデオ9226 RTP / AVP 105 34 120 C：= ALT：1~1：01BCADB3 95DFFD80 192.0.2.40 9226 C：=のfmtp：105プロファイル= 3;レベル= 20 C：=のfmtp：34 CIF = 2 QCIF = 2 MAXBR = 5120 C：= rtpmap：105 h263-2000 / 90000 C：= rtpmap：120 H263 / 90000 C：A = recvonlyで
S: SIP/2.0 200 OK S: From: UserA <sip:UAA@example.com> S: To: NetAnn <sip:annc@ms2.example.com> S: Call-ID: 8204589102@example.com S: CSeq: 1 INVITE S: Contact: <sip:netann@192.0.2.41> S: Content-Type: application/sdp S: Content-Length: 317 S: S: v=0 S: o=NetAnn 2890844527 2890844527 IN IP4 192.0.2.41 S: s=Session SDP S: c=IN IP4 192.0.2.41 S: t=3034423619 0 S: m=audio 17684 RTP/AVP 0 8 3 18 98 101
S：SIP / 2.0 200 OK S：から：ユーザーA <SIP：UAA@example.com> S：TO：NetAnn <SIP：annc@ms2.example.com> S：コールIDを：8204589102@example.com S： CSeq：1 SをINVITE：連絡先：<SIP：netann@192.0.2.41> S：コンテンツタイプ：アプリケーション/ SDP S：コンテンツの長さ：317 S：S：V = 0 S：IP4 192.0、IN NetAnn 2890844527 2890844527 = O .2.41 S：S =セッションSDP S：C = IP4 IN 192.0.2.41 S：T = 3034423619の0 S：M =オーディオ17684 RTP / AVP 0 8 3 18 98 101
S: a=rtpmap:0 PCMU/8000 S: a=rtpmap:8 PCMA/8000 S: a=rtpmap:3 GSM/8000 S: a=rtpmap:18 G729/8000 S: a=fmtp:18 annexb=no S: a=rtpmap:98 iLBC/8000 S: a=rtpmap:101 telephone-event/8000 S: a=fmtp:101 0-16
S：= rtpmap：0 PCMU / 8000 S：= rtpmap：8 PCMA / 8000 S：= rtpmap：3 GSM / 8000 S：= rtpmap：18 G729 / 8000 S：=のfmtp：18 annexb = NO S：= rtpmap：98 iLBCの/ 8000 S：= rtpmap：101電話イベント/ 8000 S：=のfmtp：101 0~16
C: ACK sip:netann@192.0.2.41 SIP/2.0 C: From: UserA <sip:UAA@example.com> C: To: NetAnn <sip:annc@ms2.example.com> C: Call-ID: 8204589102@example.com C: CSeq: 1 ACK C: Content-Length: 0
C：ACKをSIP：netann@192.0.2.41 SIP / 2.0 C：から：ユーザーA <SIP：UAA@example.com> C：TO：NetAnn <SIP：annc@ms2.example.com> C：コールID：8204589102 @ example.com C：のCSeq：1 ACK C：のContent-Length：0
Once the client has determined that the media server supports the IVR service, it is up to the client to generate a suitable MSCML request to initiate streaming of the required media.
クライアントは、メディアサーバがIVRサービスをサポートすることを決定したら、それは必要なメディアのストリーミングを開始するために、適切なMSCML要求を生成するクライアント次第です。
When using the IVR service, the initial SIP invite is used only to establish that the media server supports the MSCML IVR service, and to negotiate suitable media codecs. Once the initial SIP INVITE and response to that INVITE have been completed successfully, the client must generate a SIP INFO request with MSCML in the body of the request to initiate streaming.
IVRサービスを使用する場合は、最初のSIPは招待のみメディアサーバがMSCML IVRサービスをサポートしていることを確立すること、および、適切なメディアコーデックを交渉するために使用されます。最初のSIP INVITEをし、それに対する応答が正常に完了したINVITEたら、クライアントは、ストリーミングを開始する要求のボディにMSCMLとSIP INFO要求を生成する必要があります。
The <playcollect> request is used, as this allows the use of dual tone multi-frequency (DTMF) digits to control playback of the media, such as fast-forward or rewind.
このような早送りや巻き戻しなどのメディアの再生を制御するために、デュアルトーン多重周波数（DTMF）数字の使用を可能にするように<playcollect>要求は、使用されます。
Since the <playcollect> request is used purely for its VCR-like capabilities, there is no need for the media server to perform DTMF collection. Therefore, the playcollect attributes "firstdigittimer", "interdigittimer", and "extradigittimer" SHOULD all be set to "0ms", which will have the effect of causing digit collection to cease immediately after the media has finished playing.
<playcollect>要求はそのVCRのような機能のために純粋に使用されているので、DTMFコレクションを実行するメディアサーバーは必要ありません。したがって、playcollectは「firstdigittimer」、「interdigittimerを」属性、および「extradigittimer」すべては、メディアの再生が終了した後に数字収集がすぐに中止させるという効果があります「は0ms」に設定してください。
The "ffkey" and "rwkey" attributes of <playcollect> are used to control fast-forward and rewind behavior, with the "skipinterval" attribute being used to control the 'speed' of these actions.
「ffkey」との「rwkey」属性<playcollect>「skipinterval」属性は、これらのアクションの「速さ」を制御するために使用された状態で、早送り制御し、行動を巻き戻すために使用されています。
The <prompt> tag is used to specify the media to be played, and SHOULD have a single <audio> tag that gives the URL of the media, as per the Section 3.3. The audio-specific name of the tag is historical, as the tag can be used for video as well as audio content. The "stoponerror" attribute SHOULD be set to "yes", so that meaningful error messages will be returned by the media server in the event of problems such as retrieving the media from the IMAP server.
<プロンプト>タグは、再生するメディアを指定するために使用され、そして3.3節に従って、メディアのURLを与える単一の<audio>タグがあるはずです。タグは、ビデオならびにオーディオコンテンツのために使用することができるように、タグのオーディオ固有の名前は、歴史的です。意味のあるエラーメッセージは、IMAPサーバからメディアを取り出すなどの問題が発生した場合に、メディアサーバによって返されるように、「STOPONERROR」属性は、「はい」に設定する必要があります。
An example SIP INFO request using the <playcollect> request is shown at the end of this section.
<playcollect>要求を使用して、例えばSIP INFO要求は、このセクションの最後に示されています。
It should be noted that under normal (i.e., non-error) conditions, the response to the <playcollect> request is a SIP 200 (OK) response. The media server then streams the media, and only when the media has finished playing (naturally or due to a user request) does the media server send a <playcollect> response, which includes details of the media played, such as length and any digits collected.
正常（すなわち、非エラー）の条件下で、<playcollect>要求に対する応答は、SIP 200（OK）応答であることに留意すべきです。メディアサーバは、メディアストリーム、メディアは、メディアサーバは、メディアの詳細を含む<playcollect>応答を送信しない（天然又はによるユーザ要求に）再生が終了した場合にのみ、そのような長さと任意の数字として、再生しました集めました。
The client may suspend playback of the media at any time by either sending the DTMF escape key (specified as an attribute to the <playcollect> request) or by sending a <stop> request to the media server in a SIP INFO request. Upon receipt of the request, the media server will acknowledge it, and then cease streaming of the media, followed by a SIP INFO request containing the <playcollect> response.
クライアントは、どちらかが（<playcollect>リクエストの属性として指定された）DTMFエスケープキーを送信することによって、またはSIP INFO要求におけるメディアサーバに<停止>要求を送信することにより、任意の時点でメディアの再生を停止することができます。要求を受信すると、メディアサーバは<playcollect>応答を含むSIP INFO要求に続いて、それを確認した後、メディアのストリーミングを停止します。
If the media server cannot play the media for any reason (for example, if it cannot retrieve the media from the IMAP server), streaming will not take place, and the <playcollect> response will be sent, usually with meaningful values in the <error_info> element.
メディアサーバが何らかの理由（例えば、それはIMAPサーバからメディアを取り出すことができない場合）のためのメディアを再生できない場合は、ストリーミングは行われないだろう、と<playcollect>応答は、通常、<で意味のある値で、送信されますERROR_INFO>要素。
The following gives an example dialog between a client and media server, including a rewind request, and termination of the playback by use of the escape key. Some elements of the SIP dialog such as full SIP header fields and SDP are omitted for reasons of brevity. (The protocol diagram in Section 3.9.2 shows the high-level message flow between all the components, including the IMAP server.)
以下は、例えば、エスケープキーを使用することにより、再生の巻き戻し要求、および終了を含め、クライアントとメディアサーバーの間の対話を提供します。そのような完全なSIPヘッダフィールドおよびSDPなどのSIPダイアログのいくつかの要素は、簡潔のために省略されています。 （セクション3.9.2のプロトコル図は、IMAPサーバを含むすべてのコンポーネント間のハイレベル・メッセージ・フローを示します。）
C: INVITE sip:ivr@ms.example.com SIP/2.0 C: From: UserA <sip:UAA@example.com> C: To: IVR <sip:ivr@ms.example.com> C: Call-ID: 3298420296@example.com C: CSeq: 1 INVITE C: Contact: <sip:UAA@192.0.2.40> C: Content-Type: application/sdp C: Content-Length: XXX C: C: <SDP Here>
C：ivr@ms.example.com SIP / 2.0 C：から：ユーザーA <SIP：UAA@example.com> C：TO：IVR <SIP：ivr@ms.example.com> C：コールID SIPのINVITE ：3298420296@example.com C：のCSeq：連絡先：：<SIP：UAA@192.0.2.40> C：のContent-Type：アプリケーション/ SDP C：のContent-Length：XXX C：C：<ここにSDP> Cを1 INVITE
S: SIP/2.0 200 OK S: From: UserA <sip:UAA@example.com> S: To: IVR <sip:ivr@ms.example.com> S: Call-ID: 3298420296@example.com
S：SIP / 2.0 200 OK S：から：ユーザーA <SIP：UAA@example.com> S：TO：IVR <SIP：ivr@ms.example.com> S：コールID：3298420296@example.com
S: CSeq: 1 INVITE S: Contact: <sip:ivr@192.0.2.41> S: Content-Type: application/sdp S: Content-Length: XXX S: S: <SDP Here>
S：のCSeq：1 S INVITE：連絡先を：<SIP：ivr@192.0.2.41> S：コンテンツタイプ：コンテンツ長：：XXX S：/ SDP SアプリケーションS：<ここにSDP>
C: ACK sip:ivr@ms.example.com SIP/2.0 C: From: UserA <sip:UAA@example.com> C: To: IVR <sip:ivr@ms2.example.com> C: Call-ID: 3298420296@example.com C: CSeq: 1 ACK C: Content-Length: 0
C：ACK SIP：ivr@ms.example.com SIP / 2.0 C：から：ユーザーA <SIP：UAA@example.com> C：TO：IVR <SIP：ivr@ms2.example.com> C：コールID ：3298420296@example.com C：のCSeq：1 ACK C：のContent-Length：0
C: INFO sip:ivr@192.0.2.41 SIP/2.0 C: From: UserA <sip:UAA@example.com> C: To: IVR <sip:ivr@ms.example.com> C: Call-ID: 3298420296@example.com C: CSeq: 2 INFO C: Content-Type: application/mediaservercontrol+xml C: Content-Length: 423 C: C: <?xml version="1.0"?> C: <MediaServerControl version="1.0"> C: <request> C: <playcollect id="332985001" C: firstdigittimer="0ms" interdigittimer="0ms" extradigittimer="0ms" C: skipinterval="6s" ffkey="6" rwkey="4" escape="*"> C: <prompt stoponerror="yes" C: locale="en_US" offset="0" gain="0" rate="0" C: delay="0" duration="infinite" repeat="0"> C: <audio url="imap://joe@example.com/INBOX/;uid=24356/;section=1.2; expire=2006-12-19T16:39:57-08:00;urlauth=anonymous: internal:238234982398239898a9898998798b987s87920"/> C: </prompt> C: </playcollect> C: </request> C: </MediaServerControl>
C：INFO一口：ivr@192.0.2.41 SIP / 2.0 C：から：ユーザーA <SIP：UAA@example.com> C：TO：IVR <SIP：ivr@ms.example.com> C：コールID：3298420296 @ example.com C：のCSeq：2 INFO C：のContent-Type：アプリケーション/ mediaservercontrol + XMLのC：のContent-Length：423 C：C：<？xmlのバージョン= "1.0"> C：<MediaServerControlバージョン= "1.0 "> C <要求> C <playcollect ID =" 332985001" C：firstdigittimer = "は0ms" interdigittimer = "は0ms" extradigittimer = "は0ms" C：skipinterval = "6S" ffkey = "6" rwkey = "4"エスケープ= "*"> C：<プロンプトSTOPONERROR = "はい" C：ロケール= "en_USの" オフセット= "0"、ゲイン= "0" 率= "0" C：遅延= "0" 期間= "無限" の繰り返し= "0"> C <オーディオURL = "IMAP：//joe@example.com/INBOX/; UID = 24356 /;セクション= 1.2;期限切れ= 2006-12-19T16：39：57から08：00。 urlauth =匿名：内部：238234982398239898a9898998798b987s87920" /> C </プロンプト> C </ playcollect> C </リクエスト> C </ MediaServerControl>
S: SIP/2.0 200 OK S: From: UserA <sip:UAA@example.com> S: To: IVR <sip:ivr@ms.example.com> S: Call-ID: 3298420296@example.com S: CSeq: 2 INFO S: Contact: <sip:ivr@192.0.2.41> S: Content-Length: 0
S：SIP / 2.0 200 OK S：から：ユーザーA <SIP：UAA@example.com> S：TO：IVR <SIP：ivr@ms.example.com> S：コールIDを：3298420296@example.com S： CSeq：2 INFO S：連絡先：<SIP：ivr@192.0.2.41> S：コンテンツ長：0
S: <Media server retrieves media from IMAP server and streams to client>
S：<メディアサーバーはIMAPサーバからメディアを取得し、クライアントにストリーム>
C: <Client streams 6 key>
C：<クライアントは6キーストリーム>
S: <Media Server fast forwards media by 6 seconds>
S：<6秒によるメディアサーバー早送りメディア>
C: <Client streams * key>
C：<クライアントは*ストリームキー>
S: <Media Server stops streaming>
S：<メディアサーバーがストリーミングを停止します>
S: INFO sip:UAA@192.0.2.40 SIP/2.0 S: From: IVR <sip:ivr@ms.example.com> S: To: UserA <sip:UAA@example.com> S: Call-ID: 3298420296@example.com S: CSeq: 5 INFO S: Contact: <sip:ivr@192.0.2.41> S: Content-Type: application/mediaservercontrol+xml S: Content-Length: XXX S: S: <?xml version="1.0"?> S: <MediaServerControl version="1.0"> S: <response id="332985001" request="playcollect" code="200" S: reason="escapekey" playduration="34s" S: playoffset="34s" digits="" /> S: </MediaServerControl>
S：INFO一口：UAA@192.0.2.40 SIP / 2.0 S：から：IVR <SIP：ivr@ms.example.com> S：TO：ユーザーA <SIP：UAA@example.com> S：コールID：3298420296 @ example.com S：のCSeq：5 INFO S：連絡先：<SIP：ivr@192.0.2.41> S：コンテンツタイプ：アプリケーション/ mediaservercontrol +のxml S：コンテンツ長：XXX S：Sます。<？xml version = "1.0"> S <？MediaServerControlバージョン= "1.0"> S <応答ID = "332985001" リクエスト= "playcollect" コード= "200" S：理由= "escapekey" playduration = "34S" S：playoffset = "34S" の数字= "" /> S：</ MediaServerControl>
C: SIP/2.0 200 OK C: From: IVR <sip:ivr@ms.example.com> C: To: UserA <sip:UAA@example.com> C: Call-ID: 3298420296@example.com C: CSeq: 5 INFO C: Content-Length: 0
C：SIP / 2.0 200 OK C：から：IVR <SIP：ivr@ms.example.com> C：TO：ユーザーA <SIP：UAA@example.com> C：コールID：3298420296@example.com C： CSeq：5 INFO C：のContent-Length：0
C: BYE sip:ivr@192.0.2.41 SIP/2.0 C: From: UserA <sip:UAA@example.com> C: To: IVR <sip:ivr@ms.example.com> C: Call-ID: 3298420296@example.com C: CSeq: 6 BYE C: Content-Length: 0
C：BYE SIP：ivr@192.0.2.41 SIP / 2.0 C：から：ユーザーA <SIP：UAA@example.com> C：TO：IVR <SIP：ivr@ms.example.com> Cは：コール番号：3298420296 @ example.com C：のCSeq：6 BYE C：のContent-Length：0
S: SIP/2.0 200 OK S: From: UserA <sip:UAA@example.com> S: To: IVR <sip:ivr@ms.example.com> S: Call-ID: 3298420296@example.com S: CSeq: 6 BYE S: Contact: <sip:ivr@192.0.2.41> S: Content-Length: 0
S：SIP / 2.0 200 OK S：から：ユーザーA <SIP：UAA@example.com> S：TO：IVR <SIP：ivr@ms.example.com> S：コールIDを：3298420296@example.com S： CSeq：6 BYE S：連絡先：<SIP：ivr@192.0.2.41> S：コンテンツ長：0
This section describes how the media server converts the IMAP URL received via the announcement or IVR service into suitable IMAP commands for retrieving the content.
このセクションでは、メディアサーバがIMAPのURLがコンテンツを取得するために、適切なIMAPコマンドへの告知やIVRサービスを介して受信された変換方法を説明します。
The media server first connects to the IMAP server specified in the URL. Once connected, the media server SHOULD use TLS [TLS] to encrypt the communication path.
メディアサーバーは、最初のURLに指定されたIMAPサーバーに接続します。接続されると、メディアサーバは、通信経路を暗号化するためにTLS [TLS]を使用すべきです。
If the media server has a user identity on the IMAP server, the media server SHOULD authenticate itself to the IMAP server using the media server's user identity.
メディアサーバはIMAPサーバー上のユーザーIDを持っている場合は、メディアサーバは、メディアサーバーのユーザーIDを使用して、IMAPサーバに対して自分自身を認証する必要があります。
If the media server is not configured as an authorized user of the IMAP server, then the behavior specified in IMAP URL [IMAPURL] MUST be followed. That is, if the server advertises AUTH=ANONYMOUS IMAP capability, the media server MUST use the AUTHENTICATE command with the ANONYMOUS [ANONYMOUS] SASL mechanism. If SASL ANONYMOUS is not available, the username "anonymous" is used with the "LOGIN" command and the password is supplied as the Internet email address of the administrative contact for the media server.
メディアサーバがIMAPサーバの許可されたユーザとして設定されていない場合は、IMAP URLで指定された動作は、[IMAPURL]従わなければなりません。すなわち、サーバはAUTH = ANONYMOUS IMAP能力をアドバタイズする場合、メディアサーバは、匿名[ANONYMOUS] SASL機構をAUTHENTICATEコマンドを使用しなければなりません。 SASL ANONYMOUSが使用できない場合は、ユーザ名「匿名」は「LOGIN」コマンドとパスワードで使用されているメディアサーバーの管理担当者のインターネット電子メールアドレスとして供給されています。
Once authenticated, the media server issues the URLFETCH command, using the URL supplied in the 'play' parameter of the SIP INVITE (or audio tag of the MSCML). If the IMAP server does not advertise URLAUTH=BINARY in its post-authentication capability string, then the media server returns a suitable error code to the client.
認証されると、メディアサーバは、SIPの「遊び」パラメータINVITE（またはMSCMLのオーディオタグ）で供給されたURLを使用して、UrlFetchのコマンドを発行します。 IMAPサーバがそのポスト認証機能文字列にURLAUTH = BINARYを広告していない場合は、メディアサーバは、クライアントに適切なエラーコードを返します。
The additional parameters to the URLFETCH command specified in (URLFETCH BINARY) [URLFETCH_BINARY] are used by the media server to tell the IMAP server to remove any transfer encoding and return the content type of the media (as content-type information is not contained in the IMAP URL).
（のURLfetch BINARY）で指定のURLfetchコマンドに追加のパラメータは、[URLFETCH_BINARY】任意の転送エンコーディングを除去するために、IMAPサーバに伝えると、コンテンツタイプ情報がに含まれないように（メディアのコンテンツ・タイプを返すためにメディアサーバにより使用されていますIMAPのURL）。
A successful URLFETCH command will return the message part containing the media to be streamed. If the URLFETCH was unsuccessful, then the media server MUST return an appropriate error response to the client.
成功のURLfetchコマンドは、ストリーミングするメディアを含むメッセージの一部を返します。 UrlFetchのが失敗した場合は、メディアサーバは、クライアントに適切なエラー応答を返さなければなりません。
Assuming the content is retrieved successfully, the media server returns a 200 (OK) response code to the client. After an ACK is received, an RTP stream is delivered to the client using the parameters negotiated in the SDP.
コンテンツが正常に取得されたと仮定すると、メディア・サーバーは、クライアントに200（OK）応答コードを返します。 ACKが受信された後、RTPストリームは、SDPで交渉パラメータを使用して、クライアントに配信されます。
If appropriate, the media server MAY choose to implement connection caching, in which case, connection and disconnection from the IMAP server are handled according to whatever algorithm the media server chooses. For example, the media server may know, a priori, that it will always access the same IMAP server using the same login credentials with an access pattern that would benefit from connection caching, without unduly impacting server resources.
適切な場合、メディアサーバは、接続キャッシュを実装することを選ぶかもしれ、その場合には、IMAPサーバからの接続および切断は、メディアサーバが選択するどのようなアルゴリズムに従って処理されます。例えば、メディアサーバは、それが常に不当衝撃サーバリソースなしで、接続キャッシュから恩恵を受けるアクセスパターンと同じログイン認証情報を使用して、同じIMAPサーバーにアクセスすることを、先験的に、知っているかもしれません。
Examples:
例：
C: a001 LOGIN anonymous null
S: a001 OK LOGIN completed.
C: a002 URLFETCH
("imap://joe@example.com/INBOX/;uid=24356/;section=1.2;
expire=2006-12-19T16:39:57-08:00;urlauth=anonymous:
internal:238234982398239898a9898998798b987s87920" BODYPARTSTRUCTURE
BINARY)
S: * URLFETCH "imap://joe@example.com/INBOX/;uid=24356/;
section=1.2;expire=2006-12-19T16:39:57-08:00;urlauth=anonymous:
internal:238234982398239898a9898998798b987s87920"
(BODYPARTSTRUCTURE ("VIDEO" "MPEG" () NIL NIL "BINARY" 655350))
(BINARY ~{655350}
S: [ ~655350 octets of binary data, containing NUL octets ])
S: a002 OK URLFETCH completed.
C: a003 LOGOUT
S: a003 OK LOGOUT completed.
This section gives examples of using the mechanism described in the document to stream media from a media server to a client, fetching the content from an IMAP server. In all of the examples, the IMAP, SIP, and RTP protocols use the line styles "-", "=", and "+", respectively.
このセクションでは、IMAPサーバからコンテンツを取得する、クライアントにメディアサーバからメディアをストリーミングするために文書で説明されたメカニズムを使用する例を与えます。それぞれ、「+」、「=」、および「 - 」の例の全てにおいて、IMAP、SIP、及びRTPプロトコルは、線のスタイルを使用します。
The following diagram shows the protocol interactions between the email client, the IMAP server, and the media server when the client uses the announcement service.
次の図は、電子メールクライアント、IMAPサーバ、およびクライアントは、アナウンスメントサービスを使用してメディアサーバ間のプロトコルの相互作用を示します。
Client IMAP Server Media Server
| FETCH (BODYSTRUCTURE) | |
|---------------------------->| |
| OK | |
|<----------------------------| |
| GENURLAUTH | |
|---------------------------->| |
| OK | |
|<----------------------------| |
| | |
| SIP INVITE |
|===========================================================>|
| | |
| | URLFETCH |
| |<-----------------------------|
| | OK |
| |----------------------------->|
| | |
| 200 OK |
|<===========================================================|
| ACK |
|===========================================================>|
| | |
| Stream Message Part (RTP) |
|<+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++|
| | |
| BYE |
|<===========================================================|
| 200 OK |
|===========================================================>|
The following diagram shows a simplified view of the protocol interactions between the email client, the IMAP server, and the media server when the client uses the MSCML IVR service.
次の図は、電子メールクライアント、IMAPサーバ、およびクライアントは、MSCML IVRサービスを使用するメディアサーバ間のプロトコル相互作用の簡略図を示します。
Client IMAP Server Media Server
| FETCH (BODYSTRUCTURE) | |
|---------------------------->| |
| OK | |
|<----------------------------| |
| GENURLAUTH | |
|---------------------------->| |
| OK | |
|<----------------------------| |
| | |
| SIP INVITE |
|===========================================================>|
| | |
| 200 OK |
|<===========================================================|
| ACK |
|===========================================================>|
| | |
| SIP INFO (playcollect) |
|===========================================================>|
| | |
| 200 OK |
|<===========================================================|
| | |
| | URLFETCH |
| |<-----------------------------|
| | OK |
| |----------------------------->|
| | |
| Stream Message Part (RTP) |
|<+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++|
| | |
| SIP INFO (e.g., DTMF ff) |
|===========================================================>|
| 200 OK |
|<===========================================================|
| | |
| Continue streaming (RTP) |
|<+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++|
| | |
| (Streaming Ends or is terminated) |
| | |
| SIP INFO (playcollect response) |
|<===========================================================|
| BYE |
|===========================================================>|
| 200 OK |
|<===========================================================|
This document proposes the use of URLAUTH [URLAUTH] "pawn tickets", received over IMAP [IMAP], and transmitted over SIP [SIP], possibly within the MSCML payload of RFC 5022 [MSCML], in order to stream media received in messages. As such, the security considerations in all these documents apply to this specification.
この文書では、メディアはメッセージで受信したストリームにするために、可能性のRFC 5022 [MSCML]のMSCMLペイロード内、IMAP [IMAP]を介して受信し、SIP [SIP]を介して送信、URLAUTH [URLAUTH「ポーンチケット」の使用を提案しています。そのように、すべてのこれらの文書のセキュリティの考慮事項は、この仕様に適用されます。
In summary, as the authorized URLs may grant access to data, implementors of this specification need to consider the following with respect to the security implications of using IMAP URLs:
認可URLはデータへのアクセスを許可することができるよう要約すると、この仕様の実装は、IMAP URLを使用してのセキュリティへの影響に関して、次のことを考慮する必要があります。
o Use of an anonymous pawn ticket grants access to any client of the IMAP server without requiring any authentication credentials. The security mechanisms referenced above (with the caveats specified below) SHOULD be used to prevent unauthorized access to the pawn ticket.
O匿名ポーンチケット助成金の使用は、任意の認証資格情報を必要とせずにIMAPサーバーの任意のクライアントへのアクセスを。 （以下、指定警告と）上記参照されるセキュリティメカニズムは、ポーンチケットへの不正アクセスを防ぐために使用されるべきです。
o Use of pawn tickets that contain the "stream" access identifier restricts access to the content to those entities that are authorized users of the IMAP server for the purposes of streaming retrieved content. Use of such pawn tickets is thus desirable and so implementors should consult Section 3.3, which describes when such pawn tickets should be used.
O「ストリーム」アクセス識別子が含まれているポーンチケットの利用は、取得したコンテンツをストリーミングする目的のためにIMAPサーバーのユーザーを認可されているそれらのエンティティにコンテンツへのアクセスを制限します。例えばポーンチケットの使用は、望まれるので、実装は、ポーンチケットが使用されるべき場合について説明セクション3.3を、相談してください。
o If the announcement service is used to set up streaming, then RFC 4240 [NETANN] specifies that the pawn ticket is passed in the Request-URI, and so untrusted third parties may be able to intercept the pawn ticket. The SIP communication channel MAY be secured by using SIPS URIs [SIP], which would provide hop-by-hop TLS encryption.
アナウンスサービスは、ストリーミングを設定するために使用されている場合は、O、その後、RFC 4240には、[NETANN]ポーンチケットが要求URIに渡され、その信頼できない第三者がポーンチケットを傍受することができることを指定します。 SIP通信チャネルは、ホップバイホップTLS暗号化を提供するSIPS URIを[SIP]を用いて固定することができます。
o If the IVR service (RFC 5022 [MSCML]) is used to set up and control streaming, then MSCML is used to carry the pawn ticket in the body of the request, and so untrusted third parties may be able to intercept the pawn ticket. This MAY be secured by using SIPS URIs [SIP], which would provide hop-by-hop TLS encryption.
IVRサービス（RFC 5022 [MSCML]）を設定し、ストリーミングを制御するために使用される場合、O、次いで、MSCMLは、要求の本体にポーンチケットを運ぶために使用され、従って信頼できない第三者がポーンチケットを傍受することができるかもしれません。これは、ホップバイホップTLS暗号化を提供するであろう、SIPS URIを[SIP]を用いて固定することができます。
o Using SIPS URIs in the above situations protects the pawn ticket from third parties; however, it still allows proxies access to the pawn ticket, which could result in misuse by malicious proxies; see note below.
上記の状況でSIPS URIを使用してoを第三者からポーンチケットを保護します。しかし、それはまだ悪質なプロキシによって誤用が生じる可能性がある、ポーンチケットへのプロキシ・アクセスを可能にします。下記の注を参照。
This document describes a mechanism that makes use of two separate servers to achieve the goal of streaming the content desired by the client. A major security implication of this is that the media server and IMAP server may well be located in separate administrative domains. This leads us to consider the security implications of a three-way protocol exchange, and the potential trust model implicit in that tripartite relationship. The security implications of the individual protocols have already been referenced; therefore, this section describes the security considerations specific to the three-way data exchange, as follows:
この文書では、クライアントが希望するコンテンツをストリーミングするという目標を達成するために2台の別々のサーバーを使用するメカニズムについて説明します。このの主要なセキュリティ上の含意は、メディアサーバーおよびIMAPサーバーが良く、別の管理ドメイン内に配置することができるということです。これは、3ウェイプロトコル交換、及びその三者関係の暗黙の潜在的な信頼モデルのセキュリティへの影響を検討するために私たちをリード。個々のプロトコルのセキュリティへの影響は、既に参照されています。次のようにそのため、このセクションでは、3ウェイのデータ交換に固有のセキュリティの考慮事項について説明します。
o The client grants the media server full access to the potentially private media content specified by the IMAP URL. As a result, the client is responsible for verifying the authenticity of the media server to a degree it finds acceptable for the content (we can refer to this process as determining the "trust" that the client has in a particular media server). The security mechanisms provided by SIP [SIP] and RTP [RTP] may be used for this purpose, as well as out of band mechanisms such as pre-configuration.
Oクライアントは、IMAP URLで指定された潜在的に民間のメディアコンテンツへのメディアサーバーのフルアクセスを許可します。その結果、クライアントは、それが（私たちは、クライアントが特定のメディアサーバーであることを「信頼」を決定すると、このプロセスを参照することができます）コンテンツのために許容見つける度にメディアサーバーの信頼性を検証する責任があります。 SIP [SIP]およびRTP [RTP]によって提供されるセキュリティメカニズムは、そのような事前の構成として、この目的のためだけでなく、バンド機構から使用されてもよいです。
o However, since the media server will retrieve content from an IMAP server on the user's behalf, the issue of security between the IMAP server and the media server also needs to be considered. A client has no way of determining (programatically at least) the security of the exchanges between the media server and the IMAP server. However, it can determine, using the "stream" token that is part of the media server discovery mechanism described in Section 3.2, that the media server has a pre-existing authentication relationship with the IMAP server for the purposes of retrieving content using IMAP URLs. The IMAP server administrator may put prerequisites on media server administrator before this relationship can be established, for example, to guarantee the security of the communication between the media server and the IMAP server.
メディアサーバーがユーザーに代わってIMAPサーバからコンテンツを取得するので、Oしかし、IMAPサーバーとメディアサーバー間のセキュリティの問題も考慮する必要があります。クライアントは、（プログラム的に少なくとも）メディアサーバとIMAPサーバ間のやり取りのセキュリティを決定する方法がありません。しかし、それはメディアサーバがIMAP URLを使用してコンテンツを取得する目的で、IMAPサーバとの既存の認証関係を持っていることを、3.2節で説明したメディアサーバーの検出機構の一部である「ストリーム」トークンを使用して、決定することができます。この関係は、メディアサーバとIMAPサーバ間の通信のセキュリティを保証するために、例えば、確立することができる前に、IMAPサーバの管理者は、メディアサーバーの管理者に前提条件を置いてもよいです。
o The above two security considerations will influence the decision the client makes with regards to generation of the pawn ticket that is subsequently passed to the media server. This document mandates the use of URLs protected with the "stream" access identifier where the client knows in advance that the "stream" authentication relationship between media server and IMAP server exists. However, it does allow the use of anonymous pawn tickets where the possibility exists that use of "stream" would cause streaming to fail.
O上記の2つのセキュリティ上の考慮事項は、クライアントが、その後、メディアサーバに渡されるポーンチケットの生成に関して作る意思決定に影響を与えます。この文書では、クライアントがメディアサーバーとIMAPサーバ間の「ストリーム」の認証関係が存在することを事前に知っている「ストリーム」アクセス識別子で保護されたURLを使用することを義務付け。しかし、それは可能性が「ストリーム」の使用が失敗するストリーミング原因となることが存在する匿名のポーンチケットの使用を許可しません。
o There exists the possibility of several types of attack by a malicious media server, SIP proxy, or other network elements even against pawn tickets protected with the "stream" access identifier. All of these attacks allow access to the RTP stream, if not the original content. These attacks include:
O悪質なメディアサーバ、SIPプロキシ、あるいは「ストリーム」アクセス識別子で保護ポーンチケットに対する他のネットワーク要素による攻撃のいくつかのタイプの可能性が存在します。オリジナルのコンテンツでない場合は、これらの攻撃のすべてが、RTPストリームへのアクセスを許可します。これらの攻撃は、次のとおりです。
* The client contacts a malicious media server, MS1, that then proxies the streaming request to a second media server, MS2, that it has determined or guessed to have "stream" authorization credentials with the IMAP server specified in the pawn ticket. The media server can then redirect the streamed RTP traffic elsewhere.
*クライアントは悪質なメディアサーバは、MS1は、それはそれは決定またはポーンチケットに指定されたIMAPサーバーとの「ストリーム」の認証資格情報を持っていると推測していること、第2のメディアサーバー、MS2へのストリーミング要求をプロキシ。メディアサーバは、他の場所でストリーミングRTPトラフィックをリダイレクトすることができます。
* Any proxy on the path between the client and the media server has access to the client's message in cleartext. In this case, a malicious proxy could perform a man-in-the-middle attack and could change the message to redirect RTP traffic elsewhere.
*クライアントとメディアサーバー間のパス上の任意のプロキシがクリアテキストで、クライアントのメッセージへのアクセス権を持っています。この場合、悪意のあるプロキシは、man-in-the-middle攻撃を行うことができ、他の場所RTPトラフィックをリダイレクトするようにメッセージを変更することができます。
* Any network element that is able to "see" the traffic between the client and the media server (or between any two proxies) can capture the pawn ticket, and then reissue a request using that pawn ticket to the same media server. Again the streamed traffic can be redirected to any desired location.
*クライアントとメディアサーバー（または任意の2つのプロキシ間）ポーンチケットをキャプチャし、同じメディアサーバーへのポーンチケットを使用して要求を再発行することができます間のトラフィックを「見」することができる任意のネットワーク要素。再度ストリーミングトラフィックは、任意の所望の場所にリダイレクトすることができます。
Media servers handling streaming requests will be making use of pawn-ticket URLs for the period of time required to process the streaming request, after which the URL will be forgotten. However, media servers may log the URLs received from clients, in which case, the private data contained in the IMAP server could be accessed by a malicious or curious media server administrator. Even URLs protected with EXPIRE may be accessed within the period of expiry. Therefore, media servers SHOULD remove or anonymize the internal portion of the IMAP URL when logging that URL.
ストリーミング要求を処理するメディアサーバーは、URLを忘れされる後、ストリーミング要求を処理するために必要な時間の期間、質屋、チケットのURLの使用を作ることになります。しかし、メディアサーバーは、URLは、IMAPサーバに含まれる個人データが悪意のあるまたは好奇心メディアサーバーの管理者がアクセスすることができ、その場合には、クライアントから受け取っログインすることができます。 EXPIREで保護されてもURLは、有効期限の期間内にアクセスすることができます。そのURLをログインしたときにそのため、メディアサーバーは、IMAP URLの内部部分を削除するか、匿名化すべきです。
Additionally, many of the security considerations in the Message Submission BURL Extension apply to this document, particularly around the use of pawn tickets and prearranged trust relationships such as those described above.
また、メッセージ提出BURL拡張におけるセキュリティの考慮事項の多くは、特にポーンチケットと、上述したような事前に決められた信頼関係を使用することを中心に、このドキュメントに適用されます。
Message parts that are encrypted using mechanisms such as S/MIME [SMIME] are designed to prevent third parties from accessing the data, thus media servers will not be able to fulfill streaming requests for messages parts that are encrypted.
このようなS / MIMEなどのメカニズム[SMIME]を用いて暗号化されたメッセージ部分は、このようにメディアサーバーが暗号化されたメッセージ部品のストリーミング要求を満たすことができなくなり、データにアクセスするサードパーティのを防止するように設計されています。
IANA has registered the following [METADATA] server entry to be used for media server discovery, using the [METADATA] registry.
IANAは[METADATA]レジストリを使用して、メディアサーバーの検出に使用される、以下の[METADATA]サーバーのエントリを登録しました。
To: iana@iana.org
と： いあな＠いあな。おｒｇ
Subject: IMAP METADATA Entry Registration
件名：IMAPメタデータエントリ登録
Type: Server
種類：サーバー
Name: /shared/mediaServers
名前：/共有/ mediaServers
Description: Defines a set of URIs containing the locations of suitable media servers for streaming multimedia content
説明：マルチメディアコンテンツをストリーミングするために適したメディアサーバーの場所を含むURIのセットを定義します
Content-type: text/plain; charset=utf-8
コンテンツタイプ：テキスト/平野。文字セット= UTF-8
Contact: neil.cook@noware.co.uk
連絡先：neil.cook@noware.co.uk
This document does not specify any Digital Rights Management (DRM) mechanisms for controlling access to and copying of the media to be streamed. This is intentional. A reference to a piece of media content is created using the URLAUTH [URLAUTH] command; thus, any DRM required should be implemented within the media itself, as implementing checks within URLAUTH could affect any use of the URLAUTH command, such as the BURL [BURL] command for message submission.
この文書では、アクセスしてストリーミングするメディアのコピーを制御するための任意のデジタル著作権管理（DRM）のメカニズムを指定していません。これは意図的なものです。メディア・コンテンツのピースへの参照はURLAUTH [URLAUTH]コマンドを使用して作成されます。 URLAUTH内の実装チェックは、メッセージ提出用BURL [BURL]コマンドとして、URLAUTHコマンドのいずれかの使用に影響を与える可能性があるように、従って、必要なDRMは、メディア自体内に実装されるべきです。
The use of URLAUTH in this specification is believed to be pursuant with, and used only for, the execution of those rights to be expected when media is sent via traditional internet messaging, and causes no duplication of media content that is not essentially provided by the action of sending the message. In other words, the use of the content for downloading and viewing *is* implicitly granted by the sender of the message, in as much as the sender has the right to grant such rights.
この仕様でURLAUTHの使用はして準ずるしていると考えられ、そしてだけに使用し、メディアは伝統的なインターネットメッセージングを経由して送信され、かつ本質的で提供されていないメディアコンテンツのない重複が発生していないときこれらの権利の実行が予想されますメッセージを送信する行為。送信者がそのような権利を付与する権利を持っているように、他の言葉では、ダウンロードして閲覧するためのコンテンツの利用は、* *暗黙的に同じくらいで、メッセージの送信者によって付与されます。
The document author believes that if DRM is a requirement for Internet messaging, then a suitable DRM mechanism should be created. How such a mechanism would work is outside the scope of this document.
文書作成者はDRMはインターネットメッセージング、次に適当なDRMメカニズムのための要件である場合に作成されるべきであると考えています。このようなメカニズムが働くだろうどのようにこの文書の範囲外です。
This document assumes an Internet deployment where there are no network restrictions between the different components. Specifically, it does not address issues that can occur when network policies restrict the communication between different components, especially between the media server and the IMAP server, and between the client the media server. In particular, RFC 5022 states that "It is
この文書では、異なるコンポーネント間のネットワークの制限はありませんインターネットの展開を想定しています。具体的には、ネットワークポリシーは、特にメディアサーバとIMAPサーバ間、およびクライアントのメディアサーバー間で、異なるコンポーネント間の通信を制限するときに発生する可能性のある問題に対処していません。特に、RFC 5022は、それがある」と述べています
unlikely, but not prohibited, for end-user SIP UACs to have a direct signaling relationship with a media server". This caveat makes it likely that firewalls and other network security mechanisms will be configured to block direct end-user access to media servers.
そう、しかし、この注意事項は、ファイアウォールやその他のネットワークセキュリティメカニズムは、メディアサーバーへの直接エンドユーザーのアクセスをブロックするように設定されていること、それはそうなります。メディアサーバー」との直接的なシグナリング関係を持つために、エンドユーザSIP求めるUACのために、禁止されていません。
In order for either of the streaming mechanisms described in this document to work, local administrators MUST relax firewall policies such that appropriate SIP UACs (user agent clients) running on mobile devices are permitted to access the media servers directly using the SIP protocol. The detail of how the restrictions are relaxed (for example, only allowing clients connecting from the network space owned/maintained by the operator of the media server) is a matter of local policy, and so is outside the scope of this document.
動作には、この文書に記載されたストリーミングメカニズムのいずれかのために、ローカル管理者がモバイルデバイス上で実行されている適切なSIP求めるUAC（ユーザエージェントクライアント）が直接SIPプロトコルを使用してメディアサーバへのアクセスが許可されるように、ファイアウォールポリシーを緩和しなければなりません。制限が緩和されている方法の詳細（例えば、唯一のメディアサーバのオペレータによって維持/所有するネットワーク空間から接続するクライアントを許可する）は、ローカルポリシーの問題ですので、この文書の範囲外です。
The following syntax specification for the mediaServers METADATA entry value uses the Augmented Backus-Naur Form (ABNF) notation as specified in RFC 5234 [ABNF] and the "absolute-URI" definition from RFC 3986 [RFC3986].
RFC 5234 [ABNF]およびRFC 3986 [RFC3986]から「絶対URI」の定義で指定されmediaServersメタデータエントリ値については、次の構文仕様は、拡張バッカス・ナウアフォーム（ABNF）の表記を使用します。
Except as noted otherwise, all alphabetic characters are case-insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion.
特記しないものを除いて、すべての英字は大文字と小文字を区別しません。トークン文字列を定義するための、大・小文字の使用は、編集上明確にするためです。実装は大文字と小文字を区別しないやり方で、これらの文字列を受け入れなければなりません。
Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved.
著作権（C）2009 IETF信託コードの作者として特定の人物。全著作権所有。
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
再配布および、改変してまたは改変せずに、ソースおよびバイナリ形式で使用し、以下の条件が満たされていることを許可されます。
- Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
- ソースコードの再配布は、上記の著作権表示、条件のリストおよび以下の免責事項を保持しなければなりません。
- Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
- バイナリ形式で再配布は、上記の著作権表示、条件のリストおよび文書および/または分布を備えた他の材料で次の免責事項を再現しなければなりません。
- Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission.
- インターネット協会、IETFやIETFトラストの名称、また具体的な貢献者の名前はどちらも、特定の書面による事前の許可なしに、本ソフトウェアから派生した製品を推薦または促進するために使用することができます。
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
本ソフトウェアは著作権所有者Limitedに、適合性の黙示の保証FOR BY提供され
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
特定の目的は、放棄され。 NO EVENTの著作権所有者または貢献者は、以下を含むいかなる直接的、間接的、偶発的、特別、懲罰的、または間接的損害（についても責任を負いあってもよいが、代替商品またはサービスの調達、これらに限定されないものとし、使用、データ、または利益の損失; OR事業の中断）原因で生じた（そのような損害の可能性について知らされていた場合でも、一切このソフトウェアの使用の損失、データの損失）過失またはその他を含む責任、それが契約、厳格な責任、不法行為のどのような理論の上で。
media-servers = ms-tuple *(";" ms-tuple)
ms-tuple = "<" absolute-URI ">" [":" "stream"]
Eric Burger (eburger@standardstrack.com) provided the initial inspiration for this document, along with advice and support on aspects of the media server IVR and announcement services, as well as help with the IETF process.
エリック・バーガー（eburger@standardstrack.com）が助言や支援メディアサーバーのIVRと発表サービスの側面についてだけでなく、IETFプロセスのヘルプと一緒に、この文書の最初のインスピレーションを提供します。
Many people made helpful comments on the document, including Alexey Melnikov, Dave Cridland, Martijn Koster, and a variety of folks in the LEMONADE and SIPPING WGs.
多くの人々はアレクセイ・メルニコフ、デイブCridland、マーテホン・コスター、とレモネードとSIPPINGのWGでの人々の様々なを含む、文書上の有益なコメントをしました。
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[ABNF]クロッカー、D.、エド。そして、P. Overell、 "構文仕様のための増大しているBNF：ABNF"、STD 68、RFC 5234、2008年1月。
[ACCESSID] Cook, N., "Internet Message Access Protocol (IMAP) - URL Access Identifier Extension", RFC 5593, June 2009.
[ACCESSID]クック、N.、 "インターネットメッセージアクセスプロトコル（IMAP） - URLアクセス識別子拡張"、RFC 5593、2009年6月。
[ANONYMOUS] Zeilenga, K., "Anonymous Simple Authentication and Security Layer (SASL) Mechanism", RFC 4505, June 2006.
[ANONYMOUS] Zeilenga、K.、 "匿名簡易認証セキュリティー層（SASL）メカニズム"、RFC 4505、2006年6月。
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP]クリスピン、M.、 "インターネットメッセージアクセスプロトコル - バージョン4rev1"、RFC 3501、2003年3月。
[IMAPURL] Melnikov, A., Ed. and C. Newman, "IMAP URL Scheme", RFC 5092, October 2007.
【IMAPURL]メルニコフ、A.編。そして、C.ニューマン、 "IMAPのURLスキーム"、RFC 5092、2007年10月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[METADATA] Daboo, C., "The IMAP METADATA Extension", RFC 5464, February 2009.
[メタデータ] Daboo、C.、 "IMAPメタデータの拡張"、RFC 5464、2009年2月。
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME)", RFC 2045, November 1996.
[MIME]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）"、RFC 2045、1996年11月。
Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996.
Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
ムーア、K.、「MIME（多目的インターネットメール拡張）パート3：非ASCIIテキストのためのメッセージヘッダの拡張」、RFC 2047、1996年11月。
Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
解放された、N.とJ. Klensin、 "メディアタイプの仕様と登録手順"、BCP 13、RFC 4288、2005年12月。
Freed, N. and J. Klensin, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 4289, December 2005.
解放された、N.とJ. Klensin、 "多目的インターネットメール拡張（MIME）第四部：登録手順"、BCP 13、RFC 4289、2005年12月。
Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
解放された、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート5：適合基準と例"、RFC 2049、1996年11月。
[MSCML] Van Dyke, J., Burger, E., Ed., and A. Spitzer, "Media Server Control Markup Language (MSCML) and Protocol", RFC 5022, September 2007.
[MSCML]ヴァン・ダイク、J.、バーガー、E.、エド。、およびA.スピッツァー、 "メディアサーバ制御マークアップ言語（MSCML）とプロトコル"、RFC 5022、2007年9月。
[NETANN] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media Services with SIP", RFC 4240, December 2005.
[NETANN]バーガー、E.、ヴァン・ダイク、J.、およびA.スピッツァー、 "SIPを使用した基本的なネットワークメディアサービス"、RFC 4240、2005年12月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[RTP] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
"：リアルタイムアプリケーションのためのトランスポートプロトコルRTP"、STD 64、RFC 3550、2003年7月[RTP] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、。
[SDP] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[SDP]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
[SIP] 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.
[SIP]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[TLS]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
[URLAUTH] Crispin, M., "Internet Message Access Protocol (IMAP) - URLAUTH Extension", RFC 4467, May 2006.
[URLAUTH]クリスピン、M.、 "インターネットメッセージアクセスプロトコル（IMAP） - URLAUTH拡張"、RFC 4467、2006年5月。
[URLFETCH_BINARY] Cridland, D., "Extended URLFETCH for Binary and Converted Parts", RFC 5524, May 2009.
[URLFETCH_BINARY] Cridland、D.、 "バイナリ変換された部品の拡張のURLfetch"、RFC 5524、2009年5月。
[BURL] Newman, C., "Message Submission BURL Extension", RFC 4468, May 2006.
[BURL]ニューマン、C.、 "メッセージ提出BURL拡張"、RFC 4468、2006年5月。
[SMIME] Ramsdell, B., Ed., ""Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification"", RFC 3851, July 2004.
[SMIME] Ramsdell、B.、エド。、 ""、RFC 3851、2004年7月 "/多目的インターネットメール拡張（S / MIME）バージョン3.1メッセージ仕様を固定します"。
Author's Address
著者のアドレス
Neil L Cook Cloudmark
ニール・L・クックCloudmarkの
EMail: neil.cook@noware.co.uk
メールアドレス：neil.cook@noware.co.uk