RFC4102 日本語訳

Network Working Group                                           P. Jones
Request for Comments: 4102                           Cisco Systems, Inc.
Category: Standards Track                                      June 2005

コメントを求めるワーキンググループP.ジョーンズ要求をネットワークでつないでください: 4102年のシスコシステムズInc.カテゴリ: 標準化過程2005年6月

               Registration of the text/red MIME Sub-Type

テキスト/赤いMIME Sub-タイプの登録

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 Internet Society (2005).

Copyright(C)インターネット協会(2005)。

Abstract

要約

   This document defines the text/red MIME sub-type.  "Red" is short for
   redundant.  The actual RTP packetization for this MIME type is
   specified in RFC 2198.

このドキュメントは赤いMIMEサブテキスト/タイプを定義します。 「赤」が短い、余分です。 このMIMEの種類のための実際のRTP packetizationはRFC2198で指定されます。

1.  Introduction

1. 序論

   Text is an important component of any multimedia communication
   system.  Like audio, the transport of text can benefit from the use
   of redundancy in order to improve reliability and end-user
   experience.

テキストはどんなマルチメディア通信システムの重要な部品です。 オーディオのように、テキストの輸送は、信頼性とエンドユーザ経験を改良するために冗長の使用の利益を得ることができます。

   RFC 2198 [1] defines an RTP [2] payload format for redundant audio
   data.  The format defined in that document is quite suitable for
   providing redundancy for text, as well as audio.

RFC2198[1]は余分なオーディオデータのためにRTP[2]ペイロード書式を定義します。 そのドキュメントで定義された書式はテキスト、およびオーディオのための冗長を提供するのにかなり適当です。

   RFC 4103 [8] specifies one usage of RFC 2198 and the text/red MIME
   type for the transport of redundant text data.

RFC4103[8]はRFC2198の1つの使用法とテキスト/赤いMIMEの種類を余分なテキストデータの輸送に指定します。

   This memo provides the MIME sub-type registration information for
   text/red.  While this document focuses on the use of this MIME sub-
   type in SDP [5], the application of this MIME sub-type is not
   restricted to SDP.

このメモはテキスト/赤のためのMIMEサブタイプレジスト情報を提供します。 このドキュメントがSDP[5]のサブタイプのこのMIMEの使用に焦点を合わせている間、このMIMEサブタイプの適用はSDPに制限されません。

Jones                       Standards Track                     [Page 1]

RFC 4102                 text/red MIME Sub-Type                June 2005

ジョーンズStandards Track[1ページ]RFC4102テキスト/赤いMIME Sub-タイプ2005年6月

2.  Conventions Used in This Document

2. 本書では使用されるコンベンション

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [3].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[3]で説明されるように本書では解釈されることであるべきですか?

3.  IANA Considerations

3. IANA問題

   One new MIME sub-type has been registered by the IANA, as described
   below:

1つの新しいMIMEサブタイプが以下で説明されるようにIANAによって示されました:

   MIME media type name: text

MIMEメディア型名: テキスト

   MIME subtype name: RED

MIME「副-タイプ」は以下を命名します。 赤

   Required parameters:
      rate: the RTP clock rate of the payload carried within the RTP
      packet.  Typically, this rate is 1000, but other rates MAY be
      specified.  This parameter MUST be set equal to the clock rate of
      the text payload format carried as the primary encoding.

必要なパラメタ: 以下を評価してください。 ペイロードのRTPクロックレートはRTPパケットの中で運ばれました。 このレートは通常、1000ですが、他のレートは指定されるかもしれません。 このパラメタは第一のコード化として運ばれたテキストペイロード形式のクロックレートと等しいセットであるに違いありません。

      pt: a comma-separated ordered list of RTP payload types
      enumerating the primary, secondary, etc., in accordance with RFC
      2198.  Because comma is a special character, the list MUST be a
      quoted-string (enclosed in double quotes).  For static payload
      types, each list element is simply the type number.  For dynamic
      payload types, each list element is a mapping of the dynamic
      payload type number to an embedded MIME content-type specification
      for the payload format corresponding to the dynamic payload type.
      The format of the mapping is:

Pt: RTPペイロードのコンマで切り離された規則正しいリストは、RFC2198によると、第一の、そして、二次のなどを列挙しながら、タイプされます。 コンマが特殊文字であるので、リストは引用文字列であるに違いありません(二重引用符では、同封されます)。 静的なペイロードタイプにおいて、各リスト要素は単に形式数です。 ダイナミックなペイロードタイプにおいて、各リスト要素はダイナミックなペイロードタイプにおいて、対応するペイロード形式の埋め込まれたMIME満足しているタイプ仕様へのダイナミックなペイロード形式数に関するマッピングです。 マッピングの形式は以下の通りです。

               dynamic-payload-type "=" content-type

ダイナミックなペイロードタイプは満足しているタイプと「等しいです」。

      If the content-type string includes a comma, then the content-
      type string MUST be a quoted-string.  If the content-type string
      does not include a comma, it MAY still be quoted.  Because it is
      part of the list, which must itself be a quoted-string, the
      quotation marks MUST be quoted with backslash quoting as specified
      in RFC 2045 [4].  If the content-type string itself contains a
      quoted-string, then the requirement for backslash quoting is
      recursively applied.

満足しているタイプストリングがコンマを含んでいるなら、内容タイプストリングは引用文字列であるに違いありません。 満足しているタイプストリングがコンマを含んでいないなら、それはまだ引用されているかもしれません。 それがリストをそれ自体で、離れさせることであるので引用文字列になってください、そして、指定されるとしてのバックスラッシュ引用がRFC2045[4]にある状態で、引用符を引用しなければなりません。リストはそうしなければなりません。 満足しているタイプストリング自体が引用文字列を含んでいるなら、バックスラッシュ引用のための要件は再帰的に適用されます。

   Optional parameters: ptime, maxptime (these attributes are originally
      defined in RFC 2327 [5] and RFC 3267 [6], respectively)

任意のパラメタ: ptime、maxptime(これらの属性は元々、RFC2327[5]とRFC3267[6]でそれぞれ定義されます)

   Restrictions on Usage:
      This type is defined only for transfer via RTP.
      It shall not be defined for a storage format.

用法における制限: このタイプは転送のためだけにRTPを通して定義されます。 格納形式のためにそれを定義しないものとします。

Jones                       Standards Track                     [Page 2]

RFC 4102                 text/red MIME Sub-Type                June 2005

ジョーンズStandards Track[2ページ]RFC4102テキスト/赤いMIME Sub-タイプ2005年6月

   Encoding considerations:
      See restrictions on Usage above; this section is included per
      the requirements in RFC 3555 [7].

問題をコード化します: Usageにおける制限が上であることを見てください。 このセクションはRFC3555[7]に要件単位で含まれています。

   Security considerations: Refer to section 5 of RFC 4102.

セキュリティ問題: RFC4102のセクション5を参照してください。

   Interoperability considerations: none

相互運用性問題: なし

   Published specification: RFC 2198

広められた仕様: RFC2198

   Applications which use this media type:
      Text streaming and conferencing tools.

このメディアタイプを使用するアプリケーション: テキストストリーミングと会議ツール。

   Additional information: none

追加情報: なし

   Person & email address to contact for further information:
      Paul E. Jones
      E-mail: paulej@packetizer.com

詳細のために連絡する人とEメールアドレス: ポールE.ジョーンズメール: paulej@packetizer.com

   Intended usage: COMMON

意図している用法: 一般的

   Author:
      Paul E. Jones
      paulej@packetizer.com

以下を書いてください。 ポールE.ジョーンズ paulej@packetizer.com

   Change Controller:
      AVT Working Group delegated from the IESG

コントローラを変えてください: IESGから代表として派遣されたAVT作業部会

4.  Mapping to SDP Parameters

4. パラメタをSDPに写像します。

   The information carried in the MIME media type specification has a
   specific mapping to fields in the Session Description Protocol (SDP)
   [5], which is commonly used to describe RTP sessions.  When SDP is
   used to specify sessions employing the RFC 2198 in a text session,
   the mapping is as follows:

タイプ仕様が特定のマッピングを持っているMIMEメディアで運ばれた情報はSession記述プロトコル(SDP)で[5]をさばきます。([5]は、RTPセッションについて説明するのに一般的に使用されます)。 SDPがいつテキストセッションのときにRFC2198を使うセッション、マッピングを指定するのにおいて使用されているかは、以下の通りです:

   -  The MIME type ("text") goes in SDP "m=" as the media name.

- MIMEの種類(「テキスト」)はメディア名としてSDP「m=」に行きます。

   -  The value of the parameter "rate" goes in SDP "a=rtpmap".

- 「レート」というパラメタの値はSDP"a=rtpmap"に入ります。

   -  The MIME subtype (RED) goes in SDP "a=rtpmap" as the encoding
      name.

- MIME「副-タイプ」(RED)はコード化名としてSDP"a=rtpmap"に入ります。

   -  The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and
      "a=maxptime" attributes, respectively.

- パラメタの"ptime"と"maxptime"はそれぞれSDP"a=ptime"と"a=maxptime"属性に入ります。

Jones                       Standards Track                     [Page 3]

RFC 4102                 text/red MIME Sub-Type                June 2005

ジョーンズStandards Track[3ページ]RFC4102テキスト/赤いMIME Sub-タイプ2005年6月

   -  The pt parameter is mapped to an a=fmtp attribute by eliminating
      the parameter name (pt) and changing the commas to slashes.  For
      example, 'pt="101,102"' maps to 'a=fmtp:99 101/102', where = '99'
      is the payload type of the redundancy frames.  Note that the
      single quote marks (') used in this example are not present in the
      actual message encoding, but are present here only for
      readability.  The level of redundancy is shown by the number of
      elements in the payload type list.

- Ptパラメタは、パラメタ名(Pt)を排除して、コンマをスラッシュに変えることによって、a=fmtp属性に写像されます。 'a=fmtpへの「10万1102インチ'例えば、'Pt=地図: 99 101/102、''どこ=99'は冗長フレームのペイロードタイプであるか。 それに注意してください、ただ一つの引用符、('、)、中で使用されて、この例が実際のメッセージコード化では存在していませんが、読み易さのためだけにここに存在している、' 冗長のレベルはペイロード型の並びの要素の数によって示されます。

   Any dynamic payload type in the list MUST be represented by its
   payload type number and not by its content-type.  The mapping of
   payload types to the content-type is done using the normal SDP
   procedures with "a=rtpmap".

満足しているタイプで代理をするのではなく、そのペイロード形式数でリストのどんなダイナミックなペイロードタイプも代理をしなければなりません。 満足しているタイプへのペイロードタイプに関するマッピングは"a=rtpmap"で正常なSDP手順を用い終わっています。

   An example of SDP is:

SDPに関する例は以下の通りです。

        m=text 11000 RTP/AVP 98 100
        a=rtpmap:98 t140/1000
        a=rtpmap:100 red/1000
        a=fmtp:100 98/98

テキスト11000RTP/AVP98 100m=a=rtpmap: 98t140/1000 a=rtpmap: 100赤/1000a=fmtp: 100、98/98

   For each redundancy payload type defined, the ordering of the primary
   and redundancy encoding(s) is fixed.  If more than one combination of
   primary and redundancy encoding(s) is desired, multiple redundancy
   payload types needs to be defined.

タイプが定義したそれぞれの冗長ペイロードにおいて、(s)をコード化する予備選挙と冗長の注文は固定されています。 (s)をコード化する予備選挙と冗長の1つ以上の組み合わせが望まれているなら、複数の冗長ペイロードが定義されるべき必要性をタイプします。

5.  Security Considerations

5. セキュリティ問題

   The security considerations listed in RFC 2198 apply.  Further, it
   should be understood that text data, perhaps even more so than audio
   data, is susceptible to unwanted modification that may lead to
   undesired results.  To prevent modification of the primary,
   secondary, or header information, payload integrity protection over
   at least the complete RTP packet is RECOMMENDED, for example using
   SRTP [9].

RFC2198に記載されたセキュリティ問題は適用されます。 さらに、恐らくオーディオデータよりさらにそうであるテキストデータが望まれない結果につながるかもしれない求められていない変更に影響されやすいのが理解されるべきです。 二次予備選挙の変更かヘッダー情報、少なくとも完全なRTPパケットの上のペイロード保全保護を防ぐのは、RECOMMENDEDです、例えば、SRTP[9]を使用して。

Jones                       Standards Track                     [Page 4]

RFC 4102                 text/red MIME Sub-Type                June 2005

ジョーンズStandards Track[4ページ]RFC4102テキスト/赤いMIME Sub-タイプ2005年6月

6.  Normative References

6. 引用規格

   [1] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M.,
       Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload
       for Redundant Audio Data", RFC 2198, September 1997.

[1] パーキンス、C.、Kouvelas、I.、ホドソン、O.、ハードマン、V.、ハンドレー、M.、Bolot、J.、ベガ-ガルシア、A.、およびS.堀-Parisis、「余分なオーディオデータのためのRTP有効搭載量」、RFC2198(1997年9月)。

   [2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
       "RTP: A Transport Protocol for Real-Time Applications", STD 64,
       RFC 3550, July 2003.

[2]Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。

   [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] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
       Extensions (MIME) Part One: Format of Internet Message Bodies",
       RFC 2045, November 1996.

解放された[4]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。

   [5] Handley, M., Jackson, V., "SDP: Session Description Protocol",
       RFC 2327, April 1998.

[5] ハンドレー、M.、ジャクソン、V.、「SDP:」 「セッション記述プロトコル」、RFC2327、1998年4月。

   [6] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "Real-
       Time Transport Protocol (RTP) Payload Format and File Storage
       Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate
       Wideband (AMR-WB) Audio Codecs", RFC 3267, June 2002.

[6] シェーベリ、J.、Westerlund、M.、Lakaniemi、A.、およびQ.シェ、「本当の時間トランスポート・プロトコル(RTP)有効搭載量形式とファイル記憶装置は適応型のマルチレート(AMR)の、そして、適応型のマルチレート広帯域(AMR-WB)にオーディオコーデックをフォーマットします」、RFC3267、2002年6月。

   [7] Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload
       Formats", RFC 3555, July 2003.

[7]CasnerとS.とP.Hoschka、「RTP有効搭載量形式のMIMEの種類登録」、RFC3555、2003年7月。

7.  Informative References

7. 有益な参照

   [8] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation",
       RFC 4103, June 2005.

[8] ヘルストリョームとG.とP.ジョーンズ、「テキストの会話のためのRTP有効搭載量」、RFC4103、2005年6月。

   [9] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
       Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
       3711, March 2004.

2004年の[9]Baugher、M.、マグリュー、D.、ジーター、M.、カラーラ、E.、およびK.Norrman、「安全なリアルタイムのトランスポート・プロトコル(SRTP)」、RFC3711行進。

Author's Address

作者のアドレス

   Paul E. Jones
   Cisco Systems, Inc.
   7025 Kit Creek Rd.
   Research Triangle Park, NC 27709, USA

ポールE.ジョーンズシスコシステムズInc.7025キットCreek通り リサーチトライアングル公園、NC 27709、米国

   Phone: +1 919 392 6948
   EMail: paulej@packetizer.com

以下に電話をしてください。 +1 6948年の919 392メール: paulej@packetizer.com

Jones                       Standards Track                     [Page 5]

RFC 4102                 text/red MIME Sub-Type                June 2005

ジョーンズStandards Track[5ページ]RFC4102テキスト/赤いMIME Sub-タイプ2005年6月

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2005).

Copyright(C)インターネット協会(2005)。

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

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

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

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

Intellectual Property

知的所有権

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

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

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

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

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

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

Acknowledgement

承認

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

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

Jones                       Standards Track                     [Page 6]

ジョーンズ標準化過程[6ページ]