Hi,
On 27.12.2013 13:11, Fedor Brunner wrote:
> Hi,
> I'm comparing the documents
> http://xmpp.org/extensions/inbox/jingle-xtls.html
> https://tools.ietf.org/id/draft-meyer-xmpp-e2e-encryption-02.html
>
> in the
> http://xmpp.org/extensions/inbox/jingle-xtls.html
> the digest algorithm for X.509
Hi,
On 05/31/2012 07:49 PM, Peter Saint-Andre wrote:
> Given that Dirk it not really actively involved in XMPP any longer
> (AFAIK)
Sadly, no, my current job does not involve XMPP at all and my free
hacking time is used for Freevo. I still plan to make it possible to
control Freevo using XMPP but
http://xmpp.org/extensions/xep-0247.html
>
> IMHO we don't need this one any longer, so it can lapse without issue.
Yes, the important stuff is part of the XTLS ID
> 5. XEP-0257: Client Certificate Management for SASL EXTERNAL
>http://xmpp.org/extensions/xep-0257.html
>
Hi,
Jonathan Schleifer wrote:
> Peter Saint-Andre wrote:
>
>> Who said that including CAs is evil?
>>
>> My argument is that policies differ. Just because a lot of people use
>> a particular CA doesn't make it good.
>
> Deciding on policies is something the user should do, not the client. I
> fo
Marcus Lundblad wrote:
> A has access to a proxy.
[...]
> At this point A will try to connect to the proxy in order to activate
> the bytestream, but this will fail since A's firewall blocks port .
OK, the problem is a A THINKS it has access to a proxy but that is not
the case. A never tried i
Peter Saint-Andre wrote:
> On 10/15/09 9:53 AM, Dirk Meyer wrote:
>
>> And there is the issue when to sync the private storage. See
>> http://www.mail-archive.com/pub...@xmpp.org/msg0.html [1]
>
> As far as I can see, the discussion on the pub...@xmpp.org list did not
&
Peter Saint-Andre wrote:
> On 9/29/09 10:05 AM, Peter Ferne wrote:
>> On 29 Sep 2009, at 17:03, Peter Saint-Andre wrote:
>>
>>> I won't be convinced that XEP-0223 truly supersedes XEP-0049 until I see
>>> people actively using it for the same use cases...
>>
>>
>> Are you aware of any specific reas
Dave Cridland wrote:
> FYI, I thought this might be interesting from the point of view of
> XMPP/Jingle, whether filesharing or VOIP or whatever.
>
> It's also got an impressive sounding name.
I have no time to read the draft right now, but isn't that the reason we
have HIP (Host Identification Pr
Hi,
I wonder if someone has a comment on it. Joe and Dave suggested a
framing parameter to use BEEP instead of what I created. Since BEEP
sounds ok to me, there is no reason for a framing parameter and just use
BEEP.
Dirk Meyer wrote:
> After reading BEEP again...
>
> Dirk Meyer wrote
After reading BEEP again...
Dirk Meyer wrote:
> Dave Cridland wrote:
>> On Fri Apr 24 16:31:20 2009, Joe Hildebrand wrote:
>>> Sorry I'm so far behind. Any chance XEP-265 could have a framing
>>> parameter in the Jingle portion? Some folks might like to just use
Hi,
sorry for the late answer -- stupid PhD thesis
Dave Cridland wrote:
> On Fri Apr 24 16:31:20 2009, Joe Hildebrand wrote:
>> Sorry I'm so far behind. Any chance XEP-265 could have a framing
>> parameter in the Jingle portion? Some folks might like to just use
>> BEEP instead of the frami
Peter Saint-Andre wrote:
> On 5/29/09 1:58 PM, Justin Karneges wrote:
>> That said, I think we ought to put in something about looping the counter,
>> for
>> example going back to zero after some maximum. I suggest that the stanza
>> count be defined as a 32-bit unsigned integer, that loops at
Peter Saint-Andre wrote:
> In the XMPP Council meeting yesterday, we discussed the desirability of
> adding some implementation notes to XEP-0199 (XMPP Ping) before
> advancing it from Draft to Final.
Stupid question: why use XEP-0199 and not from XEP-0189
for this task?
> "Some XMPP clients d
XMPP Extensions Editor wrote:
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?
Yes
> 5. Is the specification accurate and clearly written?
I did not follow the whole discussion, but IMHO the 'h' attribute is not
clear.
| The 'h' att
Jiří Zárevúcky wrote:
> 2009/5/16 Dirk Meyer :
>> Peter Saint-Andre wrote:
>>> http://xmpp.org/extensions/inbox/sift.html
>>
>> I only took a quick look at the spec and maybe I missed it, but what
>> happens to an IQ that got filtered? If a client sends an
Peter Saint-Andre wrote:
> http://xmpp.org/extensions/inbox/sift.html
I only took a quick look at the spec and maybe I missed it, but what
happens to an IQ that got filtered? If a client sends an IQ it expects
an answer and that answer maybe 'client not available'. What is the
answer if the recipi
Peter Saint-Andre wrote:
> On 5/6/09 9:32 AM, Justin Karneges wrote:
>> On Wednesday 06 May 2009 07:47:10 Peter Saint-Andre wrote:
>>> Dirk Meyer and I think that we no longer need XEP-0246 (End-to-End XML
>>> Streams) and XEP-0247 (Jingle XML Streams). Are there a
Jacek Konieczny wrote:
> On Wed, Apr 01, 2009 at 07:04:12AM -0500, XMPP Extensions Editor wrote:
>> Version 1.0 of XEP-0263 (ECO-XMPP) has been released.
>>
>> Abstract: This specification defines best practices and protocol
>> modifications that will reduce the energy consumption of XMPP systems
Remko Tronçon wrote:
>> FYI, last night I adjusted the XEP boilerplate so that it shows a bit
>> more information at the top. Load any XEP to see.
>
> +1. I missed the authors on top.
Yes +1. It is also nice to have the date/revision on top.
Dirk
--
"Everything should be made as simple as poss
Andreas Monitzer wrote:
> On Mar 16, 2009, at 13:09, Dirk Meyer wrote:
>
>> Yes, maybe restrict the usage to a stanza and not allow it inside a
>> stanza by default. So a client MAY send any return from any XEP out of
>> band, but only the whole result. If out of band is al
Dave Cridland wrote:
> On Mon Mar 16 14:43:38 2009, Andreas Monitzer wrote:
>> On Mar 16, 2009, at 13:09, Dirk Meyer wrote:
>>
>>> Yes, maybe restrict the usage to a stanza and not allow it inside a
>>> stanza by default. So a client MAY send any return from any
Andreas Monitzer wrote:
> Why use a non-existing protocol as an example, when you could use the
> well-known discovery protocol for it?
Simple, I did not thought about that :) I had my future media server XEP
in mind, but XEP-0030 can also serve as an example. All the item
listings can be very lo
Andreas Monitzer wrote:
> On Mar 16, 2009, at 12:42, Pedro Melo wrote:
>
>> I like the framing part, as expected :).
>>
>> But why such a specific protocol? Why not just open a peer-to-peer
>> XMPP stream and route everything between the two endpoints through
>> it? You could even reuse end-to-end
XMPP Extensions Editor wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: OutOfBand Stream Data
>
> Abstract: This specification defines how to send parts of an XML
> stream over a direct connection between peers. This allows to send
> large stanzas or binary data
Robbie Hanson wrote:
> XEP-0065 (Socks5 Bytestreams) states in the "security considerations"
> section that "negotiation of [SSL/TLS] is outside the scope of this
> document". I believe this is no longer valid. For example, consider
> XEP-0189 (Public Key Publishing), and how the XMPP protocol co
Jonathan Schleifer wrote:
> Yeah, but they should not use the same transport ;).
> IMO, we should standarize what types of streams are transported how.
> Like E2E chat MUST be usable using IBB and MAY be possible using P2E,
Agreed. IBB MUST be possible as fallback and you can try S5B if you
want.
Dave Cridland wrote:
> On Sun Mar 1 09:45:12 2009, Dirk Meyer wrote:
>> I'm thinking of maybe having a proxy in the home network. All local
>> devices connect to the proxy and the proxy relays everything to the
>> server. In that case the proxy registers all resources
Dave Cridland wrote:
> On Sat Feb 28 19:49:51 2009, Justin Karneges wrote:
>> Given that you can bind multiple resources in a single XMPP-Core
>> session, it
>> probably makes more sense to keep the session management before
>> binding. If
>> you resume a session, then all resources are resumed.
Peter Saint-Andre wrote:
> Justin Karneges wrote:
>> On Thursday 19 February 2009 18:47:28 Peter Saint-Andre wrote:
>>> As promised at the XMPP Summit, I've been working on some revisions to
>>> XEP-0047 (In-Band Bytestreams). The changes consist of clarifying packet
>>> processing and error handli
Peter Saint-Andre wrote:
> So you'll have two kinds of certs: one that is limited to a particular
> full JID (let's call it a "full-JID cert") and one that isn't (let's
> call it a "bare-JID cert"). If a bare-JID cert is currently logged in
> with a full JID that matches a given full-JID cert (e.g.
Johansson Olle E wrote:
> I think we should change the text about self-signed vs CA-signed that
> is currently a bit ambigous. I know that Dirk's use case is not CA-
> related, but I still think that the XEP should be more neutral and I
> see a lot of use cases where a CA will be required.
I added
Alexey Melnikov wrote:
> This looks better.
Thanks, I hope I added all comments.
> 1). Semantics of "disabling" is not quite clear. In particular, are
> disabled certificates still returned in response to the list request?
> If they are returned, then you need a way to mark them somehow in the
>
Hi,
"Okano, Stephen" wrote:
> I have been following the forums on end-to-end encryption for a while
> as I am involved in a project developing group end-to-end
> encryption. It looks like the XEPs currently are focused on e2e
> encryption between two entities. Is there any framework for
> implemen
Peter Saint-Andre wrote:
> 1. authentication attempts per account
> 2. authentication attempts per IP address
> 3. connection attempts per account
> 4. connection attempts per IP address
> 5. simultaneous connections per account
> 6. simultaneous connections per account
>
> Currently XEP-0205 says
Dirk Meyer wrote:
> Peter Saint-Andre wrote:
>> Some members of the XMPP Council commented recently that the front
>> matter (author info, legal notices, etc.) in existing XEPs is quite
>> lengthy. Therefore I have modified the XSLT to move almost all of that
>> inform
Peter Saint-Andre wrote:
> Some members of the XMPP Council commented recently that the front
> matter (author info, legal notices, etc.) in existing XEPs is quite
> lengthy. Therefore I have modified the XSLT to move almost all of that
> information to appendices. All of the XEPs have been regener
XMPP Extensions Editor wrote:
> Version 0.1 of XEP-0257 (Client Certificate Management for SASL EXTERNAL) has
> been released.
>
> Abstract: This specification defines a method to manage client certificates
> that can be used with SASL External to allow clients to log in without a
> password.
>
Dave Cridland wrote:
> Okay, so humour me for a second.
Sure :)
> In practical terms, then, we move XEP-0250 negotiation inside Jingle
> as a transport, and strip down IBB to remove the initial open
> business (we can essentially compound that into the session-initiate).
>
> Furthermore, we can a
Dave Cridland wrote:
> On Mon Dec 15 17:16:19 2008, Dirk Meyer wrote:
>> Yes. The question is: what do we want? Jingle-based allows direct
>> connections with the cost of many additional roundtrips: while XTLS
>> only
>> needs 3 roundtrips, Jingle XML streams
Jonathan Schleifer wrote:
> Maybe we should make it a requirement that one stanza can only include
> one message. That'd make things a lot easier.
No, you need to have control over your TLS lib to do so. With the
current way you just feed your stanzas into your TLS lib and everytime
it outputs so
Peter Saint-Andre wrote:
> Justin Karneges wrote:
>> On Monday 15 December 2008 07:46:16 Peter Saint-Andre wrote:
>>> Therefore I suggest that we simplify e2e by using
>>> something very close to the original XTLS proposal to set up, use, and
>>> tear down and XTLS tunnel. I've outlined the protoco
Justin Karneges wrote:
> On Monday 15 December 2008 07:46:16 Peter Saint-Andre wrote:
>> Therefore I suggest that we simplify e2e by using
>> something very close to the original XTLS proposal to set up, use, and
>> tear down and XTLS tunnel. I've outlined the protocol below.
>
> First, we should u
Dave Cridland wrote:
> Okay, so the gain here is that we lose the Jingle negotiation,
> effectively, and mandate something roughly equivalent to IBB.
Yes
> The downside is that we lose the ability to go direct from client to
> client should we need to, and one reason for doing so would be for
> e
"Remko Tronçon" wrote:
> Hi Marcus,
>
>> Would it make sense to use an in-band bytestream (XEP-0047) for the
>> tunneling part?
>
> Well, to be fair, I don't expect using IBB as a transport will win you
> anything, and will rather complicate things needlessly. The only part
> that looks similar to
Jonathan Schleifer wrote:
> Sure VNC via XMPP is useless, and once again this is where XMPP could
> replace something proprietary: TeamViewer for example.
usefull?
And BTW, I guess it would cost me about one day of work to make a
prototype and does this. But it will be very slow since my stack on
Jonathan Schleifer wrote:
> Am 13.12.2008 um 09:57 schrieb Dirk Meyer:
>
>> I always like the something-over-XMPP idea. This includes HTTP, VNC,
>> and
>> VPN seems crazy but why not. But for everything like this we need more
>> bandwidth. If can not use IBB for t
Jonathan Schleifer wrote:
> Well, I recently saw that Wippien has VPN support and uses XMPP for
> the messaging part. I thought that it maybe might be a good idea to
> have a XEP for VPN via XMPP. I think this could be achieved quite well
> with Jingle. We would just need a XEP which specifies how
Hi,
as written on the devel list, I'm thinking about adding seek support to
file transfers. I'm working on media networks in my PhD thesis and a
seekable stream is exactly what I need. First a small scenario why I
think it is useful:
I have a media server with a video file. This could either be a
Kurt Zeilenga wrote:
> If there are some hidden assumptions/use cases, I think they should be
> more clearly called out and discussed in the proposal.
I will do that in the next version
> Some XMPP server implementations already support multiple passwords
> per user. Of course, the server has n
Kurt Zeilenga wrote:
> On Dec 4, 2008, at 10:18 AM, Dirk Meyer wrote:
>
>> Kurt Zeilenga wrote:
>>> On Dec 4, 2008, at 2:04 AM, Dirk Meyer wrote:
>>>
>>>> It is part of urn:xmpp:tmp:saslcert (or will be once I write the
>>>> schema)
Kurt Zeilenga wrote:
> On Dec 4, 2008, at 2:04 AM, Dirk Meyer wrote:
>
>> It is part of urn:xmpp:tmp:saslcert (or will be once I write the
>> schema). The problem is that there are two reason to revoke a
>> certificate:
>>
>> 1. A certificate is about to expi
Philipp Hancke wrote:
> why does the client generate the certificate? Sending a CSR to the
> server and signing it there (which may take a long time) seems
> easier from the certificate managment point of view.
IMHO it is more complicated. Why doing a complex CSR (which as you wrote
may take a lo
Alexey Melnikov wrote:
> This is quite sensible reminds me of an older IETF effort called
> SACRED (see RFC 3767 and friends).
Hello BEEP :)
Thanks for the pointer, I will take a look at it to see if something
useful for us is in it.
> I've scanned the document and have some quick comments/quest
Dave Cridland wrote:
> But, as well as that, it also does this:
>
>
>
>
>
>
>
If I'm in your roster, don't I get the presence update, too? And I would
think: Ah, he is chatting with Peter again. Not good for privacy. Maybe
I always wanted to know the JID of th
Peter Saint-Andre wrote:
>> ejabberd already does this if there is more than one resource with the
>> highest prio. If you have for example two resources with prio 50 and one
>> with prio 30, both with prio 50 will receive messages to the bare JID.
>
> Most servers do that. What I'm suggesting is m
XMPP Extensions Editor wrote:
> Please consider the following questions during this Last Call and send
> your feedback to the standards@xmpp.org discussion list:
Ok, here are some comments
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protoc
Hi,
Jack Erwin wrote:
> Message mine'ing provides more of a "do what I mean" experience for
> the end user. When he leaves his desk, he will still be alerted via
> his mobile client when a new conversation has been initiated, and will
> do it without any sort of preparatory action. If the end u
Hi,
there is a small typo in example 16 for XEP-0077. The is
"Password Change" and it should be something like "Cancel Account".
Since it is a final XEP, I did not dare to fix it in svn. :)
Dirk
--
When someone says, 'do you want my opinion?' - have you noticed that
it's always a negative on
Jonathan Schleifer wrote:
> I'd be interested to have a look at that client lib. In which language
> is it written?
It is written in Python. I did not use existings libs because the focus
of that lib is not normal XMPP chatting, I wanted a lib designed for
application control. E.g. I want to contr
Jonathan Schleifer wrote:
> IMO, that brings far too much complexity for a such a simple and
> mandatory thing like end-to-end encryption. A dependency on Jingle
> really is too much IMO.
IMHO Jingle should be part of any client. File transfer over Jingle is
much better than the normal one. You c
Dave Cridland wrote:
> On Tue Nov 25 13:03:15 2008, Jonathan Schleifer wrote:
>> I also like the fact that you don't try to use a direct connection,
>> which has the known problems, which many just ignored in the
>> previous discussion.
>
> Actually, it's not that the problems are ignored, they're
See my other mail for additional information, I just want to answer your
questions very quickly:
Jonathan Schleifer wrote:
> 1.) What is the current state of the XEP? Is it even a XEP now?
Open a stream with either XEP-0174 or XEP-0247 and use starttls. To help
you with that we have XEP-0250 and
Jonathan Schleifer wrote:
> Am 24.11.2008 um 18:50 schrieb Dave Cridland:
>
>> C2C TLS has numerous carefully audited crypto implementations, and
>> one (or two?) test client implementations. Now, arguably, it might
>> well have more - I'm not sure how many of the existing XEP-0174
>> clients will
Dave Cridland wrote:
> On Tue Oct 28 12:04:06 2008, Dirk Meyer wrote:
>> The whole fs is a very bad idea, but I do not see a reason against
>> exposing /home/dmeyer/shared to the rest of the world. Think of a
>> MUC. I
>> have a file with some stuff and just pos
"Remko Tronçon" wrote:
> ... which was originally implemented in Psi as a proof-of-concept, but
> never got beyond this stage for privacy reasons. You should keep in
> mind that an IM client runs on a desktop machine, which most probably
> contains a lot of sensitive information. Enabling an IM cli
Peter Saint-Andre wrote:
> Dirk Meyer wrote:
>> Hi,
>>
>> I had a strange discussion with a co-worker yesterday about the abuse of
>> HTTP. Well, to make a long story short:
>> http://www.tzi.de/~dmeyer/jingle-http.html
>>
>> This is a very early draf
Dave Cridland wrote:
> On Thu Oct 23 11:48:09 2008, Dirk Meyer wrote:
>> Hi,
>>
>> I had a strange discussion with a co-worker yesterday about the
>> abuse of
>> HTTP. Well, to make a long story short:
>> http://www.tzi.de/~dmeyer/jingle-http.html
>>
Hi,
I had a strange discussion with a co-worker yesterday about the abuse of
HTTP. Well, to make a long story short:
http://www.tzi.de/~dmeyer/jingle-http.html
This is a very early draft and only shows the very basic idea. What do
you think? IMHO it could be useful.
Dirk
--
When nothing can p
Peter Saint-Andre wrote:
> Justin Karneges wrote:
>> One idea might be to use DNS-SD to share the disco information. Publish PTR
>> records like _http://jabber.org/protocol/si/profile/filetransfer._xmpp.local.
>>
>> Maybe that would get out of hand, or not?
>
> Yes, I think that would get out of
Peter Saint-Andre wrote:
> Alban Crequy wrote:
>> I implemented an automatic caps lookup via disco in telepathy-salut
>> (the XEP-0174 implementation in the Telepathy framework). It opens a
>> stream only if a "ver" TXT record is advertised *and* if the "ver"
>> record is not already known.
>
> Rig
Peter Saint-Andre wrote:
> Alban Crequy wrote:
>> However, if the 2 clients both implement XEP-030 Service Discovery and
>> XEP-0115 Entity Capabilities, they will both initiate a stream in order
>> to send a discovery request as soon as they appear online via DNS-SD,
>> without user intervention.
Jonathan Schleifer wrote:
> Am 02.10.2008 um 13:36 schrieb Pedro Melo:
>
>> small clients that are willing to implement Jingle + E2E but can't
>> afford to implement any of the ping/ack XEPs out there?
>
> The problem is that they *DON'T* (and I already said that before)
> implement Jingle + E2E, t
Jonathan Schleifer wrote:
> Am 02.10.2008 um 14:13 schrieb Remko Tronçon:
>
>> I'm affraid you're wrong. Jingle File Transfer would be pretty useless
>> if that were true.
>
> And we can use these transports for E2E as well or will that give
> problems?
E2E over Jingle File Transfer makes no sense
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
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 cas
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 s or s
> then. And I think we should go for s, but also include a
> that states that t
Peter Saint-Andre wrote:
> Dirk Meyer wrote:
>
>> it would be nice to have a list of implementations
>> that support a specific XEP. A second step would maybe some inter-op
>> testing. There are two at the summit, but I guess that is not enough.
>
> For "maj
Hi,
first of all: sounds like a good idea. But reding this I got some
questions I had before:
Dave Cridland wrote:
> We currently create new protocols with a "urn:xmpp:tmp:protoname"
> namespace. This is useful to avoid collisions, as well as avoiding
> incompatible implementations in the wild.
>
Joe Hildebrand wrote:
> On Jul 29, 2008, at 8:23 AM, Peter Saint-Andre wrote:
>
>> Dirk Meyer wrote:
>>> Only client but IIRC adding a friend to the roster resulted in
>>> getting
>>> an iq result without sending a get or set. Very confusing.
>>
>
Peter Saint-Andre wrote:
> Dirk Meyer wrote:
>> Sorry for the late answer, I've been very busy the last weeks.
>>
>> Peter Saint-Andre wrote:
>>> Dirk Meyer wrote:
>>>> The same is true for presence (in RFC 39210. I found the presence
>>>
Sorry for the late answer, I've been very busy the last weeks.
Peter Saint-Andre wrote:
> Dirk Meyer wrote:
>> The same is true for presence (in RFC 39210. I found the presence
>> handling much too complicate to implement. It took me longer than
>> adding PubSub and XTLS
"Jack Moffitt" wrote:
>>> It's possible this is just a UI problem.
>>
>> I remember chatting to Pedro Melo about this back in February, and I
>> believe our conclusion back then was just that clients will start
>> showing -1 as a non-chat resource, or somesuch, depending on how
>> general usage pan
Peter Saint-Andre wrote:
> I've just submitted version -06 of draft-saintandre-rfc3920bis to the
> IETF. This version incorporates feedback from Joe Hildebrand, as well
> as my own near-final review and consistency check.
>
> Read it here:
>
> http://www.xmpp.org/internet-drafts/draft-saintandre-rf
JabberForum wrote:
> I have just made a test on last version of ejabberd 2.0.1 with an
> account subscribed to pubsub nodes. The server sent me pubsub messages
> (seen in xml console) but never sent me any service discovery IQ
> query!!! So the server sent me a message without even knowing if I was
Peter Saint-Andre wrote:
> On 06/17/2008 11:31 AM, Dirk Meyer wrote:
>> I have some questions about IBB: I should use if I have
>> AMP. But to detect that I need to ask both servers involved and the
>> peer if they all support it, right?
>
> Yeah. AMP is not yet widely
Peter Saint-Andre wrote:
> On 06/14/2008 4:00 AM, Dirk Meyer wrote:
>> Peter Saint-Andre wrote:
>>>> P.S.: Too bad I implemented the current XTLS today for testing
>>> Ouch. You are too fast. :(
>>
>> Doesn't matter. I also had my previous coded so i
Hi,
I have a small Jingle File Transfer question regarding multiple
candidates. In example 9 the initiator sends two offers, one with
SOCKS5 and one with IBB. After that the responder removes one and
opens the transport (in this case IBB). But why remove one _before_
trying to open (ok, we know IB
Peter Saint-Andre wrote:
>> P.S.: Too bad I implemented the current XTLS today for testing
>
> Ouch. You are too fast. :(
Doesn't matter. I also had my previous coded so it is similar to the
new specs. Except that I have no jingle implementation yet.
> If we can get this spec'd out soon, perhaps
Peter Saint-Andre wrote:
> On 06/13/2008 3:45 PM, Peter Saint-Andre wrote:
>
>> Here is an early version of the Jingle-streams spec:
>>
>> http://www.xmpp.org/extensions/inbox/jingle-streams.html
>>
>> Next I'll copy the e2e-streams stuff from XEP-0174 into a new spec.
>
> http://www.xmpp.org/ext
Peter Saint-Andre wrote:
> 1. We modify XEP-0174 so it just defines _presence._tcp as a discovery
> mechanism, as a result of which you have an IP address and port that you
> can use for a direct TCP connection that functions as a transport for an
> e2e XML stream.
>
> 2. We split the e2e XML strea
Dave Cridland wrote:
> On Sat Jun 7 00:07:36 2008, XMPP Extensions Editor wrote:
>> The XMPP Extensions Editor has received a proposal for a new XEP.
>>
>> Title: XMPP Transport Layer Security
>
> Some comments:
>
> 1) I like using streams, too, that seems to make perfect sense,
> especially given
Justin Karneges wrote:
> The default namespace is nice, since we needed to qualify the
> stanzas anyway. The 'to' and 'from' are a tad superfluous, but maybe we
> should consider them for consistency with XEP-174 (Link Local) ? Same for
> putting to/from on the message stanzas.
[...]
>xml
JabberForum wrote:
> ProtoXEP:
>
> 1. Discover Support
> 2. Send XTLS negotiation request, i.e.
> 3. Receive XTLS negotation response
> 4. Open IBB
> 5. Send stanza
>
> With stream:features step:
>
> 1. Discover Support
> 2. Open IBB
> 3. Send TLS negotiation request, i.e.
> 3. Receive TLS negoti
Justin Karneges wrote:
> I think the original intent with XTLS was to use a new parser instance for
> the
> content of each TLS packet, but this violates the TLS abstraction.
My original intent was to open a new stream incl. feature handling. I
implemented that and therefor never had the missi
Peter Saint-Andre wrote:
> Johannes Wagener has sent me version 0.0.4 of the IO DATA proposal:
>
> http://www.xmpp.org/extensions/inbox/io-data.html
I'm not sure if I understand this correctly. On
|
the node is basically the command to execute, the function call when
speaking of an API. Each fu
Peter Saint-Andre wrote:
> On 06/05/2008 9:17 AM, Justin Karneges wrote:
>> I'm not sure about overloading the sid. A more-traditional
>> namespaced-element
>> approach should work just as well:
>>
>> > from='[EMAIL PROTECTED]/orchard'
>> to='[EMAIL PROTECTED]/balcony'
>> id='inband
Peter Saint-Andre wrote:
>> Using an existing CA you have to pay a lot of money; users
>> don't like that :) And setting up your own CA is not that simple,
>
> https://www.xmpp.net/ :)
If I'm paranoid why should I trust the same CA that verified the
server I use? Maybe they are both controlled by
Justin Karneges wrote:
> XTLS as currently documented is not usable, in my opinion, because it doesn't
> treat TLS like a stream. It expects each exchange to contain specific
> TLS frames, which are not things applications normally know about. You'd
> have to write a TLS parser to inspect dat
Peter Saint-Andre wrote:
> Well XTLS is not well-defined yet, but I will turn my attention to it
> soon. The approach of starttls and then IBB was mentioned by Justin
> Karneges here:
>
> http://mail.jabber.org/pipermail/security/2007-March/18.html
>
> And that seems reasonable to me.
My fault
Hi,
while re-writing my XEP proposal I came to a simple question: what is
a node? The RFC uses node as part of the bare JID: [EMAIL PROTECTED] So a
node is something not unique at all, the same node could be used for a
different domain for a different user. PubSub uses node completly
different. So
1 - 100 of 106 matches
Mail list logo
