doc: Add RFC documents

1 files changed, 283 insertions, 0 deletions

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]
+