Sjoerd and Rob had some suggestions for better naming, of which my favourite was AvoidLowThroughput. Sjoerd pointed out that having a peer-to-peer connection doesn't necessarily guarantee that it's actually any good; conceptually, what we're after is "don't give me IBB or something similarly rubbish, I want near-direct performance or an error".

One potential problem with the AvoidLowThroughput name is that it isn't obvious whether AvoidLowThroughput=TRUE also avoids particularly high-latency connections.

> + fail if no resources
> + supporting p2p tubes over ICE are found.

We don't want to require ICE specifically: we want to allow anything with near-direct performance characteristics.

Maybe something like this:

    <p>If this property is TRUE in a request, the connection manager
      MUST only try transports that are expected to have high throughput
      and not be subject to usage limits beyond those of the underlying
      network connection, such as ICE. If no such transport
      is available, the request MUST fail with an error, typically NotCapable.
      Applications expecting to require a high-throughput connection
      SHOULD set this property to TRUE in their channel requests.</p>

    <p>If FALSE or omitted from the request, the chosen transport MAY
      have lower performance or be subject to rate-limiting or usage limits
      imposed by the IM server.</p>

    <tp:rationale>
      <p>On XMPP, Tubes can either be transported in-band through the
        server, or out-of-band. In-band data is subject to significant
        rate-limiting by the IM server, and sending too much in-band
        data can result in disconnection.</p>

      <p>For high-throughput applications, out-of-band Tubes are
        sufficient, but trying to use in-band data would be futile;
        it is better that a request to do so fails early, rather than
        sending bulk data in-band and only detecting that there is a
        problem when rate-limiting occurs.</p>
    </tp:rationale>

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-spec/issues/137.