Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)
obsoleted by
- rfc-4227 — Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)
Extracted elements (24)
The BEEP profile for SOAP does not use the BEEP 'ERR' message for SOAP faults in one-to-one exchanges. Whatever response the server generates—including fault envelopes—is always returned in the 'RPY' message, keeping SOAP-level error semantics separate from BEEP transport-level errors.
The boot exchange serves two distinct purposes: resource identification (each SOAP-profile channel is bound to a single resource/service) and feature negotiation (allowing future SOAP features such as compression to be negotiated at channel setup time rather than requiring new profiles).
Both 'soap.beep' and 'soap.beeps' URL schemes use identical algorithms and parameters for address resolution, including the same SRV service name ('soap-beep') and the same IANA-assigned TCP port. The only difference is the mandatory privacy tuning requirement for 'soap.beeps'.
All implementations MUST provide the following BEEP tuning profiles: SASL/DIGEST-MD5 for authentication, TLS with TLS_RSA_WITH_3DES_EDE_CBC_SHA for confidentiality, and TLS with TLS_RSA_WITH_3DES_EDE_CBC_SHA supporting client-side certificates for both authentication and confidentiality.
Because BEEP provides an 8-bit-wide path, a transformative Content-Transfer-Encoding (e.g., 'base64' or 'quoted-printable') SHOULD NOT be used for multipart/related SOAP messages. MIME requires the 'Content-ID' header value to be globally unique.
If a literal IPv6 address is used in a 'soap.beep' URL, it MUST conform to the syntax specified in RFC 2472. Use of literal IPv6 addresses in URLs is discouraged.
If the boot message is improperly formed, or if the requested resource is not recognized, the server-role peer MUST reply with an error message as defined in Section 7.1 of the BEEP core specification.
One-way message pattern: the client sends a BEEP 'MSG' message containing a SOAP envelope, and the server immediately sends back a 'NUL' message before processing the envelope contents, implementing a one-to-many exchange with no response envelope.
Request/N-responses exchange pattern: the client sends a BEEP 'MSG' containing a SOAP envelope; the server sends back zero or more 'ANS' messages each containing an envelope, followed by a terminating 'NUL' message, implementing a one-to-many exchange for streaming or multi-result responses.
Request-response exchange pattern: the client sends a BEEP 'MSG' containing a SOAP envelope; the server sends back a single 'RPY' message containing a SOAP envelope. SOAP faults are always returned in the 'RPY' message, never in an 'ERR' message.
The BEEP profile for SOAP is identified by the URI 'http://iana.org/beep/soap' in the BEEP 'profile' element during channel creation. The 'serverName' attribute in the 'start' element identifies the virtual host associated with the server-role peer, analogous to HTTP's 'Host' header.
The boot message ('bootmsg') carries a mandatory 'resource' attribute (analogous to HTTP's abs_path Request-URI) and an optional 'features' attribute listing requested optional profile features. The boot response ('bootrpy') echoes a subset of accepted feature tokens; absence means no features are enabled.
The 'soap.beep' URL scheme uses the generic URI syntax with scheme 'soap.beep', a server-based naming authority, and a path component that maps to the 'resource' attribute of the boot message (defaulting to '/' if absent). Both scheme and authority components are case-insensitive.
The 'soap.beeps' URL scheme is identical to 'soap.beep' except that prior to starting the SOAP profile, the BEEP session MUST be tuned for privacy via a transport security profile or a user authentication profile that supports transport security. Both schemes use the same SRV service name, port, and address resolution algorithms.
When a 'soap.beep' URL contains a domain name without a port, the SRV algorithm is used with service parameter 'soap-beep' and protocol 'tcp' to resolve IP/TCP addressing. If no SRV RRs are found, DNS A RRs are queried and the IANA-assigned well-known port is used.
IANA maintains a list of SOAP profile features registered using the template in Section 6.1. Features not registered with IANA must have identifiers starting with 'x-'. The IESG designates an expert reviewer; developers must solicit commentary on beepwg@lists.beepcore.org before contacting the IESG.
IANA registers a well-known TCP port number for 'SOAP over BEEP' (short name: 'soap-beep'), used as the default port when no explicit port or SRV record is provided in a 'soap.beep' or 'soap.beeps' URL.
IANA registers the BEEP profile for SOAP at URI 'http://iana.org/beep/soap', specifying bootmsg/bootrpy as channel-creation messages, SOAP-Env:Envelope as the primary message element, and 'error' for negative replies.
IANA registers the 'soap.beep' URL scheme identifying SOAP resources accessible via the BEEP profile for SOAP over TCP/IP, with syntax defined in Section 5.1 and generic URI character encoding.
IANA registers the 'soap.beeps' URL scheme identifying SOAP resources accessible via the BEEP profile for SOAP after the BEEP session has been tuned for privacy, with syntax defined in Section 5.2.
Implementations may additionally offer MIME-based security services such as OpenPGP (RFC 3156) or S/MIME (RFC 2633) to provide message integrity and confidentiality at the envelope level, independent of BEEP transport-layer security. BEEP-specific security issues are addressed in Section 9 of the BEEP core specification.
The BEEP profile for SOAP has two states: 'boot' and 'ready'. In 'boot', the channel-requesting peer sends a 'bootmsg'; if the other peer responds with 'bootrpy', the channel enters 'ready'. If an 'error' is returned, no state change occurs. In 'ready', either peer may initiate SOAP message patterns; no state change occurs on message exchange.
SOAP envelopes are transmitted as UTF-8-encoded XML using the media type 'application/xml'. Each BEEP MSG frame carries the SOAP-ENV:Envelope element as its payload, with a 'Content-Type: application/xml' header.
SOAP envelopes with attachments may be sent as the root part of a 'multipart/related' content, with subordinate parts referenced via 'Content-ID:' or 'Content-Location:' headers per the SOAP Messages with Attachments specification. The 'start' parameter and 'Content-ID:' on the root part are strongly recommended.