[Telepathy] The XMPP implementation of Tubes

[Simon McVittie]

On Mon, 13 Aug 2007 at 17:49:46 +0100, Simon McVittie wrote:
> To offer a tube, send a Stream Initiation request with profile
> NS_SI_TUBES or NS_SI_TUBES_OLD (currently, the latter is sent).

Clearly wrong, we should use the correct namespace.

> It's somewhat vague whether we support opening a 1-1 tubes channel with
> a MUC contact - there is code to support it, but I don't think we put
> capabilities in MUC presence. We should probably rule that it's
> unsupported.

What I said.

> In the case of D-Bus tubes, each <message> contains (a) an entire
> D-Bus message, and (b) no more than one D-Bus message.

In 1-1 tubes we should support arbitrary fragmentation - it's relatively
simple to parse enough of a D-Bus message to be able to find message
boundaries.

> The messages are sent in <message>s as specified by IBB (XEP-0047_), except
> that the sequence number @seq is meaningless on output, must be ignored
> on input, and no <open> or <close> ever occurs.

I propose sending <message><data xmlns=NS_TUBES>base64</data></message>.
The data element should also have an optional attribute "frag" or
something, with values "first", "middle", "last"; omitting the attribute
means it's a complete message (i.e. simultaneously first and last).

This means the stream-id is meaningless and can be omitted...

>     stream-id : string
>         In SI tubes, the stream ID that will be used when the IBB
>         stream is eventually opened. In MUC tubes, an arbitrary string
>         which is repeated on the pseudo-IBB messages.

... so this can be omitted too in MUC context.

>     offering : "true" or "false"
>         In SI context, OfferTube maps to offering="true". I'm not quite
>         sure how it can ever have offering="false" or why this is
>         necessary...

I need to examine stream tubes and work out whether this can ever be
useful.

> :Children:
>     parameters
>         Tube parameters. Children are named "parameter" and have attributes
>         "name" (user-specified) and "type" ("str", "bytes", "int" or "uint").
>         Character content is UTF-8 (str), Base64 (bytes), ASCII decimal
>         (int, uint).

This should be extended to support (at least) the complete set of D-Bus
basic (non-container) types, plus 'ay'. Also, we should either explicitly
not support the two 16-bit integer types, or note in the spec that
16-bit integers might become 32-bit integers in transit (dbus-glib
doesn't let you distinguish, which is IMO a bug but we're stuck with it).

I wonder whether it should just have Base64 character content which is
the D-Bus serialization of the a{sv}. This can be done easily if we can
require D-Bus 1.1.0 (i.e. dbus_message_marshal), by serializing a dummy
message with the a{sv} as payload, then Base64ing just the body part.

Sending arbitrary D-Bus strings in an XML stream is problematic, because
not all Unicode strings can be represented in XML. (Tabs may be converted
to spaces, newlines are normalized, carriage-returns are discarded and
other characters from the first 32 in ASCII are not allowed).