RFC 4227

Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)

📅 published January 2006, from ietf

RFC 4227: Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP) 🎀

Okay bestie, this one is from the Network Working Group 🌸. It was written by E. O'Tuathail of Clipcode.com and M. Rose of Dover Beach Consulting, Inc., and it's dated January 2006. It's a Standards Track document, which means it's a real protocol spec people are supposed to implement. It also obsoletes RFC 3288, so it replaces that older one. Main character energy 👑

Status of This Memo ✨

This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💬. If you want the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🦋.

Copyright (C) The Internet Society (2006). 💜

Abstract

Okay so this memo is all about a Simple Object Access Protocol (SOAP) binding to the Blocks Extensible Exchange Protocol (BEEP) core 🧚. A SOAP binding is basically just a description of how SOAP messages actually get sent across the network, and that's the whole point 🫶.

SOAP is an XML-based (eXtensible Markup Language) messaging protocol, and it's used to build all kinds of distributed messaging models 💅. It defines a message format and a bunch of message patterns, including (but not limited to) Remote Procedure Calling (RPC), asynchronous event notification, unacknowledged messages, and forwarding through SOAP intermediaries ✨.

Table of Contents 🌈

1. Introduction ....................................................3
2. BEEP Profile Identification .....................................3
   2.1. Profile Initialization .....................................4
3. SOAP Message Packages ...........................................6
4. SOAP Message Patterns ...........................................8
   4.1. One-Way Message ............................................8
   4.2. Request-Response Exchange ..................................8
   4.3. Request/N-Responses Exchange ...............................8
   4.4. Error Handling .............................................9
5. SOAP Protocol Binding Framework Conformance .....................9
   5.1. Binding Name ...............................................9
   5.2. Base URI ...................................................9
   5.3. Supported SOAP Message Exchange Patterns ...................9
   5.4. Supported Features .........................................9
   5.5. MEP Operation .............................................10
        5.5.1. Behavior of Requesting SOAP Node ...................10
               5.5.1.1. Init ......................................10
               5.5.1.2. Requesting ................................10
               5.5.1.3. Sending+Receiving .........................10
               5.5.1.4. Success and Fail ..........................11
        5.5.2. Behavior of Responding SOAP Node ...................11
               5.5.2.1. Init ......................................11
               5.5.2.2. Receiving .................................11
               5.5.2.3. Receiving+Sending .........................11
               5.5.2.4. Success and Fail ..........................11
6. URL Schemes ....................................................11
   6.1. The soap.beep URL Scheme ..................................11
        6.1.1. Resolving IP/TCP Address Information ...............12
   6.2. The soap.beeps URL Scheme .................................13
7. Registration Templates .........................................13
   7.1. SOAP Profile Feature Registration Template ................13
8. Initial Registrations ..........................................13
   8.1. Registration: The SOAP Profile ............................13
   8.2. Registration: The soap.beep URL Scheme ....................14
   8.3. Registration: The soap.beeps URL Scheme ...................14
   8.4. Registration: The System (Well-Known) TCP Port
        Number for SOAP ...........................................15
9. Security Considerations ........................................15
10. IANA Considerations ...........................................16
11. Changes from RFC 3288 .........................................16
12. Acknowledgements ..............................................17
13. References ....................................................17
   13.1. Normative References .....................................17
   13.2. Informative References ...................................18
A. Appendix - SOAP with Attachments (Informative) .................19

1. Introduction ✨

This memo explains how SOAP envelopes [15] get transmitted over a BEEP profile [1] 🦋. Conforming implementations MUST support SOAP version 1.2 [15] and MAY support other versions, like SOAP version 1.1 [17] 💖. Yep, we're saying the "how SOAP envelopes get transmitted over a BEEP profile" bit twice, because the original does too 🙈 It's the same fact, just extra sparkly. Unlike its predecessor, RFC3288 [16], this memo does not require the use of SOAP version 1.1 🎀.

Throughout this memo, the word "envelope" means the top-level element that SOAP senders and receivers swap 📬. For example, when we're talking about SOAP version 1.2, "envelope" refers to the "Envelope" element defined in Section 5.1 of [2] 💅. We also use the terms "peer", "client", "server", "one-to-one", and "one-to-many" in the context of BEEP 🧚. If you want the deep dive on BEEP roles and exchange styles, Sections 2.1 and 2.1.1 of [1] have you covered 🫶.

2. BEEP Profile Identification 🌸

The BEEP profile for SOAP is identified as:

    http://iana.org/beep/soap/VERSION

You put that in the BEEP "profile" element when you create a channel 🦋. Here, "VERSION" is the numeric version of the SOAP specification 💜.

For example:

    http://iana.org/beep/soap/1.2

refers to version 1.2 ✨.

Note that RFC 3288 [16] used http://iana.org/beep/soap to identify the profile for SOAP version 1.1 envelopes [17] 👑. If an implementation of this memo chooses to implement SOAP version 1.1, then it should support both this Uniform Resource Identifier (URI) for profile identification and "http://iana.org/beep/soap/1.1" 🌈. Notice that "should" is lowercase here, so it's a suggestion and not a hard rule 🙈.

In BEEP, when the first channel gets created successfully, the "serverName" attribute in the "start" element tells you which "virtual host" belongs to the peer acting in the server role 🏠. Here's what that looks like:

    <start number='1' serverName='stockquoteserver.example.com'>
        <profile uri='http://iana.org/beep/soap/1.2' />
    </start>

The "serverName" attribute is analogous to HTTP's "Host" request-header field (cf. Section 14.23 of [4]) 💖.

There are two states in the BEEP profile for SOAP, "boot" and "ready" 🎀:

  • In the "boot" state, the peer that's requesting the channel sends a "bootmsg" (either during channel initialization or in a "MSG" message) 🚀.
    • If the other peer sends back a "bootrpy" (either during channel initialization or in an "RPY" message), then the "ready" state gets entered 💫.
    • Otherwise, the other peer sends an "error" (either during channel initialization or in an "ERR" message), and then no state change happens 💀.
  • In the "ready" state, either peer starts a SOAP message pattern by sending a "MSG" message containing an envelope 🧚. The other peer finishes the message pattern either by:
    • sending back an "RPY" message containing an envelope, or
    • sending back zero or more "ANS" messages, each containing an envelope, followed by a "NUL" message.

Either way, no state change happens 🫶.

2.1. Profile Initialization 🦋

The boot message does two jobs 🌟:

  • resource identification: each channel bound to the BEEP profile for SOAP gives you access to a single resource (a network data object or service) 📦.
  • feature negotiation: if new features of SOAP (such as compression) show up, their use can be negotiated 🎁.

The DTD syntax for the boot message and its response looks like this 💅:

    <!ELEMENT bootmsg     EMPTY>
    <!ATTLIST bootmsg
              resource    CDATA             #REQUIRED
              features    NMTOKENS          "">

    <!ELEMENT bootrpy     EMPTY>
    <!ATTLIST bootrpy
              features    NMTOKENS          "">

The boot message has one mandatory attribute and one optional attribute 🎀:

  • the "resource" attribute, which is analogous to HTTP's "abs_path" Request-URI parameter (cf. Section 5.1.2 of [4]), and
  • the "features" attribute, which, if present, contains one or more feature tokens. Each token indicates an optional feature of the BEEP profile for SOAP that's being requested for possible use over the channel 🌸.

Section 7.1 defines a registration template for optional features 📝.

If the peer acting in the server role recognizes the requested resource, it replies with a boot response that has one optional attribute 💜:

  • The "features" attribute, if present, contains a subset of the feature tokens from the boot message. It tells you which features may be used over the channel. (If it's not present or it's empty, then no features may be used 🙅.)

Otherwise, if the boot message is improperly formed, or if the requested resource isn't recognized, the peer acting in the server role replies with an error message (cf. Section 7.1 of [1]) 💀. Usually, the boot message and its response get exchanged during channel initialization (cf. Section 2.3.1.2 of [1]) ✨.

Here's an example where the boot message and its response get exchanged during channel initialization 🧚:

    C: <start number='1' serverName='stockquoteserver.example.com'>
    C:     <profile uri='http://iana.org/beep/soap/1.2'>
    C:         <![CDATA[<bootmsg resource='/StockQuote' />]]>
    C:     </profile>
    C: </start>
    S: <profile uri='http://iana.org/beep/soap/1.2'>
    S:     <![CDATA[<bootrpy />]]>
    S: </profile>

And just like that, the channel bound to the BEEP profile for SOAP is in the "ready" state 🎉🔥.

Here's another example where the boot exchange doesn't work out 😭:

    C: <start number='1' serverName='stockquoteserver.example.com'>
    C:     <profile uri='http://iana.org/beep/soap/1.2'>
    C:         <![CDATA[<bootmsg resource='/StockPick' />]]>
    C:     </profile>
    C: </start>

    S: <profile uri='http://iana.org/beep/soap/1.2'>
    S:     <![CDATA[<error code='550'>resource not
    S:                                supported</error>]]>
    S: </profile>

Even though the channel got created successfully, it stays in the "boot" state 🥺.

3. SOAP Message Packages ✨

okay so the BEEP profile for SOAP sends envelopes encoded as UTF-8, and it SHOULD use the media type "application/soap+xml" [5] 💅 here's what a message looks like:

MSG 1 1 . 0 284
Content-Type: application/soap+xml

<env:Envelope
     xmlns:env="http://www.w3.org/2003/05/soap-envelope">
  <env:Header>
   <m:GetLastTradePrice xmlns:m="Some-URI" />
  </env:Header>
  <env:Body>
    <symbol xmlns:p="Some-URI" >DIS</symbol>
  </env:Body>
</env:Envelope>
END

bestie, to keep things compatible with RFC 3288 [16], it MAY use the media type "application/xml" [6] 🎀

also, an implementation of the BEEP profile for SOAP MAY support sending envelopes with the MTOM [7] / XOP [8] packaging technique 🦋 it looks like this:

MSG 1 2 . 283 1436
MIME-Version: 1.0
Content-Type: Multipart/Related;boundary=MIME_boundary;
    type="application/xop+xml";
    start="<mymessage.xml@example.org>";
    startinfo="application/soap+xml; action=
Content-Description: A SOAP message with my pic and sig in it

--MIME_boundary
Content-Type: application/xop+xml;
    charset=UTF-8;
    type="application/soap+xml; action=
Content-Transfer-Encoding: 8bit
Content-ID: <mymessage.xml@example.org>

<soap:Envelope
    xmlns:soap='http://www.w3.org/2003/05/soap-envelope'
    xmlns:xmlmime='http://www.w3.org/2004/11/xmlmime'>
  <soap:Body>
    <m:data xmlns:m='http://example.org/stuff'>
      <m:photo
  xmlmime:contentType='image/png'><xop:Include
    xmlns:xop='http://www.w3.org/2004/08/xop/include'
    href='cid:http://example.org/me.png'/></m:photo>
      <m:sig
  xmlmime:contentType='application/pkcs7-signature'><xop:Include
    xmlns:xop='http://www.w3.org/2004/08/xop/include'
    href='cid:http://example.org/my.hsh'/></m:sig>
    </m:data>
  </soap:Body>
</soap:Envelope>

--MIME_boundary
Content-Type: image/png
Content-Transfer-Encoding: binary
Content-ID: <http://example.org/me.png>

// binary octets for png

--MIME_boundary
Content-Type: application/pkcs7-signature
Content-Transfer-Encoding: binary
Content-ID: <http://example.org/my.hsh>
// binary octets for signature

--MIME_boundary--
END

for MIME Multipart/Related usage, go read Section 4.1 of XOP [8] 🤓 BEEP gives you an 8-bit-wide path, so a "transformative" Content-Transfer-Encoding (like "base64" or "quoted-printable") should not be used. Also, MIME [9] says the "Content-ID" header value has to be globally unique, so be careful with that one 👀

As Section 4 of XOP [8] says, XOP can be used with lots of different packaging mechanisms. When a BEEP-in-SOAP implementation does support MTOM/XOP, it SHOULD support the MIME Multipart/Related XOP Package format, and MAY support others. Future formats could include BEEP-specific XOP packages, like sending attachments on a different channel from the SOAP channel. That would skip searching for the MIME boundary tags and allow lazy delivery, so attachments only get delivered when they're really needed ✨

4. SOAP Message Patterns 🌈

4.1. One-Way Message

A one-way message means sending a message with no response coming back 🕊️

The BEEP profile for SOAP does this with a one-to-many exchange. The client sends a MSG message containing an envelope, and the server immediately sends back a NUL message, before it processes the contents of the envelope 💨

4.2. Request-Response Exchange

A request/response exchange means sending a request and getting a response back 💌

The BEEP profile for SOAP does this with a one-to-one exchange. The client sends a MSG message containing an envelope, and the server sends back a RPY message containing an envelope 🫶

4.3. Request/N-Responses Exchange

A request/N-responses exchange means sending a request that gets zero or more responses back 🧚

The BEEP profile for SOAP does this with a one-to-many exchange. The client sends a MSG message containing an envelope, and the server sends back zero or more ANS messages, each containing an envelope, followed by a NUL message 🍓

4.4. Error Handling

The BEEP profile for SOAP doesn't use the ERR message for SOAP faults. In one-to-one exchanges, whatever SOAP response the server generates (including SOAP faults) always comes back in the RPY message. In one-to-many exchanges, whatever SOAP response the server generates (including SOAP faults) always comes back in the ANS messages 🙈

If there's an error with the BEEP message that has nothing to do with the SOAP envelope (like a poorly formed MIME message or an unsupported MIME Content-Type), then the server responds with an ERR message (see Section 7.1 of [1]) with an appropriate reply code (for example, see Section 8 of [1]) 💀

5. SOAP Protocol Binding Framework Conformance 👑

5.1. Binding Name

This binding is identified by a URI that's exactly the same as the profile URI for BEEP in SOAP (see Section 2) 🏷️

5.2. Base URI

The Base URI for the SOAP envelope is the URI of the resource identified in the bootmsg 🗺️

5.3. Supported SOAP Message Exchange Patterns

An implementation of this binding MUST support the following SOAP Message Exchange Pattern (MEP) 🚨

5.4. Supported Features

An implementation of this binding MAY support the following feature: "http://www.w3.org/2003/05/soap/features/action/" (see Section 6.5 of [3].) 🎁

5.5. MEP Operation

For binding instances that conform to this specification:

5.5.1. Behavior of Requesting SOAP Node

The overall flow for a requesting SOAP node follows a state machine description that's consistent with Section 6.2 of [3] 🔄

To avoid deadlock during streaming (see Section 6.2.3 of [3]), the requesting SOAP node MUST be able to process incoming SOAP response information while the SOAP request is still being transmitted. This one is super important, no cap 🔥

5.5.1.1. Init

In the "Init" state, a BEEP message is formulated according to Section 3, transmission of the message begins, and then the state changes to "Requesting" 🚀

5.5.1.2. Requesting

In the "Requesting" state, more of the request message is sent and the node waits for the response to arrive. When the beginning of the response message shows up, if it's a BEEP ERR message, the state moves to "Fail". Otherwise, the state moves to "Sending+Receiving" 👀

5.5.1.3. Sending+Receiving

In the "Sending+Receiving" state, sending the request message and receiving the response message both get finished. The response message is assumed to contain a SOAP envelope serialized according to the rules for carrying SOAP messages in the media type given in the Content-Type header field. Once the response is fully received, the state moves to "Success" ✅

5.5.1.4. Success and Fail

"Success" and "Fail" are the terminal states for the state machine 🏁

5.5.2. Behavior of Responding SOAP Node

The overall flow for a responding SOAP node follows a state machine description that's consistent with Section 6.2 of [3] 🪞

5.5.2.1. Init

In the "Init" state, the binding waits for the inbound request to start. In this state, it may only generate ERR messages (in accordance with Section 4.4) 🧸

5.5.2.2. Receiving

The binding starts receiving the request message and gets the start of the response ready, according to Section 3. When it's ready to send the response, the state moves to "Receiving+Sending" 📥

5.5.2.3. Receiving+Sending

The binding finishes receiving the request and sending the response, and then moves to the "Success" state 📤

5.5.2.4. Success and Fail

"Success" and "Fail" are the terminal states that show the message exchange is complete 🎉

6. URL Schemes 🔗

This memo defines two URL schemes, "soap.beep" and "soap.beeps", which identify the use of SOAP over BEEP over TCP. Note that, for now, a "generic" URL scheme for SOAP isn't defined 🙅‍♀️

6.1. The soap.beep URL Scheme

The "soap.beep" URL scheme uses the "generic URI" syntax defined in Section 3 of [10], specifically:

  • the value "soap.beep" is used for the scheme component, and
  • the server-based naming authority defined in Section 3.2.2 of [10] is used for the authority component.
  • the path component maps to the "resource" component of the boot message sent during profile initialization (if it's absent, it defaults to "/").

The scheme and authority components are both case-insensitive, so no stress about capitals 💜

For example, the URL

soap.beep://stockquoteserver.example.com/StockQuote

might result in the example shown in Section 2.1 ✨

6.1.1. Resolving IP/TCP Address Information

The "soap.beep" URL scheme indicates the use of the BEEP profile for SOAP running over TCP/IP 🌐

If the authority component has a domain name and a port number, like this:

soap.beep://stockquoteserver.example.com:1026

then DNS is queried for the A Resource Records for that domain name, and the port number is used directly 📡

If the authority component has a domain name and no port number, like this:

soap.beep://stockquoteserver.example.com

then the Service Record algorithm [11] is used with a service parameter of "soap-beep" and a protocol parameter of "tcp" to work out the IP/TCP addressing information. If no appropriate SRV RRs are found (for example, for "_soap-beep._tcp.stockquoteserver.example.com"), then DNS is queried for the A RRs for the domain name, and the port number used is the one IANA assigned for the registration in Section 8.4 🔍

If the authority component has an IP address, like this:

soap.beep://192.0.2.0:1026

then DNS is not queried, and the IP address is used directly. If a port number is present, it's used directly. Otherwise, the port number used is the one IANA assigned for the registration in Section 8.4 🧭

Literal IPv6 addresses in URLs are discouraged, but if one is used in a "soap.beep" URL, it must conform to the syntax specified in [12] 🫧

6.2. The soap.beeps URL Scheme ✨

okay so the "soap.beeps" URL scheme is basically the same as "soap.beep" from Section 6.1 🎀 literally identical in every way, EXCEPT the BEEP session has to be tuned for privacy before you start the BEEP profile for SOAP 🔒 bestie, this is the secure lane. Both schemes use the exact same address resolution algorithms and parameters from Section 6.1.1 (so same service name for SRV lookups, same TCP port, all of it) 💅

there are two ways to get privacy tuning on a BEEP session:

  • a transport security profile gets successfully started, or
  • a user authentication profile that supports transport security gets successfully started.

either way 🫶 once negotiation finishes, there's a tuning reset and both BEEP peers send a brand new greeting. if you want to see how a BEEP peer can pick different greetings depending on whether privacy is on, check out Section 3 of [1] 🦋

7. Registration Templates 🌸

7.1. SOAP Profile Feature Registration Template 💖

when you register a feature for the BEEP profile for SOAP, you have to supply this info:

Feature Identification: specify a string that identifies this
   feature.  Unless the feature is registered with the IANA, the
   feature's identification must start with "x-".

Feature Semantics: specify the semantics of the feature.

Contact Information: specify the electronic contact information for
   the author of the feature.

8. Initial Registrations 📝

8.1. Registration: The SOAP Profile 🧚

Profile Identification: http://iana.org/beep/soap/VERSION
Messages exchanged during Channel Creation: bootmsg, bootrpy

Messages starting one-to-one exchanges: bootmsg, a SOAP "envelope"

Messages in positive replies: bootrpy, a SOAP "envelope"

Messages in negative replies: error

Messages in one-to-many exchanges: a SOAP "envelope"

Message Syntax: a SOAP envelope

Message Semantics: corresponds to the relevant SOAP specification,
   e.g., for SOAP version 1.2, cf. [2].

Contact Information: Eamon O'Tuathail <eamon.otuathail@clipcode.com>,
   Marshall Rose <mrose@dbc.mtview.ca.us>

8.2. Registration: The soap.beep URL Scheme 🦋

URL scheme name: soap.beep

URL scheme syntax: cf. Section 6.1

Character encoding considerations: cf. the "generic URI" syntax
   defined in Section 3 of [10]

Intended usage: identifies a SOAP resource made available using the
   BEEP profile for SOAP

Applications using this scheme: cf. "Intended usage", above

Interoperability considerations: n/a

Security Considerations: cf. Section 9

Relevant Publications: cf. [2] for SOAP version 1.2

Contact Information: Eamon O'Tuathail <eamon.otuathail@clipcode.com>,
   Marshall Rose <mrose@dbc.mtview.ca.us>

Author/Change controller: the IESG

8.3. Registration: The soap.beeps URL Scheme 🔐

URL scheme name: soap.beeps

URL scheme syntax: cf. Section 6.2
Character encoding considerations: cf. the "generic URI" syntax
   defined in Section 3 of [10]

Intended usage: identifies a SOAP resource made available using the
   BEEP profile for SOAP after the BEEP session has been tuned for
   privacy

Applications using this scheme: cf. "Intended usage", above

Interoperability considerations: n/a

Security Considerations: cf. Section 9

Relevant Publications: cf. [2] for SOAP version 1.2

Contact Information: Eamon O'Tuathail <eamon.otuathail@clipcode.com>,
   Marshall Rose <mrose@dbc.mtview.ca.us>

Author/Change controller: the IESG

8.4. Registration: The System (Well-Known) TCP Port Number for SOAP over BEEP 🔌

Protocol Number: TCP

Message Formats, Types, Opcodes, and Sequences: cf. Section 2.1

Functions: cf. [2] for SOAP version 1.2

Use of Broadcast/Multicast: none

Proposed Name: SOAP over BEEP

Short name: soap-beep

Contact Information: Eamon O'Tuathail <eamon.otuathail@clipcode.com>,
   Marshall Rose <mrose@dbc.mtview.ca.us>

9. Security Considerations 🚨

okay this part is SERIOUS 😭 even though service provisioning is a policy matter, at a minimum, all implementations MUST provide these tuning profiles:

furthermore, implementations may choose to offer MIME-based security services that give message integrity and confidentiality, like OpenPGP [13] or S/MIME [14] 🎀

regardless, check out Section 9 of [1]'s for a discussion of BEEP-specific security issues. no cap, do not skip this one 🙈

10. IANA Considerations 🌈

previously, the IANA registered http://iana.org/beep/soap for use with RFC 3288 [16]. this memo requires that the IANA register a URI-prefix of

http://iana.org/beep/soap/VERSION

to correspond to the family of profiles defined Section 8.1.

the IANA has registered "soap.beep" and "soap.beeps" as URL schemes, as specified in Section 8.2 and Section 8.3, respectively. the IANA has also registered "SOAP over BEEP" as a TCP port number, as specified in Section 8.4 🔌

the IANA now broadens these three registries to support the family of BEEP profiles defined by this URI prefix ✨

finally, the IANA maintains a list of SOAP profile features, cf. Section 7.1. the IESG is responsible for assigning a designated expert to review the specification before the IANA makes the assignment. before contacting the IESG, developers of SOAP profile features must use the mailing list beepwg@lists.beepcore.org to solicit commentary 💌

11. Changes from RFC 3288 🔄

this memo differs from RFC 3288 [16] in one substantive way: a URL prefix is defined to support a family of BEEP profiles that correspond to different versions of SOAP 👑 similarly, the IANA registrations in Section 8.1, Section 8.3, and Section 8.4 are updated to reflect this broadening.

support for W3C MTOM/XOP packaging has been added 📦

a new section was added to discuss the distributed state machine of the Request-Response MEP 🧠

in non-substantive ways, a small number of typos were fixed 💅

12. Acknowledgements 🫶

the authors gratefully thank: Christopher Ferris, Huston Franklin, Alexey Melnikov, Bill Mills, and Roy T. Fielding 💜

13. References 📚

13.1. Normative References 🔥

[1] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.

[2] Nielsen, H., Mendelsohn, N., Gudgin, M., Hadley, M., and J. Moreau, "SOAP Version 1.2 Part 1: Messaging Framework", W3C REC REC-soap12-part1-20030624, June 2003.

[3] Nielsen, H., Hadley, M., Moreau, J., Mendelsohn, N., and M. Gudgin, "SOAP Version 1.2 Part 2: Adjuncts", W3C REC REC-soap12-part2-20030624, June 2003.

[4] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

[5] Baker, M. and M. Nottingham, "The "application/soap+xml" media type", RFC 3902, September 2004.

[6] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.

[7] Nottingham, M., Mendelsohn, N., Gudgin, M., and H. Ruellan, "SOAP Message Transmission Optimization Mechanism", W3C REC REC-soap12-mtom-20050125, January 2005.

[8] Nottingham, M., Mendelsohn, N., Gudgin, M., and H. Ruellan, "XML-binary Optimized Packaging", W3C REC REC-xop10-20050125, January 2005.

[9] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.

[10] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.

[11] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.

[12] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.

[13] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.

[14] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.

13.2. Informative References 🧚

[15] Mitra, N., "SOAP Version 1.2 Part 0: Primer", W3C REC REC-soap12-part0-20030624, June 2003.

[16] O'Tuathail, E. and M. Rose, "Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)", RFC 3288, June 2002.

[17] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, N., Nielsen, H., Thatte, S., and D. Winer, "Simple Object Access Protocol (SOAP) 1.1", W3C NOTE NOTE-SOAP-20000508, May 2000.

[18] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998.

[19] Barton, J., Thatte, S., and H. Nielsen, "SOAP Messages with Attachments", W3C NOTE NOTE-SOAP-attachments-20001211, December 2000.

[20] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998.

[21] Palme, J., Hopmann, A., and N. Shelness, "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC 2557, March 1999.

Appendix A. SOAP with Attachments (Informative) 🎁

to stay compatible with RFC3288 [16], a BEEP profile for SOAP MAY allow envelopes to be sent as the root part of a "multipart/related" [18] content, with subordinate parts referenced using the rules of Section 3 of [19] (so either the "Content-ID:" [20] or "Content-Location:" [21] headers), e.g.,

MSG 1 2 . 278 657
Content-Type: multipart/related; boundary="MIME_boundary";
              type=application/xml;
              start="<claim061400a.xml@claiming-it.com>"

--MIME_boundary
Content-Type: application/xml
Content-ID: <claim061400a.xml@claiming-it.com>

<?xml version='1.0' ?>
<env:Envelope
     xmlns:env="http://www.w3.org/2003/05/soap-envelope">
 ..
</env:Header>
<env:Body>
<theSignedForm href="cid:claim061400a.tiff@claiming-it.com" />
 ..
</env:Body>
</env:Envelope>

--MIME_boundary
Content-Type: image/tiff
Content-Transfer-Encoding: binary
Content-ID: <claim061400a.tiff@claiming-it.com>

 ...binary TIFF image...
--MIME_boundary--
END

consistent with Section 2 of [19], it is strongly recommended that the multipart contain a "start" parameter, and that the root part contain a "Content-ID:" header. however, because BEEP gives you an 8bit-wide path, a "transformative" Content-Transfer-Encoding (e.g., "base64" or "quoted-printable") should not be used 🙅‍♀️ further note that MIME [9] requires the value of the "Content-ID" header to be globally unique 🌍

Authors' Addresses 💌

Eamon O'Tuathail
Clipcode.com
24 Thomastown Road
Dun Laoghaire
Dublin
IE

Phone: +353 1 2350 424
EMail: eamon.otuathail@clipcode.com
URI:   http://www.clipcode.com/


Marshall T. Rose
Dover Beach Consulting, Inc.
POB 255268
Sacramento, CA  95865-5268
US

Phone: +1 916 483 8878
EMail: mrose@dbc.mtview.ca.us

Copyright (C) The Internet Society (2006).

Okay bestie, the authors still own their stuff, but this doc is under the BCP 78 rules, so check those out before you do anything wild 🎀. The authors keep all their rights except where BCP 78 says otherwise.

Also, the whole thing comes as-is, no guarantees 🫶. The contributor, whichever org they rep, and the Internet Society plus the IETF all say "no warranties," whether they're stated outright or implied. That covers things like not infringing anyone's rights, being sellable, and being fit for a specific purpose 😭. Not a flex, just legal being legal.

Intellectual Property 🦋

Lowkey the IETF isn't picking a side on patents or other IP claims about the tech in this doc 💅. It doesn't say whether you can get a license for them, and it hasn't checked whether any exist. The rules for RFC rights live in BCP 78 and BCP 79, so go there if you're curious.

If someone filed IPR disclosures with the IETF Secretariat, you can find them, along with any license promises or attempts to get permission for implementers or users, on the IETF online IPR repository at http://www.ietf.org/ipr 🧚.

The IETF also wants you to speak up if you know about any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard. Send that info to ietf-ipr@ietf.org and they'll take it from there 🍓.

Acknowledgement 🌈

The RFC Editor function gets funded through the IETF Administrative Support Activity (IASA), so shout out to them for keeping the lights on ⭐.

📦 where this page comes from