From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3803.txt | 283 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 283 insertions(+) create mode 100644 doc/rfc/rfc3803.txt (limited to 'doc/rfc/rfc3803.txt') diff --git a/doc/rfc/rfc3803.txt b/doc/rfc/rfc3803.txt new file mode 100644 index 0000000..47e6ff3 --- /dev/null +++ b/doc/rfc/rfc3803.txt @@ -0,0 +1,283 @@ + + + + + + +Network Working Group G. Vaudreuil +Request for Comments: 3803 Lucent Technologies +Obsoletes: 2424 G. Parsons +Category: Standards Track Nortel Networks + June 2004 + + + 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 (2004). + +Abstract + + This document describes the MIME header Content-Duration that is + intended for use with any time varying media content (typically + audio/* or video/*). + +1. 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. + + + + +Vaudreuil, et al. Standards Track [Page 1] + +RFC 3803 Content Duration MIME Header Definition June 2004 + + +2.1. Syntax + + The Content-Duration field's value is a single number specifying the + time duration in seconds of the content. Formally: + + 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. + +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 + +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. + + + + + + + + + + + +Vaudreuil, et al. Standards Track [Page 2] + +RFC 3803 Content Duration MIME Header Definition June 2004 + + +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. + +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. + + + + + + + + + + + + + + +Vaudreuil, et al. Standards Track [Page 3] + +RFC 3803 Content Duration MIME Header Definition June 2004 + + +7. Authors' Addresses + + Gregory M. Vaudreuil + Lucent Technologies + 7291 Williamson Rd + Dallas, TX 75214 + United States + + EMail: gregv@ieee.org + + + Glenn W. Parsons + Nortel Networks + P.O. Box 3511, Station C + Ottawa, ON K1Y 4H7 + Canada + + Phone: +1-613-763-7582 + Fax: +1-613-763-2697 + EMail: gparsons@nortelnetworks.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Vaudreuil, et al. Standards Track [Page 4] + +RFC 3803 Content Duration MIME Header Definition June 2004 + + +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 + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + +Vaudreuil, et al. Standards Track [Page 5] + -- cgit v1.2.3