Re: [Standards] XEP-0175: Contact Addresses
Sorry for the slow reply... Pedro Melo wrote: > Hi, > > during the latest DevCon, one of the issues about deployment was contact > addresses. The current XEP for that is 0157. > > I think that 157 breaks the current disco#info usage pattern. We use > disco#info to discover which protocols an entity supports, not the get > the information directly (exception for basic ). So > receiving the entire contact information in the disco#info reply seems > wrong, because on most requests, we don't need it. > > I think we should use a pubsub node instead. This would give us all the > benefits of pubsub, and we could probably implement this faster, given > that pubsub and pep are starting to get deployed in latest releases of > some servers like Openfire and Ejabberd. > > The schema for the information could be reused from XEP-0157 or > XEP-0154 if that one comes back from the dead. Why not just put this in one of the following? 1. server vCard (XEP-0054) 2. server profile (XEP-0154) Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: Stanza Repeaters
Tobias Markmann wrote: > I think for its most common use case, MUC or PubSub, you will > end up with one repeater for each room(MUC) or node (PubSub) and if > those IDs change each time someone joins or leaves it just adds > complexity. So the repeater service creates the repeater JID however it wants and never changes it. That's well within the spec as written. > A similar optimization could be done by removing deletion of a > repeater by its creator and hand that task off to the repeater > component itself. MUC and PubSub codes don't have to care about a > repeater when they don't need it anymore; just forget about it. The > repeater component removes unused repeaters after a certain timeout > and informs the creator with a message. Sure, that makes sense, just let the repeater get garbage-collected. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: Roster Versioning
Dave Cridland wrote: > On Mon Mar 17 16:31:06 2008, Peter Saint-Andre wrote: >> >> But that's neither here nor there. The question is whether: >> >> (1) acking an occasional roster push from the server to the client >> (where BTW the server *does* know your full JID) is a serious problem >> that we need to solve because it wastes large amounts of bandwidth >> >> > It's not the bandwidth, it's the additional transmission I'm more > concerned with. For every stanza, there's an addition TCP data > packet, and therefore there'll be a further ACK - both of which will > cost power. > > The alternative is that we quietly explain to people that they needn't > bother replying to the push, which I really don't like. I'm pretty > sure that the mobile developers won't want to reply to every roster > push, anyway. You make a point. >> or >> >> (2) sending roster pushes via is a pretty optimization that >> is more elegant than what we developed in 1999, but it fundamentally >> unnecessary >> >> I think (2) obtains. Therefore I think it's just fine to keep IQs for >> roster pushes. If it ain't broke, don't fix it. > > Nothing here is necessary; the question is whether we can, and should, > do it. > > Remember, rosters are not broken right now - they work just fine. So, if > we're going to change things, we may as well consider how much we can > change things, rather than how little. I got my start in the Jabber community as the documentation guy. As a result, I've always seen it as my job to document the protocols as they are used in the community. In that sense I am a conservative, so I don't immediately think "gosh how much can we change things?" but "how little can we change to get our desired functionality?" In my opinion that's one reason our community has stuck together rather than pulled apart (with different projects and companies defining their own extensions). Changing core functionality in a significant way scares me because the feedback I typically receive is that it scares our developer community. Maybe I'm being unduly conservative here, but it seems to me that we legitimately might want to have roster sequencing without changing the core behavior of roster pushes. To summarize the discussion so far, roster sequencing enables the client to know if the roster has not changed (and this is what saves us the greatest amount of bandwidth). Beyond that I see several possible bundles, from smallest change from current behavior to greatest change from current behavior... 1. If the client provides a sequence number on login and the roster has changed since that sequence number, the client receives one old-fashioned roster push (IQ-set) for each item that has been added, modified, or removed. Subsequent roster changes are sent via old-fashioned roster pushes (IQ-set). 2. If the client provides a sequence number on login and the roster has changed since that sequence number, the client receives a "diff" -- that is, a full set of the items that have been added, modified, or removed -- in one IQ set from the server to the client (and this diff may include multiple items). Subsequent roster changes are sent via old-fashioned roster pushes (IQ-set), with one item per push. 3. If the client provides a sequence number on login and the roster has changed since that sequence number, the client receives a "diff" -- that is, a full set of the items that have been added, modified, or removed -- in one from the server to the client (and this diff may include multiple items). Subsequent roster changes are sent via stanzas, which may include multiple items. Is that an accurate summary? Are there other options on the table? Let's get clear on the options so that we can figure out which one is the best way forward. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: Stanza Repeaters
Pedro Melo wrote: > Hi, > > On Mar 17, 2008, at 4:28 PM, XMPP Extensions Editor wrote: >> The XMPP Extensions Editor has received a proposal for a new XEP. >> >> Title: Stanza Repeaters >> >> Abstract: This specification defines an XMPP extension that enables >> optimization of interdomain traffic that is intended for delivery to >> multiple recipients, using the concept of a stanza repeater. >> >> URL: http://www.xmpp.org/extensions/inbox/repeaters.html >> >> The XMPP Council will decide at its next meeting whether to accept >> this proposal as an official XEP. > > I'm sure there is some security implication that I'm missing, but why do > we need to make the hash of the repeater ID so tightly coupled with the > recipients list? We don't need to. That was one suggested approach. > I understand the need of keeping the ID unique but I fail to see what > else is gained by this complexity. > > On the other hand, the use of an ID that doesn't change each time we > update the recipients list would be easier to work it in the presence of > multiple senders. Probably, yes. > Regarding the use of repeaters for , maybe we should just use > the domain of the users as a virtual repeater, like PEP is a virtual > pubsub at the users domain. This was suggested two years ago, btw. It was? I don't remember that. There may be privacy concerns related to presence repeaters (my home server should have control over how my presence is distributed -- it's not acceptable for my server to just send my presence off to another server for it to distribute however it pleases). In any case I don't see presence as the key driver for repeaters -- IMHO, MUC and pubsub are of greater interest. > The roster at the remote host could be used as the distribution list, no > need for costly updates. Just reverse-query the roster if your DB system > provides that (easy for SQL-based rosters, not as simple for LDAP-based > ones). Rosters can get out of sync. The roster at the remote host is not necessarily to be trusted. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: Stanza Repeaters
On Mon, Mar 17, 2008 at 11:47 PM, Pedro Melo <[EMAIL PROTECTED]> wrote: > Hi, > > > > On Mar 17, 2008, at 4:28 PM, XMPP Extensions Editor wrote: > > The XMPP Extensions Editor has received a proposal for a new XEP. > > > > Title: Stanza Repeaters > > > > Abstract: This specification defines an XMPP extension that enables > > optimization of interdomain traffic that is intended for delivery > > to multiple recipients, using the concept of a stanza repeater. > > > > URL: http://www.xmpp.org/extensions/inbox/repeaters.html > > > > The XMPP Council will decide at its next meeting whether to accept > > this proposal as an official XEP. > > I'm sure there is some security implication that I'm missing, but why > do we need to make the hash of the repeater ID so tightly coupled > with the recipients list? > > I understand the need of keeping the ID unique but I fail to see what > else is gained by this complexity. > > On the other hand, the use of an ID that doesn't change each time we > update the recipients list would be easier to work it in the presence > of multiple senders. > > Regarding the use of repeaters for , maybe we should just > use the domain of the users as a virtual repeater, like PEP is a > virtual pubsub at the users domain. This was suggested two years ago, > btw. > > The roster at the remote host could be used as the distribution list, > no need for costly updates. Just reverse-query the roster if your DB > system provides that (easy for SQL-based rosters, not as simple for > LDAP-based ones). > > Best regards, > -- > Pedro Melo > Blog: http://www.simplicidade.org/notes/ > XMPP ID: [EMAIL PROTECTED] > Use XMPP! > > > Right. I think for its most common use case, MUC or PubSub, you will end up with one repeater for each room(MUC) or node (PubSub) and if those IDs change each time someone joins or leaves it just adds complexity. A similar optimization could be done by removing deletion of a repeater by its creator and hand that task off to the repeater component itself. MUC and PubSub codes don't have to care about a repeater when they don't need it anymore; just forget about it. The repeater component removes unused repeaters after a certain timeout and informs the creator with a message. Tobias
Re: [Standards] Originator & Receiver Concept
Max Indelicato wrote: > I'd like to make sure before going forward with my XMPP server design, > that I have one particular basic concept absolutely correct. Why are you developing a new server? Just curious. :) /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: Stanza Repeaters
Nolan Eakins wrote: > On Mon, Mar 17, 2008 at 6:03 PM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: >> Nolan Eakins wrote: >> >> Example 1. Stanza as sent to repeater >> > >> >>> >> from='[EMAIL PROTECTED]/foo' >> >> to='[EMAIL PROTECTED]' >> >> type='probe'/> >> >> We had that in version 0.0.0.5. :) >> >> The problem is that you can't send disco requests or other management >> tasks to the repeater. But you could do that by sending those requests >> to the repeater service and specifying the particular repeater you're >> interested in. >> >> Another thing is that the IQ semantics are helpful here -- the repeater >> validates that it has sent all the stanzas and then sends you an IQ result. > > I fail to understand the gain there. AFAIK, nothing else in Jabber > provides such an ack, not even for a single message. > > Personally, I'm failing to understand this prevalence of using > to send messages here and in pubsub. That train has left the station w.r.t. pubsub. But nothing forces us to follow that pattern here. > It really boils down to: given a > basic client that understands some disco, how can I make use of this > repeater w/o using the XML console? IMHO this spec is not for clients, it's something that servers and components (MUC, pubsub, etc.) would use among themselves. > Presumably via disco and perhaps data forms a client can manage a set > of repeaters. No new code is needed. It would give me a JID that I > could add to my roster (maybe that gets done automagically?) or > directly send a message to w/ some copy and paste. Yes, that is attractive *if* we think this is something that clients need or would use. But note the spam potential. :-) > As is, this is one more XEP that must be specifically supported by > both clients and servers. Yay! See above. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: Roster Versioning
Pedro Melo wrote: > Hi, > > On Mar 17, 2008, at 10:11 PM, Peter Saint-Andre wrote: >> Pedro Melo wrote: >>> On Mar 17, 2008, at 3:22 PM, Peter Saint-Andre wrote: Pedro Melo wrote: > On Mar 11, 2008, at 12:06 AM, Dave Cridland wrote: >> On Mon Mar 10 23:45:28 2008, Peter Saint-Andre wrote: >>> One potential problem: this is not a nice, small, incremental >>> change. >>> Now servers and clients must support: >>> 1. The 'sequence' attribute. >>> 2. Roster pushes via message, not IQ. >>> 3. Multiple items in a roster push. >>> 4. Multiple items in a roster set. >>> The more we change, the less likely it is that clients and servers >>> will >>> add this feature. Then we're back where we started. >>> "If it ain't broke, don't fix it." >>> So what's broken? >>> 1. Huge roster gets every time you log in. The 'sequence' stuff >>> fixes >>> this. >>> What's not broken? >>> 2. Roster pushes via IQ. >>> 3. One item per roster push. >>> 4. One item per roster set. >>> Why are we fixing 2, 3, and 4? Just because we can? Because it is >>> more >>> elegant? Or because it really solves a big problem on the network? >>> Unless there is a compelling need, I'd vote for changing as >>> little as >>> possible. >> >> The problem is that if you go for Joe's concept - which is certainly >> elegant - of having the roster "diff" simply sent as a bunch of >> pushes, then these - being sent as - need to be acknowledged. >> Now, I appreciate that clients don't always do this, but the fact is >> that they should be doing so. I'm unhappy with suggesting that >> clients >> quietly ignore RFC 3920 because nobody cares. >> >> So we can fix that simply by using instead of - it's >> a pretty trivial change, and it eliminates the type='result' reply >> for >> clients on all pushes, so it's inarguably a performance improvement. > > Ok, I must have been missing something because if you want to fix > something, why not just do multiple items per roster push? Because it's never been done that way. > The argument that diff is complex doesn't play well with me. Each item > is a replacement item, so no diff required. The usual code for a > client > "foreach item update my model" will work with both. But clients have never expected multiple items in a roster push. However, that might be something clients could move to if they support sequencing. My question is: will clients do that? >>> >>> Yes. Basically if I'm a client and I'm telling the server that yes, I >>> support sequencing and I want to use it, the server is OK to change >>> previous rules if they are specified in the new XEP. >> >> Yes, I know that client developers *could* add this support, but my >> question is: *will* they really do so or will they see this spec and say >> "well this roster sequencing stuff looks nice but &@#$&?^!@ I need to >> modify my roster handling code and I haven't touched that in 3 years, >> what the heck is the XSF thinking?!?!" > > Yes, I understand that. > > The whole point about this was saving bandwidth. True. I contend that not receiving the main roster on login is the major savings. If a few roster pushes dribble in after you login, it's no big deal in the grand scheme of things (after all, how many people log in with multiple clients and experience multiple roster changes while they are offline with a given client?). > The current method of a > single item per push would waste a bit in the IQ replies. A bit, yes. But we don't have to save every last little byte. Let's differentiate between what's nice and what's necessary. > The > alternatives suggested where re-using messages to deliver roster pushes, > or ignore the IQ replies with a new IQ type "fire-and-forget" (not the > final type of course :) ) or bundle up multiple roster items in a single > push. I might have missed another approach... > > Of all this, I think the multiple items per push is the least intrusive. > But if even that is a problem, we could always make it an option: when > we tell the server that we want to use roster sync, tell him that we > support multiple items per push also. Don't get me wrong: I'm not deeply opposed to multiple items in a roster push. If we bundle that feature with roster synchronization then we'll probably be OK. I just wanted to make sure we performed a sanity check with our wonderful developer community before we moved ahead. :) Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: Roster Versioning
On Mon Mar 17 16:31:06 2008, Peter Saint-Andre wrote: Dave Cridland wrote: > On Mon Mar 17 15:22:28 2008, Peter Saint-Andre wrote: >> Pedro Melo wrote: >> > Lets not abuse the meaning of just because we like their >> > network properties, like we abused in the past because it >> > broadcasts well. >> >> +1. >> >> > Absolutely. So I'm looking forward to seeing the update to XEP-0060 > which changes PubSub pushes from being to , in (for > example) section 7.1.2.1. > > Or, alternately, could someone explain to me why the use of > stanzas for the 7.1.2.1 case is not "abuse", whereas would be. Looks to > me like they're the same use-case. Very funny. :P We use messages there in part because using IQs would require knowing the full JID (and stock pubsub services do not know that). Gosh - you mean you chose because of its network properties? ;-) But that's neither here nor there. The question is whether: (1) acking an occasional roster push from the server to the client (where BTW the server *does* know your full JID) is a serious problem that we need to solve because it wastes large amounts of bandwidth It's not the bandwidth, it's the additional transmission I'm more concerned with. For every stanza, there's an addition TCP data packet, and therefore there'll be a further ACK - both of which will cost power. The alternative is that we quietly explain to people that they needn't bother replying to the push, which I really don't like. I'm pretty sure that the mobile developers won't want to reply to every roster push, anyway. or (2) sending roster pushes via is a pretty optimization that is more elegant than what we developed in 1999, but it fundamentally unnecessary I think (2) obtains. Therefore I think it's just fine to keep IQs for roster pushes. If it ain't broke, don't fix it. Nothing here is necessary; the question is whether we can, and should, do it. Remember, rosters are not broken right now - they work just fine. So, if we're going to change things, we may as well consider how much we can change things, rather than how little. Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - 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: Stanza Repeaters
Hi, On Mar 17, 2008, at 4:28 PM, XMPP Extensions Editor wrote: The XMPP Extensions Editor has received a proposal for a new XEP. Title: Stanza Repeaters Abstract: This specification defines an XMPP extension that enables optimization of interdomain traffic that is intended for delivery to multiple recipients, using the concept of a stanza repeater. URL: http://www.xmpp.org/extensions/inbox/repeaters.html The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP. I'm sure there is some security implication that I'm missing, but why do we need to make the hash of the repeater ID so tightly coupled with the recipients list? I understand the need of keeping the ID unique but I fail to see what else is gained by this complexity. On the other hand, the use of an ID that doesn't change each time we update the recipients list would be easier to work it in the presence of multiple senders. Regarding the use of repeaters for , maybe we should just use the domain of the users as a virtual repeater, like PEP is a virtual pubsub at the users domain. This was suggested two years ago, btw. The roster at the remote host could be used as the distribution list, no need for costly updates. Just reverse-query the roster if your DB system provides that (easy for SQL-based rosters, not as simple for LDAP-based ones). Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP!
Re: [Standards] Proposed XMPP Extension: Roster Versioning
Hi, On Mar 17, 2008, at 10:11 PM, Peter Saint-Andre wrote: Pedro Melo wrote: On Mar 17, 2008, at 3:22 PM, Peter Saint-Andre wrote: Pedro Melo wrote: On Mar 11, 2008, at 12:06 AM, Dave Cridland wrote: On Mon Mar 10 23:45:28 2008, Peter Saint-Andre wrote: One potential problem: this is not a nice, small, incremental change. Now servers and clients must support: 1. The 'sequence' attribute. 2. Roster pushes via message, not IQ. 3. Multiple items in a roster push. 4. Multiple items in a roster set. The more we change, the less likely it is that clients and servers will add this feature. Then we're back where we started. "If it ain't broke, don't fix it." So what's broken? 1. Huge roster gets every time you log in. The 'sequence' stuff fixes this. What's not broken? 2. Roster pushes via IQ. 3. One item per roster push. 4. One item per roster set. Why are we fixing 2, 3, and 4? Just because we can? Because it is more elegant? Or because it really solves a big problem on the network? Unless there is a compelling need, I'd vote for changing as little as possible. The problem is that if you go for Joe's concept - which is certainly elegant - of having the roster "diff" simply sent as a bunch of pushes, then these - being sent as - need to be acknowledged. Now, I appreciate that clients don't always do this, but the fact is that they should be doing so. I'm unhappy with suggesting that clients quietly ignore RFC 3920 because nobody cares. So we can fix that simply by using instead of - it's a pretty trivial change, and it eliminates the type='result' reply for clients on all pushes, so it's inarguably a performance improvement. Ok, I must have been missing something because if you want to fix something, why not just do multiple items per roster push? Because it's never been done that way. The argument that diff is complex doesn't play well with me. Each item is a replacement item, so no diff required. The usual code for a client "foreach item update my model" will work with both. But clients have never expected multiple items in a roster push. However, that might be something clients could move to if they support sequencing. My question is: will clients do that? Yes. Basically if I'm a client and I'm telling the server that yes, I support sequencing and I want to use it, the server is OK to change previous rules if they are specified in the new XEP. Yes, I know that client developers *could* add this support, but my question is: *will* they really do so or will they see this spec and say "well this roster sequencing stuff looks nice but &@#$&?^!@ I need to modify my roster handling code and I haven't touched that in 3 years, what the heck is the XSF thinking?!?!" Yes, I understand that. The whole point about this was saving bandwidth. The current method of a single item per push would waste a bit in the IQ replies. The alternatives suggested where re-using messages to deliver roster pushes, or ignore the IQ replies with a new IQ type "fire-and- forget" (not the final type of course :) ) or bundle up multiple roster items in a single push. I might have missed another approach... Of all this, I think the multiple items per push is the least intrusive. But if even that is a problem, we could always make it an option: when we tell the server that we want to use roster sync, tell him that we support multiple items per push also. Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP!
Re: [Standards] Proposed XMPP Extension: Stanza Repeaters
On Mon, Mar 17, 2008 at 6:03 PM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > Nolan Eakins wrote: > >> Example 1. Stanza as sent to repeater > > > >> >> from='[EMAIL PROTECTED]/foo' > >> to='[EMAIL PROTECTED]' > >> type='probe'/> > > We had that in version 0.0.0.5. :) > > The problem is that you can't send disco requests or other management > tasks to the repeater. But you could do that by sending those requests > to the repeater service and specifying the particular repeater you're > interested in. > > Another thing is that the IQ semantics are helpful here -- the repeater > validates that it has sent all the stanzas and then sends you an IQ result. I fail to understand the gain there. AFAIK, nothing else in Jabber provides such an ack, not even for a single message. Personally, I'm failing to understand this prevalence of using to send messages here and in pubsub. It really boils down to: given a basic client that understands some disco, how can I make use of this repeater w/o using the XML console? Presumably via disco and perhaps data forms a client can manage a set of repeaters. No new code is needed. It would give me a JID that I could add to my roster (maybe that gets done automagically?) or directly send a message to w/ some copy and paste. As is, this is one more XEP that must be specifically supported by both clients and servers. Yay! - Nolan Eakins -- SemanticGap(R) - http://www.semanticgap.com/
Re: [Standards] Proposed XMPP Extension: Stanza Repeaters
Le lundi 17 mars 2008, Peter Saint-Andre a écrit : > Olivier Goffart wrote: > > Le lundi 17 mars 2008, XMPP Extensions Editor a écrit : > >> The XMPP Extensions Editor has received a proposal for a new XEP. > >> > >> Title: Stanza Repeaters > >> > >> Abstract: This specification defines an XMPP extension that enables > >> optimization of interdomain traffic that is intended for delivery to > >> multiple recipients, using the concept of a stanza repeater. > >> > >> URL: http://www.xmpp.org/extensions/inbox/repeaters.html > >> > >> The XMPP Council will decide at its next meeting whether to accept this > >> proposal as an official XEP. > > > > maybe a bit HS: > > example.com >< example.net this is confising to read... what about > > capulet.com / montague.net or similair? :-) > > Yeah yeah yeah. People keep complaining about all the Shakespeare > examples, but when you remove them things get confusing. :P Ah, I didn't know you had complains about shakespeare. I personaly find that nice and consistant. Maybe receiver.com and sender.net ? But anyway, this is offtopic and not really important, sorry for this mail :-) -- Olivier (or alice.com and bob.net?) signature.asc Description: This is a digitally signed message part.
Re: [Standards] Proposed XMPP Extension: Roster Versioning
Pedro Melo wrote: > Hi, > > On Mar 17, 2008, at 3:22 PM, Peter Saint-Andre wrote: >> Pedro Melo wrote: >>> On Mar 11, 2008, at 12:06 AM, Dave Cridland wrote: On Mon Mar 10 23:45:28 2008, Peter Saint-Andre wrote: > One potential problem: this is not a nice, small, incremental change. > Now servers and clients must support: > 1. The 'sequence' attribute. > 2. Roster pushes via message, not IQ. > 3. Multiple items in a roster push. > 4. Multiple items in a roster set. > The more we change, the less likely it is that clients and servers > will > add this feature. Then we're back where we started. > "If it ain't broke, don't fix it." > So what's broken? > 1. Huge roster gets every time you log in. The 'sequence' stuff fixes > this. > What's not broken? > 2. Roster pushes via IQ. > 3. One item per roster push. > 4. One item per roster set. > Why are we fixing 2, 3, and 4? Just because we can? Because it is more > elegant? Or because it really solves a big problem on the network? > Unless there is a compelling need, I'd vote for changing as little as > possible. The problem is that if you go for Joe's concept - which is certainly elegant - of having the roster "diff" simply sent as a bunch of pushes, then these - being sent as - need to be acknowledged. Now, I appreciate that clients don't always do this, but the fact is that they should be doing so. I'm unhappy with suggesting that clients quietly ignore RFC 3920 because nobody cares. So we can fix that simply by using instead of - it's a pretty trivial change, and it eliminates the type='result' reply for clients on all pushes, so it's inarguably a performance improvement. >>> >>> Ok, I must have been missing something because if you want to fix >>> something, why not just do multiple items per roster push? >> >> Because it's never been done that way. >> >>> The argument that diff is complex doesn't play well with me. Each item >>> is a replacement item, so no diff required. The usual code for a client >>> "foreach item update my model" will work with both. >> >> But clients have never expected multiple items in a roster push. >> However, that might be something clients could move to if they support >> sequencing. My question is: will clients do that? > > Yes. Basically if I'm a client and I'm telling the server that yes, I > support sequencing and I want to use it, the server is OK to change > previous rules if they are specified in the new XEP. Yes, I know that client developers *could* add this support, but my question is: *will* they really do so or will they see this spec and say "well this roster sequencing stuff looks nice but &@#$&?^!@ I need to modify my roster handling code and I haven't touched that in 3 years, what the heck is the XSF thinking?!?!" smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: Roster Versioning
Hi, On Mar 17, 2008, at 3:22 PM, Peter Saint-Andre wrote: Pedro Melo wrote: On Mar 11, 2008, at 12:06 AM, Dave Cridland wrote: On Mon Mar 10 23:45:28 2008, Peter Saint-Andre wrote: One potential problem: this is not a nice, small, incremental change. Now servers and clients must support: 1. The 'sequence' attribute. 2. Roster pushes via message, not IQ. 3. Multiple items in a roster push. 4. Multiple items in a roster set. The more we change, the less likely it is that clients and servers will add this feature. Then we're back where we started. "If it ain't broke, don't fix it." So what's broken? 1. Huge roster gets every time you log in. The 'sequence' stuff fixes this. What's not broken? 2. Roster pushes via IQ. 3. One item per roster push. 4. One item per roster set. Why are we fixing 2, 3, and 4? Just because we can? Because it is more elegant? Or because it really solves a big problem on the network? Unless there is a compelling need, I'd vote for changing as little as possible. The problem is that if you go for Joe's concept - which is certainly elegant - of having the roster "diff" simply sent as a bunch of pushes, then these - being sent as - need to be acknowledged. Now, I appreciate that clients don't always do this, but the fact is that they should be doing so. I'm unhappy with suggesting that clients quietly ignore RFC 3920 because nobody cares. So we can fix that simply by using instead of - it's a pretty trivial change, and it eliminates the type='result' reply for clients on all pushes, so it's inarguably a performance improvement. Ok, I must have been missing something because if you want to fix something, why not just do multiple items per roster push? Because it's never been done that way. The argument that diff is complex doesn't play well with me. Each item is a replacement item, so no diff required. The usual code for a client "foreach item update my model" will work with both. But clients have never expected multiple items in a roster push. However, that might be something clients could move to if they support sequencing. My question is: will clients do that? Yes. Basically if I'm a client and I'm telling the server that yes, I support sequencing and I want to use it, the server is OK to change previous rules if they are specified in the new XEP. Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP!
Re: [Standards] Proposed XMPP Extension: Stanza Repeaters
Nolan Eakins wrote: > On Mon, Mar 17, 2008 at 12:28 PM, XMPP Extensions Editor > <[EMAIL PROTECTED]> wrote: >> The XMPP Extensions Editor has received a proposal for a new XEP. >> >> Title: Stanza Repeaters >> >> Abstract: This specification defines an XMPP extension that enables >> optimization of interdomain traffic that is intended for delivery to >> multiple recipients, using the concept of a stanza repeater. >> >> URL: http://www.xmpp.org/extensions/inbox/repeaters.html > > Thought I'd take a look at how this worked. My first question is: why > are we sending stanzas to the repeater using s? Why can't I > create a repeater, using s of course, and then begin sending > stanzas directly to the repeater which then forwards them out to > everyone? > > Looking at the examples, it looks like the repeater service is giving > each repeater a JID. Sending stanzas to it directly ought to work. > Perhaps something like: > >> Example 1. Stanza as sent to repeater > >>> from='[EMAIL PROTECTED]/foo' >> to='[EMAIL PROTECTED]' >> type='probe'/> We had that in version 0.0.0.5. :) The problem is that you can't send disco requests or other management tasks to the repeater. But you could do that by sending those requests to the repeater service and specifying the particular repeater you're interested in. Another thing is that the IQ semantics are helpful here -- the repeater validates that it has sent all the stanzas and then sends you an IQ result. > One problem is that all of the management use cases in the XEP would > probably need to be changed so that repeating stanzas is > simpler. This is easily changed by making the repeater service's JID > handle all management requests for individual repeaters. Right. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: Stanza Repeaters
On Mon, Mar 17, 2008 at 12:28 PM, XMPP Extensions Editor <[EMAIL PROTECTED]> wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Stanza Repeaters > > Abstract: This specification defines an XMPP extension that enables > optimization of interdomain traffic that is intended for delivery to multiple > recipients, using the concept of a stanza repeater. > > URL: http://www.xmpp.org/extensions/inbox/repeaters.html Thought I'd take a look at how this worked. My first question is: why are we sending stanzas to the repeater using s? Why can't I create a repeater, using s of course, and then begin sending stanzas directly to the repeater which then forwards them out to everyone? Looking at the examples, it looks like the repeater service is giving each repeater a JID. Sending stanzas to it directly ought to work. Perhaps something like: > Example 1. Stanza as sent to repeater > from='[EMAIL PROTECTED]/foo' > to='[EMAIL PROTECTED]' > type='probe'/> One problem is that all of the management use cases in the XEP would probably need to be changed so that repeating stanzas is simpler. This is easily changed by making the repeater service's JID handle all management requests for individual repeaters. - Nolan Eakins -- SemanticGap(R) - http://www.semanticgap.com/
Re: [Standards] Proposed XMPP Extension: Stanza Repeaters
Olivier Goffart wrote: > Le lundi 17 mars 2008, XMPP Extensions Editor a écrit : >> The XMPP Extensions Editor has received a proposal for a new XEP. >> >> Title: Stanza Repeaters >> >> Abstract: This specification defines an XMPP extension that enables >> optimization of interdomain traffic that is intended for delivery to >> multiple recipients, using the concept of a stanza repeater. >> >> URL: http://www.xmpp.org/extensions/inbox/repeaters.html >> >> The XMPP Council will decide at its next meeting whether to accept this >> proposal as an official XEP. > > maybe a bit HS: > example.com >< example.net this is confising to read... what about > capulet.com / montague.net or similair? :-) Yeah yeah yeah. People keep complaining about all the Shakespeare examples, but when you remove them things get confusing. :P smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: Stanza Repeaters
Le lundi 17 mars 2008, XMPP Extensions Editor a écrit : > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Stanza Repeaters > > Abstract: This specification defines an XMPP extension that enables > optimization of interdomain traffic that is intended for delivery to > multiple recipients, using the concept of a stanza repeater. > > URL: http://www.xmpp.org/extensions/inbox/repeaters.html > > The XMPP Council will decide at its next meeting whether to accept this > proposal as an official XEP. maybe a bit HS: example.com >< example.net this is confising to read... what about capulet.com / montague.net or similair? :-) signature.asc Description: This is a digitally signed message part.
[Standards] reminder: Last Calls for XEPs 171, 189, 222, 223
Last Calls for the following specs end on Friday, March 21: XEP-0171: Language Translation http://www.xmpp.org/extensions/xep-0171.html XEP-0189: Public Key Publishing http://www.xmpp.org/extensions/xep-0189.html XEP-0222: Persistent Storage of Public Data via Publish-Subscribe http://www.xmpp.org/extensions/xep-0222.html XEP-0223: Persistent Storage of Private Data via Publish-Subscribe http://www.xmpp.org/extensions/xep-0223.html Comment early, comment often! Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: Stanza Repeaters
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: Stanza Repeaters >>> >>> Abstract: This specification defines an XMPP extension that enables >>> optimization of interdomain traffic that is intended for delivery to >>> multiple recipients, using the concept of a stanza repeater. >>> >>> URL: http://www.xmpp.org/extensions/inbox/repeaters.html >> This is the spec that emerged from discussions about how to fix XEP-0033 >> (or not). Feedback is welcome. :) > > I chatted about this with Ralph Meijer via IM. He pointed out that a > repeater is (conceptually) a minimal pubsub node that doesn't allow you > to subscribe and that sends out stanzas on the other end, not pubsub > notification messages. He wasn't necessarily suggesting that we define > repeaters as pubsub nodes, just pointing out the strong similarities. However, to enable code re-use between pubsub services and repeater services, we might want to specify that repeater JIDs are of the following form: repeater.example.com/foo See Section 4.6.1 of XEP-0060: http://www.xmpp.org/extensions/xep-0060.html#addressing-jid /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: Stanza Repeaters
Peter Saint-Andre wrote: > XMPP Extensions Editor wrote: >> The XMPP Extensions Editor has received a proposal for a new XEP. >> >> Title: Stanza Repeaters >> >> Abstract: This specification defines an XMPP extension that enables >> optimization of interdomain traffic that is intended for delivery to >> multiple recipients, using the concept of a stanza repeater. >> >> URL: http://www.xmpp.org/extensions/inbox/repeaters.html > > This is the spec that emerged from discussions about how to fix XEP-0033 > (or not). Feedback is welcome. :) I chatted about this with Ralph Meijer via IM. He pointed out that a repeater is (conceptually) a minimal pubsub node that doesn't allow you to subscribe and that sends out stanzas on the other end, not pubsub notification messages. He wasn't necessarily suggesting that we define repeaters as pubsub nodes, just pointing out the strong similarities. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: Stanza Repeaters
On Mon, 2008-03-17 at 12:14 -0600, Joe Hildebrand wrote: > On Mar 17, 2008, at 11:38 AM, Andrew Plotkin wrote: > > > What happens if you tell a repeater to broadcast an ? > > > > The naive outcome is that all the recipients send you an > > directly, each with an ID that you've never heard > > of. That will mess with most client libraries -- at least, the ones > > I've seen; they expect IQ-results only to IQ-set or get, with > > matching IDs. > > > > Conservative proposal: declare that you can only broadcast message > > or presence. > > Good point. Perhaps just a warning that you'll get multiple responses > back, so you SHOULD NOT send IQs through the repeater unless you are > willing to deal with iq responses to requests you didn't send. Reading this spec, I assume that a server providing this functionality has some kind of tight integration between the repeater service and the part of the server responsible for the domain it acts on behalf of. In that case, I assume that the service could also aggregate the responses. Not sure if that is desirable, though. -- Groetjes, ralphm
Re: [Standards] Proposed XMPP Extension: Stanza Repeaters
On Mar 17, 2008, at 11:38 AM, Andrew Plotkin wrote: What happens if you tell a repeater to broadcast an ? The naive outcome is that all the recipients send you an directly, each with an ID that you've never heard of. That will mess with most client libraries -- at least, the ones I've seen; they expect IQ-results only to IQ-set or get, with matching IDs. Conservative proposal: declare that you can only broadcast message or presence. Good point. Perhaps just a warning that you'll get multiple responses back, so you SHOULD NOT send IQs through the repeater unless you are willing to deal with iq responses to requests you didn't send. -- Joe Hildebrand
Re: [Standards] Proposed XMPP Extension: Stanza Repeaters
On Mon, 17 Mar 2008, Peter Saint-Andre wrote: XMPP Extensions Editor wrote: The XMPP Extensions Editor has received a proposal for a new XEP. Title: Stanza Repeaters Abstract: This specification defines an XMPP extension that enables optimization of interdomain traffic that is intended for delivery to multiple recipients, using the concept of a stanza repeater. URL: http://www.xmpp.org/extensions/inbox/repeaters.html This is the spec that emerged from discussions about how to fix XEP-0033 (or not). Feedback is welcome. :) What happens if you tell a repeater to broadcast an ? The naive outcome is that all the recipients send you an directly, each with an ID that you've never heard of. That will mess with most client libraries -- at least, the ones I've seen; they expect IQ-results only to IQ-set or get, with matching IDs. Conservative proposal: declare that you can only broadcast message or presence. --Z -- "And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..." * If the Bush administration hasn't shipped you to Syria for interrogation, it's for one reason: they don't feel like it. Not because you're patriotic.
Re: [Standards] Proposed XMPP Extension: Roster Versioning
Richard Dobson wrote: > >> Very funny. :P >> >> We use messages there in part because using IQs would require knowing >> the full JID (and stock pubsub services do not know that). >> >> But that's neither here nor there. The question is whether: >> >> (1) acking an occasional roster push from the server to the client >> (where BTW the server *does* know your full JID) is a serious problem >> that we need to solve because it wastes large amounts of bandwidth >> >> or >> >> (2) sending roster pushes via is a pretty optimization that >> is more elegant than what we developed in 1999, but it fundamentally >> unnecessary >> >> I think (2) obtains. Therefore I think it's just fine to keep IQs for >> roster pushes. If it ain't broke, don't fix it. >> >> Peter >> > > Also surely if you are doing roster sequencing I would have thought it > would be important for the server to know if you have received the push > or not in order to keep things in sync correctly? So the ack is actually > quite useful. I'm not sure if the server absolutely needs to know if you have received the push because in general I think the server will just send out all the pushes without blocking on receipt of an ack. However, I can imagine cases where the server might want to receive the acks for some kind of tracking purpose. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: Roster Versioning
Very funny. :P We use messages there in part because using IQs would require knowing the full JID (and stock pubsub services do not know that). But that's neither here nor there. The question is whether: (1) acking an occasional roster push from the server to the client (where BTW the server *does* know your full JID) is a serious problem that we need to solve because it wastes large amounts of bandwidth or (2) sending roster pushes via is a pretty optimization that is more elegant than what we developed in 1999, but it fundamentally unnecessary I think (2) obtains. Therefore I think it's just fine to keep IQs for roster pushes. If it ain't broke, don't fix it. Peter Also surely if you are doing roster sequencing I would have thought it would be important for the server to know if you have received the push or not in order to keep things in sync correctly? So the ack is actually quite useful. Richard
Re: [Standards] Proposed XMPP Extension: Stanza Repeaters
XMPP Extensions Editor wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Stanza Repeaters > > Abstract: This specification defines an XMPP extension that enables > optimization of interdomain traffic that is intended for delivery to > multiple recipients, using the concept of a stanza repeater. > > URL: http://www.xmpp.org/extensions/inbox/repeaters.html This is the spec that emerged from discussions about how to fix XEP-0033 (or not). Feedback is welcome. :) Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: Roster Versioning
Dave Cridland wrote: > On Mon Mar 17 15:22:28 2008, Peter Saint-Andre wrote: >> Pedro Melo wrote: >> > Lets not abuse the meaning of just because we like their >> > network properties, like we abused in the past because it >> > broadcasts well. >> >> +1. >> >> > Absolutely. So I'm looking forward to seeing the update to XEP-0060 > which changes PubSub pushes from being to , in (for > example) section 7.1.2.1. > > Or, alternately, could someone explain to me why the use of > stanzas for the 7.1.2.1 case is not "abuse", whereas would be. Looks to > me like they're the same use-case. Very funny. :P We use messages there in part because using IQs would require knowing the full JID (and stock pubsub services do not know that). But that's neither here nor there. The question is whether: (1) acking an occasional roster push from the server to the client (where BTW the server *does* know your full JID) is a serious problem that we need to solve because it wastes large amounts of bandwidth or (2) sending roster pushes via is a pretty optimization that is more elegant than what we developed in 1999, but it fundamentally unnecessary I think (2) obtains. Therefore I think it's just fine to keep IQs for roster pushes. If it ain't broke, don't fix it. Peter smime.p7s Description: S/MIME Cryptographic Signature
[Standards] Proposed XMPP Extension: Stanza Repeaters
The XMPP Extensions Editor has received a proposal for a new XEP. Title: Stanza Repeaters Abstract: This specification defines an XMPP extension that enables optimization of interdomain traffic that is intended for delivery to multiple recipients, using the concept of a stanza repeater. URL: http://www.xmpp.org/extensions/inbox/repeaters.html The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP.
Re: [Standards] Proposed XMPP Extension: Roster Versioning
On Mon Mar 17 15:22:28 2008, Peter Saint-Andre wrote: Pedro Melo wrote: > Lets not abuse the meaning of just because we like their > network properties, like we abused in the past because it > broadcasts well. +1. Absolutely. So I'm looking forward to seeing the update to XEP-0060 which changes PubSub pushes from being to , in (for example) section 7.1.2.1. Or, alternately, could someone explain to me why the use of stanzas for the 7.1.2.1 case is not "abuse", whereas would be. Looks to me like they're the same use-case. Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - 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: Roster Versioning
Pedro Melo wrote: > Hi, > > On Mar 11, 2008, at 12:06 AM, Dave Cridland wrote: >> On Mon Mar 10 23:45:28 2008, Peter Saint-Andre wrote: >>> One potential problem: this is not a nice, small, incremental change. >>> Now servers and clients must support: >>> 1. The 'sequence' attribute. >>> 2. Roster pushes via message, not IQ. >>> 3. Multiple items in a roster push. >>> 4. Multiple items in a roster set. >>> The more we change, the less likely it is that clients and servers will >>> add this feature. Then we're back where we started. >>> "If it ain't broke, don't fix it." >>> So what's broken? >>> 1. Huge roster gets every time you log in. The 'sequence' stuff fixes >>> this. >>> What's not broken? >>> 2. Roster pushes via IQ. >>> 3. One item per roster push. >>> 4. One item per roster set. >>> Why are we fixing 2, 3, and 4? Just because we can? Because it is more >>> elegant? Or because it really solves a big problem on the network? >>> Unless there is a compelling need, I'd vote for changing as little as >>> possible. >> >> The problem is that if you go for Joe's concept - which is certainly >> elegant - of having the roster "diff" simply sent as a bunch of >> pushes, then these - being sent as - need to be acknowledged. >> Now, I appreciate that clients don't always do this, but the fact is >> that they should be doing so. I'm unhappy with suggesting that clients >> quietly ignore RFC 3920 because nobody cares. >> >> So we can fix that simply by using instead of - it's >> a pretty trivial change, and it eliminates the type='result' reply for >> clients on all pushes, so it's inarguably a performance improvement. > > Ok, I must have been missing something because if you want to fix > something, why not just do multiple items per roster push? Because it's never been done that way. > The argument that diff is complex doesn't play well with me. Each item > is a replacement item, so no diff required. The usual code for a client > "foreach item update my model" will work with both. But clients have never expected multiple items in a roster push. However, that might be something clients could move to if they support sequencing. My question is: will clients do that? > So "abusing" message just so that you don't need to reply seems wrong. > If we really need result-less IQs then make them so: allow for type="notify"> or something and be done with it. And make it > broadcast-able to all connected resources. Yes, it needs to be in > bis-work, but then again, if you don't advertise that you want > incremental rosters, you won't get them. All is fair if you pre-declare... > > Lets not abuse the meaning of just because we like their > network properties, like we abused in the past because it > broadcasts well. +1. >> Next up, Joe introduces a problem in as much as the client can't tell >> when it's finished receiving updates, and is now receiving bona-fide >> pushes. Joe says this isn't a problem, but I'm unconvinced - client >> authors have said this is a niggle, at least, for the initial presence >> push, after all. > > We lived with not knowing when the presence stream finishes, and that > was acceptable because presence is really a distributed concept so it is > impossible to know when other servers will respond. > > Rosters on the other hand are purely local to the domain concepts, so it > should be easy to say when they are over. > > On the other hand, I agree with Joe: our clients already have to deal > with roster pushes at any point in time, so I don't see the a problem here. Agreed. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
