Many said a body element is useless, well, now look at this:
I was online with Adium and Gajim, started an ESession in Gajim and
look what I got in Adium:
[This is part of an encrypted session. If you see this message,
something went wrong.] ([This is part of an encrypted session. If you
Hi,
probably all others understand exactly what you say, but can you
explain what this is about?
I don't understand where this body should be? Is it about a specific
XEP? The main stream? What is the bug you are speaking about and how to
reproduce it, etc.?
This looks interesting, but I don't
We had proposals for end-to-end encryption using TLS here. It was
suggested to use a stream in a stream using Jingle inbound. These
stream will be encapsulated in the stream using messages or iqs
then. And I think we should go for messages, but also include a
body that states that this is
Hey,
I don't know if we have it yet. But can we not make a continuous
integration project that takes these extracts of the XEPs and compiles
them, by making a xml lint?
In that way we should be able to ensure that the XML is syntactically
correct for our XEPs.
-Ciao! :-)
/Steffen
On
In http://www.xmpp.org/extensions/xep-0234.html
Example 29
Shouldn't
transport xmlns='urn:xmpp:jingle:transports:bytestreams:0'/
be
transport xmlns='urn:xmpp:jingle:transports:ibb:0'/
?
This is after a socks5 bytestream has failed and the initiator has
acknowledged the receivers request for
Jonathan Schleifer wrote:
We had proposals for end-to-end encryption using TLS here. It was
suggested to use a stream in a stream using Jingle inbound. These
stream will be encapsulated in the stream using messages or iqs
then. And I think we should go for messages, but also include a
body
Dirk Meyer [EMAIL PROTECTED] wrote:
There is no statement in the XEP that the stream in inband. The
clients can use SOCKS5 or a direct connection for the private
stream. I do not see were you want to put the body in that case.
I'm talking about IF we use IBB, which seems what most intended to
Jonathan Schleifer wrote:
Dirk Meyer [EMAIL PROTECTED] wrote:
There is no statement in the XEP that the stream in inband. The
clients can use SOCKS5 or a direct connection for the private
stream. I do not see were you want to put the body in that case.
I'm talking about IF we use IBB, which
Marcus Lundblad wrote:
In http://www.xmpp.org/extensions/xep-0234.html
Example 29
Shouldn't
transport xmlns='urn:xmpp:jingle:transports:bytestreams:0'/
be
transport xmlns='urn:xmpp:jingle:transports:ibb:0'/
?
This is after a socks5 bytestream has failed and the initiator has
Am 30.09.2008 um 16:28 schrieb Dirk Meyer:
OK. So you want to add a body if we use IBB. And because you can not
add a body with an error message to an iq you want to add a note
in the XEP to use message for IBB. Is that correct?
No. The sender is not the problem, the sender can notice through
No. The sender is not the problem, the sender can notice through XEP-0184
that the message got lost or couldn't be decrypted. The problem is: When the
receiver receives a message at the wrong resource, he'll never know.
As Dirk said, an iq cannot be delivered to the wrong resource,
unless
Version 0.8 of XEP-0234 (Jingle File Transfer) has been released.
Abstract: This specification defines a Jingle application type for transferring
files between two entities. The protocol provides a modular framework that
enables the exchange of information about the file to be transferred as
Version 0.22 of XEP-0176 (Jingle ICE-UDP Transport Method) has been released.
Abstract: This specification defines a Jingle transport method that results in
sending media data using raw datagram sockets via the User Datagram Protocol
(UDP). This transport method is negotiated via the
We had proposals for end-to-end encryption using TLS here. It was suggested
to use a stream in a stream using Jingle inbound.
'Using Jingle in-band?'. I may have missed most of the discussion, but
using Jingle if you already know the transport doesn't sound like what
was intended? I was under
Am 30.09.2008 um 16:53 schrieb Remko Tronçon:
As Dirk said, an iq cannot be delivered to the wrong resource,
unless there is a bug in the server (which is not a case you should be
trying to solve anyway).
Wrong. It can. You have client A and client B installed. Both have the
same resource
Am 30.09.2008 um 16:56 schrieb Remko Tronçon:
'Using Jingle in-band?'. I may have missed most of the discussion, but
using Jingle if you already know the transport doesn't sound like what
was intended? I was under the impression that we would use Jingle to
negotiate a transport, which *could*
On Tue Sep 30 15:53:14 2008, Remko Tronçon wrote:
It does, and in more than just the routing. I think IBB using
messages is a bad thing, both for routing and for control. I'm not
sure why this approach is still described in the IBB spec.
I disagree - I think using iq/ is probably the wrong
I disagree - I think using iq/ is probably the wrong thing to do a lot of
the time. But this is almost besides the point.
I would like to hear why, but not necessarily in this thread.
Anyway, if we generalize the fact that, when a resource goes away and
it suddenly is replaced by another, I
and report a problem to the sending user (and optionally, send an error
through Jingle to the
receiving entity).
Forget that, that was silly. There is no Jingle session anymore in this case.
cheers,
Remko
On Tue Sep 30 16:15:10 2008, Remko Tronçon wrote:
I disagree - I think using iq/ is probably the wrong thing to
do a lot of
the time. But this is almost besides the point.
I would like to hear why, but not necessarily in this thread.
I'll bore you some other time, then. :-)
Anyway, if
Jonathan Schleifer wrote:
Wrong. It can. You have client A and client B installed. Both have the
same resource configured. Client A can handle it, client B can't.
Client B connectes and kicks client A. Tada, you got the problem.
[...]
The client did that before, but it changed while sending.
Am 30.09.2008 um 17:33 schrieb Dave Cridland:
And to cover our coversation elsewhere (through that funny Instant
Messaging thing), a downside of including body is that a client
might assume it's a reasonable alternative, whereas otherwise it
could bounce the message (type=error) which
Am 30.09.2008 um 18:32 schrieb Dirk Meyer:
Why do you want to inform the receiver? He can not do anything about
the problem. It is the sender who has to fix it by either re-open the
e2e stream with the new client and resend the message or if that is
not possible (the new client has no e2e
Hello,
I was wondering if someone has already done some work on end to end
encryption to protect a stream from the relay ?
I feel this is important if we want public relay to become more useful
and more largely used.
Any thought ?
--
Mickaël Rémond
http://www.process-one.net/
On Tue Sep 30 17:42:58 2008, Jonathan Schleifer wrote:
Am 30.09.2008 um 17:33 schrieb Dave Cridland:
And to cover our coversation elsewhere (through that funny
Instant Messaging thing), a downside of including body is
that a client might assume it's a reasonable alternative, whereas
On Tuesday 30 September 2008 10:21:56 Dave Cridland wrote:
On Tue Sep 30 17:42:58 2008, Jonathan Schleifer wrote:
Am 30.09.2008 um 17:33 schrieb Dave Cridland:
And to cover our coversation elsewhere (through that funny
Instant Messaging thing), a downside of including body is
that a
On Tuesday 30 September 2008 09:44:55 Mickaël Rémond wrote:
Hello,
I was wondering if someone has already done some work on end to end
encryption to protect a stream from the relay ?
I feel this is important if we want public relay to become more useful
and more largely used.
Any thought ?
With the problem that the sender doesn't always notice it
If that is the case, then you have a serious problem in your reliable transport.
By the way, you can hack all kind of these error messages into IBB,
but keep in mind that none of these solutions apply on an E2E session
that uses a
Version 0.11 of XEP-0177 (Jingle Raw UDP Transport Method) has been released.
Abstract: This specification defines a Jingle transport method that results in
sending media data using raw datagram sockets via the User Datagram Protocol
(UDP). This simple transport method does not provide NAT
29 matches
Mail list logo
