Before a Stream Initiation is attempted the Sender should be sure that the Receiver supports both Stream Initiation and the specific profile that they wish to use. This is typically accomplished using &xep0030;:

The Receiver advertises the "http://jabber.org/protocol/si" namespace as a feature to represent that they implement this document. The specific profiles are also announced this way; they can be found by looking for "http://jabber.org/protocol/si/profile/profile-name". Shown in the result is a potential file transfer profile:

Once support is determined, the Sender starts the negotiation with the Receiver by sending an &IQ; stanza of type "set", such as in the following example from &xep0096;:

At this point the Receiver can view the profile and other information to decide if they wish to accept the Stream Initiation. If acceptable the Receiver MUST select one of the presented stream types to use.

If the profile describes data to be sent back in the result it MUST be present as described in the profile's specification.

If none of the stream types are acceptable, or if the profile is not understood, the Receiver MUST reply with a "bad request" error:

If the Receiver rejects the request, they reply with a "forbidden" error:

At this point, the Sender and Receiver make any preparations necessary for the stream to be used. The exact process is specific to each protocol, and is beyond the scope of this document. This step now marks the end of SI's responsibilities.

The <si/> element is the root element for this protocol. It is an identifiable container for all the information necessary for negotiation and signalling. It contains attributes for the identifier, intended MIME-type, and profile. The contents convey stream-negotation and profile information.

The "id" attribute is an opaque identifier. This attribute MUST be present on type='set', and MUST be a valid string. This SHOULD NOT be sent back on type='result', since the <iq/> "id" attribute provides the only context needed. This value is generated by the Sender, and the same value MUST be used throughout a session when talking to the Receiver.

The "mime-type" attribute identifies the MIME-type for the data across the stream. This attribute MUST be a valid MIME-type as registered with &IANA; (specifically, as listed at <http://www.iana.org/assignments/media-types>). During negotiation, this attribute SHOULD be present, and is otherwise not required. If not included during negotiation, its value is assumed to be "binary/octect-stream".

The "profile" attribute defines the SI profile in use. This value MUST be present during negotiation, and is the namespace of the profile to use.

When the Sender first negotiates a Stream Initiation, all of the attributes SHOULD be present, and the id" and "profile" MUST be present. The contents MUST contain one profile, in the namespace declared in the "profile" attribute, and the feature negotiation for the stream. The feature negotiation MUST contain at least one option and use the field var "stream-method".

When the Receiver accepts a Stream Initiation, the <si/> element SHOULD NOT possess any attributes. The selected stream MUST be in the feature negotiation for the stream. There MUST only be one selected stream.

To simplify the discussion on error conditions, this document uses the following mapping between namespace URIs and namespace prefixesThis mapping is provided for the purpose of simplifying this discussion, and is not intended to be used in the actual protocol..

Below are the most common errors that can result.

For further information about the relationship between XMPP error handling and "legacy" (HTTP-style) error codes, refer to &xep0086;.

Stream Initiation on its own is of limited use; the Receiver almost always requires some reason for SI. Knowing this allows the Receiver to make a more educated choice about whether or not to accept the stream. This information is provided in Stream Initiation via a profile. A profile is a collection of information that describes the reason for and structure of the stream data, including what the data represents and what stream protocols are expected to be supported.

The initial request for Stream Initiation MUST have only one profile, and this profile is in its own namespace. The profile is indicated not only by the presence of a "root" element in that particular namespace, but also be the "profile" attribute in <si/> The SUGGESTED format for profile namespaces is:

The information that the profile presents SHOULD be defined in an official XEP. The XEP defining the profile SHOULD contain explanations of what the profile consists of and MUST define the profile in a complete manner using DTD, Schema or another appropiate definition language.

A profile SHOULD define what stream protocols MUST be supported, and MUST define what stream protocols MAY be supported. If a profile specifies only a single stream protocol that MUST be supported (even if others MAY also be supported), the "fneg" for the stream protocol may be omitted from the initial <si/>; the receiving entity then assumes the stream protocol that MUST be supported is the one to use.

This document does not define any profiles, nor does it place any restrictions on what type of information a profile should detail. Other specifications will define profiles to be used with Stream Initiation.

While Stream Initiation is not directly required for stream usage, it does provide many benefits. In order to fully appreciate these benefits, streams must link the Stream Initiation to the stream. The "id" attribute transported on the <si/> element is intended to do this. Once a session is fully negotiated, the value of the <si/> "id" attribute is used during the actual stream negotiation as the protocol's stream identifier attribute.

To be compatible to this document, a stream protocol MUST define a stream identifier (typically "sid"), which MUST have a unique string representation. The stream protocol MUST be able to use any string identifier chosen during Stream Initiation, as long as the sending party does not use the same identifier more than once.

The ®ISTRAR; includes the 'http://jabber.org/protocol/si' namespace in its registry of protocol namespaces.