Re: [Standards] Proposed XMPP Extension: OutOfBand Stream Data
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: 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 framing mechanism specified in the XEP. Or at least a BEEP-lite - we (Isode) may actually produce a spec for the MPP protocol that is, more or less, that - we use it for internal fast comms in our products already. What do you mean by BEEP-lite? I looked at BEEP again to check if we could use it instead of the self-made framing and found two parts I don't like: 1. Every MSG needs an RPY or NUL as answer? If you transfer a video in frames (that is one reason why I wrote it), what is the answer? Or does your BEEP-lite ignore the it? That is still an issue. We could just ignore that and just use MSG in all cases. We don't speak BEEP in channel 0 anyway, so it is not BEEP. Suggestion: we only send MSG frames. Om the other hand we could use NUL as answer to some frames as ack to get reliability. 2. I also do not like the seqno. It has a maximum value of 4GB which is not enough when watching HD content. I see, it wraps back to 0. That works for larger content but I would prefer larger values in seqnum ... and the question remains if seqnum is needed after all. Would it be bad to increase the range of the value? Even if it wraps at 4GB, I would prefer to make it larger. But that could break with BEEP. Besides that, it would be ok for me to use the BEEP style frameming. This would move the content-type stuff away from the XML stream into the frameming but that is ok for me. Reading BEEP again, I don't see where BEEP says how I can check if I have mime headers or not. The BEEP header is only the one line and the payload does not specify MIME in the ABNF style. I would be nice if someone with more knowledge on BEEP could comment on that. We do not need the mime-stuff, only the framing. Dirk -- program, n.: A magic spell cast over a computer allowing it to turn one's input into error messages. tr.v. To engage in a pastime similar to banging one's head against a wall, but with fewer opportunities for reward.
Re: [Standards] Proposed XMPP Extension: OutOfBand Stream Data
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 framing mechanism specified in the XEP. Or at least a BEEP-lite - we (Isode) may actually produce a spec for the MPP protocol that is, more or less, that - we use it for internal fast comms in our products already. What do you mean by BEEP-lite? I looked at BEEP again to check if we could use it instead of the self-made framing and found two parts I don't like: 1. Every MSG needs an RPY or NUL as answer? If you transfer a video in frames (that is one reason why I wrote it), what is the answer? Or does your BEEP-lite ignore the it? 2. I also do not like the seqno. It has a maximum value of 4GB which is not enough when watching HD content. Besides that, it would be ok for me to use the BEEP style frameming. This would move the content-type stuff away from the XML stream into the frameming but that is ok for me. But in any case, yes, a framing mechanism sounds great. I'm thinking about it. It would be nice to know what parts of BEEP you need and how your so-called BEEP-lite looks like. BEEP over XMPP who would have thought that 5 years ago? Dirk -- To study and not think is a waste. To think and not study is dangerous. [Confucius 551 BC - 479 BC]
Re: [Standards] Proposed XMPP Extension: OutOfBand Stream Data
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 framing mechanism specified in the XEP. On Thu, Mar 12, 2009 at 5:19 PM, XMPP Extensions Editor edi...@xmpp.org 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 without blocking the XML stream for other stanzas. URL: http://www.xmpp.org/extensions/inbox/outofband.html The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP. -- Joe Hildebrand
Re: [Standards] Proposed XMPP Extension: OutOfBand Stream Data
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 framing mechanism specified in the XEP. Or at least a BEEP-lite - we (Isode) may actually produce a spec for the MPP protocol that is, more or less, that - we use it for internal fast comms in our products already. But in any case, yes, a framing mechanism sounds great. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] Proposed XMPP Extension: OutOfBand Stream Data
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 allowed somewehere deep inside a stanza it SHOULD be added to the XEP defining that namespace. That's not a good idea, since then you couldn't use it for binary data at all (since you never have base64-encoded data at the top level). Having it only in specific stanzas would mean that you couldn't implement a solution for everything, but only on a case-by-case basis (or you'd have to carry around a list of situations where it's allowed – ugh). Yes, but on the other hand it would be a pain for the developer to expect out of band data everywhere. And it is not needed in most cases. Maybe use the service discovery to handle the list: featureurn:xmpp:jingle:apps:out-of-band:0/feature featureurn:xmpp:tmp:media:server+outband/feature This means that the client expects out of band data as first child element in any stanza and inside every element in the media server namespace. I know it kind of sucks to carry the list around. Another way would be that the urn:xmpp:tmp:media:server namespace defines where out of band data may happen. So if you support out of band data, just must expect for every complete stanza and everytwhere in the media server namespace where it is defined. No idea what the best solution is. Dirk -- Drugs cause amnesia and other things I can't remember...
Re: [Standards] Proposed XMPP Extension: OutOfBand Stream Data
Hi, On Mar 14, 2009, at 11:34 AM, Dirk Meyer wrote: 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 without blocking the XML stream for other stanzas. URL: http://www.xmpp.org/extensions/inbox/outofband.html I would like to know what others think about this idea. I know it is kind of strange but would be very usefull for large stanzas and emedded binary data. 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 encryption XEPs. Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: m...@simplicidade.org Use XMPP!
Re: [Standards] Proposed XMPP Extension: OutOfBand Stream Data
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 encryption XEPs. Because then you'd have to base64 encode all binary data, making most of the advantages of this extension mood. andy
Re: [Standards] Proposed XMPP Extension: OutOfBand Stream Data
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 encryption XEPs. Because then you'd have to base64 encode all binary data, making most of the advantages of this extension mood. That is one reason, the other one is that a large stanza will block the e2e stream. Having one stream for large stanzas and binary data with framing helps. And you can use xtls over that stream, too. Dirk -- Evolution doesn't take prisoners
Re: [Standards] Proposed XMPP Extension: OutOfBand Stream Data
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 long. Section 3, Example 5: That's not EBNF, could you change it to the correct syntax, so there is no room for interpretation? It is not? OK, I will fix it. It should have been EBNF :) On a higher level, I think that's a great idea :) Could be hell for some client implementations, though, due to the asynchronicity (you have to buffer the parts of the stanza you already know, and collect the rest before passing it to the upper layers). 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 allowed somewehere deep inside a stanza it SHOULD be added to the XEP defining that namespace. You should also add the regular section about discovering support for this protocol. Yes, it is only a first draft. If people think that it is a good idea, I will add all this. Thanks for the feedback. Dirk -- I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone. -- Bjarne Stroustrup
Re: [Standards] Proposed XMPP Extension: OutOfBand Stream Data
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 allowed somewehere deep inside a stanza it SHOULD be added to the XEP defining that namespace. That's not a good idea, since then you couldn't use it for binary data at all (since you never have base64-encoded data at the top level). Having it only in specific stanzas would mean that you couldn't implement a solution for everything, but only on a case-by-case basis (or you'd have to carry around a list of situations where it's allowed – ugh). andy
Re: [Standards] Proposed XMPP Extension: OutOfBand Stream Data
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 XEP out of band, but only the whole result. If out of band is allowed somewehere deep inside a stanza it SHOULD be added to the XEP defining that namespace. That's not a good idea, since then you couldn't use it for binary data at all (since you never have base64-encoded data at the top level). Having it only in specific stanzas would mean that you couldn't implement a solution for everything, but only on a case-by-case basis (or you'd have to carry around a list of situations where it's allowed – ugh). Bob... XEP-0231 Bob already defines a mechanism for referencing blobs. This provides an alternative transport for them. Yes, reading bob gave me the idea :) I want to add a section to describe how this can interact with bob. What this won't allow is for huge XML blobs to be referenced within stanzas, but I can't think of a single use case for that - perhaps I'm being naïve, but I think Bob and this between them are an interesting concept. I thought about using bob's cid for the content, but the use case is different. For bob I request the stuff later, in my idea it comes by itself. No need for a constant id like bob. Dirk -- An aquarium is just interactive television for cats.
