Both 'soap.beep' and 'soap.beeps' URL schemes use identical address resolution algorithms and parameters (same SRV service name, same TCP port), distinguishing only whether session privacy tuning is required.

The BEEP profile for SOAP does not use the BEEP ERR message for SOAP faults; SOAP faults are always returned in RPY (one-to-one) or ANS (one-to-many) messages. ERR is reserved for BEEP-level errors unrelated to the SOAP envelope (e.g., malformed MIME).

The boot message serves two purposes: resource identification (each channel provides access to a single resource) and feature negotiation (allowing optional SOAP features such as compression to be negotiated per-channel). This mirrors HTTP's Host header and abs_path conventions.

RFC 3288 used the profile URI 'http://iana.org/beep/soap' for SOAP 1.1. Implementations supporting SOAP 1.1 should recognize both that legacy URI and 'http://iana.org/beep/soap/1.1' for backward compatibility.

An implementation of this binding MUST support the SOAP Message Exchange Pattern 'http://www.w3.org/2003/05/soap/mep/request-response/'.

BEEP profile for SOAP envelopes SHOULD use the media type 'application/soap+xml'; for compatibility with RFC 3288 it MAY use 'application/xml'.

Conforming implementations MUST support SOAP version 1.2 and MAY support other versions, such as SOAP version 1.1.

security

To avoid deadlock during streaming, the requesting SOAP node MUST be able to process incoming SOAP response information while the SOAP request is still being transmitted.

When an implementation supports MTOM/XOP, it SHOULD support the MIME Multipart/Related XOP Package format and MAY support additional formats.

A one-way message is implemented via a one-to-many BEEP exchange: the client sends a MSG containing a SOAP envelope and the server immediately returns a NUL message before processing the envelope.

A request/N-responses exchange is implemented via a one-to-many BEEP exchange: the client sends a MSG containing a SOAP envelope, and the server sends zero or more ANS messages each containing an envelope, followed by a NUL message.

A request-response exchange is implemented via a one-to-one BEEP exchange: the client sends a MSG containing a SOAP envelope and the server returns an RPY message containing a SOAP envelope.

The BEEP profile for SOAP is identified by the URI 'http://iana.org/beep/soap/VERSION' in the BEEP 'profile' element during channel creation, where VERSION is the numeric SOAP version (e.g., '1.2').

The 'bootmsg' element carries a mandatory 'resource' attribute (analogous to HTTP's abs_path Request-URI) and an optional 'features' attribute listing requested optional features. The 'bootrpy' element carries an optional 'features' attribute listing the accepted subset of features.

The 'soap.beep' URL scheme uses the generic URI syntax with 'soap.beep' as the scheme, a server-based naming authority for the host, and a path component mapping to the 'resource' attribute of the boot message (defaulting to '/' if absent).

dns

The 'soap.beeps' URL scheme is identical to 'soap.beep' except that the BEEP session must be tuned for privacy (via a transport security profile or a user authentication profile supporting transport security) before the SOAP profile starts.

security, tls

When the soap.beep URL authority contains a domain name with no port, the DNS SRV record algorithm is used with service 'soap-beep' and protocol 'tcp'; if no SRV RRs are found, the IANA-assigned well-known port is used.

dns

IANA registers 'SOAP over BEEP' as a well-known TCP port number (short name: 'soap-beep') for use when no SRV record is present.

registry

IANA registers the 'soap.beep' URL scheme identifying a SOAP resource made available using the BEEP profile for SOAP over TCP.

registry

IANA registers the 'soap.beeps' URL scheme identifying a SOAP resource made available using the BEEP profile for SOAP after the BEEP session has been tuned for privacy.

registry

IANA registers the URI prefix 'http://iana.org/beep/soap/VERSION' for the family of BEEP profiles for SOAP (one per SOAP version), superseding the earlier 'http://iana.org/beep/soap' registered for RFC 3288.

registry

All implementations MUST provide tuning profiles for authentication (SASL/DIGEST-MD5), confidentiality (TLS with TLS_RSA_WITH_AES_EDE_CBC_SHA), and both combined (TLS with client-side certificates). Implementations may additionally offer MIME-based security such as OpenPGP or S/MIME.

security, tls, crypto

The BEEP profile for SOAP has two states: 'boot' and 'ready'. In 'boot', the requesting peer sends a 'bootmsg'; receiving a 'bootrpy' transitions to 'ready', while receiving an 'error' leaves the state unchanged. In 'ready', either peer may initiate SOAP message patterns; no state change occurs during message exchange.

The requesting SOAP node state machine has states: Init (formulate BEEP message, begin transmission) → Requesting (transmit request, await response; on ERR → Fail, otherwise → Sending+Receiving) → Sending+Receiving (complete request/response; on completion → Success). Success and Fail are terminal states.

The responding SOAP node state machine has states: Init (await inbound request; may only generate ERR) → Receiving (receive request, prepare response) → Receiving+Sending (complete receiving/sending) → Success. Success and Fail are terminal states.