RFC 3803

RFC 3803

Content-Duration

RFC

Content Duration MIME Header Definition

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.
 
* Copyright Notice
> Copyright (C) The Internet Society (1998) (2004).  All Rights Reserved.

Overview Abstract

This document describes the MIME header Content-Duration that is intended for use with any timed time varying media content (typically audio/* or video/*).

1. Abstract Introduction

This document describes the MIME header Content-Duration that is intended for use with any time varying media content (typically audio/* or video/*). The length of time is represented in seconds without any units indication. This document obsoletes RFC 2424.

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

 
* 2. Content-Duration Header Field
>   Time varying media contents, for example, a spoken voice message or a
video clip, have an inherent time duration.  Many audio and video
encodings may include their duration as header information or may
allow accurate calculation based on the byte length of the data.
However, it may be useful to present the time duration of the content
in a MIME header to allow its simple determination without dealing
with the actual content.

時変化媒体内容、例えば話し声メッセージやビデオは元から時間を持っています。 多くの音声や動画の符号化はこの時間情報を頭部情報として含めていたり、 データのバイト長に基づいて正確に計算できたりします。 しかし、実際の内容を処理せずに MIME 頭で簡単に内容の時間を決定できれば便利です。

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

2.1. Syntax

The Content-Duration field's value is a single number specifying the time duration in seconds of the content. Formally:

Content-Duration 欄の値は数値1つで、 内容の時間を秒数で指定します。

duration := "Content-Duration" ":" 1*10DIGIT

Note that practically (though highly unlikely in MIME media), the upper bound on the numerical value of the time duration is (2^^31 -1) or 2147483647.

実際上は (MIME 媒体ではありそうにありませんが) 時間の数値の上限は 231 − 1 (2147483647) であることに注意して下さい。

 
*2.2. Semantics
>    This field represents the time duration of the associated time
varying media content.  The time duration is noted in seconds with no
units tag.  The time value should be exact, however the exact value of
the time duration cannot be known without opening the content and
playing it.  If an exact value must be known, then the latter method
should be used.  This mechanism simply allows placing a sender
determined time duration value in the header for easy access.

この欄は時変化媒体内容に関する時間を表します。 時間は単位指定なしで秒単位で記述します。 時間値は、正確には内容を開いて演奏するまでわからないかもしれませんが、 正確であるべきです。 正確な値が分からないと行けない時には、実際に開いて確かめてみるべきです。 この方法簡単に時間値を決定できるように送信者が値を置けるようにするだけのものです。

Though there are several ways to present this duration to the recipient (e.g., with the inbox headers, when audio attachment opened), the actual use of this field on reception is a local implementation issue.

この時間を受信者に示す方法は色々あります (例えば添付音声を開いた時に受信箱の頭部に提示) が、 受信者側でのこの欄の実際の用法は各実装の問題です。

2.3. Example

In this example the content duration represents 33 seconds:

Content-Duration: 33

この例では内容の時間は33秒です。

3. VPIM Usage

The Content-Duration header field for the audio/32KADPCM sub-type is a useful component of the VPIM specification [VPIM2]. All VPIM Messages MUST contain this sub-type to carry the audio of a voice message. It may be useful in some instances (e.g., viewing on a simple MIME or non-MIME desktop) to have the time duration of the voice message available without having to open the audio content.

audio/32kadpcm 亜型に対する Content-Duration 頭欄は VPIM 仕様の便利な部品です。すべての VPIM 部品は動画メッセージの音声を伝達するためにこの亜型を含めなければなりません。 場合によっては音声内容を開かなくても同がメッセージの時間が分かると (例えば単純 MIME 机上や非 MIME 机上で見るのに) 便利です。

4. Security Considerations

This definition introduces the option of explicitly identifying the time duration of an audio/* or video/* content outside of the binary data that forms the content. In some environments (though likely not the majority), the identification of the actual time duration in a header field may be a security issue and as a result should not be noted. Reliance on the time indicated in this header field cannot be trusted for the purposes of determining the exact size of the data. The exact length of the data must be determined by examining the data itself.

この定義は audio/*video/* の内容の時間を、 その内容を形成するバイナリ・データの外部で明示的に識別するという選択肢を導入します。 環境によっては (大部分ではないにしろ) 頭欄で実際の時間を識別すると安全上問題となり、 結果として示すべきではないとなるかもしれません。 この頭欄で示す次官はデータの実際の大きさを決定する目的では信頼できません。 データの実際の長さはデータ自体を検査して決定しなければなりません。

5. References

5.1. Normative References

   [MIME2]   Gellens, R., "The Text/Plain Format Parameter", RFC 2646,
             August 1999.
   [VPIM2R2] Vaudreuil, G., and G. Parsons, "Voice Profile for Internet
             Mail - version 2 (VPIMv2)", RFC 3801, June 2004.
   [REQ]     Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

5.2. Informative References

   [DUR]     Parsons, G. and G. Vaudreuil, "Content Duration MIME Header
             Definition", RFC 2424, September 1998.
   [VPIM2]   Vaudreuil, G. and G. Parsons, "Voice Profile for Internet
             Mail - version 2", RFC 2421, September 1998.

6. Changes from RFC 2424

Only editorial and boilerplate changes from RFC 2424 have been made to this document.

5. 7. Authors' Addresses

   Gregory M. Vaudreuil
   Lucent Technologies
   7291 Williamson Rd
   Dallas, TX  75214
   United States
   EMail: gregv@ieee.org
    Glenn W. Parsons
    Northern Telecom
    Nortel Networks
    P.O. Box 3511, Station C
    Ottawa, ON  K1Y 4H7
    Canada
 
    Phone: +1-613-763-7582
    Fax:   +1-613-763-4461 +1-613-763-2697
    EMail: Glenn.Parsons@Nortel.ca gparsons@nortelnetworks.com
   Gregory M. Vaudreuil
   Lucent Technologies
   17080 Dallas Parkway
   Dallas, TX  75248-1905
   United States
 
   Phone/Fax: +1-972-733-2722
   EMail: GregV@Lucent.Com

6. References

   [MIME2] Freed, N., and N. Borenstein, "Multipurpose Internet Mail
           Extensions (MIME) Part Two: Media Types", RFC 2046, November
           1996.
 
   [VPIM2] Vaudreuil, G., and G. Parsons, "Voice Profile for Internet
           Mail - version 2", RFC 2421, September 1998.
 
   [REQ] Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

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.
 
   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.
 
   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.

Acknowledgement

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

License

RFCのライセンス

メモ