idnits 2.17.1 draft-ema-vpim-vmsg-02.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 2) being 105 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Abstract' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' Security considerations:' ) ** 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 an Authors' Addresses Section. ** There are 44 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([MIME4], [VPIM1], [VPIM2], [MIME2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 85: '...ns of this content type, there MUST be...' RFC 2119 keyword, line 101: '... VPIM specification [VPIM2]. All VPIM Messages MUST contain this...' RFC 2119 keyword, line 109: '... MUST NOT be assumed in any case....' RFC 2119 keyword, line 110: '... contents appear SHOULD be the order i...' 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 (November 21, 1997) is 9652 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) -- Missing reference section? 'VPIM2' on line 225 looks like a reference -- Missing reference section? 'VPIM1' on line 222 looks like a reference -- Missing reference section? 'MIME2' on line 214 looks like a reference -- Missing reference section? 'MIME4' on line 218 looks like a reference Summary: 14 errors (**), 0 flaws (~~), 4 warnings (==), 7 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 1911 Northern Telecom 6 November 21, 1997 8 VPIM Voice Message 9 MIME Sub-type Registration 11 13 Status of this Memo 15 This document is an Internet Draft. Internet Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its Areas, 17 and its Working Groups. Note that other groups may also distribute 18 working documents as Internet Drafts. 20 Internet Drafts are valid for a maximum of six months and may be 21 updated, replaced, or obsoleted by other documents at any time. It 22 is inappropriate to use Internet Drafts as reference material or to 23 cite them other than as a "work in progress". 25 To learn the current status of any Internet-Draft, please check the 26 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 27 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 28 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 29 ftp.isi.edu (US West Coast). 31 Copyright Notice 33 Copyright (C) The Internet Society (1997). All Rights Reserved. 35 Overview 37 This document describes the registration of the MIME sub-type 38 multipart/voice-message for use with the Voice Profile for Internet 39 Mail (VPIM). A full description of usage can be found in the VPIM 40 v2 specification. 42 1. Abstract 44 This document describes the registration of the MIME sub-type 45 multipart/voice-message for use with the Voice Profile for Internet 46 Mail (VPIM). A full description of usage can be found in the VPIM 47 v2 specification [VPIM2]. This document revises an earlier sub-type 48 registration in RFC 1911 [VPIM1]. 50 2. VPIM Scope 52 The VPIM specification defines a restricted profile of the Internet 53 multimedia messaging protocols for use between voice processing 54 platforms. These platforms have historically been special-purpose 55 computers and often do not have the same facilities normally 56 associated with a traditional Internet Email-capable computer. As a 57 result, VPIM also specifies additional functionality as it is 58 needed. The profile is intended to specify the minimum common set 59 of features to allow interworking between compliant systems. 61 3. Voice Message Interchange 63 3.1 multipart/voice-message 65 The MIME sub-type multipart/voice-message is defined to hold 66 specific media contents that are interchanged in messages between 67 voice messaging systems described in [VPIM2]. Essentially, the sub- 68 type provides a simple wrapper that easily identifies the entire 69 content as being the components of a single voice message. The sub- 70 type is identical in semantics and syntax to multipart/mixed, as 71 defined in [MIME2]. As such, it may be safely interpreted as a 72 multipart/mixed by systems that do not understand the sub-type (only 73 the identification as a voice message would be lost). 75 This mechanism allows the insertion of an explanatory preamble (e.g. 76 VPIM voice message attached) for recipients who read the message 77 with pre-MIME software, since the preamble will be ignored by MIME- 78 compliant software. 80 In addition to the MIME required boundary parameter, a version 81 parameter is also required for this sub-type. This is to 82 distinguish, this refinement of the sub-type from the previous 83 definition in [VPIM1]. The value of the version parameter is "2.0" 84 if the content conforms to the requirements of [VPIM2]. Should 85 there be further revisions of this content type, there MUST be 86 backwards compatibility (i.e. systems implementing version n can 87 read version 2, and systems implementing version 2 can read version 88 2 contents within a version n). The default version value (when the 89 parameter is missing) is 1, indicating the content conforms to the 90 requirements of [VPIM1]. 92 [VPIM2] describes the restriction that only specific media types, 93 applicable to voice messaging, are valid `next-level' contents of 94 this sub-type (when version=2.0). They are: audio/*, image/*, 95 message/rfc822 and application/directory. The multipart provides 96 for the packaging of as many of these contents as is necessary. 98 3.2 VPIM v2 Usage 100 The multipart/voice-message sub-type is a primary component of the 101 VPIM specification [VPIM2]. All VPIM Messages MUST contain this 102 sub-type to identify the wrapping of a voice message. The contents 103 of this wrapper can vary from only one audio/32KADPCM content to a 104 complex set of related and nested contents. 106 Typically, if more than one audio segment is present, the first is 107 the spoken name of the originator, the second is the spoken subject, 108 and the third is the voice message itself. This order, however, 109 MUST NOT be assumed in any case. Further, the order that the 110 contents appear SHOULD be the order in which they are presented to 111 the user. 113 The spoken name segment, if available, shall contain the name of the 114 message sender in the voice of the sender. The length of the spoken 115 name segment must not exceed 12 seconds. 117 The spoken subject segment, if available, shall contain the subject 118 of the message sender in the voice of the sender. The length of the 119 spoken subject segment must not exceed 20 seconds. 121 The directory information part, if present, will contain information 122 specific to the orginator of the voice message. 124 Refer to the VPIM v2 Specification for details on proper usage. 126 4. IANA Registration 128 To: ietf-types@iana.org 129 Subject: Registration of MIME media type multipart/voice- 130 message 132 MIME media type name: multipart 134 MIME subtype name: voice-message 136 Required parameters: boundary, version 138 The use of boundary is defined in [MIME2] 140 The version parameter that contains the value "2.0" if 141 enclosed content conforms to [VPIM2]. The absence of this 142 parameter indicates conformance to the previous version 143 defined in RFC 1911 [VPIM1]. 145 Optional parameters: none 147 Encoding considerations: 7bit, 8bit or Binary 149 Security considerations: 151 This defintion introduces the enforcement of explicitly 152 identifying the content as being a voice message. In some 153 environments (though likely not the majority), the loss of 154 the anonymity of the content may be a security issue. 156 Interoperability considerations: 158 Systems developed to conform with [VPIM1] may not conform to 159 this registration. Specifically, the required version will 160 likely be absent, in this case the recipient system should 161 still be able to accept the message and will be able to 162 handle the content. The VPIM v1 positional identification, 163 however, would likely be lost. 165 Published specification: 166 This document 167 [VPIM2] 169 Applications which use this media type: primarily voice 170 messaging 172 Additional information: 174 Magic number(s): ? 175 File extension(s): .VPM 176 Macintosh File Type Code(s): VPIM 178 Person & email address to contact for further information: 180 Glenn W. Parsons 181 Glenn.Parsons@Nortel.ca 183 Gregory M. Vaudreuil 184 Greg.Vaudreuil@Octel.Com 186 Intended usage: COMMON 188 Author/Change controller: 190 Glenn W. Parsons & Gregory M. Vaudreuil 192 5. Authors' Addresses 194 Glenn W. Parsons 195 Northern Telecom 196 P.O. Box 3511, Station C 197 Ottawa, ON K1Y 4H7 198 Canada 199 Phone: +1-613-763-7582 200 Fax: +1-613-763-4461 201 Glenn.Parsons@Nortel.ca 203 Gregory M. Vaudreuil 204 Lucent Technologies 205 Octel Messaging Division 206 17080 Dallas Parkway 207 Dallas, TX 75248-1905 208 United States 209 Phone/Fax: +1-972-733-2722 210 GregV@Lucent.Com 212 6. References 214 [MIME2] N. Freed and N. Borenstein, "Multipurpose Internet Mail 215 Extensions (MIME) Part Two: Media Types ", RFC 2046, Innosoft, 216 First Virtual, Nov 1996. 218 [MIME4] N. Freed and N. Borenstein, "Multipurpose Internet Mail 219 Extensions (MIME) Part Four: Registration Procedures", RFC 220 2048, Innosoft, First Virtual, Nov 1996. 222 [VPIM1] Vaudreuil, Greg, "Voice Profile for Internet Mail", RFC 223 1911, Feb 1996. 225 [VPIM2] Greg Vaudreuil and Glenn Parsons, "Voice Profile for 226 Internet Mail - version 2", Work in Progress, November 1997. 229 7. Full Copyright Statement 231 Copyright (C) The Internet Society (1997). All Rights Reserved. 233 This document and translations of it may be copied and furnished to 234 others, and derivative works that comment on or otherwise explain it 235 or assist in its implmentation may be prepared, copied, published 236 and distributed, in whole or in part, without restriction of any 237 kind, provided that the above copyright notice and this paragraph 238 are included on all such copies and derivative works. However, this 239 document itself may not be modified in any way, such as by removing 240 the copyright notice or references to the Internet Society or other 241 Internet organizations, except as needed for the purpose of 242 developing Internet standards in which case the procedures for 243 copyrights defined in the Internet Standards process must be 244 followed, or as required to translate it into languages other than 245 English. 247 The limited permissions granted above are perpetual and will not be 248 revoked by the Internet Society or its successors or assigns. 250 This document and the information contained herein is provided on an 251 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 252 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 253 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 254 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 255 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."