Sophie

Sophie

distrib > Mageia > 1 > i586 > by-pkgid > a5dbf6ee2ee5472594a21ad3da0b99f6 > files > 8

telepathy-gabble-0.11.10-2.mga1.i586.rpm

<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-loose.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>XEP-proto-muc-bytestream: MUC Bytestreams</title><link rel="stylesheet" type="text/css" href="../xmpp.css" /><link href="../prettify.css" type="text/css" rel="stylesheet" /><link rel="shortcut icon" type="image/x-icon" href="/favicon.ico" /><script type="text/javascript" src="../prettify.js"></script><meta name="DC.Title" content="MUC Bytestreams" /><meta name="DC.Creator" content="Simon McVittie" /><meta name="DC.Description" content="A protocol for message transfer within a MUC." /><meta name="DC.Publisher" content="XMPP Standards Foundation" /><meta name="DC.Contributor" content="XMPP Extensions Editor" /><meta name="DC.Date" content="2007-09-07" /><meta name="DC.Type" content="XMPP Extension Protocol" /><meta name="DC.Format" content="XHTML" /><meta name="DC.Identifier" content="XEP-proto-muc-bytestream" /><meta name="DC.Language" content="en" /><meta name="DC.Rights" content="" /></head><body onload="prettyPrint()"><h1>XEP-proto-muc-bytestream: MUC Bytestreams</h1><table><tr valign="top"><td><strong>Abstract:</strong></td><td>A protocol for message transfer within a MUC.</td></tr><tr valign="top"><td><strong>Author:</strong></td><td>Simon McVittie</td></tr><tr valign="top"><td><strong>Copyright:</strong></td><td>© 1999 - 2009 XMPP Standards Foundation. <a href="#appendix-legal">SEE LEGAL NOTICES</a>.</td></tr><tr valign="top"><td><strong>Status:</strong></td><td>ProtoXEP</td></tr><tr valign="top"><td><strong>Type:</strong></td><td>External extension</td></tr><tr valign="top"><td><strong>Version:</strong></td><td>0.0.1</td></tr><tr valign="top"><td><strong>Last Updated:</strong></td><td>2007-09-07</td></tr></table><hr /><p style="color:red">WARNING: This document has not yet been accepted for consideration or approved in any official manner by the XMPP Standards Foundation, and this document is not yet an XMPP Extension Protocol (XEP). If this document is accepted as a XEP by the XMPP Council, it will be published at &lt;<a href="http://xmpp.org/extensions/">http://xmpp.org/extensions/</a>&gt; and announced on the &lt;standards@xmpp.org&gt; mailing list.</p><hr /><h2>Table of Contents</h2><div class="indent"><p><br />1.  <a href="#intro">Introduction</a><br />2.  <a href="#reqs">Requirements</a><br />3.  <a href="#usecases">Use Cases</a><br />4.  <a href="#security">Security Considerations</a><br />5.  <a href="#iana">IANA Considerations</a><br />6.  <a href="#registrar">XMPP Registrar Considerations</a><br />7.  <a href="#schema">XML Schema</a></p><p><a href="#appendices">Appendices</a><br />    <a href="#appendix-docinfo">A: Document Information</a><br />    <a href="#appendix-authorinfo">B: Author Information</a><br />    <a href="#appendix-legal">C: Legal Notices</a><br />    <a href="#appendix-xmpp">D: Relation to XMPP</a><br />    <a href="#appendix-discuss">E: Discussion Venue</a><br />    <a href="#appendix-conformance">F: Requirements Conformance</a><br />    <a href="#appendix-notes">G: Notes</a><br />    <a href="#appendix-revs">H: Revision History</a></p></div><hr /><h2>1.
       <a name="intro" id="intro">Introduction</a></h2>
  <p>This document describes a protocol for tunneling binary message streams
    through an XMPP MUC (XEP-0045). It's designed for use in Tubes
    but could be useful for other similar protocols.</p>
  <p>The XML namespace defined here is
    http://telepathy.freedesktop.org/xmpp/protocol/muc-bytestream
    (NS_MUC_BYTESTREAM in Gabble source code).</p>
<h2>2.
       <a name="reqs" id="reqs">Requirements</a></h2>

  <p>D-Bus Tubes require a mechanism by which binary messages, possibly larger
    than the MUC service's maximum message size, can be transmitted through
    a MUC, preserving message boundaries. Multicasting messages to all
    participants, and sending unicast messages to a single participant,
    are both required.</p>

  <p>The protocol used is intentionally similar to IBB (XEP-0047).</p>

<h2>3.
       <a name="usecases" id="usecases">Use Cases</a></h2>
  <p>MUC Bytestream messages are multiplexed using a stream ID similar to that
    used in In-Band Bytestreams. As with In-Band Bytestreams, the stream ID
    SHOULD be randomly generated in a way that will avoid collisions, and
    any specification that references this one will need to describe how the
    stream ID can be associated with a higher-level construct (e.g. a
    Tube).</p>

  <p>The uniqueness requirement for stream IDs is per-MUC, not
    per-participant, so collision avoidance must occur with the same scope.</p>

  <p>Within a particular message stream, some messages can be broadcast to
    all participants in the MUC while some messages can be sent to a particular
    participant.</p>

  <p class="caption"><a name="example-1" id="example-1"></a>Example 1. Sending a short binary message to all participants</p><div class="indent"><pre class="prettyprint">
    
    &lt;message from='chat@conf.example/someone' to='chat@conf.example'
      type='groupchat'&gt;
      &lt;data
        xmlns='http://telepathy.freedesktop.org/xmpp/protocol/muc-bytestream"
        sid="some-stream-id'&gt;base64base64...&lt;/data&gt;
    &lt;/message&gt;
    
  </pre></div>
  <p class="caption"><a name="example-2" id="example-2"></a>Example 2. Sending a short binary message to a single participant</p><div class="indent"><pre class="prettyprint">
    
    &lt;message from='chat@conf.example/someone' to='chat@conf.example/otherguy'
      type='groupchat'&gt;
      &lt;data
        xmlns='http://telepathy.freedesktop.org/xmpp/protocol/muc-bytestream'
        sid='some-stream-id'&gt;base64base64...&lt;/data&gt;
    &lt;/message&gt;
    
  </pre></div>

  <p>Messages which are too large for the MUC to relay them intact SHOULD be
    "fragmented", i.e. split into multiple stanzas.</p>

  <p>To send messages which need to be fragmented, set the 'frag' attribute
    to "first" on the first part of the message, "middle" on any intermediate
    parts and "last" on the last part. Setting 'frag' to "complete", or
    omitting it, means the XMPP stanza is a complete message in the
    underlying message stream, i.e. it is simultaneously the first and
    last fragment.</p>

  <p>When receiving messages, participants MUST buffer and reassemble
    fragmented messages independently for each (sender, 'sid') pair.</p>

  <p>When a participant has started to send a fragmented message, it MUST
    send all the fragments of that message, finishing with one with 'frag'
    set to "last", before it starts to send any subsequent message with the
    same 'sid' attribute.</p>

  <p>If a participant leaves the MUC, or signals via a higher-level protocol
    that it has left the MUC Bytestream stream with a particular 'sid',
    any buffered fragments from that sender representing an incomplete
    message SHOULD be discarded by recipients.</p>

  <p class="caption"><a name="example-3" id="example-3"></a>Example 3. Sending a long binary message</p><div class="indent"><pre class="prettyprint">
    
    &lt;!--This example sends a message to all participants, but the process
    to send a message to one participant is the same --&gt;

    &lt;message from='chat@conf.example/someone' to='chat@conf.example'
        type='groupchat'&gt;
      &lt;data frag='first'
        xmlns='http://telepathy.freedesktop.org/xmpp/protocol/muc-bytestream'
        sid='some-stream-id'&gt;base64base64...&lt;/data&gt;
    &lt;/message&gt;

    &lt;!-- 0 or more stanzas with frag='middle' - this example
      has one such stanza --&gt;
    &lt;message from='chat@conf.example/someone' to='chat@conf.example'
        type='groupchat'&gt;
      &lt;data frag='middle'
        xmlns='http://telepathy.freedesktop.org/xmpp/protocol/muc-bytestream'
        sid='some-stream-id'&gt;base64base64...&lt;/data&gt;
    &lt;/message&gt;

    &lt;message from='chat@conf.example/someone' to='chat@conf.example'
        type='groupchat'&gt;
      &lt;data frag='last'
        xmlns='http://telepathy.freedesktop.org/xmpp/protocol/muc-bytestream"
        sid="some-stream-id'&gt;base64base64...&lt;/data&gt;
    &lt;/message&gt;
    
  </pre></div>
<h2>4.
       <a name="security" id="security">Security Considerations</a></h2>
  <p>Senders can cause denial of service to recipients via memory exhaustion
    if they send very large fragmented messages. Recipients MUST impose a
    limit on the size of message they will reassemble; higher-level protocols
    that reference this one SHOULD recommend a suitable limit for that
    protocol.</p>
<h2>5.
       <a name="iana" id="iana">IANA Considerations</a></h2>
  <p>None.</p>
<h2>6.
       <a name="registrar" id="registrar">XMPP Registrar Considerations</a></h2>
  <p>None.</p>
<h2>7.
       <a name="schema" id="schema">XML Schema</a></h2>
  <p class="caption"></p><div class="indent"><pre class="prettyprint">
    &lt;xs:schema
      xmlns:xs='http://www.w3.org/2001/XMLSchema'
      targetNamespace='http://telepathy.freedesktop.org/xmpp/protocol/muc-bytestream'
      xmlns='http://telepathy.freedesktop.org/xmpp/protocol/muc-bytestream'
      elementFormDefault='qualified'&gt;

      &lt;xs:element name='data'&gt;
        &lt;xs:complexType&gt;
          &lt;xs:simpleContent&gt;
            &lt;xs:extension base="xs:base64Binary"&gt;
              &lt;xs:attribute name='sid' type='xs:string' use='required' /&gt;
              &lt;xs:attribute name='frag' use='optional' default='complete'&gt;
                &lt;xs:restriction base='xs:NCName'&gt;
                  &lt;xs:enumeration value='first' /&gt;
                  &lt;xs:enumeration value='middle' /&gt;
                  &lt;xs:enumeration value='last' /&gt;
                  &lt;xs:enumeration value='complete' /&gt;
                &lt;/xs:restriction&gt;
              &lt;/xs:attribute&gt;
            &lt;/xs:extension&gt;
          &lt;/xs:simpleContent&gt;
        &lt;/xs:complexType&gt;
      &lt;/xs:element&gt;
    &lt;/xs:schema&gt;
  </pre></div>
<hr /><a name="appendices" id="appendices"></a><h2>Appendices</h2><hr /><a name="appendix-docinfo" id="appendix-docinfo"></a><h3>Appendix A: Document Information</h3><p class="indent">
            Series: <a href="http://xmpp.org/extensions/">XEP</a><br />
            Number: proto-muc-bytestream<br />
            Publisher: <a href="/xsf/">XMPP Standards Foundation</a><br />
            Status: 
            <a href="http://xmpp.org/extensions/xep-0001.html#states-ProtoXEP">ProtoXEP</a><br />
            Type:
            <a href="http://xmpp.org/extensions/xep-0001.html#types-External extension">External extension</a><br />
            Version: 0.0.1<br />
            Last Updated: 2007-09-07<br />
                Approving Body: <a href="http://xmpp.org/council/">XMPP Council</a><br />Dependencies: XMPP Core, XEP-0045<br />
                Supersedes: None<br />
                Superseded By: None<br />
            Short Name: NOT YET ASSIGNED<br /></p><hr /><a name="appendix-authorinfo" id="appendix-authorinfo"></a><h3>Appendix B: Author Information</h3><div class="indent"><h3>Simon McVittie</h3><p class="indent">
        Email:
        <a href="mailto:simon.mcvittie@collabora.co.uk">simon.mcvittie@collabora.co.uk</a><br />
        JabberID: 
        <a href="xmpp:simon.mcvittie@collabora.co.uk">simon.mcvittie@collabora.co.uk</a><br /></p></div><hr /><a name="appendix-legal" id="appendix-legal"></a><h3>Appendix C: Legal Notices</h3><div class="indent"><h4>Copyright</h4><h4>Permissions</h4><h4>Disclaimer of Warranty</h4><span style="font-weight: bold"></span><h4>Limitation of Liability</h4><h4>IPR Conformance</h4></div><hr /><a name="appendix-xmpp" id="appendix-xmpp"></a><h3>Appendix D: Relation to XMPP</h3><p class="indent">The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.</p><hr /><a name="appendix-discuss" id="appendix-discuss"></a><h3>Appendix E: Discussion Venue</h3><p class="indent">The primary venue for discussion of XMPP Extension Protocols is the &lt;<a href="http://mail.jabber.org/mailman/listinfo/standards">standards@xmpp.org</a>&gt; discussion list.</p><p class="indent">Discussion on other xmpp.org discussion lists might also be appropriate; see &lt;<a href="http://xmpp.org/about/discuss.shtml">http://xmpp.org/about/discuss.shtml</a>&gt; for a complete list.</p><p class="indent">Errata can be sent to &lt;<a href="mailto:editor@xmpp.org">editor@xmpp.org</a>&gt;.</p><hr /><a name="appendix-conformance" id="appendix-conformance"></a><h3>Appendix F: Requirements Conformance</h3><p class="indent">The following requirements keywords as used in this document are to be interpreted as described in <a href="http://www.ietf.org/rfc/rfc2119.txt">RFC 2119</a>: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".</p><hr /><a name="appendix-notes" id="appendix-notes"></a><h3>Appendix G: Notes</h3><div class="indent"></div><hr /><a name="appendix-revs" id="appendix-revs"></a><h3>Appendix H: Revision History</h3><p>Note: Older versions of this specification might be available at <a href="http://xmpp.org/extensions/attic/">http://xmpp.org/extensions/attic/</a></p><div class="indent"><h4>Version 0.0.1 (2007-09-07)</h4><div class="indent"><p>First draft.</p> (smcv)
    </div></div><hr /><p>END</p></body></html>