idnits 2.17.1 draft-ietf-vpim-ivm-06.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): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 493. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 504. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 511. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 517. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 698 lines 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.) 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 (May 2004) is 7286 days in the past. Is this intentional? 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: 'VPIM2' is mentioned on line 62, but not defined == Missing Reference: 'MDN' is mentioned on line 195, but not defined == Unused Reference: 'DSN2' is defined on line 385, but no explicit reference was found in the text == Unused Reference: 'DSN3' is defined on line 388, but no explicit reference was found in the text == Unused Reference: 'DSN4' is defined on line 391, but no explicit reference was found in the text == Unused Reference: 'DUR' is defined on line 400, but no explicit reference was found in the text == Unused Reference: 'MIME1' is defined on line 416, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ADDRESS' ** Obsolete normative reference: RFC 2422 (ref. 'ADPCM') (Obsoleted by RFC 3802) -- Possible downref: Non-RFC (?) normative reference: ref. 'BEHAVIOUR' -- Possible downref: Non-RFC (?) normative reference: ref. 'CLID' ** Obsolete normative reference: RFC 2821 (ref. 'DRUMSMTP') (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 2822 (ref. 'DRUMSIMF') (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 2424 (ref. 'DUR') (Obsoleted by RFC 3803) ** Obsolete normative reference: RFC 2303 (ref. 'SELECTOR') (Obsoleted by RFC 3191) -- Possible downref: Non-RFC (?) normative reference: ref. 'SCHEMA' -- Possible downref: Non-RFC (?) normative reference: ref. 'VPIMENUM' ** Obsolete normative reference: RFC 2421 (ref. 'VPIMV2') (Obsoleted by RFC 3801) Summary: 14 errors (**), 0 flaws (~~), 9 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 VPIM Working Group Stuart McRae 2 Internet Draft IBM 3 Document: Glenn Parsons 4 Category: Standards Track Nortel Networks 5 May 2004 7 Internet Voice Messaging 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference material 20 or to cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 23 The list of Internet-Draft Shadow Directories can be accessed at 24 http://www.ietf.org/shadow.html. 26 1. Abstract 28 This document provides for the carriage of voicemail messages over 29 Internet mail as part of a unified messaging infrastructure. 31 The Internet Voice Messaging (IVM) concept described in this document 32 is not a successor format to VPIM v2 (Voice Profile for Internet Mail 33 Version 2), but rather an alternative specification for a different 34 application. 36 2. Conventions used in this document 38 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 39 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 40 document are to be interpreted as described in RFC-2119 [KEYWORDS]. 42 McRae & Parsons Expires: 28/11/04 1 43 Internet Voice Messaging May 2004 45 3. Introduction 47 People naturally communicate using their voices, and this is 48 preferable to typing for some forms of communication. By permitting 49 voicemail to be implemented in an interoperable way on top of Internet 50 Mail, voice messaging and electronic mail need no longer remain 51 separate, isolated worlds and users will be able to choose the most 52 appropriate form of communication. This will also enable new types of 53 device, without keyboards, to be used to participate in electronic 54 messaging when mobile, in a hostile environment, or in spite of 55 disabilities. 57 There exist unified messaging systems which will transmit voicemail 58 messages over the Internet using SMTP/MIME, but these systems suffer 59 from a lack of interoperability because various aspects of such a 60 message have not hitherto been standardized. In addition, voicemail 61 systems can now conform to the Voice Profile for Internet Messaging 62 (VPIM v2 as defined in RFC 2421 [VPIM2] and being clarified for Draft 63 Standard in [VPIMV2R2]) when forwarding messages to remote voicemail 64 systems, but VPIM v2 was designed to allow two voicemail systems to 65 exchange messages, not to allow a voicemail system to interoperate 66 with a desktop e-mail client, and it is often not reasonable to expect 67 a VPIM v2 message to be usable by an e-mail recipient. The result is 68 messages which cannot be processed by the recipient (e.g., because of 69 the encoding used), or look ugly to the user. 71 This document therefore proposes a standard mechanism for 72 representing a voicemail message within SMTP/MIME, and a standard 73 encoding for the audio content, which unified messaging systems and 74 mail clients MUST implement to ensure interoperability. By using a 75 standard SMTP/MIME representation, and a widely implemented audio 76 encoding, this will also permit most users of e-mail clients not 77 specifically implementing the standard to still access the voicemail 78 message. In addition, this document describes features an e-mail 79 client SHOULD implement to allow recipients to display voicemail 80 message in a more friendly, context sensitive way to the user, and 81 intelligently provide some of the additional functionality typically 82 found in voicemail systems (such as responding with a voice message 83 instead of e-mail). Finally it is explained how a client MAY provide a 84 level of interoperability with VPIM v2. 86 It is desirable that unified messaging mail clients also be able to 87 fully interoperate with voicemail servers. This is possible today, 88 providing the client implements VPIM v2 [VPIMV2] in addition to this 89 specification, and uses it to construct messages to be sent to a 90 voicemail server. 92 The definition in this document is based on the IVM Requirements 93 document [GOALS]. It references separate work on critical content 94 [CRITICAL] and message context [HINT]. Addressing and directory issues 95 are discussed in related documents [ADDRESS], [VPIMENUM], [SCHEMA]. 97 McRae & Parsons Expires: 28/11/04 2 98 Internet Voice Messaging May 2004 100 Further information on VPIM and related activities can be found at 101 http://www.vpim.org or http://www.ema.org/vpim. 103 4. Message Format 105 Voice messages may be created explicitly by a user (e.g. recording a 106 voicemail message in their mail client) or implicitly by a unified 107 messaging system (when it records a telephone message). 109 All messages MUST conform with the Internet Mail format, as updated by 110 the DRUMS working group [DRUMSIMF]. 112 When creating a voice message from a client supporting IVM, the 113 message header MUST indicate a message context of "voice-message" (see 114 [HINT]). However, to support interoperability with clients not 115 explicitly supporting IVM a recipient MUST NOT require its presence in 116 order to correctly process voice messages. 118 The receiving agent must be able to support multipart messages [MIME5]. 119 If the receiving user agent identifies the message as a voice message 120 (from the message context), it SHOULD present it to the user as a 121 voice message rather than as an electronic mail message with a voice 122 attachment (see [BEHAVIOUR]). 124 Any content type is permitted in a message, but the top level content 125 type on origination of a new, forwarded or reply voice message SHOULD 126 be multipart/mixed. If the recipient is known to be VPIM v2 compliant 127 then multipart/voice-message MAY be used instead (in which case all 128 the provisions of [VPIMV2R2] MUST be implemented in constructing the 129 message). 131 If the message was created as a voice message, and so is not useful if 132 the audio content is omitted, then the appropriate audio body part MUST 133 be indicated as critical content, via a Criticality parameter of 134 CRITICAL on the Content-Disposition (see [CRITICAL]). Additional 135 important body parts (such as the original audio message if a 136 voicemail is being forwarded) MAY also be indicated via a Criticality 137 of CRITICAL. Contents which are not essential to communicating the 138 meaning of the message (e.g., an associated vCard for the originator) 139 MAY be indicated via a Criticality of IGNORE. 141 When forwarding IVM messages clients MUST preserve the content type of 142 all audio body parts in order to ensure that the new recipient is able 143 to play the forwarded messages. 145 The top level content type on origination of a delivery notification 146 message MUST be multipart/report. This will allow automatic processing 147 of the delivery notification - for example, so that text-to-speech 148 processing can render a non-delivery notification in the appropriate 149 language for the recipient. 151 McRae & Parsons Expires: 28/11/04 3 152 Internet Voice Messaging May 2004 154 5. Transport 156 The message MUST be transmitted in accordance with the Simple Mail 157 Transport Protocol, as updated by the DRUMS working group [DRUMSMTP]. 159 Delivery Status Notifications MAY be requested [DSN] if delivery of 160 the message is important to the originator and a mechanism exists to 161 return status indications to them (which may not be possible for 162 voicemail originators). 164 6. Addressing 166 Any valid Internet Mail address may be used for a voice message. 168 It is desirable to be able to use an onramp/offramp for delivery of a 169 voicemail message to a user, which will result in specific addressing 170 requirements, based on service selectors as defined in [SELECTOR]. 171 Further discussion of addressing requirements for voice messages can 172 be found in the VPIM Addressing document [ADDRESS]. 174 It is desirable to permit the use of a directory service to map 175 between the E.164 phone number of the recipient and an SMTP mailbox 176 address. A discussion on how this may be achieved using the ENUM 177 infrastructure is in [VPIMENUM]. A definition of the VPIM LDAP schema 178 that a system would use is found in [SCHEMA]. 180 If a message is created and stored as a result of call answering, the 181 caller's name and number MAY be stored in the message headers in its 182 original format per [CLID]. 184 7. Notifications 186 Delivery Status Notifications MUST be supported. All non-delivery of 187 messages MUST result in a NDN, if requested [DSN]. If the receiving 188 system supports content criticality and is unable to process all of the 189 critical media types within a voice message (indicated by the content 190 criticality), then it MUST non-deliver the entire message per 191 [CRITICAL]. 193 Message Disposition Notifications SHOULD be supported (but according 194 to MDN rules the user MUST be given the option of deciding whether 195 MDNs are returned) per [MDN]. 197 If the recipient is unable to display all of the indicated critical 198 content components indicated, then it SHOULD give the user the option 199 of returning an appropriate MDN (see [CRITICAL]). 201 McRae & Parsons Expires: 28/11/04 4 202 Internet Voice Messaging May 2004 204 8. Voice Contents 206 Voice messages may be contained at any location within a message and 207 MUST always be contained in an audio/basic content-type unless the 208 originator is aware that the recipient can handle other content. 209 Specifically, Audio/32kadpcm MAY be used when the recipient is known 210 to support VPIM v2 [VPIMV2]. 212 The VOICE parameter on Content-Disposition from VPIM v2 [VPIMV2] 213 SHOULD be used to identify any spoken names or spoken subjects (as 214 distinct from voice message contents). 216 The originator's spoken name MAY be included with messages as separate 217 audio contents, if known, and SHOULD be indicated by the 218 Content-Disposition VOICE parameter as defined in VPIM v2 [VPIMV2]. 219 If there is a single recipient for the message, their spoken name MAY 220 also be included (per VPIM v2). A spoken subject MAY also be provided 221 (per VPIM v2). 223 A sending implementation MAY determine the recipient capabilities 224 before sending a message and choose a codec accordingly (e.g., using 225 some form of content negotiation). In the absence of such recipient 226 knowledge, sending implementations MUST use raw G.711 mu-law 227 indicated with a MIME content type of "audio/basic" (and SHOULD use a 228 filename parameter that ends ".au") [G711],[MIME2]. A sending 229 implementation MAY support interoperability with VPIM v2 [VPIMV2], in 230 which case it MUST be able to record G.726 (indicated as 231 audio/32kadpcm)[G726],[ADPCM]. 233 Recipients MUST be able to play a raw G.711 mu-law message, and MAY be 234 able to play G.726 (indicated as audio/32kadpcm) to provide 235 interoperability with VPIM v2. A receiving implementation MAY also be 236 able to play messages encoded with other codecs (either natively or 237 via transcoding). 239 These requirements may be summarized as follows: 241 Codec No VPIM v2 Support With VPIM v2 Support 242 Record Playback Record Playback 243 ------------- ------ -------- ------ -------- 245 G.711 mu-law MUST MUST MUST MUST 246 G.726 * MAY MUST MUST 247 Other * MAY * MAY 249 * = MUST NOT, but MAY only if recipient capabilities known 251 9. Fax Contents 253 Fax contents SHOULD be carried according to RFC 2532 [IFAX]. 255 McRae & Parsons Expires: 28/11/04 5 256 Internet Voice Messaging May 2004 258 10. Interoperability with VPIM v2 260 Interoperability between VPIM v2 systems and IVM systems can take a 261 number of different forms. While a thorough investigation of how full 262 interoperability might be provided between IVM and VPIM v2 systems is 263 beyond the scope of this document, three key alternatives are 264 discussed below. 266 10.1 Handling VPIM v2 Messages in an IVM client 268 If an IVM conformant client is able to process a content type of 269 multipart/voice-message (by treating it as multipart/mixed) and play a 270 G.726 encoded audio message within it (indicated by a content type of 271 audio/32kadpcm), then a VPIM v2 message which gets routed to that 272 desktop will be at least usable by the recipient. 274 This delivers a level of partial interoperability which would ease the 275 life of end users. However, care should be taken to ensure that any 276 attempt to reply to such a message does not result in an invalid VPIM 277 v2 message being sent to a VPIM v2 system. Note that replying to an 278 e-mail user who has forwarded a VPIM v2 message to you is, however, 279 acceptable. 281 A conformant IVM implementation MUST NOT send a non-VPIM v2 messages 282 to something it knows to be a VPIM v2 system, unless it also knows 283 that the destination system can handle such a message (even though 284 VPIM v2 systems are encouraged to handle non-VPIM v2 messages in a 285 graceful manner). In general, it must be assumed that if a system 286 sends you a conformant VPIM v2 message, then it is a VPIM v2 system 287 and so you may only reply with a VPIM v2 compliant message (unless you 288 know by some other means that the system supports IVM). 290 In addition, it should be noted that an IVM client may well not fully 291 conform to VPIM v2 even if it supports playing a G.726 message (e.g., 292 it may not respect the handling of the Sensitivity field required by 293 VPIM v2). This is one reason why VPIM v2 systems may choose not to 294 route messages to any system they do not know to be VPIM v2 compliant. 296 10.2 Dual Mode Systems and Clients 298 A VPIM v2 system could be extended to also be able to support IVM 299 compliant messages, and an IVM conformant client could be extended to 300 implement VPIM v2 in full when corresponding with a VPIM v2 compliant 301 systems. This is simply a matter of implementing both specifications 302 and selecting the appropriate one depending on the received message 303 content or the recipient's capabilities. This delivers full 304 interoperability for the relevant systems, providing the capabilities 305 of the target users can be determined. 307 McRae & Parsons Expires: 28/11/04 6 308 Internet Voice Messaging May 2004 310 Note that the mechanism for determining if a given recipient is using 311 a VPIM v2 system or client is outside of the scope of this 312 specification. Various mechanisms for capabilities discovery exist 313 which could be applied to this problem, but no standard solution has 314 yet been defined. 316 10.3 Gateways 318 It would be possibly to build a gateway linking a set of VPIM v2 users 319 with a set of IVM users. This gateway would implement the semantics 320 of the two worlds, and translate between them according to defined 321 policies. 323 For example, VPIM v2 messages with a Sensitivity of Private might be 324 rejected instead of being forwarded to an IVM recipient, because it 325 might not implement the semantics of a Private message, while an IVM 326 message containing content not supported in VPIM v2 (e.g., a PNG 327 image) with a Criticality of CRITICAL would be rejected in the 328 gateway. 330 Such a gateway MUST fully implement this specification and the VPIM v2 331 specification [VPIMV2R2] unless it knows somehow that the specific 332 originators/recipients support capabilities beyond those required by 333 these standards. 335 11. Security Considerations 337 This document presents an optional gateway between IVM and VPIM 338 systems. Gateways are inherently lossy systems and not all 339 information can be accurately translated. This applies to both the 340 transcoding of the voice and the translation of features. Two 341 examples of feature translation are given in 10.3, but the risk 342 remains that different gateways will handle the translation 343 differently since it is undefined in this document. This may lead 344 to unexpected behavior through gateways. 346 In addition, gateways present an additional point of attack for those 347 interested in compromising a messaging system. If a gateway is 348 compromised, "monkey in the middle" attacks conducted from the 349 compromised gateway may be difficult to detect or appear to be 350 authorized transformations. 352 Besides the gateway issue, it is anticipated that there are no 353 additional new security issues beyond those identified in VPIM v2 354 [VPIMV2R2] and in the other RFCs referenced by this document -- 355 especially SMTP [DRUMSMTP], Internet Message Format [DRUMSIMF], 356 MIME [MIME2], Critical Content [CRITICAL] and Message Context [HINT]. 358 McRae & Parsons Expires: 28/11/04 7 359 Internet Voice Messaging May 2004 361 12. References 363 12.1 Normative References 365 [ADDRESS] Parsons, G., "VPIM Addressing", , June 2002, Work in Progress. 368 [ADPCM] G. Vaudreuil and G. Parsons, "Toll Quality Voice - 32 kbit/s 369 ADPCM: MIME Sub-type Registration", RFC 2422, September 1998. 370 Revised by: , May 2002. 372 [BEHAVIOUR] Parsons, G., Maruszak, J., "Voice Messaging Client 373 Behaviour", , July 2001, Work in Progress. 375 [CLID] Parsons, G., Maruszak, J., "Calling Line Identification for 376 VPIM Messages", , May 2004, Work in 377 Progress. 379 [CRITICAL] Burger, E., Candell, E., "Critical Content of Internet 380 Mail" RFC 3459, June 2002. 382 [DSN] Moore, K., "SMTP Service Extension for Delivery Status 383 Notifications" RFC 3461, January 2003. 385 [DSN2] The Multipart/Report Content Type for the Reporting of Mail 386 System Administrative Messages. G. Vaudreuil. RFC 3262 Jan 2003. 388 [DSN3] Enhanced Mail System Status Codes. G. Vaudreuil. RFC 3263 389 January 2003. 391 [DSN4] An Extensible Message Format for Delivery Status Notifications. 392 K. Moore, G. Vaudreuil. RFC 3264 January 2003. 394 [DRUMSMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821 , 395 April 2001. 397 [DRUMSIMF] Resnick, P., "Internet Message Format", RFC 2822, April 398 2001. 400 [DUR] G. Parsons and G. Vaudreuil, "Content Duration MIME Header 401 Definition", RFC 2424, September 1998. Revised by: , May 2002, Work in Progress. 404 [HINT] Burger, E., Candell, E., Eliot, C., Klyne, G. "Message Context 405 Internet Mail" RFC 3458, June 2002. 407 [IFAX] Masinter, L., Wing, D. "Extended Facsimile Using Internet 408 Mail", RFC 2532, March 1999. 410 McRae & Parsons Expires: 28/11/04 8 411 Internet Voice Messaging May 2004 413 [KEYWORDS] Bradner, S., "Key Words for use in RFCs To Indicate 414 Requirement Levels", RFC 2119, March 1997. 416 [MIME1] Freed, N., Borenstein, N., "Multipurpose Internet Mail 417 Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 418 2045, November 1996. 420 [MIME2] N. Freed and N. Borenstein, "Multipurpose Internet Mail 421 Extensions (MIME) Part Two: Media Types ", RFC 2046, Innosoft, First 422 Virtual, November 1996. 424 [MIME5] N. Freed and N. Borenstein, Multipurpose Internet Mail 425 Extensions (MIME) Part Five: Conformance Criteria and Examples, 426 RFC 2049, November 1996. 428 [SELECTOR] Allocchio, C., "Minimal PSTN address format in Internet 429 Mail", RFC 2303, March 1998. 431 [SCHEMA] Vaudreuil, G. "Voice Messaging Directory Service", , May 2002, Work in Progress. 434 [VPIMENUM] Vaudreuil, G. "Voice Message Routing Service", , October 2003, Work in Progress. 437 [VPIMV2] Vaudreuil, G., Parsons, G., "Voice Profile for Internet 438 Mail - version 2", RFC 2421, September 1998. 440 [VPIMV2R2] Vaudreuil, G., Parsons, G., "Voice Profile for Internet 441 Mail - version 2", RFC 3801, June 2004. 443 12.2 Informative References 445 [GOALS] Candell, E., "Goals for Internet Voice Mail", RFC 3773, 446 June 2004. 448 [G726] CCITT Recommendation G.726 (1990), General Aspects of Digital 449 Transmission Systems, Terminal Equipment - 40, 32, 24, 16 kbit/s 450 Adaptive Differential Pulse Code Modulation (ADPCM). 452 [G711] ITU-T Recommendation G.711 (1993), General Aspects of Digital 453 Transmission Systems, Terminal Equipment - Pulse Code Modulation (PCM) 454 of Voice Frequencies. 456 13. Author's Addresses 458 Stuart J. McRae 459 IBM 460 43 Seymour Gardens 461 Twickenham, United Kingdom 462 TW1 3AR 464 Phone: +44 208 891 1896 465 Fax: +44 1784 499 112 466 Email: stuart.mcrae@uk.ibm.com 468 Glenn W. Parsons 469 Nortel Networks 470 P.O. Box 3511, Station C 471 Ottawa, ON K1Y 4H7 472 Canada 474 Phone: +1-613-763-7582 475 Fax: +1-613-967-5060 476 Email: gparsons@nortelnetworks.com 478 McRae & Parsons Expires: 28/11/04 9 479 Internet Voice Messaging May 2004 481 14. Full Copyright Statement 483 Copyright (C) The Internet Society (2004). This document is subject 484 to the rights, licenses and restrictions contained in BCP 78, and 485 except as set forth therein, the authors retain all their rights. 487 This document and the information contained herein are provided on an 488 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 489 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 490 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 491 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 492 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 493 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 495 Intellectual Property 497 The IETF takes no position regarding the validity or scope of any 498 Intellectual Property Rights or other rights that might be claimed to 499 pertain to the implementation or use of the technology described in 500 this document or the extent to which any license under such rights 501 might or might not be available; nor does it represent that it has 502 made any independent effort to identify any such rights. Information 503 on the procedures with respect to rights in RFC documents can be 504 found in BCP 78 and BCP 79. 506 Copies of IPR disclosures made to the IETF Secretariat and any 507 assurances of licenses to be made available, or the result of an 508 attempt made to obtain a general license or permission for the use of 509 such proprietary rights by implementers or users of this 510 specification can be obtained from the IETF on-line IPR repository at 511 http://www.ietf.org/ipr. 513 The IETF invites any interested party to bring to its attention any 514 copyrights, patents or patent applications, or other proprietary 515 rights that may cover technology that may be required to implement 516 this standard. Please address the information to the IETF at ietf- 517 ipr@ietf.org. 519 Acknowledgement 521 Funding for the RFC Editor function is currently provided by the 522 Internet Society. 524 McRae & Parsons Expires: 28/11/04 10