idnits 2.17.1 draft-baker-soap-media-reg-06.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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages 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 17, 2004) is 7277 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) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Baker 3 Internet-Draft Independent 4 Expires: November 15, 2004 M. Nottingham 5 BEA Systems 6 May 17, 2004 8 The "application/soap+xml" media type 9 draft-baker-soap-media-reg-06 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 other 17 groups may also distribute working documents as Internet-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 November 15, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Abstract 38 This document defines the "application/soap+xml" media type which can 39 be used to describe SOAP 1.2 messages serialized as XML 1.0. 41 1. Notational Conventions 43 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 44 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 45 document are to be interpreted as described in [RFC2119]. 47 =0C 49 2. Introduction 51 SOAP version 1.2 (SOAP) is a lightweight protocol intended for 52 exchange of structured information between peers in a decentralized, 53 distributed environment. It defines an extensible messaging framework 54 that contains a message construct based on XML technologies that can 55 be exchanged over a variety of underlying protocols. 57 This specification defines the media type "application/soap+xml" 58 which can be used to identify SOAP 1.2 message envelopes that have 59 been serialized with XML 1.0. Such serializations are useful as the 60 basis of "wire formats" for SOAP 1.2 Protocol Binding Specifications 61 [W3C.REC-soap12-part1-20030624], or in other situations where an XML 62 serialization of a SOAP envelope is required. 64 The "application/soap+xml" media type explicitly identifies SOAP 1.2 65 message envelopes that have been serialised with XML 1.0; message 66 envelopes with a different SOAP namespace version or using another 67 XML serialisation MUST NOT use it. 69 3. Registration 71 MIME media type name: application 72 MIME subtype name: soap+xml 73 Required parameters: none 74 Optional parameters: 75 "charset": This parameter has identical semantics to the charset 76 parameter of the "application/xml" media type as specified in 77 RFC 3023 [RFC3023]. 78 "action": This optional parameter can be used to specify the URI 79 that identifies the intent of the message. In SOAP 1.2, it 80 serves a similar purpose as the SOAPAction HTTP header field 81 did in SOAP 1.1. Namely, its value identifies the intent of the 82 message. 83 The value of the action parameter is an absolute URI-reference 84 as defined by RFC 2396 [RFC2396]. SOAP places no restrictions 85 on the specificity of the URI or that it is resolvable. 86 Although the purpose of the action parameter is to indicate the 87 intent of the SOAP message there is no mechanism for 88 automatically computing the value based on the SOAP envelope. 89 In other words, the value has to be determined out of band. 90 It is recommended that the same value be used to identify sets 91 of message types that are logically connected in some manner, 92 for example part of the same "service". It is strongly 93 RECOMMENDED that the URI be globally unique and stable over 94 time. 96 =0C 97 The presence and content of the action parameter MAY be used by 98 servers such as firewalls to appropriately filter SOAP messages 99 and it may be used by servers to facilitate dispatching of SOAP 100 messages to internal message handlers etc. It SHOULD NOT be 101 used as an insecure form of access authorization. 102 Use of the action parameter is OPTIONAL. SOAP Receivers MAY use 103 it as a hint to optimize processing, but SHOULD NOT require its 104 presence in order to operate. 105 Encoding considerations: Identical to those of "application/xml" as 106 described in RFC 3023 [RFC3023], section 3.2, as applied to the 107 SOAP envelope infoset. 108 Security considerations: Because SOAP can carry application defined 109 data whose semantics is independent from that of any MIME wrapper 110 (or context within which the MIME wrapper is used), one should not 111 expect to be able to understand the semantics of the SOAP message 112 based on the semantics of the MIME wrapper alone. Therefore, 113 whenever using the "application/soap+xml" media type, it is 114 strongly RECOMMENDED that the security implications of the context 115 within which the SOAP message is used is fully understood. The 116 security implications are likely to involve both the specific SOAP 117 binding to an underlying protocol as well as the 118 application-defined semantics of the data carried in the SOAP 119 message (though one must be careful when doing this, as discussed 120 in SOAP 1.2 Part 1 [W3C.REC-soap12-part1-20030624], section 121 Binding to Application-Specific Protocols. 122 Also, see SOAP 1.2 Part 1 [W3C.REC-soap12-part1-20030624], the 123 entire section Security Considerations. 124 In addition, as this media type uses the "+xml" convention, it 125 shares the same security considerations as described in RFC 3023 126 [RFC3023], section 10. 127 Interoperability considerations: There are no known interoperability 128 issues. 129 Published specification: SOAP 1.2 Part 1 130 [W3C.REC-soap12-part1-20030624] and SOAP 1.2 Part 2 131 [W3C.REC-soap12-part2-20030624]. 132 Applications which use this media type: No known applications 133 currently use this media type. 135 Additional information: 136 File extension: SOAP messages are not required or expected to be 137 stored as files. 138 Fragment identifiers: Identical to that of "application/xml" as 139 described in RFC 3023 [RFC3023], section 5. 140 Base URI: As specified in RFC 3023 [RFC3023], section 6. Also see 141 SOAP 1.2 Part 1 [W3C.REC-soap12-part1-20030624], section Use of 142 URIs in SOAP. 144 =0C 146 Macintosh File Type code: TEXT 147 Person and email address to contact for further information: Mark 148 Nottingham 149 Intended usage: COMMON 150 Author/Change controller: The SOAP 1.2 specification set is a work 151 product of the World Wide Web Consortium's XML Protocol Working 152 Group. The W3C has change control over these specifications. 154 4. Security Considerations 156 See the "Security Considerations" section of the registration 157 template found in Section 3. 159 Normative References 161 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 162 Requirement Levels", BCP 14, RFC 2119, March 1997. 164 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 165 Resource Identifiers (URI): Generic Syntax", RFC 2396, 166 August 1998. 168 [RFC3023] Murata, M., St. Laurent, S. and D. Kohn, "XML Media 169 Types", RFC 3023, January 2001. 171 [W3C.REC-soap12-part1-20030624] 172 Hadley, M., Mendelsohn, N., Moreau, J., Nielsen, H. and M. 173 Gudgin, "SOAP Version 1.2 Part 1: Messaging Framework", 174 W3C REC REC-soap12-part1-20030624, June 2003. 176 [W3C.REC-soap12-part2-20030624] 177 Moreau, J., Nielsen, H., Gudgin, M., Hadley, M. and N. 178 Mendelsohn, "SOAP Version 1.2 Part 2: Adjuncts", W3C REC 179 REC-soap12-part2-20030624, June 2003. 181 Authors' Addresses 183 Mark A. Baker 184 Independent 185 37 Charles St. 186 Ottawa, Ontario K1M 1R3 187 CA 189 EMail: mailto:distobj@acm.org 191 =0C 192 Mark Nottingham 193 BEA Systems 194 235 Montgomery St., Level 15 195 San Francisco, CA 94010 196 US 198 EMail: mailto:mnot@pobox.com 200 =0C 202 Intellectual Property Statement 204 The IETF takes no position regarding the validity or scope of any 205 intellectual property or other rights that might be claimed to 206 pertain to the implementation or use of the technology described in 207 this document or the extent to which any license under such rights 208 might or might not be available; neither does it represent that it 209 has made any effort to identify any such rights. Information on the 210 IETF's procedures with respect to rights in standards-track and 211 standards-related documentation can be found in BCP-11. Copies of 212 claims of rights made available for publication and any assurances of 213 licenses to be made available, or the result of an attempt made to 214 obtain a general license or permission for the use of such 215 proprietary rights by implementors or users of this specification can 216 be obtained from the IETF Secretariat. 218 The IETF invites any interested party to bring to its attention any 219 copyrights, patents or patent applications, or other proprietary 220 rights which may cover technology that may be required to practice 221 this standard. Please address the information to the IETF Executive 222 Director. 224 Full Copyright Statement 226 Copyright (C) The Internet Society (2004). All Rights Reserved. 228 This document and translations of it may be copied and furnished to 229 others, and derivative works that comment on or otherwise explain it 230 or assist in its implementation may be prepared, copied, published 231 and distributed, in whole or in part, without restriction of any 232 kind, provided that the above copyright notice and this paragraph are 233 included on all such copies and derivative works. However, this 234 document itself may not be modified in any way, such as by removing 235 the copyright notice or references to the Internet Society or other 236 Internet organizations, except as needed for the purpose of 237 developing Internet standards in which case the procedures for 238 copyrights defined in the Internet Standards process must be 239 followed, or as required to translate it into languages other than 240 English. 242 The limited permissions granted above are perpetual and will not be 243 revoked by the Internet Society or its successors or assignees. 245 This document and the information contained herein is provided on an 246 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 247 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 248 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 250 =0C 251 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 252 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 254 Acknowledgment 256 Funding for the RFC Editor function is currently provided by the 257 Internet Society.