idnits 2.17.1 draft-ietf-vpim-vpimv2r2-vm-00.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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** Missing revision: the document name given in the document, 'draft-ietf-vpim', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-vpim', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-vpim', but the file name used is 'draft-ietf-vpim-vpimv2r2-vm-00' == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 64 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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. ** The abstract seems to contain references ([VPIM1], [VPIM2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (November 16, 2000) is 8555 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: 'V-MSG' is defined on line 209, but no explicit reference was found in the text == Unused Reference: 'MIME4' is defined on line 215, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2423 (ref. 'V-MSG') (Obsoleted by RFC 3801) ** Obsolete normative reference: RFC 2048 (ref. 'MIME4') (Obsoleted by RFC 4288, RFC 4289) ** Obsolete normative reference: RFC 1911 (ref. 'VPIM1') (Obsoleted by RFC 2421, RFC 2422, RFC 2423) ** Obsolete normative reference: RFC 2421 (ref. 'VPIM2') (Obsoleted by RFC 3801) -- Possible downref: Non-RFC (?) normative reference: ref. 'VPIM2R2' Summary: 13 errors (**), 1 flaw (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Greg Vaudreuil 2 Internet Draft Lucent Technologies 3 Document: Glenn Parsons 4 Obsoletes: RFC 2423 Nortel Networks 5 Category: Standards Track November 16, 2000 7 VPIM Voice Message 8 MIME Sub-type Registration 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. Internet-Drafts are draft documents valid for a maximum of 19 six months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- Drafts 21 as reference material or to cite them other than as "work in 22 progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 1. Abstract 32 This document describes the registration of the MIME sub-type 33 multipart/voice-message for use with the Voice Profile for Internet 34 Mail(VPIM). A full description of usage can be found in the VPIM v2 35 specification [VPIM2]. This document revises an earlier sub-type 36 registration in RFC 1911 [VPIM1]. 38 This document obsoletes RFC 2423. 40 2. Conventions used in this document 42 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 43 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 44 this document are to be interpreted as described in RFC-2119. 46 3. VPIM Scope 48 The VPIM specification defines a restricted profile of the Internet 49 multimedia messaging protocols for use between voice processing 50 platforms. These platforms have historically been special-purpose 51 computers and often do not have the same facilities normally 52 associated with a traditional Internet Email-capable computer. As a 53 result, VPIM also specifies additional functionality as it is 54 needed. The profile is intended to specify the minimum common set of 55 features to allow interworking between compliant systems. 57 Vaudreuil & Parsons Expires: 16/05/01 1 58 4. Voice Message Interchange 60 4.1 multipart/voice-message 62 The MIME sub-type multipart/voice-message is defined to hold 63 specific media contents that are interchanged in messages between 64 voice messaging systems described in [VPIM2R2]. Essentially, the 65 sub-type provides a simple wrapper that easily identifies the entire 66 content as being the components of a single voice message. The sub- 67 type is identical in semantics and syntax to multipart/mixed, as 68 defined in [MIME2]. As such, it may be safely interpreted as a 69 multipart/mixed by systems that do not understand the sub-type (only 70 the identification as a voice message would be lost). 72 This mechanism allows the insertion of an explanatory preamble (e.g. 73 VPIM voice message attached) for recipients who read the message 74 with pre-MIME software, since the preamble will be ignored by MIME- 75 compliant software. 77 In addition to the MIME required boundary parameter, a version 78 parameter is also required for this sub-type. This is to 79 distinguish, this refinement of the sub-type from the previous 80 definition in [VPIM1]. The value of the version parameter is "2.0" 81 if the content conforms to the requirements of [VPIM2R2]. Should 82 here be further revisions of this content type, there MUST be 83 backwards compatibility (i.e. systems implementing version n can 84 read version 2, and systems implementing version 2 can read version 85 2 contents within a version n). The default version value (when the 86 parameter is missing) is 1, indicating the content conforms to the 87 requirements of [VPIM1]. 89 [VPIM2R2] describes the restriction that only specific media types, 90 applicable to voice messaging, are valid `next-level' contents of 91 this sub-type (when version=2.0). They are: audio/*, image/*, 92 message/rfc822 and applicationtext/directory. The multipart 93 provides or the packaging of as many of these contents as is 94 necessary. 96 3.2 VPIM v2 Usage 98 The multipart/voice-message sub-type is a primary component of the 99 VPIM specification [VPIM2R2]. All VPIM Messages MUST contain this 100 sub-type to identify the wrapping of a voice message. The contents 101 of this wrapper can vary from only one audio/32KADPCM content to a 102 complex set of related and nested contents. 104 Typically, if more than one audio segment is present, the first is 105 the spoken name of the originator, the second is the spoken subject, 106 and the third is the voice message itself. This order, however, 107 MUST NOT be assumed in any case. Further, the order that the 108 contents appear SHOULD be the order in which they are presented to 109 the user. 111 Vaudreuil & Parsons Expires: 16/05/01 2 112 The spoken name segment, if available, shall contain the name of the 113 message sender in the voice of the sender. The length of the spoken 114 name segment must not exceed 12 seconds. 116 The spoken subject segment, if available, shall contain the subject 117 of the message sender in the voice of the sender. The length of the 118 spoken subject segment must not exceed 20 seconds. 120 The directory information part, if present, will contain information 121 specific to the originator of the voice message. 123 Refer to the VPIM v2 Specification for details on proper usage. 125 4. IANA Registration 127 To: ietf-types@iana.org 128 Subject: Registration of MIME media type 129 multipart/voice-message 131 MIME media type name: multipart 133 MIME subtype name: voice-message 135 Required parameters: boundary, version 137 The use of boundary is defined in [MIME2] 139 The version parameter that contains the value "2.0" if 140 enclosed content conforms to [VPIM2R2]. The absence of this 141 parameter indicates conformance to the previous version 142 defined in RFC 1911 [VPIM1]. 144 Optional parameters: none 146 Encoding considerations: 7bit, 8bit or Binary 148 Security considerations: 150 This definition identifies the content as being a voice 151 message. In some environments (though likely not the 152 majority), the loss of the anonymity of the content may be a 153 security issue. 155 Interoperability considerations: 157 Systems developed to conform with [VPIM1] may not conform to 158 this registration. Specifically, the required version will 159 likely be absent, in this case the recipient system should 160 still be able to accept the message and will be able to 161 handle the content. The VPIM v1 positional identification, 162 however, would likely be lost. 164 Published specification: 165 This document 166 [VPIM2R2] 167 [VPIM2] 169 Applications which use this media type: 171 Vaudreuil & Parsons Expires: 16/05/01 3 172 Primarily voice messaging 174 Additional information: 176 Magic number(s): ? 177 File extension(s): .VPM 178 Macintosh File Type Code(s): VPIM 180 Person & email address to contact for further information: 182 Glenn W. Parsons 183 gparsons@nortelnetworks.com 185 Gregory M. Vaudreuil 186 gregv@lucent.com 188 Intended usage: COMMON 190 Author/Change controller: 192 Glenn W. Parsons & Gregory M. Vaudreuil 194 5. Security Considerations 196 Most security considerations are described in [VPIM2R2]. 198 This definition identifies the content as being a voice message. In 199 some environments (though likely not the majority), the loss of the 200 anonymity of the content may be a security issue. 202 In addition, implementors should be aware that they may receive 203 invalid content in a mulitpart/voice-message that cannot be 204 processed or stored. This SHOULD NOT compromise the integrity of 205 the valid contents of message. 207 6. References 209 [V-MSG] G. Vaudreuil and G. Parsons, "VPIM Voice Message MIME Sub- 210 type Registration", RFC 2423, September 1998. 212 [MIME2] Freed, N., and N. Borenstein, "Multipurpose Internet Mail 213 Extensions (MIME) Part Two: Media Types ", RFC 2046, November 1996. 215 [MIME4] Freed, N., Klensin, J., and J. Postel, "Multipurpose 216 Internet Mail Extensions (MIME) Part Four: Registration Procedures", 217 RFC 2048, November 1996. 219 [VPIM1] Vaudreuil, G., "Voice Profile for Internet Mail", RFC 1911, 220 February 1996. 222 [VPIM2] Vaudreuil, G., and G. Parsons, "Voice Profile for Internet 223 Mail - version 2", RFC 2421, September 1998. 225 [VPIM2R2] Vaudreuil, G., and G. Parsons, "Voice Profile for Internet 226 Mail - version 2", , November 2000. 228 Vaudreuil & Parsons Expires: 16/05/01 4 229 11. Author's Addresses 231 Glenn W. Parsons 232 Nortel Networks 233 P.O. Box 3511, Station C 234 Ottawa, ON K1Y 4H7 235 Canada 237 Phone: +1-613-763-7582 238 Fax: +1-416-597-7005 239 EMail: gparsons@nortelnetworks.com 241 Gregory M. Vaudreuil 242 Lucent Technologies 243 17080 Dallas Parkway 244 Dallas, TX 75248-1905 245 United States 247 Phone/Fax: +1-972-733-2722 248 EMail: gregv@lucent.com 250 Vaudreuil & Parsons Expires: 16/05/01 5 251 8. Full Copyright Statement 253 Copyright (C) The Internet Society (2000). All Rights Reserved. 255 This document and translations of it may be copied and furnished to 256 others, and derivative works that comment on or otherwise explain it 257 or assist in its implementation may be prepared, copied, published 258 and distributed, in whole or in part, without restriction of any 259 kind, provided that the above copyright notice and this paragraph 260 are included on all such copies and derivative works. However, this 261 document itself may not be modified in any way, such as by removing 262 the copyright notice or references to the Internet Society or other 263 Internet organizations, except as needed for the purpose of 264 developing Internet standards in which case the procedures for 265 copyrights defined in the Internet Standards process must be 266 followed, or as required to translate it into languages other than 267 English. 269 The limited permissions granted above are perpetual and will not be 270 revoked by the Internet Society or its successors or assigns. 272 This document and the information contained herein is provided on an 273 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 274 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 275 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 276 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 277 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 279 Vaudreuil & Parsons Expires: 16/05/01 6