I don't understand what's the purpose and function of the additional IBB streams negotiated via "transport-info" (see section 2.4).
XEP-0166 (Jingle) explains that transport-info is to be used to exchange transport candidates (for trickle ICE). Adding an additional bytestream as "candidate" does not make sense: IBB either works or does not work between two parties, a different session ID will not change this. What is the proposed semantics of the second stream? Just exchanging a session via transport-info gives no way of defining the disposition of the data sent over this stream, shall the second stream simply mirror the first stream, shall on of the streams be used at random (then the sequentiality of the data is lost if a peer decides to change the used stream repeatedly)? What happens if another streaming transport is used for a Jingle application relying on this feature? Otherwise, to add another content transported over an additional IBB transport, one should use a content-add action (which properly declares how to process the data sent over the stream with Jingle methods). Is there any application out there that uses this feature (note: Jingle File Transfer, to my knowledge the only non-proprietary protocol using the jingle IBB transport method, does not use it)? If so, could this use be replaced by a proper content-add action? If the answers to the questions questions above is "no one uses it" or "all uses could be replaced", I would be strongly in favour of removing this feature. If it is used, precise semantics of the additional streams should be documented in the XEP. kind regards, Sebastian
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
