RFC

Content Duration MIME Header Definition

• Network Working Group
• Request for Comments: 2424 3803
• Obsoletes: 2424
• Category: Standards Track
• G. Vaudreuil
• Lucent Technologies
• G. Parsons
• Northern Telecom
• Nortel Networks
• September 1998
• June 2004

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.

 
* 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 頭で簡単に内容の時間を決定できれば便利です。

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

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

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

   [VPIM2]   Vaudreuil, G. and G. Parsons, "Voice Profile for Internet
             Mail - version 2", RFC 2421, September 1998.

6. Changes from RFC 2424

5. 7. Authors' Addresses

   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

6. References

7. Full Copyright Statement

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.
 
   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

8. Full Copyright Statement

   Copyright (C) The Internet Society (2004).  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.
 
   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.

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

License

RFCのライセンス

メモ