Re: [jdev] Resource Binding Means End of Stream Negotiation?
Thank you guys for the comments. In that case, this part of RFC 6120 is indeed a bit confusing. Might be nice if a clearer description is added to the errata. Kevin Smith 於 2017/8/22 下午9:36 寫道: > On 22 Aug 2017, at 14:05, 殷啟聰 | Kai-Chung Yan wrote: >> I tried with Prosody 0.9.12 today and found that it has the same behavior as >> ejabberd. I guess that "Resource Binding indicating stream negotiation" has >> been a consensus among developers. I personally do not think this is good, >> because clients who strictly comply with RFC 6120 will have trouble talking >> to the rest of the world. > I think in this case 4.3.5 is somewhat misleading, here (maybe it’s an > artefact of trying to support clients that don’t resource bind). For the full > flow, see 9.1.3 and 9.1.4, where it’s explicit that after resource binding > (and without sending stream features), "Now the client is allowed to send XML > stanzas over the negotiated stream." > > So yes, you shouldn’t expect stream features after a resource bind, at that > point you’re done and can start Doing Stuff. > > /K > ___ > JDev mailing list > Info: https://mail.jabber.org/mailman/listinfo/jdev > Unsubscribe: jdev-unsubscr...@jabber.org > ___ signature.asc Description: OpenPGP digital signature ___ JDev mailing list Info: https://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Resource Binding Means End of Stream Negotiation?
On 22 Aug 2017, at 14:05, 殷啟聰 | Kai-Chung Yan wrote: > I tried with Prosody 0.9.12 today and found that it has the same behavior as > ejabberd. I guess that "Resource Binding indicating stream negotiation" has > been a consensus among developers. I personally do not think this is good, > because clients who strictly comply with RFC 6120 will have trouble talking > to the rest of the world. I think in this case 4.3.5 is somewhat misleading, here (maybe it’s an artefact of trying to support clients that don’t resource bind). For the full flow, see 9.1.3 and 9.1.4, where it’s explicit that after resource binding (and without sending stream features), "Now the client is allowed to send XML stanzas over the negotiated stream." So yes, you shouldn’t expect stream features after a resource bind, at that point you’re done and can start Doing Stuff. /K ___ JDev mailing list Info: https://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Resource Binding Means End of Stream Negotiation?
I tried with Prosody 0.9.12 today and found that it has the same behavior as ejabberd. I guess that "Resource Binding indicating stream negotiation" has been a consensus among developers. I personally do not think this is good, because clients who strictly comply with RFC 6120 will have trouble talking to the rest of the world. Peter Saint-Andre 於 2017/8/16 上午11:32 寫道: > On 8/15/17 9:18 PM, 殷啟聰 wrote: >> @Kim >> >> Yes I noticed that note, though I believe the "exception" means "must >> not send stanza before completing stream negotiation except for Resource >> Binding" rather than "send a element after negotiating every >> feature except Resource Binding". > That's my interpretation, as the author. :-) However, it could have been > worded more clearly. > > Peter > > > ___ > JDev mailing list > Info: https://mail.jabber.org/mailman/listinfo/jdev > Unsubscribe: jdev-unsubscr...@jabber.org > ___ signature.asc Description: OpenPGP digital signature ___ JDev mailing list Info: https://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Resource Binding Means End of Stream Negotiation?
On 8/15/17 9:18 PM, 殷啟聰 wrote: > @Kim > > Yes I noticed that note, though I believe the "exception" means "must > not send stanza before completing stream negotiation except for Resource > Binding" rather than "send a element after negotiating every > feature except Resource Binding". That's my interpretation, as the author. :-) However, it could have been worded more clearly. Peter ___ JDev mailing list Info: https://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Resource Binding Means End of Stream Negotiation?
@Kim Yes I noticed that note, though I believe the "exception" means "must not send stanza before completing stream negotiation except for Resource Binding" rather than "send a element after negotiating every feature except Resource Binding". @Peter No I didn't test against other servers. The server I used was ejabberd from Debian Sid. My client only supports WebSocket for now and there are so few XMPP providers out there enabling WebSocket. ☹️ 2017年8月16日 01:43 於 "Peter Saint-Andre" 寫道： > On 8/15/17 10:34 AM, Kai-Chung Yan (殷啟聰) wrote: > > Dear XMPP community, > > > > I am implementing (yet another) XMPP client library and found > > something confusing in RFC 6120: XMPP Core. > > > > Section 4.3.5 states that the receiving party sends either an empty > > element or one containing only optional features in order > > to indicate the completion of a stream negotiation. In fact, I > > believe the receiving party should send a element > > immediately after negotiating every single feature. > > > > However my client stuck after finishing Resource Binding and both > > parties are waiting for further XML data. After I changed the > > behavior to assume that Resource Binding indicates end of stream > > negotiation, everything works perfectly I can start exchanging > > stanzas. > > > > Does that indicate that Resource Binding means the end of a stream > > negotiation? I fail to find such policy in RFC 6120 or its errata. > > It sounds to me as if the server software you're connecting to makes an > incorrect assumption. Have you tested this with multiple server > implementations? > > Peter > > > > ___ > JDev mailing list > Info: https://mail.jabber.org/mailman/listinfo/jdev > Unsubscribe: jdev-unsubscr...@jabber.org > ___ > > ___ JDev mailing list Info: https://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Resource Binding Means End of Stream Negotiation?
On 8/15/17 10:34 AM, Kai-Chung Yan (殷啟聰) wrote: > Dear XMPP community, > > I am implementing (yet another) XMPP client library and found > something confusing in RFC 6120: XMPP Core. > > Section 4.3.5 states that the receiving party sends either an empty > element or one containing only optional features in order > to indicate the completion of a stream negotiation. In fact, I > believe the receiving party should send a element > immediately after negotiating every single feature. > > However my client stuck after finishing Resource Binding and both > parties are waiting for further XML data. After I changed the > behavior to assume that Resource Binding indicates end of stream > negotiation, everything works perfectly I can start exchanging > stanzas. > > Does that indicate that Resource Binding means the end of a stream > negotiation? I fail to find such policy in RFC 6120 or its errata. It sounds to me as if the server software you're connecting to makes an incorrect assumption. Have you tested this with multiple server implementations? Peter signature.asc Description: OpenPGP digital signature ___ JDev mailing list Info: https://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Resource Binding Means End of Stream Negotiation?
Hi, On Wed, Aug 16, 2017 at 12:34:06AM +0800, Kai-Chung Yan (殷啟聰) wrote: > I am implementing (yet another) XMPP client library and found > something confusing in RFC 6120: XMPP Core. > > Section 4.3.5 states that the receiving party sends either an empty > element or one containing only optional features in order > to indicate the completion of a stream negotiation. In fact, I believe > the receiving party should send a element immediately > after negotiating every single feature. > > However my client stuck after finishing Resource Binding and both > parties are waiting for further XML data. After I changed the behavior > to assume that Resource Binding indicates end of stream negotiation, > everything works perfectly I can start exchanging stanzas. > > Does that indicate that Resource Binding means the end of a stream > negotiation? I fail to find such policy in RFC 6120 or its errata. See this note: https://xmpp.org/rfcs/rfc6120.html#streams-negotiation-complete > Informational Note: Resource binding as specified under Section 7 is > an historical exception to the foregoing rule, since it is > mandatory-to-negotiate for clients but uses XML stanzas for > negotiation purposes. -- Regards, Kim "Zash" Alvefur ___ JDev mailing list Info: https://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
[jdev] Resource Binding Means End of Stream Negotiation?
Dear XMPP community, I am implementing (yet another) XMPP client library and found something confusing in RFC 6120: XMPP Core. Section 4.3.5 states that the receiving party sends either an empty element or one containing only optional features in order to indicate the completion of a stream negotiation. In fact, I believe the receiving party should send a element immediately after negotiating every single feature. However my client stuck after finishing Resource Binding and both parties are waiting for further XML data. After I changed the behavior to assume that Resource Binding indicates end of stream negotiation, everything works perfectly I can start exchanging stanzas. Does that indicate that Resource Binding means the end of a stream negotiation? I fail to find such policy in RFC 6120 or its errata. Best regards, Kai-Chung Yan signature.asc Description: OpenPGP digital signature ___ JDev mailing list Info: https://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Resource binding
On 3/4/10 11:00 AM, Peter Saint-Andre wrote: > On 3/4/10 6:27 AM, Tomasz Sterna wrote: >> Dnia 2010-03-04, czw o godzinie 05:59 -0700, Peter Saint-Andre pisze: >>> I don't know that I promised to do this. :) I think it would be great >>> for us to define this and I've provided most of the pieces, *but* I am >>> extremely busy these days and I don't have time to work on every XEP >>> anymore, so I am encouraging other people to take over some of this >>> work. Resurrecting and slightly modifying XEP-0193 seems like a good >>> opportunity for someone to help out. >> >> OK. Sorry for this. >> It probably was wishful thinking that stored this reminiscence. :-) > > I *might* find time to do this, but I can't promise. Let's at least > raise this issue in the next Council meeting... Added to the Radar: http://wiki.xmpp.org/web/Radar#Other_items smime.p7s Description: S/MIME Cryptographic Signature ___ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Resource binding
On 3/4/10 6:27 AM, Tomasz Sterna wrote: > Dnia 2010-03-04, czw o godzinie 05:59 -0700, Peter Saint-Andre pisze: >> I don't know that I promised to do this. :) I think it would be great >> for us to define this and I've provided most of the pieces, *but* I am >> extremely busy these days and I don't have time to work on every XEP >> anymore, so I am encouraging other people to take over some of this >> work. Resurrecting and slightly modifying XEP-0193 seems like a good >> opportunity for someone to help out. > > OK. Sorry for this. > It probably was wishful thinking that stored this reminiscence. :-) I *might* find time to do this, but I can't promise. Let's at least raise this issue in the next Council meeting... Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature ___ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Resource binding
Dnia 2010-03-04, czw o godzinie 05:59 -0700, Peter Saint-Andre pisze: > I don't know that I promised to do this. :) I think it would be great > for us to define this and I've provided most of the pieces, *but* I am > extremely busy these days and I don't have time to work on every XEP > anymore, so I am encouraging other people to take over some of this > work. Resurrecting and slightly modifying XEP-0193 seems like a good > opportunity for someone to help out. OK. Sorry for this. It probably was wishful thinking that stored this reminiscence. :-) ___ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Resource binding
On 3/4/10 5:43 AM, Tomasz Sterna wrote: > Dnia 2010-03-01, pon o godzinie 05:21 -0800, chris pisze: >> The ability to multiplex multiple resources is certainly desirable. >> It is too bad that it has missed the core spec at this point. > [...] >> It'd be great to see this put back in the draft-ietf-xmpp-3920bis. :) > > Peter promised to resurrect this as a XEP, so you should have an option > of using the server supporting this XEP. I don't know that I promised to do this. :) I think it would be great for us to define this and I've provided most of the pieces, *but* I am extremely busy these days and I don't have time to work on every XEP anymore, so I am encouraging other people to take over some of this work. Resurrecting and slightly modifying XEP-0193 seems like a good opportunity for someone to help out. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature ___ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Resource binding
Dnia 2010-03-01, pon o godzinie 05:21 -0800, chris pisze: > The ability to multiplex multiple resources is certainly desirable. > It is too bad that it has missed the core spec at this point. [...] > It'd be great to see this put back in the draft-ietf-xmpp-3920bis. :) Peter promised to resurrect this as a XEP, so you should have an option of using the server supporting this XEP. ___ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Resource binding
On Wed, 3 Mar 2010 21:56:43 -0700, Peter Saint-Andre wrote > On 3/3/10 9:18 PM, chris wrote: >> I still haven't read any reasonable argument against multiplexed resource >> binding. The two main points made are "it complicates the protocol" and >> "for what purpose". >> >> To the first point, it was a very simple change to the protocol in my >> perception and OPTIONAL (unfortunately) at that. >> >> To the second point I think this and other threads have answered that >> question, but essentially it boils down to allowing the only type of XMPP >> entity, a client, that does not require DNS and custom server support to >> be something besides an instant messenger or a one off implementation >> that is only useful within its own network. > > As I've already said, if you and other people care about multiplexing > resources on a single XML stream, then write a document defining how it > works and propose it for consideration. Basically all you need to do is: Peter, thanks for the heavy lifting and foot work in laying that out for us. I certainly care, so we will have to see where this takes us. regards, chris _ Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. http://clk.atdmt.com/GBL/go/201469229/direct/01/ ___ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Resource binding
On 3/3/10 9:18 PM, chris wrote: > I still haven't read any reasonable argument against multiplexed resource > binding. The two main points made are "it complicates the protocol" and > "for what purpose". > > To the first point, it was a very simple change to the protocol in my > perception and OPTIONAL (unfortunately) at that. > > To the second point I think this and other threads have answered that > question, but essentially it boils down to allowing the only type of XMPP > entity, a client, that does not require DNS and custom server support to > be something besides an instant messenger or a one off implementation > that is only useful within its own network. As I've already said, if you and other people care about multiplexing resources on a single XML stream, then write a document defining how it works and propose it for consideration. Basically all you need to do is: 1. Copy the XML for XEP-0193, as described at http://xmpp.org/xsf/sourcecontrol.shtml (sorry, the SVN viewer is broken right now but you can find the XML through git or directly via SVN checkout) 2. Perhaps factor in some of the differences that might be found in older versions of draft-saintandre-rfc3920bis, such as: http://xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-07.html#bind-multi 3. Change the namespace for the unbind feature (or perhaps we should call it "multibind") to something like urn:xmpp:multibind:0 in accordance with XEP-0053 4. Submit it for consideration by the XMPP Council, as described at http://xmpp.org/extensions/submit.shtml We have an open standards process at the XSF, and most of the hard work has been done already in this case. If all this is too confusing, feel free to ping me via IM at stpe...@jabber.org... Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature ___ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Resource binding
On Wed, 3 Mar 2010 15:14:15 +, Dave Cridland wrote: > On Wed Mar 3 14:18:45 2010, chris wrote: >> So, I am not certain what you meant by "individually addressable >> objects within a client" in the context of XEP-0030 as applied to a >> client JID. I would appreciate some clarifications on that >> statement. > > Pubsub nodes, for instance, are addressable (ie, you can send stuff > to them) but they share a single jid. This happens not to be within a > client, but there's plenty of examples of XEP-0030 nodes being used > for addressing. For a client, XEP-0030 nodes aren't helpful as they aren't addressable. In any case, if multiplexing resource bindings do not become standard, I've intended to use XEP-0163 for a stripped down feature set, and expose the rest via custom extensions. But I believe that approach greatly reduces the usefulness of this system. > If you want your objects to appear as being individually addable to > rosters, etc, then you do have a problem, but the solution is really > to use multiple connections, since you'll find it extremely difficult > to add full jids (ie, ones with a resource) to rosters with most > clients anyway. I'm sorry to hear that... I guess I haven't tested enough clients, but the few I have, allowed full JIDs to be added to the roster, per the specification, just fine. > Of course, you could always use the component protocol, which *will* > give you multiple jids within a domain on a single connection, which > you can then process how you want. Component protocols require associated DNS entries. They also require connection to a specific server that is configured to accept the connection. Unfortunately, neither restriction is acceptable for my requirements. Simply put, XMPP only provides the notion of client entities that do not require custom server implementations in order to connect to the network. I still haven't read any reasonable argument against multiplexed resource binding. The two main points made are "it complicates the protocol" and "for what purpose". To the first point, it was a very simple change to the protocol in my perception and OPTIONAL (unfortunately) at that. To the second point I think this and other threads have answered that question, but essentially it boils down to allowing the only type of XMPP entity, a client, that does not require DNS and custom server support to be something besides an instant messenger or a one off implementation that is only useful within its own network. chris _ Hotmail: Free, trusted and rich email service. http://clk.atdmt.com/GBL/go/201469228/direct/01/ ___ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Resource binding
On Wed Mar 3 14:18:45 2010, chris wrote: So, I am not certain what you meant by "individually addressable objects within a client" in the context of XEP-0030 as applied to a client JID. I would appreciate some clarifications on that statement. Pubsub nodes, for instance, are addressable (ie, you can send stuff to them) but they share a single jid. This happens not to be within a client, but there's plenty of examples of XEP-0030 nodes being used for addressing. If you want your objects to appear as being individually addable to rosters, etc, then you do have a problem, but the solution is really to use multiple connections, since you'll find it extremely difficult to add full jids (ie, ones with a resource) to rosters with most clients anyway. Of course, you could always use the component protocol, which *will* give you multiple jids within a domain on a single connection, which you can then process how you want. 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 ___ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Resource binding
On Mon, 1 Mar 2010 14:01:18 +, Dave Cridland wrote: > On Mon Mar 1 13:21:41 2010, chris wrote: >> Anyway, my use case for this is generalized as such, and is not IM >> related: >> >> An internet connected client exists for n...@example.com, this >> client is the interface to many non internet enabled clients which >> are identified by resources n...@example.com/x1,x2..xn, where n >> could be a fairly large number. As x1..xn are all associated in a >> particular way for this use case, it makes sense (for reasons not >> here explained) that they are connected using a single bare JID, >> besides the fact that maintaining many streams/connections is >> certainly not ideal and even problematic. > > But you're likely to be running your own extension anyway to talk to > these things, so you could make your XMPP client handle the routing > in other ways than try to break the 1:1 relationship between > connections and resources. Not quite true... Although I did say this was not IM related, I am using XMPP for the core functionality it was built around, namely presence and messaging (along with custom extensions) with the expectation of being interoperable at a basic level with the federated XMPP network. So, if they are not exposed as a resource then they can not appear as a resource to the rest of the network. ie one can no longer naturally add them to the roster, get presence information, send messages etc. Any generic XMPP client loses the ability to interact with them at all. Only a custom client implementing the necessary extensions are able interact with them. Not very interesting. You allude that a 1:1 relationship between a connection and resource is desirable; I don't see why that should be so. A 1:1 relationship between a connection and a stream, ok. But I see no specification level need to limit the number of resources bound to a stream let alone, either implicitly or explicitly, to a connection. > For instance, XEP-0030 encapsulates individually addressable objects > within a client perfectly well without introducing multiple > resources on a single connection. What XEP-0030 does provide is a way to discover an XMPP entity's features, extensions, resources et al. as well as enumerate a client's *non* addressable items; this is most useful in its own regard. However, I do not see how this is meaningful as a replacement or alternative to binding multiple resources to a single stream, nor negating the need for it. I don't believe this discussion is about discovery, and XEP-0030 provides nothing for accessing non-addressable 'items' as normal XMPP resources - ie, basic presence and messaging capabilities, let alone any other commonly implemented client functionality. So, I am not certain what you meant by "individually addressable objects within a client" in the context of XEP-0030 as applied to a client JID. I would appreciate some clarifications on that statement. regards, chris _ Hotmail: Powerful Free email with security by Microsoft. http://clk.atdmt.com/GBL/go/201469230/direct/01/ ___ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Resource binding
On Mon Mar 1 13:21:41 2010, chris wrote: Anyway, my use case for this is generalized as such, and is not IM related: An internet connected client exists for n...@example.com, this client is the interface to many non internet enabled clients which are identified by resources n...@example.com/x1,x2..xn, where n could be a fairly large number. As x1..xn are all associated in a particular way for this use case, it makes sense (for reasons not here explained) that they are connected using a single bare JID, besides the fact that maintaining many streams/connections is certainly not ideal and even problematic. But you're likely to be running your own extension anyway to talk to these things, so you could make your XMPP client handle the routing in other ways than try to break the 1:1 relationship between connections and resources. For instance, XEP-0030 encapsulates individually addressable objects within a client perfectly well without introducing multiple resources on a single connection. 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 ___ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Resource binding
On 1/24/10 5:43 AM, Jonathan Dickinson wrote: > You can 'multiplex' multiple resources into one stream. Not sure > about server support though. On 2010-01-24, 20:55 -0700, Peter Saint-Andre wrote: > we removed the protocol for multiple resources over a single stream > from draft-ietf-xmpp-3920bis because list consensus led me to think > that people believe it is unnecessary and too complicated. On 2010-01-25, 14:40 -0700, Peter Saint-Andre wote: > The multi-resource stuff seemed like a good idea at the time but > people on the XMPP WG discussion list were concerned about adding > complexity. We could, of course, still define it as an XMPP > extension if there's interest. On 1/30/10 9:22 AM, Tomasz Sterna wrote: > One may always establish multiple connections to bring up more > resources. But I think resource binding is way simpler method. On Thu Feb 11 22:12:12 CST 2010 Justin Karneges wrote: > Also, the feature seemed to come out of left field. Maybe I missed > the discussion, but to me it felt like this feature was just a case > of "Why Not?" rather than being born from real necessity. That > doesn't make it a bad thing, but I want to remind that we should be > conservative about our changes to the core specs. Hello, The ability to multiplex multiple resources is certainly desirable. It is too bad that it has missed the core spec at this point. Strange however, that draft-ietf-xmpp-3920bis-04 still contains the text in section 1.1 Overview: "Defined of optional support for multiple resources over the same connection" Yet no where in that draft revision does it discuss multiple resources anymore. The last draft I could locate this in is: http://xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-10.html#bind-multi Anyway, my use case for this is generalized as such, and is not IM related: An internet connected client exists for n...@example.com, this client is the interface to many non internet enabled clients which are identified by resources n...@example.com/x1,x2..xn, where n could be a fairly large number. As x1..xn are all associated in a particular way for this use case, it makes sense (for reasons not here explained) that they are connected using a single bare JID, besides the fact that maintaining many streams/connections is certainly not ideal and even problematic. It'd be great to see this put back in the draft-ietf-xmpp-3920bis. :) I imagine that as XMPP moves further passed the IM world, these types of needs will become more apparent. It is unfortunate a forward looking update to the protocol was axed for the lack of understanding its use cases. chris _ Hotmail: Trusted email with Microsoft’s powerful SPAM protection. http://clk.atdmt.com/GBL/go/201469226/direct/01/ ___ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Resource binding
On 2/11/10 9:12 PM, Justin Karneges wrote: > On Thursday 11 February 2010 19:53:10 Peter Saint-Andre wrote: >> On 1/30/10 9:22 AM, Tomasz Sterna wrote: >>> Dnia 2010-01-29, pią o godzinie 07:52 -0700, Peter Saint-Andre pisze: You mean http://xmpp.org/extensions/inbox/private-muc.html I suppose. It's not clear to me if we absolutely need multi-resource support in order to have private MUCs. And I wouldn't want to have a dependency on the server to provide private MUCs anyway. >>> >>> One may always establish multiple connections to bring up more >>> resources. >>> But I think resource binding is way simpler method. >>> >>> BTW: What was the exact reasons for dropping it? >>> I didn't find it nor confusing, nor hard to implement. >> >> That's helpful feedback. >> >>> Pros: >>> - does not add another flow, just reuse existing one >>> - easy to implement (servers already support one resource bind and >>> multiple connections from one client) >>> - very straightforward once you get what resource bind is >>> (and you need to bind one) >>> >>> Cons: >>> - ?? >> >> - Changing the existing flows for resource binding >> - Managing multiple resources on the client side >> - Knowing when the session is really finished >> >> I'm sure were other reasons but I'd need to re-read the list archives to >> remember them. > > Also, the feature seemed to come out of left field. Maybe I missed the > discussion, but to me it felt like this feature was just a case of "Why Not?" > rather than being born from real necessity. At the time I knew of some implementations and deployments that wanted multi-resource support for carrying sessions from multiple processes running on the desktop, but the people who cared about it didn't ever get involved in the standards process and I'd prefer not to be a proxy for such people (if you don't care enough to get involved, why should we care enough to add your feature?). > That doesn't make it a bad > thing, but I want to remind that we should be conservative about our changes > to the core specs. Agreed. That doesn't mean we can't define an extension for this... Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature ___ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Resource binding
On Thursday 11 February 2010 19:53:10 Peter Saint-Andre wrote: > On 1/30/10 9:22 AM, Tomasz Sterna wrote: > > Dnia 2010-01-29, pią o godzinie 07:52 -0700, Peter Saint-Andre pisze: > >> You mean http://xmpp.org/extensions/inbox/private-muc.html I suppose. > >> It's not clear to me if we absolutely need multi-resource support in > >> order to have private MUCs. And I wouldn't want to have a dependency > >> on the server to provide private MUCs anyway. > > > > One may always establish multiple connections to bring up more > > resources. > > But I think resource binding is way simpler method. > > > > BTW: What was the exact reasons for dropping it? > > I didn't find it nor confusing, nor hard to implement. > > That's helpful feedback. > > > Pros: > > - does not add another flow, just reuse existing one > > - easy to implement (servers already support one resource bind and > > multiple connections from one client) > > - very straightforward once you get what resource bind is > > (and you need to bind one) > > > > Cons: > > - ?? > > - Changing the existing flows for resource binding > - Managing multiple resources on the client side > - Knowing when the session is really finished > > I'm sure were other reasons but I'd need to re-read the list archives to > remember them. Also, the feature seemed to come out of left field. Maybe I missed the discussion, but to me it felt like this feature was just a case of "Why Not?" rather than being born from real necessity. That doesn't make it a bad thing, but I want to remind that we should be conservative about our changes to the core specs. -Justin ___ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Resource binding
On 1/30/10 9:22 AM, Tomasz Sterna wrote: > Dnia 2010-01-29, pią o godzinie 07:52 -0700, Peter Saint-Andre pisze: >> You mean http://xmpp.org/extensions/inbox/private-muc.html I suppose. >> It's not clear to me if we absolutely need multi-resource support in >> order to have private MUCs. And I wouldn't want to have a dependency >> on the server to provide private MUCs anyway. > > One may always establish multiple connections to bring up more > resources. > But I think resource binding is way simpler method. > > BTW: What was the exact reasons for dropping it? > I didn't find it nor confusing, nor hard to implement. That's helpful feedback. > Pros: > - does not add another flow, just reuse existing one > - easy to implement (servers already support one resource bind and > multiple connections from one client) > - very straightforward once you get what resource bind is > (and you need to bind one) > > Cons: > - ?? - Changing the existing flows for resource binding - Managing multiple resources on the client side - Knowing when the session is really finished I'm sure were other reasons but I'd need to re-read the list archives to remember them. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature ___ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
[jdev] Resource binding
Dnia 2010-01-29, pią o godzinie 07:52 -0700, Peter Saint-Andre pisze: > You mean http://xmpp.org/extensions/inbox/private-muc.html I suppose. > It's not clear to me if we absolutely need multi-resource support in > order to have private MUCs. And I wouldn't want to have a dependency > on the server to provide private MUCs anyway. One may always establish multiple connections to bring up more resources. But I think resource binding is way simpler method. BTW: What was the exact reasons for dropping it? I didn't find it nor confusing, nor hard to implement. Pros: - does not add another flow, just reuse existing one - easy to implement (servers already support one resource bind and multiple connections from one client) - very straightforward once you get what resource bind is (and you need to bind one) Cons: - ??? -- Tomasz Sterna Instant Messaging & EDI Consultant Open Source Developer http://tomasz.sterna.tv/ http://www.xiaoka.com/ ___ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Resource binding limit(ation)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vinod Panicker wrote: > On 11/24/05, Vinod Panicker <[EMAIL PROTECTED]> wrote: >> On 11/24/05, Norman Rasmussen <[EMAIL PROTECTED]> wrote: >>> I think you can by forcing binding to an existing resource, but I'm >>> not sure it allows you to force an old resource off and bind a new >>> one. >> Wont work since even binding to an existing resource would mean that >> I'm adding one more connected resource (albeit of a same name). What >> I'm asking is - shouldn't this be treated in the same way we treat >> server provisioning for allowing/disallowing two resources of the same >> name to be available? >> >>> On 11/24/05, Vinod Panicker <[EMAIL PROTECTED]> wrote: According to RFC 3920 - o The client is not allowed to bind a resource to the stream (e.g., because the node or user has reached a limit on the number of connected resources allowed). Wont it make sense if there is some provision to automatically logoff the user from a previous resource (based on server provisioning) if he's trying to login from a new resource? > > No closure on this so I'm assuming that we are not allowing any more > resources to login once the limit has reached, though it would be > great to have something that allows the server to logoff an existing > resource to make way for the new one. Sure, an implementation could do that if it wants. Nothing in the spec forbids it and you can implement it if you think it's a cool feature. Peter - -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEFb5jNF1RSzyt3NURAo6NAKDVcmmaKqEZ5dH+tVCbRUVeglw3CgCdEl86 g7w7wU8LvfAtZHtl9aJzrmI= =yox4 -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature
Re: [jdev] Resource binding limit(ation)
On 11/24/05, Vinod Panicker <[EMAIL PROTECTED]> wrote: > On 11/24/05, Norman Rasmussen <[EMAIL PROTECTED]> wrote: > > I think you can by forcing binding to an existing resource, but I'm > > not sure it allows you to force an old resource off and bind a new > > one. > > Wont work since even binding to an existing resource would mean that > I'm adding one more connected resource (albeit of a same name). What > I'm asking is - shouldn't this be treated in the same way we treat > server provisioning for allowing/disallowing two resources of the same > name to be available? > > > On 11/24/05, Vinod Panicker <[EMAIL PROTECTED]> wrote: > > > According to RFC 3920 - > > > > > >o The client is not allowed to bind a resource to the stream (e.g., > > > because the node or user has reached a limit on the number of > > > connected resources allowed). > > > > > > Wont it make sense if there is some provision to automatically logoff > > > the user from a previous resource (based on server provisioning) if > > > he's trying to login from a new resource? No closure on this so I'm assuming that we are not allowing any more resources to login once the limit has reached, though it would be great to have something that allows the server to logoff an existing resource to make way for the new one. Regards, Vinod.
Re: [jdev] Resource binding limit(ation)
On 11/24/05, Norman Rasmussen <[EMAIL PROTECTED]> wrote: > I think you can by forcing binding to an existing resource, but I'm > not sure it allows you to force an old resource off and bind a new > one. Wont work since even binding to an existing resource would mean that I'm adding one more connected resource (albeit of a same name). What I'm asking is - shouldn't this be treated in the same way we treat server provisioning for allowing/disallowing two resources of the same name to be available? > On 11/24/05, Vinod Panicker <[EMAIL PROTECTED]> wrote: > > According to RFC 3920 - > > > >o The client is not allowed to bind a resource to the stream (e.g., > > because the node or user has reached a limit on the number of > > connected resources allowed). > > > > Wont it make sense if there is some provision to automatically logoff > > the user from a previous resource (based on server provisioning) if > > he's trying to login from a new resource? Regards, Vinod.
Re: [jdev] Resource binding limit(ation)
I think you can by forcing binding to an existing resource, but I'm not sure it allows you to force an old resource off and bind a new one. On 11/24/05, Vinod Panicker <[EMAIL PROTECTED]> wrote: > According to RFC 3920 - > >o The client is not allowed to bind a resource to the stream (e.g., > because the node or user has reached a limit on the number of > connected resources allowed). > > Wont it make sense if there is some provision to automatically logoff > the user from a previous resource (based on server provisioning) if > he's trying to login from a new resource? > > Regards, > Vinod. > > PS: any ideas on the directed presence + presence probe issue? > -- - Norman Rasmussen - Email: [EMAIL PROTECTED] - Home page: http://norman.rasmussen.co.za/
[jdev] Resource binding limit(ation)
According to RFC 3920 - o The client is not allowed to bind a resource to the stream (e.g., because the node or user has reached a limit on the number of connected resources allowed). Wont it make sense if there is some provision to automatically logoff the user from a previous resource (based on server provisioning) if he's trying to login from a new resource? Regards, Vinod. PS: any ideas on the directed presence + presence probe issue?
Re: [jdev] Resource binding question
On Sat, Jun 18, 2005 at 01:41:33PM +0530, Vinod Panicker wrote: > Hi, > > If there is a stream over which Resource Binding has successfully > happened, should the client be allowed to perform Resource Binding > again if it requests? > > This scenario is explicitly allowed in the case of Session > Establishment where the server allows the client to perform Resource > Binding with another resource identifier. > > My question is basically whether this should be allowed in other > circumstances as well - the RFC doesn't mention anything explicitly > about this. You'd better to ask this on the xmppwg@jabber.org mailinglist. That list is concerned with protocol discussions on pure XMPP. For JEP protocol discussions there is also the [EMAIL PROTECTED] list. -- Groetjes, ralphm ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo/jdev
[jdev] Resource binding question
Hi, If there is a stream over which Resource Binding has successfully happened, should the client be allowed to perform Resource Binding again if it requests? This scenario is explicitly allowed in the case of Session Establishment where the server allows the client to perform Resource Binding with another resource identifier. My question is basically whether this should be allowed in other circumstances as well - the RFC doesn't mention anything explicitly about this. Regards, Vinod. ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo/jdev
