Re: [Standards] Binary data over XMPP
On Nov 11, 2007 12:09 AM, Fabio Forno <[EMAIL PROTECTED]> wrote: > > But if the ids are independently chosen by the clients there may be > the risk of colliding acks, so how can the server chose in the correct > way? I answer to myself, when I read the XEP the first time I've mistaken the id used for reconnecting with the ids used for acks. Since the "ack_id" for "reconnecting" is given at the beginning of the examples and then the example using it for reconnecting is described at the end, I suggest to give it a more meaningful name in order to avoid misunderstandings, as it happened ;) -- Fabio Forno, PhD Istituto Superiore Mario Boella Jabber ID: xmpp:[EMAIL PROTECTED] ** Try Jabber http://www.jabber.org
Re: [Standards] Binary data over XMPP
On Nov 9, 2007 7:37 PM, Rachel Blackman <[EMAIL PROTECTED]> wrote: > Facetious comments aside, my point is that if we're talking about > modifying how the XMPP parser works, why bother doing things halfway > with little workarounds? Throw out XMPP 1.0 entirely and come up with > an extensible 2.0 binary protocol. > If we like to chant the 'XMPP is not really XML' mantra and the 'we > must shave off every byte we can to spare the poor mobile users' > mantras, that's great. But considering we only have 3 actual main > stanza types, a purely binary (and not necessarily XML-related) > protocol would be more efficient. That's exactly my point: XMPP 1.0 is good for desktop clients, and at present for a series of reasons I've already talked about I prefer BOSH for mobiles, but an extensible binary xml protocol would be the best of both worlds. > I think we've lost sight of whatever the original problem we were > trying to solve was (inline images? Size of binary blobs to mobiles?) > and have become caught up in hypothetical solutions which may no > longer be directly connected to the issue. :) One more good reason for using BOSH with mobiles: you can fix very quickly the binary data issue offering the decoded, more compact, data on the same channel, accessing it using a different path in the request. The change would be almost trivial, leaving the time for a decent binary XMPP 2.0 -- Fabio Forno, PhD Istituto Superiore Mario Boella Jabber ID: xmpp:[EMAIL PROTECTED] ** Try Jabber http://www.jabber.org
Re: [Standards] Binary data over XMPP
On Nov 8, 2007 8:11 PM, Justin Karneges <[EMAIL PROTECTED]> wrote: > When you connect again, you specify the ack session id of the disconnected > connection, so that the server knows which session you are trying to recover. > But if the ids are independently chosen by the clients there may be the risk of colliding acks, so how can the server chose in the correct way? > According to the XEP, you then would do resource binding. At the very least, > the XEP should be updated to state that the client must bind to the same > resource as before, and if it doesn't then the server must assert the correct > resource in the bind iq reply. However, I'm tempted to say that when you > resume an ack session, the resource binding step should just be skipped. > After all, both parties already know what the resource is supposed to be. I think the resource binding MUST be skipped and the resource maintained, usually a session object in servers is associated to a given resource that cannot be changed during its life. Moreover the other clients will see a presence of type unvailable from the former resource, and a new presence from the new one. I don't think that this is the behavior we want. -- Fabio Forno, PhD Istituto Superiore Mario Boella Jabber ID: xmpp:[EMAIL PROTECTED] ** Try Jabber http://www.jabber.org
Re: [Standards] Reconnections and fast reauth
On Nov 8, 2007 11:20 AM, Dave Cridland <[EMAIL PROTECTED]> wrote: [...] > (The assertion, and usage of it, gets complicated by whether channel > binding has been involved, and MITMs - even legitimate ones like BOSH > - complicate the issue enormously, but you get the drift). > Got the whole picture. I was pushing on bosh for these kind of issues since the with a correct use of the sid/rid couple you fall in the same situation of fast tls with external auth + session reconnection, and it's already working[1] ;) [1] though there are few servers offering bosh, and among those few only a part gracefully handles disconnections > It's not just an XMPP thing, it hopefully applies to all protocols > using SASL and TLS, and therefore it's not a protoXEP, but an I-D. agree -- Fabio Forno, PhD Istituto Superiore Mario Boella Jabber ID: xmpp:[EMAIL PROTECTED] ** Try Jabber http://www.jabber.org
Re: [Standards] Proposed XMPP Extension: Data Element
On Nov 10, 2007, at 00:38, Peter Saint-Andre wrote: URL: http://www.xmpp.org/extensions/inbox/data-element.html See, that was easy, wasn't it? ;-) I can see three issues here: 1. Your extension doesn't have any namespace and doesn't use the x- element. 2. URLs are limited to 1024 bytes IIRC, so your 10k limit can not be reached. If you go into the trouble of inventing a new element for it, why not put the base64-data between the tags? Yet here's a spot. iVBORw0KGgoNSUhEUgoKCAYAAACNMs+9BGdBTUEAALGP C/ xhBQlwSFlzAAALEwAACxMBAJqcGAd0SU1FB9YGARc5KB0XV+IA AAAddEVYdENvbW1lbnQAQ3JlYXRlZCB3aXRoIFRoZSBHSU1Q72QlbgAAAF1J REFUGNO9zL0NglAAxPEfdLTs4BZM4DIO4C7OwQg2JoQ9LE1exdlYvBBeZ7jq ch9// q1uH4TLzw4d6+ErXMMcXuHWxId3KOETnnXXV6MJpcq2MLaI97CER3N0 vr4MkhoXe0rZigBJRU5ErkJggg== 3. Your data tag in the example starts with a ' but ends with a ". (ok, that's nitpicking) andy
Re: [Standards] Proposed XMPP Extension: Data Element
Dnia 09-11-2007, Pt o godzinie 16:55 -0700, Peter Saint-Andre pisze: > And there's always > http://wiki.jabber.org/index.php/XHTML_Inband_Images > too (I haven't looked at that in a while, but we might want a way to > refer to the element from within the same stanza via a sid of > some kind). Well... This was the first idea we had when designing Inband Images (thus the name), that we just attach BASE64 image to the and refer it from xhtml part. But it would prevent the reuse of already got images, and sender would waste bandwidth by sending the same smiley all over again. Thus we dropped the idea, and moved to the file transfer based method. -- /\_./o__ Tomasz Sterna (/^/(_^^' Xiaoka.com ._.(_.)_ XMPP: [EMAIL PROTECTED]
Re: [Standards] Proposed XMPP Extension: Data Element
Le samedi 10 novembre 2007, Rachel Blackman a écrit : > On Nov 9, 2007, at 3:55 PM, Peter Saint-Andre wrote: > > Peter Saint-Andre wrote: > >> XMPP Extensions Editor wrote: > >>> The XMPP Extensions Editor has received a proposal for a new XEP. > >>> > >>> Title: Data Element > >>> > >>> Abstract: This document specifies a method for including small bits > >>> of binary data in an XMPP stanza via the data: URL scheme. > >>> > >>> URL: http://www.xmpp.org/extensions/inbox/data-element.html > >> > >> See, that was easy, wasn't it? ;-) > > > > And there's always http://wiki.jabber.org/index.php/ > > XHTML_Inband_Images > > too (I haven't looked at that in a while, but we might want a way to > > refer to the element from within the same stanza via a sid of > > some kind). > > In the XHTML-IM body: > > > > ...and then within the same message stanza... > > > > La. :) personally, i'd prefer So it can be passed directly to the html engine. (My client already support receiving such image) And it is shorter and simpler, also. signature.asc Description: This is a digitally signed message part.
