idnits 2.17.1 draft-sparks-sip-mimetypes-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: ---------------------------------------------------------------------------- == 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 Introduction section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 42 has weird spacing: '... method to tu...' -- 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 (April 26, 2002) is 8034 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) == Outdated reference: A later version (-07) exists of draft-ietf-sip-refer-02 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP R. Sparks 3 Internet-Draft dynamicsoft 4 Expires: October 25, 2002 April 26, 2002 6 Internet Media Type message/sipfrag 7 draft-sparks-sip-mimetypes-03 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 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 This Internet-Draft will expire on October 25, 2002. 32 Copyright Notice 34 Copyright (C) The Internet Society (2002). All Rights Reserved. 36 Abstract 38 This document registers the message/sipfrag MIME media type. This 39 type is similar to message/sip , but allows fragments of well formed 40 SIP messages to be used for the same tunelling purposes as message/ 41 sip. In addition to end-to-end security uses , message/sipfrag is 42 used with the REFER method to tunnel information about the status of 43 a referrenced request. 45 Table of Contents 47 1. message/sipfrag . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3 49 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 50 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 52 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 5 54 1. message/sipfrag 56 This document registers the message/sipfrag MIME media type. This 57 type is similar to message/sip as defined in [1], but allows 58 fragments of well formed SIP messages to be used for the same 59 tunelling purposes as message/sip. In addition to the end-to-end 60 security uses discussed in [1], message/sipfrag is used in the REFER 61 [2] to tunnel information about the status of a referrenced request. 63 The motivation and examples of usage of message/sip as a security 64 mechanism in concert with S/MIME are given in seciton 23.4 of [1]. 65 These apply equally to message/sipfrag, with the additional benefit 66 of being able to choose which portions of the message to protect. 68 Motivation and examples of usage of message/sipfrag to carry the 69 status of referrenced requests is provided in [2]. In particular, 70 allowing only a portion of a SIP message to be carried allows 71 information that could compromise privacy and confidentiality to be 72 protected by removal. 74 Where a message/sip mime-part must be a complete well formed SIP 75 message, a mime-part of type message/sipfrag can contain a subset of 76 a SIP message. A valid message/sipfrag part is one that could be 77 obtained by starting with some valid SIP message and deleting any of 78 the following 80 o the entire start line 82 o one or more entire headers 84 o the body 86 If the message/sipfrag part contains a body, it must also contain a 87 Content-Length header and the null-line separating headers from the 88 body. 90 2. IANA Considerations 92 The message/sipfrag media type is defined by the following 93 information: 95 Media type name: message 96 Media subtype name: sipfrag 97 Required parameters: none 98 Optional parameters: version 99 version: The SIP-Version number of the enclosed message 100 (e.g., "2.0"). If not present, the version defaults to "2.0". 101 Encoding scheme: SIP messages consist of an 8-bit header optionally 102 followed by a binary MIME data object. As such, SIP messages 103 must be treated as binary. Under normal circumstances SIP 104 messages are transported over binary-capable transports, no 105 special encodings are needed. 106 Security considerations: see below 108 3. Security Considerations 110 A message/sip mime-part may contain sensitive information or 111 information used to affect processing decisions at the receiver. 112 When exposing that information or modifying it during transport would 113 do harm its level of protection can be improved using the S/MIME 114 mechanisms described in section 23 of , with the limitations 115 described in section 26 of that document. 117 References 119 [1] PlaceHolder, A., "Placeholder", RFC 3261, May 2002. 121 [2] Sparks, R., "The REFER Method", draft-ietf-sip-refer-02 (work in 122 progress), September 2001. 124 Author's Address 126 Robert J. Sparks 127 dynamicsoft 128 5100 Tennyson Parkway 129 Suite 1200 130 Plano, TX 75024 132 EMail: rsparks@dynamicsoft.com 134 Full Copyright Statement 136 Copyright (C) The Internet Society (2002). All Rights Reserved. 138 This document and translations of it may be copied and furnished to 139 others, and derivative works that comment on or otherwise explain it 140 or assist in its implementation may be prepared, copied, published 141 and distributed, in whole or in part, without restriction of any 142 kind, provided that the above copyright notice and this paragraph are 143 included on all such copies and derivative works. However, this 144 document itself may not be modified in any way, such as by removing 145 the copyright notice or references to the Internet Society or other 146 Internet organizations, except as needed for the purpose of 147 developing Internet standards in which case the procedures for 148 copyrights defined in the Internet Standards process must be 149 followed, or as required to translate it into languages other than 150 English. 152 The limited permissions granted above are perpetual and will not be 153 revoked by the Internet Society or its successors or assigns. 155 This document and the information contained herein is provided on an 156 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 157 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 158 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 159 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 160 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 162 Acknowledgement 164 Funding for the RFC Editor function is currently provided by the 165 Internet Society.