[要約] RFC 5616は、ストリーミングインターネットメッセージングの添付ファイルに関する規格です。その目的は、メッセージングアプリケーションでの効率的な添付ファイルのストリーミング転送を可能にすることです。
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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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]などのプロトコルを使用して、メディアをデバイスにストリーミングできます。SIP [SIP]などのプロトコル、特にRFC 4240 [NetAnn]またはMSCML [MSCML]で指定されているメディアサーバープロファイルを使用して、ストリーミングを開始および制御できます。メディアをデバイスにストリーミングすると、クライアントが比較的迅速にメディアをプレイし始めることができるため、クライアントはメディアをローカルに保存する必要がないため、両方のレイテンシの問題に対処します。トレードオフは、デバイスがオフラインであるときにメディアを表示/再生できないことです。
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.
クライアントは、Pause、Fast-Forward、Rewindなどの単純な「VCRスタイル」コントロールを使用する機能をユーザーに提示することをお勧めします。これを考慮して、このドキュメントは、ストリーミングメディアの2つの選択肢を提示します。これは、RFC 4240の発表サービスを利用する単純なメカニズムと、MSCML（RFC 5022）[MSCML]に基づくVCR制御を可能にするより複雑なメカニズムです。どのメカニズムを使用するかの選択は、クライアント次第です。たとえば、クライアントまたは構成されたメディアサーバーの制限に基づいている場合があります。このドキュメントは、これらのストリーミングサービスのどれが利用可能かを決定するための提案を提示します。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119 [キーワード]に記載されているとおりに解釈されます。
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 binary extension [urlfetch_binary] - urlfetchコマンドにバイナリおよびボディパートストラクチャの引数を指定する機能を提供します。
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] - Media Serverクライアントが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 Media Server Interactive Voice Response（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を構築し、Genurlauth [urlauth]コマンドを使用して、urlauthを認めるIMAP URLを生成します。
(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]で指定されているアナウンスサービスまたはRFC 5022 [MSCML]で指定されているIVRサービスを使用して、SIPメディアサーバーに接続し、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.
o モバイルデバイスで使用されるメディアサーバーは、発表および/またはIVRサービスのIMAP URL [IMAPURL]スキームをサポートしています。
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 URLFETCHバイナリ[urlfetch_binary]拡張機能を使用して匿名IMAP URLの生成をサポートします。
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メタデータ[メタデータ]拡張を使用したこのようなメカニズムを提供します。
There are two possibilities for clients with regard to determining the hostname and port number information of a suitable media server:
適切なメディアサーバーのホスト名とポート番号情報の決定に関して、クライアントには2つの可能性があります。
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の使用を回避することにより、メディアサーバーの発見がストリーミングメカニズムのセキュリティを改善するシナリオもあります。たとえば、クライアントは、ストリーミング目的でIMAPサーバーの承認されたユーザーであるメディアサーバーアドレスを発見できます。これにより、クライアントはURLを生成できます。コンテンツを取得するために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メタデータ[メタデータ]拡張機能を使用することについて説明します。メディアサーバーの発見はオプションです。クライアントは、メタデータ拡張機能または提案されているエントリをサポートしていない、またはそうでないものをサポートしていない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 ";".
「/shared/mediaServers」という名前のメタデータエントリを使用して、IMAPサーバーに知られている適切なメディアサーバーの場所を保存します。エントリは、セクション8で指定されたフォーマル膜に従ってフォーマットされています。これは、URIが<>シンボルに囲まれている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.)
「Stream」文字列（C.F. [AccessID]からの「Stream」アクセス識別子）は、「Stream」アクセス識別子を使用して構築された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):
/shared /mediaServersメタデータエントリの例（N.B.以下のラインラップは、明確にするための目的のためです）：
"<sip:ivr@ms.example.net:5060>:stream;<sip:annc@
ms1.example.net:5060>;<sips: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" 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：ivr@192.0.2.40：5060>; <sip：192.0.2.41：5060>; <sips：annc@ 192.0.2.42:5060 >: stream" ABNFで指定されたURIが指定されていることに注意する必要があります（セクション8）は一般的です。つまり、SIP URIに限定されません。ただし、このドキュメントは、SIP URIを使用する方法のみを指定しています。さらに、URIのコンポーネントは、「userinfo」（RFC 4240およびRFC 4722の「サービスインジケーター」として知られています）はオプションです。指定されている場合、メディアサーバーの機能に関する追加情報がクライアントに提供されます。たとえば、「ANNC」の「userInfo」コンポーネントは、メディアサーバーがRFC 4240をサポートし、「IVR」がRFC 4722のサポートを示していることを示します。
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.
クライアントは、 /shared /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を生成します。次に、クライアントは、 "; expire = <datetime>" and "; urlauth = <access>"を初期URLに追加して、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 = <dateTime>」パラメーターはオプションです。ただし、匿名のurlauthが許可したURLを使用することはセキュリティリスクであり（セクション4を参照）、将来のある時点でそのURLが停止することを保証するため、使用する必要があります。IMAPサーバーの実装者は、現地のセキュリティポリシーの問題として、安全でないと見なされる匿名のURLを拒否することを選択できます（たとえば、将来的には期限が切れすぎる）。これが相互運用性の問題を引き起こすのを防ぐために、このプロファイルを実装するIMAPサーバーは、期限切れの時間に基づいて匿名のURLのGenurlauthコマンドを拒否してはなりません。
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.
urlauth URLの<Access>部分は、帯域外のメカニズムまたはセクション3.2で説明されているメディアサーバーの発見メカニズムが、メディアサーバーがIMAPの承認されたユーザーであることを指定している場合、「Stream」（[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.
ただし、クライアントが、任意のメディアサーバーで使用できるURLの生成に関連するリスクを取得したい場合（セクション4を参照）、Urlauth URLの<アクセス>部分をGenurlauthコマンドに渡す<アクセス>部分として「匿名」を使用する場合があります。。たとえば、クライアントは、これらのメディアサーバーが既存の信頼関係を持っているかどうかを知らずに、ローカル管理ドメインのメディアサーバーのアドレス（したがって、これらのメディアサーバーの信頼レベルを暗示している）で事前に構成されている可能性があります。使用する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.
このセクションでは、セクション3.2で説明したように、セクション3.2で説明したように、構成を介して静的に、または動的に発見プロセスを介して動的に）、サービスに関するメディアサーバーの機能（つまり、RFC 4240または5022）をサポートしているクライアントの動作を指定します。そのメディアサーバーによって。これらの機能を決定したクライアントは、必要に応じて、セクション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招待状を送信することにより、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.
メディアサーバーがエラーなしで招待に応答すると仮定すると、クライアントはセクション3.7で指定されているようにMSCML IVRサービスを使用して続行できます。メディアサーバーが「IVR」サービスがサポートされていないことを示すエラーで応答した場合、クライアントがサポートする場合、クライアントはセクション3.5で説明されているように、アナウンスサービスを使用してメディアサーバーに連絡しようとする必要があります。
The following example shows an example SIP INVITE using the "ivr" service indicator:
次の例は、「IVR」サービスインジケーターを使用したSIP招待の例を示しています。
C: INVITE sip:ivr@ms2.example.com SIP/2.0
< SIP Header fields omitted for reasons of brevity >
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.
クライアントまたはメディアサーバーがMSCMLプロトコルの使用をサポートしていないと仮定すると、RFC 4240 [NetAnn]に記載されているように、メディアサーバーアナウンスサービスが使用されます。このサービスにより、クライアントは、セクション3.3に従って取得したURLを提供するメディアサーバー（「アナウンス」ユーザー）のSIP招待状（「ANNC」）に特別なユーザー名（「ANNC」）に送信できます。
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招待状は、以下の例に示すように構築されています。RFC 4240によると、Playパラメーターは必須であり、再生される許可されたIMAP URLを指定することに注意してください。
Examples of valid SIP INVITE URIs sent to the media server announcement service:
有効なSIPの例は、Media Serverアナウンスサービスに送信されるURISを招待します。
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@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
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.
IMAP URIのパラメーターとして使用される文字の多くは、IMAP URLパラメーターの代わりにSIP URIパラメーターと見なされることにより、囲まれた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コマンドを使用してメディアサーバーに連絡し、アナウンスサービス（セクション3.5を参照）、さまざまなオーディオおよびビデオコーデック（SDP [SDP]を使用）の広告サポート、およびメディアに応答して、サーバーは、オーディオコーデックのセットのみを宣伝します。このプロセスは、IVRサービスと同じですが、IVRサービスはSIPリクエストURIを使用してプレイするコンテンツを示していません。代わりに、これは後続のSIP情報リクエストで運ばれます。
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.
アナウンスサービスを使用しているクライアントの場合、メディアサーバーは、クライアント、サーバー、メディアの間に共通のコーデックを見つけることができない場合、または適切なコーデックにトランスコードできない場合、招待にエラーを返す必要があります。同様に、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
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: 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
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
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の招待とその招待への応答が正常に完了したら、クライアントは、ストリーミングを開始するためのリクエストの本文でMSCMLを使用してSIP情報リクエストを生成する必要があります。
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.
<PlayCollect>リクエストが使用されます。これにより、デュアルトーンマルチ周波数（DTMF）数字を使用して、高速道路や巻き戻しなどのメディアの再生を制御できるためです。
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」、および「Exthigittimer」をすべて「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.
<PlayCollect>の「FFKEY」および「RWKEY」属性は、動作を早送りして巻き戻すために使用され、「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.
<prompt>タグは、再生されるメディアを指定するために使用され、セクション3.3に従って、メディアのURLを提供する<オーディオ>タグを1つ持っている必要があります。タグのオーディオ固有の名前は歴史的です。タグは、音声コンテンツだけでなくビデオにも使用できるためです。「stoponerror」属性は「はい」に設定する必要があります。そのため、IMAPサーバーからメディアを取得するなどの問題が発生した場合、メディアサーバーによって意味のあるエラーメッセージが返されます。
An example SIP INFO request using the <playcollect> request is shown at the end of this section.
このセクションの最後に、<PlayCollect>リクエストを使用したSIP情報要求の例が表示されます。
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.
クライアントは、DTMFエスケープキー（<PlayCollect>リクエストの属性として指定）を送信するか、SIP情報リクエストで<Stop>リクエストをメディアサーバーに送信することにより、いつでもメディアの再生を一時停止することができます。リクエストを受け取ると、メディアサーバーはそれを認め、メディアのストリーミングを停止し、その後<PlayCollect>応答を含むSIP情報リクエストが続きます。
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>
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: 1 INVITE
S: Contact: <sip:ivr@192.0.2.41>
S: Content-Type: application/sdp
S: Content-Length: XXX
S:
S: <SDP Here>
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: 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>
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: <Media server retrieves media from IMAP server and streams to
client>
C: <Client streams 6 key>
S: <Media Server fast forwards media by 6 seconds>
C: <Client streams * key>
S: <Media Server stops streaming>
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>
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: 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
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
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.
このセクションでは、メディアサーバーが、コンテンツを取得するために、発表またはIVRサービスを介して受信したIMAP URLを適切なIMAPコマンドに変換する方法について説明します。
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 =匿名IMAP機能を宣伝する場合、メディアサーバーは匿名[匿名] SASLメカニズムを使用して認証コマンドを使用する必要があります。SASL Anonymousが利用できない場合、ユーザー名「匿名」は「ログイン」コマンドで使用され、パスワードはメディアサーバーの管理連絡先のインターネットメールアドレスとして提供されます。
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_binary]で指定されたurlfetchコマンドへの追加のパラメーターは、メディアサーバーが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を受信した後、SDPでネゴシエートされたパラメーターを使用して、RTPストリームがクライアントに配信されます。
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.
次の図は、クライアントがMSCML IVRサービスを使用するときの電子メールクライアント、IMAPサーバー、およびメディアサーバー間のプロトコルの相互作用の簡略化されたビューを示しています。
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.
このドキュメントでは、urlauth [urlauth]「ポーンチケット」の使用を提案し、IMAP [IMAP]を介して受信し、おそらくRFC 5022 [MSCML]のMSCMLペイロード内でSIP [SIP]を介して送信され、メッセージで受信されたメディアをストリーミングするために。そのため、これらすべてのドキュメントのセキュリティ上の考慮事項は、この仕様に適用されます。
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通信チャネルは、SIPS URIS [SIP]を使用して保護される場合があります。これにより、ホップバイホップTLS暗号化が提供されます。
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.
o IVRサービス（RFC 5022 [MSCML]）を使用してストリーミングをセットアップおよび制御する場合、MSCMLを使用してリクエストの本文でポーンチケットを運ぶため、信頼されていないサードパーティがポーンチケットを傍受できる可能性があります。これは、SIPS URIS [SIP]を使用して保護され、ホップバイホップTLS暗号化を提供します。
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.
o 上記の状況でSIPS URIを使用すると、第三者からポーンチケットが保護されます。ただし、ポーンチケットへのプロキシアクセスが引き続きアクセスでき、悪意のあるプロキシによる誤用が生じる可能性があります。以下のメモを参照してください。
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.
o ただし、メディアサーバーはユーザーに代わってIMAPサーバーからコンテンツを取得するため、IMAPサーバーとメディアサーバーの間のセキュリティの問題も考慮する必要があります。クライアントは、メディアサーバーとIMAPサーバーの間の交換のセキュリティを（少なくともプログラム的に）決定する方法がありません。ただし、セクション3.2で説明されているメディアサーバーの発見メカニズムの一部である「ストリーム」トークンを使用して、メディアサーバーはIMAP URLを使用してコンテンツを取得する目的でIMAPサーバーと既存の認証関係を持っていることを決定できます。。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に連絡し、2番目のメディアサーバーであるMS2にストリーミングリクエストをプロキシにし、ポーンチケットで指定されたIMAPサーバーを使用して認証資格情報を「ストリーミング」していると判断または推測しました。メディアサーバーは、他の場所でストリーミングされた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.
* クライアントとメディアサーバーの間のパス上のプロキシは、ClearTextのクライアントのメッセージにアクセスできます。この場合、悪意のあるプロキシは中間の攻撃を実行し、他の場所で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サーバーに含まれるプライベートデータには、悪意のあるまたは好奇心の強いメディアサーバー管理者がアクセスできます。期限切れに保護された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.
さらに、メッセージの提出のセキュリティに関する考慮事項の多くは、特に上記のようなポーンチケットと事前に配置された信頼関係の使用について、このドキュメントに適用されます。
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は、[メタデータ]レジストリを使用して、メディアサーバーの発見に使用するために、次の[メタデータ]サーバーエントリを登録しました。
To: iana@iana.org
宛先：iana@iana.org
Subject: IMAP METADATA Entry Registration
件名：IMAPメタデータの入力登録
Type: Server
タイプ：サーバー
Name: /shared/mediaServers
名前： /shared /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
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 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.
このドキュメントでは、異なるコンポーネント間にネットワークの制限がないインターネット展開を想定しています。具体的には、ネットワークポリシーが異なるコンポーネント間、特にメディアサーバーとIMAPサーバー間、およびクライアント間のメディアサーバー間の通信を制限する場合に発生する可能性のある問題に対処しません。特に、RFC 5022は、「エンドユーザー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].
MediaServersメタデータの入力値の次の構文仕様は、RFC 5234 [ABNF]で指定されている拡張されたBackus-NAURフォーム（ABNF）表記と、RFC 3986 [RFC3986]からの「絶対的な」定義を使用します。
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.
Copyright（c）2009 IETF TrustおよびCodeの著者として特定された人。全著作権所有。
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 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.
このソフトウェアは、制限された著作権所有者と貢献者によって提供されます。商品性と特定の目的に対する適合性の暗黙の保証は否認されます。いかなる場合でも、著作権所有者または貢献者は、直接的、間接的、偶発的、特別な、模範的、または結果的な損害（代替品またはサービスの調達を含むがこれらに限定されない、使用の損失、データ、または利益に対して責任を負いません。ただし、契約、厳格責任、または不法行為（過失などを含む）であろうと、このソフトウェアの使用から何らかの形で発生するかどうかにかかわらず、責任の理論に起因します。
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.
Eric Burger（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.
Alexey Melnikov、Dave Cridland、Martijn Koster、LemonadeやSipping WGSのさまざまな人々など、多くの人々がこの文書について有益なコメントをしました。
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[ABNF] Crocker、D.、ed。および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] Cook、N。、「インターネットメッセージアクセスプロトコル（IMAP） - URLアクセス識別子拡張機能」、RFC 5593、2009年6月。
[ANONYMOUS] Zeilenga, K., "Anonymous Simple Authentication and Security Layer (SASL) Mechanism", RFC 4505, June 2006.
[匿名] Zeilenga、K。、「匿名の単純認証とセキュリティレイヤー（SASL）メカニズム」、RFC 4505、2006年6月。
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP] Crispin、M。、「インターネットメッセージアクセスプロトコル -バージョン4REV1」、RFC 3501、2003年3月。
[IMAPURL] Melnikov, A., Ed. and C. Newman, "IMAP URL Scheme", RFC 5092, October 2007.
[Imapurl] Melnikov、A.、ed。C. Newman、「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.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Freed、N。and 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.
Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート2：メディアタイプ」、RFC 2046、1996年11月。
Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
ムーア、K。、「MIME（多目的インターネットメール拡張）パート3：ASSASCII以外のテキストのメッセージヘッダー拡張機能」、RFC 2047、1996年11月。
Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
Freed、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.
Freed、N。およびJ. Klensin、「多目的インターネットメールエクステンション（MIME）パート4：登録手順」、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.
Freed、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] Van Dyke、J.、Burger、E.、Ed。、およびA. Spitzer、「Media Server Control Markup Language（MSCML）およびProtocol」、RFC 5022、2007年9月。
[NETANN] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media Services with SIP", RFC 4240, December 2005.
[Netann] Burger、E.、van Dyke、J。、およびA. Spitzer、「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] Berners-Lee、T.、Fielding、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] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[SDP] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[SDP] Handley、M.、Jacobson、V。、およびC. Perkins、「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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIATION Protocol」、RFC 3261、2002年6月。
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[TLS] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocolバージョン1.2」、RFC 5246、2008年8月。
[URLAUTH] Crispin, M., "Internet Message Access Protocol (IMAP) - URLAUTH Extension", RFC 4467, May 2006.
[Urlauth] Crispin、M。、「インターネットメッセージアクセスプロトコル（IMAP） - Urlauth Extension」、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] Newman、C。、「Message Submission Burl Extension」、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.、ed。、 "" Secure/Multipurpose Internet Mail Extensions（S/MIME）バージョン3.1メッセージ仕様 ""、RFC 3851、2004年7月。
Author's Address
著者の連絡先
Neil L Cook Cloudmark
ニールLクッククラウドマーク
EMail: neil.cook@noware.co.uk