idnits 2.17.1 draft-ietf-vpim-vpimv2r2-dur-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 68 instances of too long lines in the document, the longest one being 8 characters in excess of 72. -- The abstract seems to indicate that this document obsoletes RFC2424, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 14, 2002) is 8107 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'DUR' is defined on line 121, but no explicit reference was found in the text == Unused Reference: 'MIME2' is defined on line 124, but no explicit reference was found in the text == Unused Reference: 'VPIM2R2' is defined on line 130, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2424 (ref. 'DUR') (Obsoleted by RFC 3803) ** Obsolete normative reference: RFC 2421 (ref. 'VPIM2') (Obsoleted by RFC 3801) -- Possible downref: Non-RFC (?) normative reference: ref. 'VPIM2R2' Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Greg Vaudreuil 3 Internet Draft Lucent Technologies 4 Expires in six months Glenn Parsons 5 Obsoletes: RFC 2424 Nortel Networks 6 February 14, 2002 8 Content Duration 9 MIME Header Definition 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with all 16 provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering Task 19 Force (IETF), its areas, and its working groups. Note that other groups 20 may also distribute working documents as Internet-Drafts. Internet- 21 Drafts are draft documents valid for a maximum of six months and may be 22 updated, replaced, or obsoleted by other documents at any time. It is 23 inappropriate to use Internet- Drafts as reference material or to cite 24 them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document describes the MIME header Content-Duration that is 35 intended for use with any time varying media content (typically 36 audio/* or video/*). 38 This document obsoletes RFC 2424. 40 Copyright Notice 42 Copyright (C) The Internet Society (2002). All Rights Reserved. 44 Vaudreuil & Parsons Expires: August 14, 2002 1 45 1. Introduction 47 This document describes the MIME header Content-Duration that is 48 intended for use with any time varying media content (typically 49 audio/* or video/*). The length of time is represented in seconds 50 without any units indication. 52 This document obsoletes RFC 2424. 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC-2119 [REQ]. 58 2. Content-Duration Header Field 60 Time varying media contents, for example, a spoken voice message or a 61 video clip, have an inherent time duration. Many audio and video 62 encodings may include their duration as header information or may allow 63 accurate calculation based on the byte length of the data. 64 However, it may be useful to present the time duration of the content in 65 a MIME header to allow its simple determination without dealing with the 66 actual content. 68 2.1 Syntax 70 The Content-Duration field's value is a single number specifying the 71 time duration in seconds of the content. Formally: 73 duration := "Content-Duration" ":" 1*10DIGIT 75 Note that practically (though highly unlikely in MIME media), the upper 76 bound on the numerical value of the time duration is (2^^31 -1) or 77 2147483647. 79 2.2 Semantics 81 This field represents the time duration of the associated time varying 82 media content. The time duration is noted in seconds with no units tag. 83 The time value should be exact, however the exact value of the time 84 duration cannot be known without opening the content and playing it. If 85 an exact value must be known, then the latter method should be used. 86 This mechanism simply allows placing a sender determined time duration 87 value in the header for easy access. 89 Though there are several ways to present this duration to the recipient 90 (e.g. with the inbox headers, when audio attachment opened), the actual 91 use of this field on reception is a local implementation issue. 93 2.3 Example 95 In this example the content duration represents 33 seconds: 97 Content-Duration: 33 99 3. VPIM Usage 101 The Content-Duration header field for the audio/32KADPCM sub-type is a 102 useful component of the VPIM specification [VPIM2]. All VPIM Messages 103 MUST contain this sub-type to carry the audio of a voice message. It may 104 be useful in some instances (e.g. viewing on a simple MIME or non-MIME 105 desktop) to have the time duration of the voice message available 106 without having to open the audio content. 108 4. Security Considerations 110 This definition introduces the option of explicitly identifying the 111 time duration of an audio/* or video/* content outside of the binary 112 data that forms the content. In some environments (though likely not the 113 majority), the identification of the actual time duration in a header 114 field may be a security issue and as a result should not be noted. 115 Reliance on the time indicated in this header field cannot be trusted 116 for the purposes of determining the exact size of the data. The exact 117 length of the data must be determined by examining the data itself. 119 5. References 121 [DUR] G. Parsons and G. Vaudreuil, "Content Duration MIME Header 122 Definition", RFC 2424, September 1998. 124 [MIME2] Freed, N., and N. Borenstein, "Multipurpose Internet Mail 125 Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. 127 [VPIM2] Vaudreuil, G., and G. Parsons, "Voice Profile for Internet 128 Mail - version 2", RFC 2421, September 1998. 130 [VPIM2R2] Vaudreuil, G., and G. Parsons, "Voice Profile for Internet 131 Mail - version 2", , October 22, 2001. 133 [REQ] S. Bradner, "Key words for use in RFCs to Indicate Requirement 134 Levels", RFC 2119, March 1997. 136 6. Authors' Addresses 138 Glenn W. Parsons 139 Nortel Networks 140 P.O. Box 3511, Station C 141 Ottawa, ON K1Y 4H7 142 Canada 144 Phone: +1-613-763-7582 145 Fax: +1-613-763-2697 146 Email: gparsons@nortelnetworks.com 148 Gregory M. Vaudreuil 149 Lucent Technologies 150 7291 Williamson Rd 151 Dallas, TX 75214 152 United States 154 Phone/Fax: +1-972-733-2722 155 Email: gregv@ieee.org 157 7. Changes from RFC 2424 159 Only editoral and boilerplate changes from RFC 2424 have been made to 160 this document. 162 8. Full Copyright Statement 164 Copyright (C) The Internet Society (2002). All Rights Reserved. 166 This document and translations of it may be copied and furnished to 167 others, and derivative works that comment on or otherwise explain it or 168 assist in its implementation may be prepared, copied, published and 169 distributed, in whole or in part, without restriction of any kind, 170 provided that the above copyright notice and this paragraph are included 171 on all such copies and derivative works. However, this document itself 172 may not be modified in any way, such as by removing the copyright notice 173 or references to the Internet Society or other Internet organizations, 174 except as needed for the purpose of developing Internet standards in 175 which case the procedures for copyrights defined in the Internet 176 Standards process must be followed, or as required to translate it into 177 languages other than English. 179 The limited permissions granted above are perpetual and will not be 180 revoked by the Internet Society or its successors or assigns. 182 This document and the information contained herein is provided on an "AS 183 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 184 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 185 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 186 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 187 FITNESS FOR A PARTICULAR PURPOSE.