RFC4796 日本語訳

Network Working Group                                      J. Hautakorpi
Request for Comments: 4796                                  G. Camarillo
Category: Standards Track                                       Ericsson
                                                           February 2007

Hautakorpiがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 4796年のG.キャマリロカテゴリ: 標準化過程エリクソン2007年2月

        The Session Description Protocol (SDP) Content Attribute

セッションの記述のプロトコルの(SDP)満足している属性

Status of This Memo

このメモの状態

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The IETF Trust (2007).

IETFが信じる著作権(C)(2007)。

Abstract

要約

   This document defines a new Session Description Protocol (SDP) media-
   level attribute, 'content'.  The 'content' attribute defines the
   content of the media stream to a more detailed level than the media
   description line.  The sender of an SDP session description can
   attach the 'content' attribute to one or more media streams.  The
   receiving application can then treat each media stream differently
   (e.g., show it on a big or small screen) based on its content.

このドキュメントはメディアレベルが結果と考える新しいSession記述プロトコル(SDP)、'内容'を定義します。 '満足している'属性はメディア記述系列より詳細なレベルとメディアストリームの内容を定義します。 SDPセッション記述の送付者は'満足している'属性を1つ以上のメディアストリームに付けることができます。次に、受信アプリケーションは内容に基づいてそれぞれのメディアストリームを異なっ(例えば、大きいか小さいスクリーンにそれを示している)て扱うことができます。

Table of Contents

目次

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  2
   3.  Related Techniques . . . . . . . . . . . . . . . . . . . . . .  2
   4.  Motivation for the New Content Attribute . . . . . . . . . . .  3
   5.  The Content Attribute  . . . . . . . . . . . . . . . . . . . .  4
   6.  The Content Attribute in the Offer/Answer Model  . . . . . . .  5
   7.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   8.  Operation with SMIL  . . . . . . . . . . . . . . . . . . . . .  7
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     12.1.  Normative References  . . . . . . . . . . . . . . . . . .  9
     12.2.  Informational References  . . . . . . . . . . . . . . . .  9

1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 2 3。 関連手法. . . . . . . . . . . . . . . . . . . . . . 2 4。 新しい満足している属性. . . . . . . . . . . 3 5に関する動機。 満足している属性. . . . . . . . . . . . . . . . . . . . 4 6。 申し出/答えモデル. . . . . . . 5 7の満足している属性。 例. . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8。 SMIL. . . . . . . . . . . . . . . . . . . . . 7 9との操作。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 7 10。 IANA問題. . . . . . . . . . . . . . . . . . . . . 8 11。 承認. . . . . . . . . . . . . . . . . . . . . . . 8 12。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 9 12.1。 引用規格. . . . . . . . . . . . . . . . . . 9 12.2。 情報の参照. . . . . . . . . . . . . . . . 9

Hautakorpi & Camarillo      Standards Track                     [Page 1]

RFC 4796                   Content Attribute               February 2007

Hautakorpiとキャマリロ規格は属性2007年2月にRFC4796内容を追跡します[1ページ]。

1.  Introduction

1. 序論

   The Session Description Protocol (SDP) [1] is a protocol that is
   intended to describe multimedia sessions for the purposes of session
   announcement, session invitation, and other forms of multimedia
   session initiation.  One of the most typical use cases of SDP is
   where it is used with the Session Initiation Protocol (SIP) [5].

Session記述プロトコル(SDP)[1]はセッション発表(セッション招待、および他の形式のマルチメディアセッション開始)の目的のためのマルチメディアセッションについて説明することを意図するプロトコルです。 典型的な使用がケースに入れるSDPの大部分の1つはそれがSession Initiationプロトコル(SIP)[5]と共に使用されるところです。

   There are situations where one application receives several similar
   media streams, which are described in an SDP session description.
   The media streams can be similar in the sense that their content
   cannot be distinguished just by examining their media description
   lines (e.g., two video streams).  The 'content' attribute is needed
   so that the receiving application can treat each media stream
   appropriately based on its content.

状況が1つのアプリケーションがSDPセッション記述で説明されるいくつかの同様のメディアストリームを受けるところにあります。 メディアストリームはそれらのメディア記述系列(例えば、2つのビデオストリーム)を調べるだけでそれらの内容を区別できないという意味において同様である場合があります。 '満足している'属性が、受信アプリケーションが適切に内容に基づくそれぞれのメディアストリームを扱うことができるくらい必要です。

   This specification defines the SDP 'content' media-level attribute,
   which provides more information about the media stream than the 'm'
   line in an SDP session description.

(属性はメディアストリームに関する詳しい情報を提供します)。中に'系列があります。'この仕様がSDP'内容'メディアレベル属性を定義する、SDPセッション記述。

   The main purpose of this specification is to allow applications to
   take automated actions based on the 'content' attributes.  However,
   this specification does not define those actions.  Consequently, two
   implementations can behave completely differently when receiving the
   same 'content' attribute.

この仕様の主な目的はアプリケーションが'満足している'属性に基づく自動化された行動を取るのを許容することです。 しかしながら、この仕様はそれらの動作を定義しません。 同じ'満足している'属性を受けるとき、その結果、2つの実装が完全に異なって振る舞うことができます。

2.  Terminology

2. 用語

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
   RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
   described in BCP 14, RFC 2119 [3], and indicate requirement levels
   for compliant implementations.

本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「お勧めでなく」て「推薦され」て、「5月」の、そして、「任意」のNOTが解釈されるのは中でBCP14について説明しました、RFC2119[3]ということであり、対応する実装のために要件レベルを示すべきであるかをさせましょう。

3.  Related Techniques

3. 関連手法

   The 'label' attribute [10] enables a sender to attach a pointer to a
   particular media stream.  The namespace of the 'label' attribute
   itself is unrestricted; so, in principle, it could also be used to
   convey information about the content of a media stream.  However, in
   practice, this is not possible because of the need for backward
   compatibility.  Existing implementations of the 'label' attribute
   already use values from that unrestricted namespace in an
   application-specific way.  So, it is not possible to reserve portions
   of the 'label' attribute's namespace without possible conflict with
   already used application-specific labels.

'ラベル'属性[10]は、送付者が特定のメディアストリームに指針を付けるのを可能にします。 'ラベル'属性自体の名前空間は無制限です。 それで、また、原則として、メディアストリームの内容に関して情報を伝達するのにそれを使用できました。 しかしながら、実際には、これは後方の互換性の必要性のために可能ではありません。 'ラベル'属性の既存の実装はその無制限な名前空間から値を既にアプリケーション特有の方法で使用します。 それで、'ラベル'の蓄えの部分には、可能のない属性の名前空間が既に使用されたアプリケーション特有のラベルと衝突するのが、可能ではありません。

Hautakorpi & Camarillo      Standards Track                     [Page 2]

RFC 4796                   Content Attribute               February 2007

Hautakorpiとキャマリロ規格は属性2007年2月にRFC4796内容を追跡します[2ページ]。

   It is possible to assign semantics to a media stream with an external
   document that uses the 'label' attribute as a pointer.  The downside
   of this approach is that it requires an external document.
   Therefore, this kind of mechanism is only applicable to special use
   cases where such external documents are used (e.g., centralized
   conferencing).

指針として'ラベル'属性を使用する外部のドキュメントでメディアストリームに意味論を割り当てるのは可能です。 このアプローチの下落傾向は外部のドキュメントを必要とするということです。 したがって、この種類のメカニズムは単に使用がそのような外部のドキュメントが使用されている(例えば、会議を集結します)ところにケースに入れる特別番組に適切です。

   Yet another way to attach semantics to a media stream is to use the
   'i' SDP attribute, defined in [1].  However, values of the 'i'
   attribute are intended for human users and not for automata.

しかし、メディアストリームに意味論を付ける別の方法は[1]で定義された'i'SDP属性を使用することです。 しかしながら、'i'属性の値はオートマトンのために意図するのではなく、人間のユーザのために意図します。

4.  Motivation for the New Content Attribute

4. 新しい満足している属性に関する動機

   Currently, SDP does not provide any means for describing the content
   of a media stream (e.g., speaker's image, slides, sign language) in a
   form that the application can understand.  Of course, the end user
   can see the content of the media stream and read its title, but the
   application cannot understand what the media stream contains.

現在、SDPはアプリケーションが理解できる書式でメディアストリーム(例えば、スピーカーのイメージ、スライド、サイン言語)の内容について説明するためのどんな手段も提供しません。 もちろん、エンドユーザはメディアの中身がタイトルを流して、読むのを見ることができますが、アプリケーションは、メディアストリームが何を含むかを理解できません。

   The application that is receiving multiple similar (e.g., same type
   and format) media streams needs, in some cases, to know what the
   contents of those streams are.  This kind of situation occurs, for
   example, in cases where presentation slides, the speaker's image, and
   sign language are transported as separate media streams.  It would be
   desirable that the receiving application could distinguish them in a
   way that it could handle them automatically in an appropriate manner.

いくつかの場合、複数の同様(例えば、同じタイプと形式)のメディアストリームを受けているアプリケーションは、それらのストリームのコンテンツが何であるかを知る必要があります。 例えば、この種類の状況はプレゼンテーションスライド、スピーカーのイメージ、およびサイン言語が別々のメディアストリームとして輸送される場合で起こります。適切な方法で自動的にそれらを扱うかもしれないのは、受信アプリケーションが方法でそれらを区別するかもしれないのが望ましいでしょう。

                +--------------------------------------+
                |+------------++----------------------+|
                ||            ||                      ||
                || speaker's  ||                      ||
                ||   image    ||                      ||
                ||            ||                      ||
                |+------------+|     presentation     ||
                |+------------+|        slides        ||
                ||            ||                      ||
                ||    sign    ||                      ||
                ||  language  ||                      ||
                ||            ||                      ||
                |+------------++----------------------+|
                +--------------------------------------+

+--------------------------------------+ |+------------++----------------------+| || || || || スピーカーのもの|| || || イメージ|| || || || || |+------------+| プレゼンテーション|| |+------------+| スライド|| || || || || サイン|| || || 言語|| || || || || |+------------++----------------------+| +--------------------------------------+

                      Figure 1: Application's Screen

図1: アプリケーションのスクリーン

   Figure 1 shows a screen of a typical communication application.  The
   'content' attribute makes it possible for the application to decide
   where to show each media stream.  From an end user's perspective, it

図1は典型的なコミュニケーションアプリケーションのスクリーンを示しています。 '満足している'属性で、アプリケーションが、どこにそれぞれのメディアストリームを示すかを決めるのが可能になります。 エンドユーザの見解からそれ

Hautakorpi & Camarillo      Standards Track                     [Page 3]

RFC 4796                   Content Attribute               February 2007

Hautakorpiとキャマリロ規格は属性2007年2月にRFC4796内容を追跡します[3ページ]。

   is desirable that the user does not need to arrange each media stream
   every time a new media session starts.

ニューメディアセッションが始まるときはいつも、ユーザがそれぞれのメディアストリームをアレンジする必要はないのが望ましいです。

   The 'content' attribute could also be used in more complex
   situations.  An example of such a situation is an application
   controlling equipment in an auditorium.  An auditorium can have many
   different output channels for video (e.g., main screen and two
   smaller screens) and audio (e.g., main speakers and headsets for the
   participants).  In this kind of environment, a lot of interaction
   from the end user who operates the application would be required in
   absence of cues from a controlling application.  The 'content'
   attribute would make it possible, for example, for an end user to
   specify, only once, which output each media stream of a given session
   should use.  The application could automatically apply the same media
   layout for subsequent sessions.  So, the 'content' attribute can help
   reduce the amount of required end-user interaction considerably.

また、'満足している'属性は、より複雑な状況で使用されるかもしれません。 そのような状況に関する例は講堂のアプリケーション制御装置です。 講堂はビデオ(例えば、メイン画面と2個のより小さいスクリーン)とオーディオ(例えば、関係者のための主なスピーカーとヘッドホン)のための多くの異なった出力チャネルを持つことができます。 この種類の環境で、アプリケーションを操作するエンドユーザからの多くの相互作用が制御アプリケーションから手がかりの欠如で必要でしょう。 '満足している'属性で指定するのは例えばエンドユーザにとって可能になるでしょう、一度だけ与えられたセッションのそれぞれのメディアストリームはその出力を使用するべきです。 アプリケーションはその後のセッションのために自動的に同じメディアレイアウトを当てはまるかもしれません。 それで、'満足している'属性は、必要なエンドユーザ相互作用の量をかなり減少させるのを助けることができます。

5.  The Content Attribute

5. 満足している属性

   This specification defines a new media-level value attribute,
   'content'.  Its formatting in SDP is described by the following ABNF
   (Augmented Backus-Naur Form) [2]:

この仕様はニューメディアレベル値の属性、'内容'を定義します。 SDPの形式は以下のABNF(BN記法を増大させる)[2]によって説明されます:

       content-attribute   = "a=content:" mediacnt-tag
       mediacnt-tag        = mediacnt *("," mediacnt)
       mediacnt            = "slides" / "speaker" / "sl" / "main"
                             / "alt" / mediacnt-ext
       mediacnt-ext        = token

満足している属性=「aは内容と等しいです」。 mediacnt-タグmediacnt-タグ=mediacnt*、(「」、mediacnt) mediacntは「スライド」/「スピーカー」/"sl"/「メイン」/"alt"/mediacnt-ext mediacnt-ext=トークンと等しいです。

   The 'content' attribute contains one or more tokens, which MAY be
   attached to a media stream by a sending application.  An application
   MAY attach a 'content' attribute to any media stream it describes.

'満足している'属性は1つ以上のトークンを含んでいます。(トークンは送付アプリケーションでメディアストリームに付けられるかもしれません)。 アプリケーションは'満足している'属性をそれが説明するどんなメディアストリームにも付けるかもしれません。

   This document provides a set of pre-defined values for the 'content'
   attribute.  Other values can be defined in the future.  The pre-
   defined values are:

このドキュメントは'満足している'属性に1セットの事前に定義された値を提供します。 将来、他の値を定義できます。 あらかじめ定義された値は以下の通りです。

   slides:  the media stream includes presentation slides.  The media
      type can be, for example, a video stream or a number of instant
      messages with pictures.  Typical use cases for this are online
      seminars and courses.  This is similar to the 'presentation' role
      in H.239 [12].

スライド: メディアストリームはプレゼンテーションスライドを含んでいます。 例えば、メディアタイプは、画像があるビデオストリームか多くのインスタントメッセージであるかもしれません。 典型的である、これがオンラインセミナーとコースであるので、ケースを使用してください。 これはH.239[12]における'プレゼンテーション'の役割と同様です。

Hautakorpi & Camarillo      Standards Track                     [Page 4]

RFC 4796                   Content Attribute               February 2007

Hautakorpiとキャマリロ規格は属性2007年2月にRFC4796内容を追跡します[4ページ]。

   speaker:  the media stream contains the image of the speaker.  The
      media can be, for example, a video stream or a still image.
      Typical use cases for this are online seminars and courses.

スピーカー: メディアストリームはスピーカーのイメージを含んでいます。 例えば、メディアは、ビデオストリームか静止画像であるかもしれません。 典型的である、これがオンラインセミナーとコースであるので、ケースを使用してください。

   sl:  the media stream contains sign language.  A typical use case for
      this is an audio stream that is translated into sign language,
      which is sent over a video stream.

sl: メディアストリームはサイン言語を含んでいます。 A典型的である、これがビデオストリームの上に送られるサイン言語に翻訳されるオーディオストリームであるので、ケースを使用してください。

   main:  the media stream is taken from the main source.  A typical use
      case for this is a concert where the camera is shooting the
      performer.

メイン: メディア小川は主なソースから抜粋されます。 A典型的である、これがカメラがパフォーマーを撃っているコンサートであるので、ケースを使用してください。

   alt:  the media stream is taken from the alternative source.  A
      typical use case for this is an event where the ambient sound is
      separated from the main sound.  The alternative audio stream could
      be, for example, the sound of a jungle.  Another example is the
      video of a conference room, while the main stream carries the
      video of the speaker.  This is similar to the 'live' role in
      H.239.

alt: メディア小川は代替のソースから抜粋されます。 A典型的である、これが周囲の音がメインと深く切り離されるところのイベントであるので、ケースを使用してください。 例えば、代替のオーディオストリームはジャングルの音であるかもしれません。 別の例は会議室のビデオですが、本流はスピーカーのビデオを運びます。 これはH.239における'ライブな'役割と同様です。

   All these values can be used with any media type.  We chose not to
   restrict each value to a particular set of media types in order not
   to prevent applications from using innovative combinations of a given
   value with different media types.

どんなメディアタイプでもこれらのすべての値を使用できます。 私たちは、アプリケーションが異なったメディアタイプで与えられた価値の革新的な組み合わせを使用するのを防がないように各値を特定のメディアタイプに整然とした状態で制限しないのを選びました。

   The application can make decisions on how to handle a single media
   stream based on both the media type and the value of the 'content'
   attribute.  If the application does not implement any special logic
   for the handling of a given media type and 'content' value
   combination, it applies the application's default handling for the
   media type.

アプリケーションはどうメディアタイプと'満足している'属性の値の両方に基づくただ一つのメディアストリームを扱うかに関する決定をすることができます。 アプリケーションが与えられたメディアタイプと'満足している'値の組み合わせの取り扱いのために少しの特別な論理も実装しないなら、それはメディアタイプのためにアプリケーションのデフォルト取り扱いを適用します。

   Note that the same 'content' attribute value can occur more than once
   in a single session description.

同じ'満足している'属性値がただ一つのセッション記述における一度より起こることができることに注意してください。

6.  The Content Attribute in the Offer/Answer Model

6. 申し出/答えモデルの満足している属性

   This specification does not define a means to discover whether the
   peer endpoint understands the 'content' attribute because 'content'
   values are just informative at the offer/answer model [8] level.  The
   fact that the peer endpoint does not understand the 'content'
   attribute does not keep the media session from being established.
   The only consequence is that end user interaction on the receiving
   side may be required to direct the individual media streams
   appropriately.

この仕様は'満足している'値が申し出/答えモデル[8]レベルでただ有益であるので同輩終点が'満足している'属性を理解しているかどうか発見する手段を定義しません。 同輩終点が'満足している'属性を理解していないという事実は、メディアセッションが確立されるのを妨げません。 唯一の結果は受信側におけるエンドユーザ相互作用が適切に個々のメディアストリームを指示するのに必要であるかもしれないということです。

Hautakorpi & Camarillo      Standards Track                     [Page 5]

RFC 4796                   Content Attribute               February 2007

Hautakorpiとキャマリロ規格は属性2007年2月にRFC4796内容を追跡します[5ページ]。

   The 'content' attribute describes the data that the application
   generating the SDP session description intends to send over a
   particular media stream.  The 'content' values for both directions of
   a media stream do not need to be the same.  Therefore, an SDP answer
   MAY contain 'content' attributes even if none were present in the
   offer.  Similarly, the answer MAY contain no 'content' attributes
   even if they were present in the offer.  Furthermore, the values of
   'content' attributes do not need to match in an offer and an answer.

'満足している'属性はSDPセッション記述を生成するアプリケーションが特定のメディアストリームの上で送るつもりであるデータについて説明します。 メディアストリームの両方の方向への'満足している'値は同じである必要はありません。 したがって、なにも申し出で存在していなかったとしても、SDP答えは'満足している'属性を含むかもしれません。 同様に、それらが申し出で存在していたとしても、答えは'満足している'属性を全く含まないかもしれません。 その上、'満足している'属性の値は申し出と答えで合う必要はありません。

   The 'content' attribute can also be used in scenarios where SDP is
   used in a declarative style.  For example, 'content' attributes can
   be used in SDP session descriptors that are distributed with Session
   Announcement Protocol (SAP) [9].

また、SDPが宣言的なスタイルに使用されるシナリオで'満足している'属性を使用できます。 例えば、Session Announcementプロトコル(SAP)[9]で分配されるSDPセッション記述子で'満足している'属性を使用できます。

7.  Examples

7. 例

   There are two examples in this section.  The first example, shown
   below, uses a single 'content' attribute value per media stream:

2つの例がこのセクションにあります。 以下に示された最初の例はメディアストリームあたり1つのただ一つの'満足している'属性値を使用します:

       v=0
       o=Alice 292742730 29277831 IN IP4 131.163.72.4
       s=Second lecture from information technology
       c=IN IP4 131.164.74.2
       t=0 0
       m=video 52886 RTP/AVP 31
       a=rtpmap:31 H261/9000
       a=content:slides
       m=video 53334 RTP/AVP 31
       a=rtpmap:31 H261/9000
       a=content:speaker
       m=video 54132 RTP/AVP 31
       a=rtpmap:31 H261/9000
       a=content:sl

0 0t=mのIN IP4 131.164.74.2=ビデオ52886RTP/AVP31情報技術cからのアリスの292742730 29277831IN IP4 131.163.72.4 s=の2番目のv=0o=講演=a=rtpmap: 31 H261/9000a=内容: ビデオ53334RTP/AVP31スライドm=a=rtpmap: 31 H261/9000a=内容: ビデオ54132RTP/AVP31スピーカーm=a=rtpmap: 31 H261/9000a=は以下をslに満足させます。

   The second example, below, is a case where there is more than one
   'content' attribute value per media stream.  The difference with the
   previous example is that now the conferencing system might
   automatically mix the video streams from the presenter and slides:

2番目の例は以下のメディアストリームあたりの1'内容'の属性値があるケースです。 前の例がある違いは今、会議システムがプレゼンターとスライドからビデオストリームを自動的に混ぜるかもしれないということです:

Hautakorpi & Camarillo      Standards Track                     [Page 6]

RFC 4796                   Content Attribute               February 2007

Hautakorpiとキャマリロ規格は属性2007年2月にRFC4796内容を追跡します[6ページ]。

       v=0
       o=Alice 292742730 29277831 IN IP4 131.163.72.4
       s=Second lecture from information technology
       c=IN IP4 131.164.74.2
       t=0 0
       m=video 52886 RTP/AVP 31
       a=rtpmap:31 H261/9000
       a=content:slides,speaker
       m=video 54132 RTP/AVP 31
       a=rtpmap:31 H261/9000
       a=content:sl

0 0t=mのIN IP4 131.164.74.2=ビデオ52886RTP/AVP31情報技術cからのアリスの292742730 29277831IN IP4 131.163.72.4 s=の2番目のv=0o=講演=a=rtpmap: ビデオ54132RTP/AVP31スピーカーm=a=rtpmap: 31H261/9000a=内容: スライド、31H261/9000a=は以下をslに満足させます。

8.  Operation with SMIL

8. SMILとの操作

   The values of 'content' attribute, defined in Section 5, can also be
   used with Synchronized Multimedia Integration Language (SMIL) [11].
   SMIL contains a 'param' element, which is used for describing the
   content of a media flow.  However, this 'param' element, like the
   'content' attribute, provides an application-specific description of
   the media content.

また、Synchronized Multimedia Integration Language(SMIL)[11]と共にセクション5で定義された'満足している'属性の値を使用できます。 SMILは'param'要素を含んでいます。(それは、メディア流動の内容について説明するのに使用されます)。 しかしながら、'満足している'属性のように、この'param'要素はメディア内容のアプリケーション明確な記述を提供します。

   Details on how to use the values of the 'content' attribute with
   SMIL's 'param' element are outside the scope of this specification.

この仕様の範囲の外にSMILの'param'要素と共に'満足している'属性の値をどう使用するかに関する詳細があります。

9.  Security Considerations

9. セキュリティ問題

   An attacker may attempt to add, modify, or remove 'content'
   attributes from a session description.  Depending on how an
   implementation chooses to react to the presence or absence of a given
   'content' attribute, this could result in an application behaving in
   an undesirable way; therefore, it is strongly RECOMMENDED that
   integrity protection be applied to the SDP session descriptions.

攻撃者は、セッション記述から'満足している'属性を加えるか、変更するか、または取り除くのを試みるかもしれません。 これは望ましくない方法で振る舞うアプリケーションをもたらして、実装が、与えられた'満足している'属性の存在か欠如に反応するのをどう選ぶかによるかもしれません。 強く、保全保護をあるRECOMMENDEDは、申し込みました。したがって、それがそうである、SDPセッション記述。

   Integrity protection can be provided for a session description
   carried in an SIP [5], e.g., by using S/MIME [6] or Transport Layer
   Security (TLS) [7].

SIP[5]で運ばれたセッション記述に保全保護を提供できます、例えば、S/MIME[6]かTransport Layer Security(TLS)[7]を使用することによって。

   It is assumed that values of 'content' attribute do not contain data
   that would be truly harmful if it is exposed to a possible attacker.
   It must be noted that the initial set of values does not contain any
   data that would require confidentiality protection.  However, S/MIME
   and TLS can be used to protect confidentiality, if needed.

'満足している'属性の値がそれが可能な攻撃者に暴露されるなら本当に、有害なデータを含まないと思われます。 値の始発が秘密性保護を必要とする少しのデータも含まないことに注意しなければなりません。 しかしながら、必要であるなら、秘密性を保護するのにS/MIMEとTLSを使用できます。

Hautakorpi & Camarillo      Standards Track                     [Page 7]

RFC 4796                   Content Attribute               February 2007

Hautakorpiとキャマリロ規格は属性2007年2月にRFC4796内容を追跡します[7ページ]。

10.  IANA Considerations

10. IANA問題

   This document defines a new 'content' attribute for SDP.  It also
   defines an initial set of values for it.  Some general information
   regarding the 'content' attribute is presented in the following:

このドキュメントはSDPのために新しい'満足している'属性を定義します。 また、それはそれのために1人の始発の値を定義します。 '満足している'属性に関するいくらかの一般情報が以下に提示されます:

   Contact name:        Jani Hautakorpi <Jani.Hautakorpi@ericsson.com>.

名前に連絡してください: ヤニ Hautakorpi <Jani.Hautakorpi@ericsson.com 、gt。

   Attribute name:      'content'.

名前を結果と考えてください: '内容'。

   Type of attribute    Media level.

属性メディアレベルのタイプ。

   Subject to charset:  No.

charsetへの対象: いいえ

   Purpose of attribute:  The 'content' attribute gives information from
      the content of the media stream to the receiving application.

属性の目的: '満足している'属性はメディアストリームの内容から受信アプリケーションまで知らせます。

   Allowed attribute values: "slides", "speaker", "sl", "main", "alt",
      and any other registered values.

許容属性値: 「スライド」、「スピーカー」、"sl"、「メイン」、"alt"、およびいかなる他のも値を示しました。

   The IANA created a subregistry for 'content' attribute values under
   the Session Description Protocol (SDP) Parameters registry.  The
   initial values for the subregistry are as follows:

IANAはSession記述プロトコル(SDP)パラメタ登録の下で'満足している'属性値のための副登録を作成しました。 副登録のための初期の値は以下の通りです:

   Value of 'content' attribute Reference Description
   ---------------------------- --------- -----------
   slides                       RFC 4796  Presentation slides
   speaker                      RFC 4796  Image from the speaker
   sl                           RFC 4796  Sign language
   main                         RFC 4796  Main media stream
   alt                          RFC 4796  Alternative media stream

'内容'属性Reference記述の値---------------------------- --------- ----------- Presentationがスピーカーsl RFC4796Sign言語からスピーカーRFC4796Imageを滑らせるRFC4796にストリームalt RFC4796Alternativeメディアが流す主なRFC4796Mainメディアを滑らせます。

   As per the terminology in RFC 2434 [4], the registration policy for
   new values for the 'content' parameter shall be 'Specification
   Required'.

RFC2434[4]の用語に従って、'満足している'パラメタのための新しい値のための登録方針は'仕様Required'でしょう。

   If new values for 'content' attributes are specified in the future,
   they should consist of a meta description of the contents of a media
   stream.  New values for 'content' attributes should not describe
   things like what to do in order to handle a stream.

'満足している'属性のための新しい値が将来指定されるなら、それらはメディアストリームのコンテンツのメタ記述から成るべきです。 '満足している'属性のための新しい値はストリームを扱うためにするべきことのようなものについて説明するべきではありません。

11.  Acknowledgements

11. 承認

   The authors would like to thank Arnoud van Wijk and Roni Even, who
   provided valuable ideas for this document.  We wish to also thank Tom
   Taylor for his thorough review.

作者はArnoudバンウェイクとロニEvenに感謝したがっています。(Evenはこのドキュメントのための貴重な考えを提供しました)。 また、彼の徹底的なレビューについてトム・テイラーに感謝申し上げます。

Hautakorpi & Camarillo      Standards Track                     [Page 8]

RFC 4796                   Content Attribute               February 2007

Hautakorpiとキャマリロ規格は属性2007年2月にRFC4796内容を追跡します[8ページ]。

12.  References

12. 参照

12.1.  Normative References

12.1. 引用規格

   [1]   Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
         Description Protocol", RFC 4566, July 2006.

[1] ハンドレー、M.、ジェーコブソン、V.、およびC.パーキンス、「SDP:」 「セッション記述プロトコル」、RFC4566、2006年7月。

   [2]   Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
         Specifications: ABNF", RFC 4234, October 2005.

[2] エドクロッカー、D.、P.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。

   [3]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

[3] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [4]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
         Considerations Section in RFCs", BCP 26, RFC 2434,
         October 1998.

[4]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。

12.2.  Informational References

12.2. 情報の参照

   [5]   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.

[5] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。

   [6]   Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
         (S/MIME) Version 3.1 Message Specification", RFC 3851,
         July 2004.

Ramsdell(B.)が「/マルチパーパスインターネットメールエクステンション(S/MIME)バージョン3.1メッセージ仕様であると機密保護する」[6]、RFC3851、2004年7月。

   [7]   Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
         Protocol Version 1.1", RFC 4346, April 2006.

[7] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。

   [8]   Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
         Session Description Protocol (SDP)", RFC 3264, June 2002.

[8] ローゼンバーグとJ.とH.Schulzrinne、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。

   [9]   Handley, M., Perkins, C., and E. Whelan, "Session Announcement
         Protocol", RFC 2974, October 2000.

[9] ハンドレーとM.とパーキンス、C.とE.ウィーラン、「セッション発表プロトコル」、RFC2974、2000年10月。

   [10]  Levin, O. and G. Camarillo, "The Session Description Protocol
         (SDP) Label Attribute", RFC 4574, August 2006.

[10] レヴィンとO.とG.キャマリロ、「セッション記述プロトコル(SDP)ラベル属性」、RFC4574、2006年8月。

   [11]  Michel, T. and J. Ayars, "Synchronized Multimedia Integration
         Language (SMIL 2.0) - [Second Edition]", World Wide Web
         Consortium Recommendation REC-SMIL2-20050107, January 2005,
         <http://www.w3.org/TR/2005/REC-SMIL2-20050107>.

[11] ミシェル、T.、およびJ.Ayars、「連動しているマルチメディア統合言語(SMIL2.0)--、[第2版]、」、ワールドワイドウェブコンソーシアム推薦REC-SMIL2-20050107(<http://www.w3.org/TR/2005/REC-SMIL2-20050107 2005年1月の>)

   [12]  ITU-T, "Infrastructure of audiovisual services - Systems
         aspects; Role management and additional media channels for
         H.300-series terminals", Series H H.239, July 2003.

[12] ITU-T、「視聴覚のサービスのインフラストラクチャ--、システム局面、」、。 「H.300-シリーズ端末への役割の管理と追加メディアチャンネル」、Series H H.239、2003年7月。

Hautakorpi & Camarillo      Standards Track                     [Page 9]

RFC 4796                   Content Attribute               February 2007

Hautakorpiとキャマリロ規格は属性2007年2月にRFC4796内容を追跡します[9ページ]。

Authors' Addresses

作者のアドレス

   Jani Hautakorpi
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

ヤニHautakorpiエリクソンHirsalantie11Jorvas02420フィンランド

   EMail: Jani.Hautakorpi@ericsson.com

メール: Jani.Hautakorpi@ericsson.com

   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

ゴンサロキャマリロエリクソンHirsalantie11Jorvas02420フィンランド

   EMail: Gonzalo.Camarillo@ericsson.com

メール: Gonzalo.Camarillo@ericsson.com

Hautakorpi & Camarillo      Standards Track                    [Page 10]

RFC 4796                   Content Attribute               February 2007

Hautakorpiとキャマリロ規格は属性2007年2月にRFC4796内容を追跡します[10ページ]。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2007).

IETFが信じる著作権(C)(2007)。

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。

Intellectual Property

知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Hautakorpi & Camarillo      Standards Track                    [Page 11]

Hautakorpiとキャマリロ標準化過程[11ページ]