Re: [Standards] Inconsistent Subscriptions in XMPP
You just have to tell the deveopers to do it, then :). On Tue, 24 Feb 2009 15:54:38 + Pedro Melo m...@simplicidade.org wrote: Hi, On Feb 24, 2009, at 12:49 AM, Pavel Simerda wrote: There are several cases when subscription databases in XMPP are inconsistent. You may view subscription information as a global distributed database. Subscription state between two JIDs, for example a...@a and b...@b are stored in two places at the same time. Servers A and B maintain their own copies of subscription state. [] What with the roster items that are inconsistent? * Mark as inconsistent, let the client present it to the user to take action. * Auto-repair and thus maintain consistency Looking forward to all feedback. When you send out a presence type=probe / include the local view of the subscription state. The receiving server can then look to see if the state is consisten with his own state. If you opt by the lowest trust level (a from/to beats a both, none beats all), you should be able to re-sync subscription state automagically. Best regards, -- Freelance consultant and trainer in networking, communications and security. Web: http://www.pavlix.net/ Jabber, Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] various rfc3920bis feedback
On Tue, 24 Feb 2009 20:14:27 +0100 Philipp Hancke fi...@goodadvice.pages.de wrote: Pavel Simerda wrote: * connection reuse for multiple s2s links would be a very useful feature, ask Dave for details Piggybacking. Which is subtly broken in RFC 3920 - at least 50% of it. host-unknown/ makes 'target piggybacking' (different to) unusable, as you risk the entire stream. Please provide more specific info about how to fix it in bis I fixed in in my working copy of 220 by completly getting rid of host-unknown for dialback. type='error' seems a good fix. and if/why it is broken now. The relevant passage from 3920 about piggybacking is: After successful dialback negotiation, the Receiving Server SHOULD accept subsequent db:result/ packets (e.g., validation requests sent to a subdomain or other hostname serviced by the Receiving Server) from the Originating Server over the existing validated connection; this enables piggybacking of the original validated connection in one direction. If the receiving server is 'jabber.org', validation requests sent to a subdomain or other hostname serviced by the Receiving Server means that I can piggyback stanzas to 'users.jabber.org' on that connection (target piggybacking, google uses source piggybacking). draft-saintandre-rfc3920bis-08.html added the host-unknown stream error to dialback with the following description: the value of the 'to' attribute provided by the initiating entity in the stream header does not correspond to a hostname that is hosted by the ^ server. Now what happens should I attempt to piggyback the users.jabber.org connection on the jabber.org connection? jabber.org kills my stream. As I said to Peter IMO the whole idea of piggybacking is misguided. Piggybacking means re-using a connection A for data that would otherwise come in B. It would be better to think about it as a generic multiplex. Then all virtual connections would be equal (A and B, specifically). One would immediately see the consequences of closing the physical connection (that should only be closed if all virtual connections are closed). Keeping this as an optional feature (I believe that is a near consensus) will further simplify the most basic implementations. philipp -- Freelance consultant and trainer in networking, communications and security. Web: http://www.pavlix.net/ Jabber, Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] Inconsistent Subscriptions in XMPP
On Tue, 24 Feb 2009 15:54:38 + Pedro Melo m...@simplicidade.org wrote: Hi, On Feb 24, 2009, at 12:49 AM, Pavel Simerda wrote: There are several cases when subscription databases in XMPP are inconsistent. You may view subscription information as a global distributed database. Subscription state between two JIDs, for example a...@a and b...@b are stored in two places at the same time. Servers A and B maintain their own copies of subscription state. [] What with the roster items that are inconsistent? * Mark as inconsistent, let the client present it to the user to take action. * Auto-repair and thus maintain consistency Looking forward to all feedback. When you send out a presence type=probe / include the local view of the subscription state. Btw presence probe seems too weak... as it doesn't reveal full subscription state. The receiving server can then look to see if the state is consisten with his own state. If you opt by the lowest trust level (a from/to beats a both, none beats all), you should be able to re-sync subscription state automagically. Best regards, -- Freelance consultant and trainer in networking, communications and security. Web: http://www.pavlix.net/ Jabber, Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] XMPP-IM - presence subscription handling
On Wed, 25 Feb 2009 18:14:40 +0100 Jiří Zárevúcký zarevucky.j...@gmail.com wrote: The user interface may be easily fixed by client developers... and possibly a very short Best Practice document. No, it can't, since behavior required for this is explicitly forbidden by the specification. Also, implementing client's capabilities so differently from the actual protocol makes a terrible mess. Uh? I'm afraid one of us must be very very mistaken then. As I read the spec, it's not forbidden at all, on the contrary. I would like too see something that shows I'm wrong. I see it the other way around. IMO the current way is too complicated to fit in the common needs. I believe it is equally complicated to your proposal but more flexible. From the client perspective, the current variant can work, according to the specs: Client A: [subscribed],[subscribe*] Client B: [subscribed*],[subscribe*] with some roster management stanzas around and A's server automatically answering with [subscribed*]. (Hope I didn't do any mistake here, * denotes a more basic flow here, if A's server doesn't respond - some IMO misinterpret the presence type=subscribed/, A's client does) From user's perspective it's: User A: Add contact B. User B: Accept contact A (means to both grant subscription and add, of course) Unfortunately, due to some server's not handling presence type=subscribed/ This seems perfectly correct and pretty easy to me. Forbidden and not really a clean solution. Citation needed. As for the problems you described, any inconsistency could just be reset to a clean no-subscription state. How often could this happen? Too often to ignore. You cannot require users to reset it manually... users don't care about protocols! Read Would it be so often for user to be bothered by vanishing of subscription?. I really don't get the difference from current spec in this area. Vanishing of subscription is unrelated. Yes, I agree that immediate effect would be increasing complexity and need of additional effort to maintain backward compatibility. That would be a tricky task, but I believe that with proper interoperability rules, it would be possible to make transition relatively painless. I believe that in a long run, such change would be a huge improvement. You'd need to know if the transition gives or takes. First compare the protocol interface itself. My approach would simplify new implementations significantly, once it is widely used. I don't believe it would simplify them significantly. That's probably because you never tried. Then look at the end-user client interface. I find it a bit unintuitive. Go and file a bug report or feature request to your client's developer. I'm my client's developer. That doesn't prevent you from filing a bug report, does it? Pardon my ignorance. Also, the mutual subscription round-trips always annoy me. You get the request, user approves and sends his request, contact needs to approve again. This is simply not true. Yet in practice, this is completely ordinary work-flow. In practice, it is done, but I believe it is not needed. This has been considered in the specification by allowing preliminary approval, but that just adds need for the server to track this, Which is very easy... Yes. and there is no way to tell if there is one. I One what? Preliminary approval. It's not forbidden anywhere AFAIK. would like a simple work-flow Request presence sharing - Sharing approved, both are subscribed / Sharing declined, nobody is subscribed. This usecase works well with the current specification Possible, but not really simple. Just thinking a moment about it gives me a few possible problems. I already stated the benefits. I haven't seen any. Cleaner protocol, I don't think so. Now I'm beginning to think you either have a very bad taste or haven't read XMPP-IM at all. No offense intended. I like my taste... And I will not be as arrogant as you are... and will just say you probably haven't read carefully and invented limitations that are not there. None taken :). simpler implementation I don't see the difference. As I already told, you probably never written any. You seem to use your arrogance instead of real evidence. and user interface much closer to the real-life needs. And this is definitely your client's problem. User interface is always constrained by the underlying protocol's possibilities. That's not really a client's problem, is it? Your question is based on a premise that I don't believe (namely that it applies to this case). Just a question... did you ever need to have someone's subscription, while he must not have it? Not yet. Or the other way around? Probably yes. Now I'm talking about human
Re: [Standards] various rfc3920bis feedback
On Wed, 25 Feb 2009 22:48:35 +0100 Philipp Hancke fi...@goodadvice.pages.de wrote: Pavel Simerda wrote: Piggybacking is the ability to have more than one validated combination of 'from' and 'to' on single XML stream. There was no preference of A over B originally, 0.9 streams did not have from/to attributes iirc. Yes, that's only what the name suggests and from/to was something I first ask about... it actually seems it brings more trouble that it saves... or not? Piggybacking is going to be necessary in the future, considering a limit on simultaneous connections as described in 0205. Repeating the obvious, er? Keeping this as an optional feature (I believe that is a near consensus) will further simplify the most basic implementations. The last consensus I know of was to make passive support a MUST even: http://mail.jabber.org/pipermail/standards/2007-June/015673.html Did I miss something? I was referring to what I heard at jdev@ some time ago, ask Peter for details (you'll have more after the council). The mail seems too old to me. S2S topics are not very frequent. AFAIK (and it's also what I understood from stpeter) backwords compatibility is now being solved by *compatibility notes* in the RFC and not by treating compatibility hacks as eternal truth :). Piggybacking is not a hack. Maybe I wasn't clear enough. It was a reaction to what you have written and referred to your general statements. Would you please read Robs summary on s2s issues: http://mail.jabber.org/pipermail/xmppwg/2004-February/002008.html I may look at it, if it makes you happy. It has a whole section on why piggybacking and backward compability is necessary. Repeating what I have already agreed? philipp, wondering about a piggybacking sucks note on his rfc3920bis-01 copy What sucks is the view that is *suggested* by this particular term, not the technology itself. Pavel -- Freelance consultant and trainer in networking, communications and security. Web: http://www.pavlix.net/ Jabber, Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] Inconsistent Subscriptions in XMPP
On Thu, 26 Feb 2009 00:15:18 +0100 Robin Redeker el...@x-paste.de wrote: On Tue, Feb 24, 2009 at 01:49:50AM +0100, Pavel Simerda wrote: There are several cases when subscription databases in XMPP are inconsistent. You may view subscription information as a global distributed database. Subscription state between two JIDs, for example a...@a and b...@b are stored in two places at the same time. Servers A and B maintain their own copies of subscription state. The problem is not just subscription state, but any state that is not synchronized, basic presence information comes to mind, they also get out of sync sometimes. Maybe it's less of a problem, because a client logging in again, can refresh that state. Ah, thanks for pointing out. Subscription information of course isn't as easily 'synchronized'. Not so easily, but it's possible... as in most situations, you mostly know you've screwed it up... And you must write all your contacts to delete you and add back. That is tough. If at least these scenarios were caught and the servers would synchronize upon your communication. You write Alice, Alice writes you... and by that time the servers would synchronize. The same could work for presences... and repeated request... so if you screw up the server... you would just let it send subscription requests for all contacts and then the servers would detect and fix all inconsistencies. Other scenarios might come in hand. I don't know whether servers already do this, but having a consistent state for presence, would allow for caching the presence information on the receiving server. Possibly. A generic synchronisation protocol would of course help any state information that has to be shared with other servers. Hmm, not sure if generic or specific, but I would like to see some. I brought this topic up some weeks ago (and I think also a year ago), Then bring it again, please :). but I'm not a server developer (If I was, I would probably have already implemented some proof of concept protocol to do this). But these things don't seem to bother the (and/or developers) They're lazy (everybody is). users much and there doesn't seem to be much (or enough) interest for consistent information sharing amog servers. It shouldn't be too complicated. We should prefer a nice and easy way to go. You probably that a review of the core protocols is underway. Maybe we can have a chat on Jabber? Greetings, Robin -- Freelance consultant and trainer in networking, communications and security. Web: http://www.pavlix.net/ Jabber, Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] XMPP-IM - presence subscription handling
On Thu, 26 Feb 2009 01:35:33 +0100 Jiří Zárevúcký zarevucky.j...@gmail.com wrote: 2009/2/25 Pavel Simerda pav...@pavlix.net: On Wed, 25 Feb 2009 18:14:40 +0100 Jiří Zárevúcký zarevucky.j...@gmail.com wrote: The user interface may be easily fixed by client developers... and possibly a very short Best Practice document. No, it can't, since behavior required for this is explicitly forbidden by the specification. Also, implementing client's capabilities so differently from the actual protocol makes a terrible mess. Uh? I'm afraid one of us must be very very mistaken then. As I read the spec, it's not forbidden at all, on the contrary. I would like too see something that shows I'm wrong. Sorry, you are right in this. I overlooked a part defining it as subject to configuration. I still think this can't be done without numerous problem. Ok, I might forget your bullying... and You might try to look again and reconsider, with the rfc3920-1 and also the bis variants (as I will of course do also, but I don't have so much time, you can imagine). I recommend to finish this thread... and start a new one, rather concentrating on the technical points and correct reasoning. For example: You get an inbound request. You approve, believing that once you click Approve, you are both subscribed. This can't be done, since you still depend on the other side to fulfill it's part of a contract. If you wait for the other side to approve first, you are deadlocked if the other side implements the same behavior. As for the problems you described, any inconsistency could just be reset to a clean no-subscription state. How often could this happen? Too often to ignore. You cannot require users to reset it manually... users don't care about protocols! Read Would it be so often for user to be bothered by vanishing of subscription?. I really don't get the difference from current spec in this area. Vanishing of subscription is unrelated. Then I misunderstood you. What problems with the authority did you mean? Then look at the end-user client interface. I find it a bit unintuitive. Go and file a bug report or feature request to your client's developer. I'm my client's developer. That doesn't prevent you from filing a bug report, does it? Pardon my ignorance. Sure. It doesn't. It would still be closed as WONTFIX, since it can't be fixed. Also, the mutual subscription round-trips always annoy me. You get the request, user approves and sends his request, contact needs to approve again. This is simply not true. Yet in practice, this is completely ordinary work-flow. In practice, it is done, but I believe it is not needed. That's exactly my point. This has been considered in the specification by allowing preliminary approval, but that just adds need for the server to track this, Which is very easy... Yes. and there is no way to tell if there is one. I One what? Preliminary approval. It's not forbidden anywhere AFAIK. I meant that there is no way to figure out, whether the contact auto-approves my request before I actually send it. That's just a completely unimportant cosmetic flaw. I already stated the benefits. I haven't seen any. Cleaner protocol, I don't think so. Now I'm beginning to think you either have a very bad taste or haven't read XMPP-IM at all. No offense intended. I like my taste... And I will not be as arrogant as you are... and will just say you probably haven't read carefully and invented limitations that are not there. None taken :). If you don't consider writing twice as much code because of protocols flexibility, making user interaction unreliable, being a valid reason, then I'm inventing limitations. Yes. simpler implementation I don't see the difference. As I already told, you probably never written any. You seem to use your arrogance instead of real evidence. Once I have time for changing my code to use protocol no one else uses, I'll send you a diff. Forgive me, if I consider you being arrogant in the first place. Even reducing number of possible states from nine to four IS a simplification. You simply ignore everything and generalize to there is no difference. and user interface much closer to the real-life needs. And this is definitely your client's problem. User interface is always constrained by the underlying protocol's possibilities. That's not really a client's problem, is it? Your question is based on a premise that I don't believe (namely that it applies to this case). My question is purely rhetorical. It would move complication from the current protocol to the extension. It wouldn't just pop up anywhere. The flexibility, you have been talking about
Re: [Standards] various rfc3920bis feedback
On Tue, 24 Feb 2009 09:14:13 + Dave Cridland d...@cridland.net wrote: On Tue Feb 24 00:31:25 2009, Pavel Simerda wrote: * bidirectional s2s could be announced in stream:features sent right after the opening stream tag from the initiator. Well... What you need is to: a) Signal the ability of the receiver to handle features sent by the initiator. Why? b) Signal the ability of the initiator to handle bidi streams. Agreed. c) Turn this on, which presumably involves an authorization phase. Ah, that'true... I was thinking that the receiver has a stream:feature to handle stream:features, the initiator then sends these, If the reciever is not handling features/, it can ignore it, can't it? Peter said it was never forbidden to send them anyway. and the receiver can then proceed as the initiator in the other direction. So the initiator would send SASL mechanisms, and the receiver would act as a SASL client to the initator and request authorization. Some way or another, mutual authentication should be established, two SASL exchanges seem an obvious way to do that. * connection reuse for multiple s2s links would be a very useful feature, ask Dave for details Piggybacking. What I'd like to do here is use the dialback elements as an authorization request mechanism. What I would like... is to have an easy-to-understand and easy-to-implement piggybacking feature without unnecessary hassle. In fact, by specifying how to do this without actually doing dialbacks, but instead by verifying the identity of the sender based on the X.509 cert, we can actually get rid of SASL EXTERNAL and just use X.509 only, which eliminates the difference between the first authorization and subsequent ones. I don't see any reason to get rid of SASL EXTERNAL. I quite like the concept of using the same authentication flows for all authenticated connections. It would be nice to be able to authenticate each virtual connection separately. It's a multiplex, anyway, if one associations fails, others should remain working. The dialback flow then becomes: 1) O2R : db:result/ 2) R: If TLS, and X.509 cert matches requested domain, goto ACCEPT 3) R: Connect to A 4) R2A: Establish TLS. 5) R2A: If A's certificate matches O's, goto ACCEPT 6) R2A: db:verify/ 7) A2R: db:verify/, goto ACCEPT ACCEPT: 8) R2O: Authorize O as requested domain, send db:result/ * resource conflicts should be handled consistently in servers It's not always possible to handle conflicts in the same way. Could you please be more specific? * an explicit way to kick other resources might be very handy Here be tigers. * multiple resources could have a less confusing named feature (not unbind, but something like multi-bind probably) I'm less than convinced about the validity of multiple resources as a solution to any problem. It doesn't matter so much... it's an optional feature that seems to help someone. Anyway it's just c2s multiplexing, a counterpart to s2s multiplexing that you want. * xml:lang per stanza seems to be pretty rare, I would prefer MAY to SHOULD, or even to discurage per-stanza xml:lang entirerely and encourage use of xml:lang only for elements with localized strings. Many users (and also client developers) just don't care about languages. Unqualified strings are (and will be) very common, I would use MAY even for the elements. In principle, the stanza-level xml:lang can be used especially over S2S sessions to indicate a preferred language for errors. This doesn't seem to be too useful. We use language-neutral XMLish errors anyway, not localized errors (except additional info for geeks). However... various protocols have had features like this for years, and to the best of my knowledge nobody ever uses them. I'd guess this won't be used even when SHOULD... and I see no reason for the SHOULD for something that is generally considered useless. * gone has a very good usecase that could be made explicit... it is JID redirection and could be handled by clients (e.g. the client could offer the user to add the new JID upon error - presence/message would trigger it). Right - a jid redirection would be useful. We'd also need to put together a companion protocol for users to enable it. Would be nice. * Consider including XEP-198 Stream Management in the RFC We need to actually prove it, first. I don't think anyone's got as far as coding it, yet. Prove or test? :D Dave. -- Freelance consultant and trainer in networking, communications and security. Web: http://www.pavlix.net/ Jabber, Mail: pavlix(at)pavlix.net OpenID: pavlix.net
[Standards] Inconsistent Subscriptions in XMPP
There are several cases when subscription databases in XMPP are inconsistent. You may view subscription information as a global distributed database. Subscription state between two JIDs, for example a...@a and b...@b are stored in two places at the same time. Servers A and B maintain their own copies of subscription state. For a...@a's subscripton to b...@b, server B holds the authoritative record, while server A has a non-authoritative copy. I believe we need a mechanism to automatically check consistency of these records and fix any inconsistency to ensure that: * If the authoritative information changed without notification to an interested party, the interested party should discover it as soon as possible. * The same for nonexistant users. Inconsistencies occur when: * The interested server is down while the changes occur. * A notification was lost. * A domain is moved to another server without copying the database (the subscriptions must be re-created manually) * Database is restored from a backup due to data corruption. Possible approaches: * Server would monitor suspicious stanzas (e.g. messages and presence from an offline resource) and check the subscription state. What with the roster items that are inconsistent? * Mark as inconsistent, let the client present it to the user to take action. * Auto-repair and thus maintain consistency Looking forward to all feedback. Pavel -- Freelance consultant and trainer in networking, communications and security. Web: http://www.pavlix.net/ Jabber, Mail: pavlix(at)pavlix.net OpenID: pavlix.net
[Standards] Fw: [Security] Unsubscribe on Userdelete (Was: Password protected rooms)
This crossposting is hell. On Fri, 13 Feb 2009 11:52:19 +0100 Alexander Gnauck gna...@ag-software.de wrote: Thats an very interesting point - in many respects. Two more examples: - I have a service with many users from other servers subscribed. As there is no unsubscribe if the user has been deleted, I have many zombie-subscription. I can only check the subscriptions from my own server if the accounts still exist. And even that is not so easy. - A friend subscribed my presence. He was some time in hospital, so I never noticed, that his account was deleted on the server (due to inactivity?). As the jid came back online I wrote him gladly, how he is after the surgery... I realised very late, that the account was now new assigned. I had a similar problem when I unregistered my jabber.org account by error with a beta version of a client. The subscription was out of sync, and still is for many of my contacts, because server don't route my subscription requests. The only solution is to delete the contact on both sides and subscribe again. I had similar problems in other scenarios too... I see only the solution, that there has to be an unsubscribe-request to every contact in the roster of an user if that user is going to be deleted. right, this is how it should (MUST) be done. This does not help enough (though it catches the easiest cases). I believe the subscription stuff in XMPP should be further re-thinked. There are many real-world cases that break integrity of subscriptions across servers. * User delete * Server switch (if you're not careful enough about the database) * User grants subscription without being asked (I believe this is an implementation issue) * Some important presence/ stanza gets lost due to lost connection * Various server errors (happenes once, but the integrity is lost) * Other cases I believe the only way is to implement some sort of auto-correction that occures upon any sort of interaction. E.g. the server could check the subscription when the following suspicious (though many times valid) events occur. * You got a presence/ from someone you're not subscribed to * You got a message/ (or iq/) from someone you're subscribed to but you haven't got his presence * User tries to subscribe to someone he's already subscribed (and similar) * Of course, user deletion should trigger unsubscribe, but it would be better to distinguish it from regular unsubscribe. It would also be good to have some sort of redirection support that would allow an account to be in a state between registered and nonexistant. Could be as simple as a redirect/ element in any error answers. Supporting clients could then offer the user to *delete* the contact or *replace* the contact with his new ID, request subscription and retain group, local name and comments. Pavel Alex -- Alexander Gnauck http://www.ag-software.de xmpp:gna...@jabber.org -- Freelance consultant and trainer in networking, communications and security. Web: http://www.pavlix.net/ Jabber, Mail: pavlix(at)pavlix.net OpenID: pavlix.net -- Freelance consultant and trainer in networking, communications and security. Web: http://www.pavlix.net/ Jabber, Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] Password protected rooms
On Wed, 11 Feb 2009 10:45:34 -0800 Justin Karneges justin-keyword-jabber.093...@affinix.com wrote: On Wednesday 11 February 2009 05:06:24 Kevin Smith wrote: On Wed, Feb 11, 2009 at 12:58 PM, Kurt Zeilenga kurt.zeile...@isode.com wrote: I'm thinking more about a non-comprised server case, but just the case of poor administrative practices. Ok, I follow, thanks. Given that, maybe keeping password requirements on all affiliations is sensible. There are quite many XMPP services (bots and such) that you authenticate with just by JID. Why would those things be okay, but MUC is somehow more secure and requires a password? I smell a new security discussion. Wouldn't these be better on the security list? I'm also against over-specific password authentication in individual XEPS. If we want better authentication, it may be reused by several XEPs and may be optional, too. Pavel -Justin -- Freelance consultant and trainer in networking, communications and security. Web: http://www.pavlix.net/ Jabber, Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] Password protected rooms
On Wed, 11 Feb 2009 04:58:01 -0800 Kurt Zeilenga kurt.zeile...@isode.com wrote: On Feb 10, 2009, at 11:25 PM, Kevin Smith wrote: On Tue, Feb 10, 2009 at 11:02 PM, Kurt Zeilenga kurt.zeile...@isode.com wrote: It seems not so sensible when the admin happens to be authenticating directly to the server hosting the chatroom. But for the case where the administrator authenticates elsewhere, possibly to a server under separate administrative control, (to the extent that password protected rooms are at all sensible) it seems at least reasonable for a server to be allowed to require the administrator know the password. If we assume secure s2s, it seems that requiring the muc owner know a password only protects against a compromised (or maliciously adminned) server where the user can be impersonated by the server admin. Given that the muc password is sent in plaintext, a compromised server could pull this out of the stream anyway, so does it buy us much to require a password for the muc owner? I'm thinking more about a non-comprised server case, but just the case of poor administrative practices. Say the owner's account was deleted by his site's admin, and then that account name was reassigned to some other person. Now a different person is in control of the owner's account. This person might know or discover his account has ownership rights on various chatrooms and abuse those rights. I would propose to solve this issue differently and completely, not just for this special case. So I wonder if the password mechanism might be a way of mitigating risks associated with such administrative practices. Though passwords might help, IMO it's not the best solution (e.g. a UUID published with the presence or elsewhere would do much much better). Admin's password is rather inconvenient. An admin's password may help to re-acquire adminship with a new JID, though, but that would be better solved by more general *authentication* and *authorization* that would both allow reuse for other purposes (not only MUC) and could be much more flexible (with regard to authentication mechanisms). Server implementations can add features to deal with this problem with both the owner and chat room are hosted on the same server, but I don't know any way of deal well this in the remote case except by authentication of owner to room. Easy, just add authentication :). But remember, if you want to maintain at least some real security, you'd not only authenticate the remote user, but also maintain integrity of all incoming data. Please move to the security list if interested in further authentication/authorization discussion. Pavel Now one can argue that the password does nothing to specifically authenticate the owner, so maybe the password doesn't well mitigate the risk. -- Kurt -- Pavel Šimerda Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] Full XML
On Wed, 08 Oct 2008 21:30:27 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Brett Zamir wrote: As comments, processing instructions, DTD subset, and entity reference are prohibited in XMPP, I was wondering whether there were or could be a standard way to escape at least processing instructions, comments, and the internal DTD subset (canonical features) so they could be reliably preserved? Why? Maybe you could tell us a bit more about your use cases. I had thought that such features could be preserved by making them the character data of particular elements in a special namespace (necessarily encapsulating such documents or fragments within a pseudo-root element in order to allow for document-root-level comments/processing instructions as well as Doctype declarations). I would think that providing some means for fidelity of an XML document transmitted over XMPP would be helpful (e.g., to share source code in band (without the need to escape), to allow full XHTML or SVG with ?xml-stylsheet?'s to be shared, etc.). To do full XHTML, full SVG, or whatever, we would typically just include that data in a message/ or iq/ stanza, properly namespaced of course. See for instance XEP-0071 (the XHTML-IM subset) and XEP-0072 (SOAP Over XMPP). But please note that XMPP is not designed for transferring complete XML documents as you seem to be envisioning. Or they can be transfered just like any files or blocks of data. Pavel By the way, as far as section 12.1 in http://xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-07.html referring to entity references as being in section 4.2 of the XML standard, I think it perhaps should instead be section 4.1, where entity reference is defined. Thanks, I'll check that. Peter -- Pavel Šimerda Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] multiple FORM_TYPEs
On Wed, 08 Oct 2008 22:28:36 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Brett Zamir wrote: I had been wondering whether multiple FORM_TYPEs in Data Forms be added to allow for multiple /standard/ specs being represented at the same time... I have no particular need for this now, but I was curious about it for the sake of future extensibility... Jack, in the developer chat room today mentioned Pubsub Queueing at http://xmpp.org/extensions/inbox/pubsub-queueing.html (in example 1) as having such a need, but I thought I'd bring it up again here to bring it up formally... Thinking ahead, eh? Scoping the same data form with two different FORM_TYPEs would be like qualifying the same XML element with different namespaces. No go. Or at least that's how XEP-0004 and XEP-0068 were designed. But you could include two different forms... Peter Can I extend this question? Shouldn't we use some sort of more proper namespacing of form fields (or multiple forms) instead of practice that like node config in PubSub, etc? Pavel -- Pavel Šimerda Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] question on guaranteed delivery and pub-sub
On Thu, 9 Oct 2008 13:11:25 +0200 Jonathan Schleifer [EMAIL PROTECTED] wrote: Am 09.10.2008 um 06:51 schrieb Peter Saint-Andre: This doesn't apply, because a publish happens via IQ. And why would the pubsub service poke the publisher if not all the messages can be delivered? I think it would be the service's responsibility to retry the notifications. ejabberd sends the message that would have been delivered to the recipient with an error attached. Isn't it the other way round? Isn't it an error message with an original message attached? :) Broken clients should be fixed, this was the case for some older version of Psi and it showed error messages as chat messages. This is very funny for PEP, as some clients don't see that there's an error attached and you see your own mood / activity / tune at ohters then when there was an error :) *looking at Adium, looks at old Gajim versions*. -- Jonathan -- Pavel Šimerda Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] RCF3920bis07: Resource generation
On Mon, 6 Oct 2008 16:35:03 +0100 Pedro Melo [EMAIL PROTECTED] wrote: On Oct 6, 2008, at 3:43 PM, Jonathan Schleifer wrote: Am 06.10.2008 um 13:30 schrieb Pedro Melo: IMHO, you should use caps for that. That's the proper way to solve it. Use an identity client/phone or client/handheld. Doesn't solve the issue with you are connected via laptop and desktop at home and are online using GPRS on the laptop (I already gave this example before, so I won't give it again - read the old messages for the full example). See my previous messages: caps, disco, and disco identities, with the name attribute, solve all your current problems. And in a standard, document, way, not subject to I8N interpretations. Best regards, +1 Thanks for pointing out the right solution for this particular case... but I don't see home/work and other info there. Pavel -- Pavel Šimerda Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] RCF3920bis07: Resource generation
On Tue, 7 Oct 2008 13:12:49 +0100 Pedro Melo [EMAIL PROTECTED] wrote: Hi, On Oct 7, 2008, at 12:17 PM, Pavel Simerda wrote: On Mon, 6 Oct 2008 16:33:59 +0100 Pedro Melo [EMAIL PROTECTED] wrote: On Oct 6, 2008, at 3:39 PM, Michal 'vorner' Vaner wrote: On Mon, Oct 06, 2008 at 12:30:10PM +0100, Pedro Melo wrote: On Mon, Oct 06, 2008 at 11:37:34AM +0100, Pedro Melo wrote: The reasons given to use a well-known resource can be solved better using other methods. You omit the reason the resource name carries an information. When I see someone connected with resource 'mobile', I know I should not spam him with large messages. IMHO, you should use caps for that. That's the proper way to solve it. Use an identity client/phone or client/handheld. Then you will need caps containing any string to show to user, since resource can carry any information. name attribute of the identity? Doesn't it break the purpose of the caps? I originally thought the authors wanted to have a reasonable number of different caps to cache at the servers. Yes, it does. For each name, the hash will be different. Best regards, I expected at least Yes it does but we don't care. :) Pavel -- Pavel Šimerda Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] invisibility
On Mon, 6 Oct 2008 17:02:24 +0100 Artur Hefczyc [EMAIL PROTECTED] wrote: Hi, While reviewing XEP-0186 just now, I noticed that when a resource goes invisible, its server must send presence of type unavailable from that resource. As far as I can see, when a contact's server receives unavailable presence from the user (and if the user+contact have a two-way presence subscription), it will stop sending presence updates to the user (if that was the last online resource for the user). This somewhat defeats the purpose of invisibility, no? The implication is that the user's information about the presence of its contacts will soon become stale. But I suppose that's one price you pay for invisibility, which I continue to think is a stupid concept anyway. :) I thought we gave up with invisibility anyway. Especially that this can be quite easily achieved with privacy lists without those unwanted side effects. And privacy lists give us much more flexibility to set invisibility for a single user, group. I'm afraid you missed one thing. These unwanted side effects can't be avoided. Therefore privacy lists have them too, of course. Pavel Artur -- Pavel Šimerda Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] RCF3920bis07: Resource generation
On Tue, 7 Oct 2008 13:09:07 +0100 Pedro Melo [EMAIL PROTECTED] wrote: Hi, On Oct 7, 2008, at 12:13 PM, Pavel Simerda wrote: On Mon, 6 Oct 2008 16:35:03 +0100 Pedro Melo [EMAIL PROTECTED] wrote: On Oct 6, 2008, at 3:43 PM, Jonathan Schleifer wrote: Am 06.10.2008 um 13:30 schrieb Pedro Melo: IMHO, you should use caps for that. That's the proper way to solve it. Use an identity client/phone or client/handheld. Doesn't solve the issue with you are connected via laptop and desktop at home and are online using GPRS on the laptop (I already gave this example before, so I won't give it again - read the old messages for the full example). See my previous messages: caps, disco, and disco identities, with the name attribute, solve all your current problems. And in a standard, document, way, not subject to I8N interpretations. Best regards, +1 Thanks for pointing out the right solution for this particular case... but I don't see home/work and other info there. Sure, that would be the name attribute value. Because home, work, et al is the name you choose to give to those instances. Best regards, Thanks I got it while reading other posts. Your patience will be remembered :). Pavel -- Pavel Šimerda Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] RCF3920bis07: Resource generation
On Mon, 6 Oct 2008 20:06:01 +0200 Remko Tronçon [EMAIL PROTECTED] wrote: Another idea would be that the client requests a resource from the server and when it gets disconnected tries to re-use that resource on reconnecting so the dead connection gets kicked. Two clients can't kick each other that way. Yes, that works as well (provided that the server doesn't do mangling on the resource names it created itself). I think the best way would be to specify the old resource string as a hint to the server. The server would then ping it and close it. cheers, Remko -- Pavel Šimerda Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] RCF3920bis07: Resource generation
On Mon, 6 Oct 2008 17:24:38 +0200 Remko Tronçon [EMAIL PROTECTED] wrote: Doesn't solve the issue with you are connected via laptop and desktop at home and are online using GPRS on the laptop Neither does setting a resource named 'Laptop', as that doesn't say anything about your connection. Even if I was on GPRS, I would like my contacts to send me links in my current chat window. I'll decide whether I want them to be stored for later offline usage, sent to my desktop pc (in which case I'll ask them to send it there), or just open them. And you can send them yourself :). Pavel cheers, Remko -- Pavel Šimerda Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] RCF3920bis07: Resource generation
On Mon, 6 Oct 2008 13:35:56 +0200 Remko Tronçon [EMAIL PROTECTED] wrote: IMHO, you should use caps for that. +1. And clients should support this better by showing icons for different types of resources. That might prove much better than the current approach. cheers, Remko -- Pavel Šimerda Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] RCF3920bis07: Resource generation
On Mon, 6 Oct 2008 11:53:51 +0100 Pedro Melo [EMAIL PROTECTED] wrote: Hi, On Oct 5, 2008, at 2:07 PM, Pavel Simerda wrote: Please look into real world, not idealistic. Servers have sometimes long timeouts (nobody says they can't), don't do any sort of pings (nobody says they must) and many people have unstable connections, even on ADSL, but much more on wireless, especially when moving aroud. IMHO, pings are awful. I would much rather have session-reconnect and link-level acks for stanzas. The pair should provide an even more resiliant network than pings will ever do. link-level pings, of course. This is what you might want to do: 1) when you don't get an ack and want to retry last before disconnection (maybe not useful at all, not sure) 2) when there are no messages for some time at all (acks are correct, but you don't know anyway) These pings are to be found in xep-198 together with acks, if it didn't change from last time I saw it. Pings assert only one thing: A stanza reached the server, and another was able to get back. You cannot extrapolate any assurances of quality what so ever from this. link-level pings assert a working connection, and indirectly all previous stanzas (because of TCP underneath). ACKs are better for this if there are stanzas to acknowledge. Sure, XMPP-level pings (xep-199) should not be used there. Having said that, a link level keep-alive is useful for silent network losses, and pings have its place on my toolbox to kick-start S2S connections. If I want to send stanzas to a certain domain and I don't know if they have a S2S connection available on my server, I delay the send until I get back some sort of ping response. I am sorry for the confusion between link-level (XEP-198) and xmpp-level (XEP-199) pings. It's a common things to loose messages on Jabber for people with bad connectins. The good thing is that when one comes back, the old resource is kicked (with reason: reconnected) and the user is notified... and after some time, users learn that after other party's reconnect, they must re-send what they have posted. Yes, as I said above, pings are great to kickstart S2S connections. Although I think servers should keep S2S connections open while there is an active session with a roster item from the remote domain If this is not the case, users become confused and will start to think Jabber is unreliable. And what more, they will rightly do so. I agree that reliability is still a problem with the larger XMPP network, specially small servers. IMO it doesn't depend so much on the scale of the servers. It's that... 1) Broken connection are often not closed early enough (half an hour is quite usual). 2) When they are still broken but open (from one or both sides), they're filled with stanzas the senders expect to deliverd or passed to offline storage or something (handled may be the best word). 3) Such stanzas are not handled as the connection is broken, they're lost. 4) The sender recieves no error regardles the point where the message was dropped. 5) He cannot resend it manually nor his client can handle it automatically. Some issues are bad, some are even worse :). I admit that resource-based kicking is an ugly hack that only solves one specific situation. I would like to cease it with a better replacement, not without it. There are no more concerns of mine :). Pavel But unwinding the conversation, using the same resource as a session- resume/takeover tool is the wrong way to go about it. Even if you reconnect 10 seconds after you lost the first connection, you can still loose messages and other stanzas. You need a proper session-resume service to deal with that. Everything else is like using a sieve to block out the sun: half- measures. Best regards, -- Pavel Šimerda Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] RCF3920bis07: Resource generation
On Mon, 6 Oct 2008 18:28:30 -0400 Eric Will [EMAIL PROTECTED] wrote: On Oct 6, 2008, at 4:31 PM, Peter Saint-Andre wrote: That seems quite sensible. Why force the indirection? This seems to be largely a matter of taste as opposed to good technical reasoning. I don't think there IS a good technical reasoning. Both points have merit. The whole thread is based on technical reasoning. On the one hand, it's a good thing that clients can specify their own so that advanced-ish XMPP users have that extra bit of oomph to utilize (and let's face it, most XMPP users are advanced-ish). If one can assing a name to a resource (in the meaning of a connected client, not a resource string), he SHOULD :) be satisfied. Furthermore... if this feature serves well both advanced users and basic users, it definitely brings a much better value than if it only served advanced users. Noticed that I changed my mind thanks to Pedro Melo's and other's good reasoning. On the other hand, it's a good thing that resources are an implementation detail and can be abstracted away from the client. /psa -- Eric Will -- Pavel Šimerda Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] RCF3920bis07: Resource generation
On Tue, 7 Oct 2008 13:19:22 +0100 Kevin Smith [EMAIL PROTECTED] wrote: Doesn't it break the purpose of the caps? I originally thought the authors wanted to have a reasonable number of different caps to cache at the servers. There's also that the disco spec says that identity / should be consistent beyond what is being suggested here. I think overloading identity at the deployment level is a bad idea, fwiw. What do you suggest then? Pavel /K -- Pavel Šimerda Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] RCF3920bis07: Resource generation
On Mon, 6 Oct 2008 19:07:24 +0100 Pedro Melo [EMAIL PROTECTED] wrote: On Oct 6, 2008, at 5:27 PM, Jonathan Schleifer wrote: Ok, I can understand your suggestions now. However, you're missing one point: What advantage do we get by a resource that has no meaing? IMO, nothing. A static resource just makes it easier for everyone, IMO. Replacing the connection, etc. No it does not, because you don't want a connection replaced. you want a controlled take-over of an old session. You want a new connection to arrive and tell the server Hey, I'm session-ID X and I want to take over it. Hmm, you helped me to understand the case. Do we have a way to at least specify the old session-ID? Abruptly taking over the other connection makes it harder for proper stanza re-routing. Besides, we already know that some servers will not allow you to control the resource. Also, re-using the resource opens the previous discusses presence leaks problems. IMO, you're suggestion to resume a session is really good, so the resource could get a session ID then. But until we have a XEP that does that, I'd like to keep it the way we have it and make it possible to use both - once we can resume sessions, clients that support that could ask for a random resource, while other clients still get a static one. Sure. I said a couple of mails back, I have no problem that the bis RFC says something like respect the resource the client sends. I was just arguing that it is a bad default, going forward, and we should move to a network where the resource is plumbing, non-visible to end users. As I (hopefully) demonstrated in the past emails, all the current use cases (resource identification and capabilities) are better solved using Disco. Plus I see one problem with resuming a session: You don't know what got lost. So we also need wide XEP-0198 implementation. Otherwise we can't resend on resume what got lost. Sure: session resume requires link-level acks. Have you read 198? It talks about resumed sessions here: http://xmpp.org/extensions/ xep-0198.html#resumption Best regards, -- Pavel Šimerda Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] RCF3920bis07: Resource generation
On Tue, 7 Oct 2008 14:34:15 +0100 Pedro Melo [EMAIL PROTECTED] wrote: Hi, On Oct 7, 2008, at 1:00 PM, Pavel Simerda wrote: On Mon, 6 Oct 2008 11:53:51 +0100 Pedro Melo [EMAIL PROTECTED] wrote: On Oct 5, 2008, at 2:07 PM, Pavel Simerda wrote: Please look into real world, not idealistic. Servers have sometimes long timeouts (nobody says they can't), don't do any sort of pings (nobody says they must) and many people have unstable connections, even on ADSL, but much more on wireless, especially when moving aroud. IMHO, pings are awful. I would much rather have session-reconnect and link-level acks for stanzas. The pair should provide an even more resiliant network than pings will ever do. link-level pings, of course. This is what you might want to do: 1) when you don't get an ack and want to retry last before disconnection (maybe not useful at all, not sure) This is TCP, one lost ping is enough. That's why I wrote I'm not sure about usefullness. 2) when there are no messages for some time at all (acks are correct, but you don't know anyway) These pings are to be found in xep-198 together with acks, if it didn't change from last time I saw it. They are there. If this is not the case, users become confused and will start to think Jabber is unreliable. And what more, they will rightly do so. I agree that reliability is still a problem with the larger XMPP network, specially small servers. IMO it doesn't depend so much on the scale of the servers. It's that... The paragraph was meant for S2S connections, sorry, didn't made myself clear. With a small server (small in terms of users) each S2S connection has light use, so the risk of disconnect for lack of traffic is higher than on busy servers. Hence, on small servers, the first message to a remote domain has a higher change of failing (the S2S link is not up, and even if the server buffers the message to send later, he might control the size of such buffers). Best regards, -- Pavel Šimerda Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] RCF3920bis07: Resource generation
On Tue, 7 Oct 2008 14:40:28 +0100 Pedro Melo [EMAIL PROTECTED] wrote: On Oct 7, 2008, at 12:20 PM, Pavel Simerda wrote: On Mon, 6 Oct 2008 11:39:11 +0100 Pedro Melo [EMAIL PROTECTED] wrote: On Oct 5, 2008, at 1:48 AM, Jonathan Schleifer wrote: Matthew Wild [EMAIL PROTECTED] wrote: If they type it manually then they know what they are doing, and when they come to type the stanza for resource binding, they will read the RFC and see that it recommends not specifying a resource :) Which is IMO a painfully bad idea for users with instable connections. They will have thousands of resources online after a short while and you don't know which to msg. Very, very bad idea, IMO. Makes it totally unusable with an unstable conenction. You *WANT* a static resource then, so you can replace the old, dead connection. I would recommend those clients to use BOSH and its native session resume capabilities. I would recommend not to break the TCP way only to use a bunch of layers. Too many layers (in protocol, session layers, etc) add (usually unnecessary) complexity. Sure, but the scenario was unstable networks. On those networks, you need a strong session-level reconnect protocol, and right now, XMPP over http BOSH has that, and XMPP over TCP doesn't. The users will be a lot happier. On a perfect world you would be able to use the same session-resume capabilities on TCP. Maybe someday you will. That would be much better. But still it doesn't solve the disconnect without reconnect case (xep-198 mostly does). disconnect without reconnect? you mean when a client looses the connection and doesn't reconnect in the allowed time? Yep, that's it. Just curious why minutes was chosen while seconds tend to be the basic unit anywhere there's no need for finer granularity... but that's just a detail. There won't be any way to change this from a client? It would trigger the longest allowable time period for session resumption timeout. Btw, it seems xep-198 is not clear enough. 1) When exactly can be the resume feature used? When the client doesn't properly end the stream? What about stream errors? 2) When exactly should be the resume connection ended and error returned for pending stanzas (apart from the timeout)? Does it mean that I loose connection on my laptop so I connect my mobile client... then talk with the same people e.g. for 20 minutes (the 'max' period) and then they get a bunch of errors that I didn't recieve their messages? In XEP-0198 (see example-2, http://xmpp.org/extensions/xep-0198.html#example-2) , the servers sends you back a max attribute with the longest allowable time to reconnect. If that expires, the server assumes the connection is dead, and cleans up. Best regards, -- Pavel Šimerda Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] invisibility
On Tue, 7 Oct 2008 14:50:35 +0100 Pedro Melo [EMAIL PROTECTED] wrote: Hi, On Oct 7, 2008, at 1:11 PM, Pavel Simerda wrote: On Mon, 6 Oct 2008 16:50:54 +0100 Pedro Melo [EMAIL PROTECTED] wrote: On Oct 6, 2008, at 3:52 PM, Peter Saint-Andre wrote: While reviewing XEP-0186 just now, I noticed that when a resource goes invisible, its server must send presence of type unavailable from that resource. As far as I can see, when a contact's server receives unavailable presence from the user (and if the user+contact have a two-way presence subscription), it will stop sending presence updates to the user (if that was the last online resource for the user). This somewhat defeats the purpose of invisibility, no? Depends. It defeats the purpose of lurkers, who want to keep seeing the others online without revealing their own presence. But if you want to be online to talk to XMPP-based services but skip Instant Messaging, I think its ok. I assume that if you are really interested on getting presence updates from a particular contact, you would send him a directed presence and become visible just for him. Anyway, in a federated network, I don't see a way to do better than this. If we had a server-2-server protocol for hey, i'm invisible but keep sending those presences, you would be leaking the presence anyway. I'm fine with this XEP as it stands. One nit: third security consideration, about last activity - replying service-unavailable / is a information leak. The proper reply would be to reply with the time of invisible request. This would also leak information :). If you don't want others to know you are online... you might also not want them to know you connected just five minutes ago. Huhs? Sorry, don't follow. last-activity will only reply to people already on your roster. When I move to invisible, I don't want people to know that I'm invisible, so if someone in my rosters asks for last activity, the response should be consistent with my make-believe offline mode: the last-activity is the time of my logout. But what if you want to be Invisible from the beginning of a connection. I don't know the detais of the two invisibility xeps but... it seems just logical that when I connect and start invisible, I don't want my subscribed friends to know when exactly I connected (and disappeared). Maybe I want them to think I was not online at all the whole day. Giving a radically different response when you move from visible to invisible is a clear signature of invisibility. Best regards, -- Pavel Šimerda Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] invisibility
On Tue, 7 Oct 2008 17:58:59 +0100 Pedro Melo [EMAIL PROTECTED] wrote: Hi, On Oct 7, 2008, at 5:45 PM, Pavel Simerda wrote: On Tue, 7 Oct 2008 14:50:35 +0100 Pedro Melo [EMAIL PROTECTED] wrote: On Oct 7, 2008, at 1:11 PM, Pavel Simerda wrote: On Mon, 6 Oct 2008 16:50:54 +0100 Pedro Melo [EMAIL PROTECTED] wrote: On Oct 6, 2008, at 3:52 PM, Peter Saint-Andre wrote: While reviewing XEP-0186 just now, I noticed that when a resource goes invisible, its server must send presence of type unavailable from that resource. As far as I can see, when a contact's server receives unavailable presence from the user (and if the user+contact have a two-way presence subscription), it will stop sending presence updates to the user (if that was the last online resource for the user). This somewhat defeats the purpose of invisibility, no? Depends. It defeats the purpose of lurkers, who want to keep seeing the others online without revealing their own presence. But if you want to be online to talk to XMPP-based services but skip Instant Messaging, I think its ok. I assume that if you are really interested on getting presence updates from a particular contact, you would send him a directed presence and become visible just for him. Anyway, in a federated network, I don't see a way to do better than this. If we had a server-2-server protocol for hey, i'm invisible but keep sending those presences, you would be leaking the presence anyway. I'm fine with this XEP as it stands. One nit: third security consideration, about last activity - replying service-unavailable / is a information leak. The proper reply would be to reply with the time of invisible request. This would also leak information :). If you don't want others to know you are online... you might also not want them to know you connected just five minutes ago. Huhs? Sorry, don't follow. last-activity will only reply to people already on your roster. When I move to invisible, I don't want people to know that I'm invisible, so if someone in my rosters asks for last activity, the response should be consistent with my make-believe offline mode: the last-activity is the time of my logout. But what if you want to be Invisible from the beginning of a connection. I don't know the detais of the two invisibility xeps but... it seems just logical that when I connect and start invisible, I don't want my subscribed friends to know when exactly I connected (and disappeared). Maybe I want them to think I was not online at all the whole day. I guess you don't send your initial presence then. First send the invisible IQ, and then set you presence. Best regards, I'm sorry, it was not a question, it was a reply to yours. You suggested: The proper reply would be to reply with the time of request. But this breaks the case I have just described and leaks information that you were connected at some specific time. Pavel -- Pavel Šimerda Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] RCF3920bis07: Resource generation
On Sun, 5 Oct 2008 02:48:55 +0200 Jonathan Schleifer [EMAIL PROTECTED] wrote: Matthew Wild [EMAIL PROTECTED] wrote: If they type it manually then they know what they are doing, and when they come to type the stanza for resource binding, they will read the RFC and see that it recommends not specifying a resource :) Which is IMO a painfully bad idea for users with instable connections. They will have thousands of resources online after a short while and you don't know which to msg. Very, very bad idea, IMO. Makes it totally unusable with an unstable conenction. You *WANT* a static resource then, so you can replace the old, dead connection. Very good point! Btw, is there a real reason to use randomized resource strings... or is it just to overcome bugs made by client and server developers? Pavel -- Pavel Šimerda Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] RCF3920bis07: Resource generation
On Sun, 5 Oct 2008 11:33:46 +0200 Jonathan Schleifer [EMAIL PROTECTED] wrote: If you get a conflict, you can continue and replace the old resource. IIRC, with the current RFC, it's undefined what the server does then, but most replace it. This should be clearified IMO so that the RFC I'm very much for a clarification that leads to a reliable service (at least reliable in the sense that the user knows when to re-send stuff, even better, if the client does it for him). This sort of works now with or without ACKs but will break with random resources unless there is a way to avoid. Pavel -- Pavel Šimerda Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] RCF3920bis07: Resource generation
On Sun, 5 Oct 2008 15:10:42 +0200 Jonathan Schleifer [EMAIL PROTECTED] wrote: Am 05.10.2008 um 15:07 schrieb Pavel Simerda: It's a common things to loose messages on Jabber for people with bad connectins. The good thing is that when one comes back, the old resource is kicked (with reason: reconnected) and the user is notified... and after some time, users learn that after other party's reconnect, they must re-send what they have posted. This is how legacy networks handle it - XMPP is more modern, we have This is how the modern XMPP handles it. I'm afraid it's time to drop your ideals. I had time to study it and to test it. Sorry. We're here to fix the problems, not to say they doesn't exist :). XEP-0184 which tells the sender that the message did not arrive and As for message receipts, they don't work in many cases (privacy issues, etc). You CANNOT expect anyone to send you message reciepts (just as you cannot with e-mail). XEP-0198 for reliable delivery ;). Oh, read better, in XEP-198, there is NOTHING about (reliable) delivery. -- Jonathan -- Pavel Šimerda Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] RCF3920bis07: Resource generation
On Sun, 5 Oct 2008 15:27:21 +0200 Jonathan Schleifer [EMAIL PROTECTED] wrote: Am 05.10.2008 um 15:20 schrieb Pavel Simerda: As for message receipts, they don't work in many cases (privacy issues, etc). You CANNOT expect anyone to send you message reciepts (just as you cannot with e-mail). Yeah, sure, the other end has to support it. I only know of Gajim and Miranda answering it so far adding it in the caps. In Gajim, we look at caps and if it's supported warn if we don't get a XEP-0184 receipt. That's works very well so far :). Then it doesn't work at all. It's not useful at all to achieve reliable services. Even xep-198 helps much better but doesn't work alone and is not required anyway. I'll wait for others to join the conversation :). Pavel -- Jonathan -- Pavel Šimerda Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] RCF3920bis07: Resource generation
On Sun, 5 Oct 2008 15:12:18 +0200 Jonathan Schleifer [EMAIL PROTECTED] wrote: Am 05.10.2008 um 15:02 schrieb Pavel Simerda: Btw, is there a real reason to use randomized resource strings... or is it just to overcome bugs made by client and server developers? Main reason is to work around presence leaks - wrong approach, IMO. That is a nice opinion. But this needs a lot of knowledge and discussions. I am also very curious to hear why to spoil one of XMPP's long-used and funcional features instead of fixing the bugs. Anyway this too much resembles security-by-obscurity (more specifically privacy-by-obscurity). I personally thing this idea only brings a FALSE sense of privacy and no real gain. Any single use case that can't be fixed by better means than randomizing a convenient resource string? Pavel Another reason I could think of is so that Average Joe can use the same Jabber Client on two machines without the need to know how to change the resource - but for that, the client could generate a random resource when the account is added and save that. -- Jonathan -- Pavel Šimerda Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] RCF3920bis07: Resource generation
As Justin, Dave and others, I was always for this method... even before it became official XEP. Pavel On Sun, 5 Oct 2008 15:37:00 +0200 Jonathan Schleifer [EMAIL PROTECTED] wrote: Am 05.10.2008 um 15:31 schrieb Pavel Simerda: Then it doesn't work at all. It's not useful at all to achieve reliable services. Even xep-198 helps much better but doesn't work alone and is not required anyway. I haven't said it helps reliability, but the sender is warned that the message has not arrived and can resend it. This is awfully useful, as you often don't know what the last message was that someone received. And for me, it's enough if Gajim supports it, as that is already more than 50% of my roster, I guess :). We need to encourage more client developers to implement it. Gajim already gives a good example of how you could display messages that did not arrive to the user (AFAIK, it's the only client showing that to the user so far). -- Jonathan -- Pavel Šimerda Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] RCF3920bis07: Resource generation
I am very sorry I didn't have enough... But as it seems now... the new RFC breaks the current behavior that was not the best, but acceptable. And the new behavior is totally broken unless other (for now optional, specified in XEP-198) means are used for disconnection detection and stanza acks. That's pretty bad and will lead to a loss of trust that XMPP services work at least reasonably reliably. That's my opinion. Pavel Šimerda On Sun, 5 Oct 2008 11:10:15 -0400 Eric Will [EMAIL PROTECTED] wrote: On Sun, Oct 5, 2008 at 5:33 AM, Jonathan Schleifer [EMAIL PROTECTED] wrote: Not every client supports XMPP ping and this does a lot of traffic and isn't acceptable for mobile devices. Thousands might be a bit exagerated, but you can really see 5 - 10 resources. Currently, I send a space to any resource I haven't heard from in 120 seconds, and if the write succeeds I reset the time. If the write fails, I kill them. XMPP-CORE approves using whitespace for a ping, so I don't see the need for XMPP PING support. Also, the RFC is quite mute on what should be done about conflicting resources. The new draft actually recommends overriding the resource and adding randomness to it instead of replacing the already-connected one by the same name. At the moment, my code just returns conflict/ and closes the stream. -- Pavel Šimerda Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] RCF3920bis07: Resource generation
On Sun, 5 Oct 2008 21:30:56 +0200 Pavel Simerda [EMAIL PROTECTED] wrote: As Justin, Dave and others, I was always for this method... even before it became official XEP. Sorry, I meant as justin, dave and others KNOW. (XEP-198 and its history) Pavel On Sun, 5 Oct 2008 15:37:00 +0200 Jonathan Schleifer [EMAIL PROTECTED] wrote: Am 05.10.2008 um 15:31 schrieb Pavel Simerda: Then it doesn't work at all. It's not useful at all to achieve reliable services. Even xep-198 helps much better but doesn't work alone and is not required anyway. I haven't said it helps reliability, but the sender is warned that the message has not arrived and can resend it. This is awfully useful, as you often don't know what the last message was that someone received. And for me, it's enough if Gajim supports it, as that is already more than 50% of my roster, I guess :). We need to encourage more client developers to implement it. Gajim already gives a good example of how you could display messages that did not arrive to the user (AFAIK, it's the only client showing that to the user so far). -- Jonathan -- Pavel Šimerda Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] RCF3920bis07: Resource generation
On Sat, 4 Oct 2008 09:42:43 +0100 Kevin Smith [EMAIL PROTECTED] wrote: On Sat, Oct 4, 2008 at 1:18 AM, Matthew Wild [EMAIL PROTECTED] wrote: I thought I recalled some discussion on the lists already regarding this, but I haven't been able to find it. On resource binding, the RFC says the server MAY modify the client's chosen resource. Is there a reason that it doesn't say If the client provides a resource, the server SHOULD use this instead? I'm +1 on servers SHOULD do as they're told. /K pavlix agrees too -- Pavel Šimerda Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] [E2E] Why we need a body element
On Thu, 2 Oct 2008 12:46:52 +0100 Pedro Melo [EMAIL PROTECTED] wrote: On Oct 2, 2008, at 8:34 AM, Jonathan Schleifer wrote: Anyway, as we're currently on that OOB vs. IBB thing for E2E: I think using OOB is bad. Direct connections are a leak of privacy (I'm assuming that your loss of privacy is the other party getting your IP address) Not necessarily. You are assuming OOB using direct connections I assume, and forgetting about mediated connections. Besides, the entire discussion about E2E assumes that parties will use certificates and some sort of trust-upgrade mechanism. I would say that the information inside the certificate is probably more privacy- important than my IP address, but other might disagree. +1 If you don't want your IP to be known, you can still do that. I admit I find it hard to see how you can have a secure and *trusted* connection without loss of privacy. But I'm not an expert on security. Secure connections just requires mutual authentication. and not very reliable. I don't understand why a direct or mediated TCP connection is less reliable than a C2S + S2S * 2 + C2S set of connections. I think a direct connection is the most reliable of them all because I've got instant notification when something goes wrong: the connection gets dropped. I am very much for direct connections where possible if we're dealing security and/or performance. Sensible decentralization is already XMPP's advantage. I deal with lost stanzas everyday due to S2S fluctuations, and those problems go away with direct connections. Even mediated connections look better. Good then. I think we should always use IBB for E2E, as long as it's only text. ICQ demonstrated back then HOW bad this is. I encourage exactly the opposite, specially in a corporate environment. If I make sure the chat doesn't ever leave the local network, I reduce the risk of snooping considerable. Correct, ICQ didn't demonstrate anything of this sort. I encourage the opposite in all environments except maybe very special ones. Corporate environment should though have its own XMPP server. Just because its encrypted, safe is still a relative term to your paranoia level. Yep. Somewhere it was unencrypted and somewhere it will be decrypted again. Hopefully only by the right recipient :). Pavel -- Pavel Šimerda Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] Namespaces, specifications, and protocol life cycles
I'm deligted you finally took my idea. Pavel On Tue, 23 Sep 2008 12:24:40 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Kevin Smith wrote: On Tue, Sep 9, 2008 at 4:36 PM, Dave Cridland [EMAIL PROTECTED] wrote: urn:xmpp:protoname:1 Sane. Kev and I just chatted about this via IM. So I take it that we'd start with urn:xmpp:protoname:0 and increment from there? I'm fine with that, and it does seem more sane than the :tmp: approach. I'm working on Jingle right now, so I wonder about things like this: urn:xmpp:tmp:jingle:apps:rtp Which of the following does that become? 1. urn:xmpp:jingle:0:apps:rtp or: 2. urn:xmpp:jingle:apps:rtp:0 I think I prefer the number at the end in all cases. Shall we update all the Jingle namespaces along these lines? I'd be happy to do that during the current revision cycle. Speaking of which, back to work... /psa -- Pavel Šimerda Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] Namespaces, specifications, and protocol life cycles
I believe it both helps with the discipline (a little bit) and helps to maintain graceful transitions in cases we fail. Furthermore it simplifies (sometimes allows at all) maintaining compatibility if used (very) carefully and with as little major version transitions as possible. Pavel On Tue, 09 Sep 2008 19:51:26 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: This would also affect the best practice in protocol changes and versioning. I personally believe this would provide more help than harm. For version 0, incompatible changes would by allright, for higher versions it would be sensible to add new features as optional (we still have discovery) and possibly, in the future, they would be marked REQUIRED all at once with a major protocol change. I believe the incompatible changes for higher versions would be rare. That's what we strive for. Certainly once something is Final, and usually when something is Draft. But I don't see exactly how the namespace versioning helps us here -- what we need is more discipline about standardization, not fancy namespacing. If the latter helps us be more disciplined, that's great. If not, it's just confusing. IMHO. But I'm willing to be convinced otherwise. :) /psa -- Pavel Šimerda Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] Namespaces, specifications, and protocol life cycles
On Tue, 09 Sep 2008 19:54:19 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Dave Cridland wrote: the advantage here is that if the protocol is stable earlier than its move to Draft - and actually, this is normally the case, a lot of the pre-draft stuff is specification wrangling rather than proptocol redesign - people can go ahead and implement it, and it'll continue to work. Otherwise, as we get closer to Draft, we're actually putting people off implementation at the very moment we want to encourage it. I think that's the key bit. But how much are developers scared off by the need to support both urn:xmpp:tmp:foo and urn:xmpp:foo? It seems to me that's just a simple switch statement in your code. Also, it's not clear how we'd handle sub-namespaces: urn:xmpp:foo:4:sub This one looks better and more logical to me. Pavel or urn:xmpp:foo:sub:4 ? Peter -- Pavel Šimerda Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] Namespaces, specifications, and protocol life cycles
On Wed, 10 Sep 2008 15:29:53 +0100 Dave Cridland [EMAIL PROTECTED] wrote: On Wed Sep 10 02:54:19 2008, Peter Saint-Andre wrote: Dave Cridland wrote: the advantage here is that if the protocol is stable earlier than its move to Draft - and actually, this is normally the case, a lot of the pre-draft stuff is specification wrangling rather than proptocol redesign - people can go ahead and implement it, and it'll continue to work. Otherwise, as we get closer to Draft, we're actually putting people off implementation at the very moment we want to encourage it. I think that's the key bit. But how much are developers scared off by the need to support both urn:xmpp:tmp:foo and urn:xmpp:foo? It seems to me that's just a simple switch statement in your code. No, it's not, because urn:xmpp:tmp:* is actually meaningless. These namespaces are used for documents in wild fluidity, and one implementation's urn:xmpp:tmp:foo may well be completely different from another's. A specification might stay stable for months, if not years, with a :tmp: namespace, only to change later. And in any case, if urn:xmpp:tmp:foo really is just a swich statement away from urn:xmpp:foo, then why bother with tmp at all? FWIW, I definitely prefer to have :tmp: instead of a 0-version, because it makes it clear that version changing is unusual, whereas :tmp: really means unknown namespace. After thinking it through, I agree with you. But then I think we should push the 0-version (after :tmp:) when we expect wider implementation and not :tmp:. This is much earlier than we do with non-:tmp: versions now. Pavel Dave. -- Pavel __imerda Freelancer v oblasti pota__ov__ch s__t__, komunikace a bezpe__nosti Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] website transition
+1 for lighttpd, I always liked it. Pavel On Mon, 08 Sep 2008 11:55:50 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Matthew Wild and I just completed the transition of apollo (the jabber.org/xmpp.org webserver) from Apache to lighttpd. Concurrently we also migrated jabber.org and xmpp.net from Drupal to MediaWiki. So far everything seems to be working great. If you find any website problems, please let us know! /psa -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] website transition
A regularly-run XSLT would help... MattJ is good in writing them ;). Don't beat me, friend (to MattJ). Pavel On Mon, 08 Sep 2008 13:36:37 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Andreas Monitzer wrote: On Sep 08, 2008, at 19:55, Peter Saint-Andre wrote: If you find any website problems, please let us know! Yes, my feature request dating back to the website version even before the move to drupal still isn't implemented, even though I was repeatedly told that it's on the todo list since back then :( My request was to have an RSS or Atom feed of the public server list, so I can display that list in Adium in the registration dialog. I had totally forgotten about that feature request. We do have a plain XML file: http://www.jabber.org/servers.xml But perhaps that's not what you need. Of course, moving to a wiki makes the whole thing even worse, since there's no easy solution to that problem now (since the completely nonsemantic wiki code is the only data source). I could do some kind of html extraction, but that would break as soon as someone does an edit that changes the website slightly. All the data I need is there, I just can't access it... Correct. Right now I'm hand-editing servers.xml... /psa -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] website transition
Actually, if you really need it, you can transform the XML file (and other ones) yourself, it can't be so hard. Pavel On Tue, 9 Sep 2008 01:07:21 +0200 Andreas Monitzer [EMAIL PROTECTED] wrote: On Sep 08, 2008, at 21:36, Peter Saint-Andre wrote: I had totally forgotten about that feature request. Yes, that's what I hear every time I remind somebody of the jabber.org- team :) We do have a plain XML file: http://www.jabber.org/servers.xml But perhaps that's not what you need. Well, I'd need the additional info available on the detail pages, too: e.g. http://www.jabber.org/web/Jabber.org esp. the description, location and lat/long. Right now I'm hand-editing servers.xml... Uh, you should know better than that... andy -- Pavel Šimerda Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] xmpp-commits list
Maybe it would easier for other people to participate. Git is just one option. There are other decentralized systems, though I understand that the concepts of decentralized SCM were not so well known either. Some of my friends even prefer other decentralized systems to Git... for me it's just the first one I have learned. Their reasons include simplicity and ease of use though I'm still happy with what Git offers. But maybe it's just I didn't have time to thoroughly test the others (notably Monotone and Darcs). Maybe we can discuss off-list if there's more to say? Pavel On Fri, 05 Sep 2008 08:05:03 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: Never knew why is Subversion the SCM of choice for a decentralized IM protocol project. They must have known centralization is a barrier to open collaboration. Maybe because only one person writes all the documentation? :P Plus, I don't think Git was widely known or used when we switched from CVS to SVN. /psa -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] roster sequencing
Maybe because XE-0237 is just an optimization, not a solution to problems with stanza limits? Pavel On Fri, 5 Sep 2008 21:50:04 +0100 Pedro Melo [EMAIL PROTECTED] wrote: On Sep 4, 2008, at 6:52 PM, Peter Saint-Andre wrote: Pavel Simerda wrote: +1 for a generic method Yeah, that means I need to re-work XEP-0237. :( :( I wouldn't. We talked a lot to get 237 to the place where it is now. In the process I *believe* we discussed using 0059. I find 0237 elegant and simple to implement on most servers. Before starting 0237 all over again, I was hoping to hear from server implementors about this. I understand the desire of having solutions that work likes tools, that we can reuse on several places. But just because it looks like a nail, we shouldn't just get the hammer. For example, rosters have this property where a single age flag can be used to send the roster delta with little effort on the server (assuming a SQL-style backend). Do we sacrifice that just to use a standard tool? Its not clear to me. Best regards, -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] roster sequencing
Oh, good point. It might be good to go with the optimizations only. I'd just like to see a way to avoid what often happens... that is waiting one or two minutes before the connection is usable (that means I can both send and recieve). Pavel On Sat, 6 Sep 2008 01:08:42 +0100 Pedro Melo [EMAIL PROTECTED] wrote: Hi, sorry about the previous empty email. Premature sending. On Sep 4, 2008, at 7:19 PM, Fabio Forno wrote: On Thu, Sep 4, 2008 at 7:52 PM, Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: +1 for a generic method Yeah, that means I need to re-work XEP-0237. :( Since Pavel has reminded XEP-59, what about transforming xep-237 into an extension of it? XEP-59 allows to set the boundaries of a result set by setting a first of last item; by extending the possible conditions (one is the sequence number, are there others?) the changes should be trivial. Instead of asking all the items after last, request all the items after sequence-no recent-thansequence/recent-than ? This is also the answer to the other question about what happens to large roster when there are stanza size limitations: just return a partial set and then ask the remaining ones. I read an email message from peter (ejabberd list I think) mentioning that server-to-local-client flows where not restricted by stanza limits. I remember because: a) I didn't knew that; b) it makes sense after thinking about it; c) I'm not sure which implementations do this. -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: [EMAIL PROTECTED] -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] xmpp-commits list
Hey, you saved me the time needed to learn git-svn! Never knew why is Subversion the SCM of choice for a decentralized IM protocol project. They must have known centralization is a barrier to open collaboration. Pavel On Fri, 5 Sep 2008 09:08:31 +0100 Pedro Melo [EMAIL PROTECTED] wrote: On Sep 4, 2008, at 6:24 PM, Peter Saint-Andre wrote: Tobias Markmann wrote: On Thu, Sep 4, 2008 at 6:55 PM, Peter Saint-Andre [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: At the request of Jack Moffitt, I have set up an announce list for commits to the xmpp SVN repository, so that folks can track more closely what changes in the XEPs, registries, schemas, and the xmpp.org http://xmpp.org website in general. You can subscribe here: http://mail.jabber.org/mailman/listinfo/xmpp-commits The list is new so I may still have a few mailman config issues to fix. /psa Is there an RSS or Atom feed too? Yes. There are links from http://www.xmpp.org/xsf/sourcecontrol.shtml And there is a mirrored Git repo of the SVN always update at http://github.com/xsf/documentation Updated hourly. Best regards, -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] roster sequencing
Yep, this should be included to... Btw... just reminding XEP-0059: Result Set Management Pavel On Thu, 04 Sep 2008 09:13:22 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: Just a sidenote to the roster sequencing... There are clients (e.g. Gajim) that ask for vCard right now to show user avatars. In future the usual flow might be that the client asks sequentially for various user information via some PubSub/PEP requests. IMO we should not forget this when designing protocols for optimization. We might want to unify roster-optimization with PEP/PubSub optimization. There is probably also optimization we can do with disco#items (think of large result sets for things like chatrooms at a MUC service). /psa -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] roster sequencing
I think it's not so time-critical. On Thu, 04 Sep 2008 11:52:43 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: +1 for a generic method Yeah, that means I need to re-work XEP-0237. :( /psa -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] roster sequencing
Yep, that would be a good idea. Thanks! Btw... I suggest a clean-up of XEP-59 also for my user-search proposal I sent to the pubsub list. It's not even in INBOX yet but if you want to look: http://data.pavlix.net/xmpp/user-search/user-search.html Pavel On Thu, 4 Sep 2008 20:19:36 +0200 Fabio Forno [EMAIL PROTECTED] wrote: On Thu, Sep 4, 2008 at 7:52 PM, Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: +1 for a generic method Yeah, that means I need to re-work XEP-0237. :( Since Pavel has reminded XEP-59, what about transforming xep-237 into an extension of it? XEP-59 allows to set the boundaries of a result set by setting a first of last item; by extending the possible conditions (one is the sequence number, are there others?) the changes should be trivial. Instead of asking all the items after last, request all the items after sequence-no This is also the answer to the other question about what happens to large roster when there are stanza size limitations: just return a partial set and then ask the remaining ones. -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] Controlling Receipt of MUC participant presence
+1 for this idea On Sun, 31 Aug 2008 12:42:13 +0200 Jonathan Schleifer [EMAIL PROTECTED] wrote: Am 30.08.2008 um 23:52 schrieb Peter Saint-Andre: Heck, I wonder if certain features in MUC might be better defined in separate specifications (e.g., all the room history handling and the request a unique room name feature). That sounds like a good idea! -- Jonathan -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] Controlling Receipt of MUC participant presence
Are you sure it's good enough for final? Pavel On Sat, 30 Aug 2008 15:52:13 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Dave Cridland wrote: ... and Keith suggestion works the other way around - the client *is* a participant, but makes everyone else invisible to it. There is also a room configuration option to not send presence for various roles and affiliations. It'd be interesting to see if it's worth offering control of a range of traffic, or whether we should just implement Keith's suggestion more or less as-is. One thing aimed at Keith in particular, though - I'd much rather not add things to MUC at this point. We can certainly tidy existing practise, and we can of course always extend: x xmlns='http://jabber.org/protocol/muc' nopresence xmlns='urn:xmpp:tmp:nopresence'/ /x +1 to not changing XEP-0045 -- I'd prefer to push it to Final soon, not tinker with it forever. Heck, I wonder if certain features in MUC might be better defined in separate specifications (e.g., all the room history handling and the request a unique room name feature). /psa -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] refactoring of XEP-0154: User Profile
Hi again, I forgot to mention... I have an almost finished version of User Searching by profile and events. I wanted to do this first as it may affect the design of User Profile. I will post some preliminary version soon. Btw, xmlstarlet leaves out the entities when transforming, any suggestions on XSL for XEPs? Pavel On Wed, 27 Aug 2008 12:03:18 +0100 Pedro Melo [EMAIL PROTECTED] wrote: Hi, On Aug 27, 2008, at 1:04 AM, Pavel Simerda wrote: I prepared the long-promised examples of possible XEP-0154 protocol flows. http://www.pavlix.net/xmpp-profile.txt Some typos: * in Example 8, I think you mean feature var='urn:xmpp:tmp:profile:basic+notify'/ , per secion 10.2 of XEP 0060; * there is a lost http://jabber.org/protocol/tune in Example 9 and 10; I need to re-read section 3 with more time, I don't understand what is its purpose yet. But the rest seems fine. Best regards, -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] refactoring of XEP-0154: User Profile
Hello Thanks for your comments and corrections. Ad section 3: The purpose is to fulfill the requirements brought up by Dave Cridland but useful to many others, mainly corporate networks and big social networks. PEP-publishing is insuitable for these use cases but mimicking the fetching and notification keeps read access working. All boils down to just specifying a name of an ad-hoc command to be tried if PEP-publish is forbidden. The only catch is that it is a slightly extended PEP ;). Cheers, Pavel On Wed, 27 Aug 2008 12:03:18 +0100 Pedro Melo [EMAIL PROTECTED] wrote: Hi, On Aug 27, 2008, at 1:04 AM, Pavel Simerda wrote: I prepared the long-promised examples of possible XEP-0154 protocol flows. http://www.pavlix.net/xmpp-profile.txt Some typos: * in Example 8, I think you mean feature var='urn:xmpp:tmp:profile:basic+notify'/ , per secion 10.2 of XEP 0060; * there is a lost http://jabber.org/protocol/tune in Example 9 and 10; I need to re-read section 3 with more time, I don't understand what is its purpose yet. But the rest seems fine. Best regards, -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] Controlling Receipt of MUC participant presence
A disco feature on the MUC side would be good. So the client knows if this will work or not. Pavel On Tue, 26 Aug 2008 08:11:15 -0400 Lirette, Keith J. CONTR J9C618 [EMAIL PROTECTED] wrote: I have a use case for a low bandwidth client which would benefit from the ability to control client receipt of MUC participant presence packets. In the use case, the user is interested in the message traffic but does not need to know who is currently participating in the MUC session. A user would always receive it's own presence packet, but could control whether it received presence packets of other participants. An additional optional element to the http://www.xmpp.org/schemas/muc.xsd schema could be used to control whether this feature: presence from='[EMAIL PROTECTED]/pda' to='[EMAIL PROTECTED]/thirdwitch' x xmlns='http://jabber.org/protocol/muc' nopresence/ /x /presence -Keith -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
On Mon, 18 Aug 2008 02:52:50 +0100 Matthew Wild [EMAIL PROTECTED] wrote: On Mon, Aug 18, 2008 at 2:21 AM, Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: Ok, just... couldn't this be at least partially automated (not to have the sure check himself)? If it's not possible, never mind. Sure it could. I'm not sure if we really need that, given that members-only rooms are relatively uncommon, but we could presumably define a data form or ad-hoc command for the automated flow if we really need to. I'm leaning toward crossing that bridge when we come to it. My reason for bringing invite-only rooms was not to suggest they should be done, just that this protocol takes away the possibility to implement them (and it happens to be something I was thinking about a couple of weeks ago). We don't have invite-only rooms, but IRC doesn't have members-only rooms. I can't think of many cases an invite-only room would be called for, unless it is an admin doing the inviting, in which case it is easy to add invitees to the member list. That, or just use a password, as exampled in this XEP. But this must apparently by written by the inviting user. Matthew. -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] LAST CALL: XEP-0231 (Bits of Binary)
Looks fine to me, looking forward for Zenek's comments! Pavel On Sat, 16 Aug 2008 20:52:20 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: On Fri, 15 Aug 2008 20:15:35 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Zenon Kuder jr. wrote: Dne Friday 15 of August 2008 23:45:44 Peter Saint-Andre napsal(a): Pavel Simerda wrote: If we need metadata to specify the origin, we can add an additional optional metadata element inside the data/. Sure, we could do that. So something like this? data cid='[EMAIL PROTECTED]' origin='http://bundles.jabbim.cz/'/ Peter Seems nice. We should specify the hash algorithm in the cid somehow though. I don't know what the common practice for that would be. We might do something like this: 1. [EMAIL PROTECTED] 2. [EMAIL PROTECTED] I don't have a strong preference. I might have a slight preference for #1, because it's possible that we might even host image bundles at those domains via HTTP (so if your client supports SHA1 it can go to the URL http://sha1.bob.xmpp.org/ and retrieve the public images hosted there). Possibly. :) I prefer #2. We could possibly host on bob.xmpp.cz anyway. Sure/ If we ever host these images, bob.xmpp.org could round-robin to other domains, or just redirect. And since we use hash now, we don't need to cache per JID. Nifty. But we may if we don't want to check the hash or don't believe the hash functions (future consideration). Depends on the implementation and configuration. Correct. /psa -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
Ok, just... couldn't this be at least partially automated (not to have the sure check himself)? If it's not possible, never mind. Pavel On Sat, 16 Aug 2008 20:08:55 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: On Fri, 15 Aug 2008 15:47:17 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: On Fri, 15 Aug 2008 08:55:28 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: But then what is an invitation for? You have to make someone a member and send him an invitation message. But for this, you have to be able to add members. I don't think the concept of an invitation-only room makes much sense, especially because we don't have ways of delivering secure invitations (right now invitations are more social interactions, not technical interactions, and I think we might want to leave it that way). But i thought I've seen some members-only rooms. Oh sure, one example is [EMAIL PROTECTED] :) /psa But that means we have some sort of room authorization :). And we should know what happens if you invite someone to a room that's members-only and he's not a member. Because just sending a direct invite is no good. Making him a member and sending a direct invite seems natural to me. I've added an implementation note about that. /psa -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] LAST CALL: XEP-0231 (Bits of Binary)
Then I just didn't follow the references, my bad. Pavel On Fri, 15 Aug 2008 15:45:44 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: Btw, what I didn't know before... I have looked into the CID/MID rfc and there's nothing about requiring the at-sign. It's only written in the common practice sections but there they use. And they do use local hstnames, not shared strings. But then xmpp.sha1.da39aee5e6b4b0d3255bfef95601890afd807099 (or similar syntax) is just as conforming as any other syntax. The interesting point of the RFC is that the CIDs must be globally unique but it apparently leaves it for the implementors to be clever enough not to have the same idea. It depends if you want to break common practice. I don't think that's right. Looking at RFC 2111 we find: content-id= url-addr-spec and url-addr-spec = addr-spec ; URL encoding of RFC 822 addr-spec Then consulting RFC 822 we find: addr-spec = local-part @ domain However, I think we don't have to use a UUID for the local-part, we could use a hash. The hostname is just useless for the XMPP purposes. But if we keep it for common practice, I'd suggest a constant one then (as it's useless anyway). I don't see a use for it now, but that doesn't mean it's useless. However, I'm OK with hardcoding it to bob.xmpp.org or something. If we need metadata to specify the origin, we can add an additional optional metadata element inside the data/. Sure, we could do that. So something like this? data cid='[EMAIL PROTECTED]' origin='http://bundles.jabbim.cz/'/ Peter -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] LAST CALL: XEP-0231 (Bits of Binary)
On Fri, 15 Aug 2008 20:15:35 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Zenon Kuder jr. wrote: Dne Friday 15 of August 2008 23:45:44 Peter Saint-Andre napsal(a): Pavel Simerda wrote: Btw, what I didn't know before... I have looked into the CID/MID rfc and there's nothing about requiring the at-sign. It's only written in the common practice sections but there they use. And they do use local hstnames, not shared strings. But then xmpp.sha1.da39aee5e6b4b0d3255bfef95601890afd807099 (or similar syntax) is just as conforming as any other syntax. The interesting point of the RFC is that the CIDs must be globally unique but it apparently leaves it for the implementors to be clever enough not to have the same idea. It depends if you want to break common practice. I don't think that's right. Looking at RFC 2111 we find: content-id= url-addr-spec and url-addr-spec = addr-spec ; URL encoding of RFC 822 addr-spec Then consulting RFC 822 we find: addr-spec = local-part @ domain However, I think we don't have to use a UUID for the local-part, we could use a hash. The hostname is just useless for the XMPP purposes. But if we keep it for common practice, I'd suggest a constant one then (as it's useless anyway). I don't see a use for it now, but that doesn't mean it's useless. However, I'm OK with hardcoding it to bob.xmpp.org or something. If we need metadata to specify the origin, we can add an additional optional metadata element inside the data/. Sure, we could do that. So something like this? data cid='[EMAIL PROTECTED]' origin='http://bundles.jabbim.cz/'/ Peter Seems nice. We should specify the hash algorithm in the cid somehow though. I don't know what the common practice for that would be. We might do something like this: 1. [EMAIL PROTECTED] 2. [EMAIL PROTECTED] I don't have a strong preference. I might have a slight preference for #1, because it's possible that we might even host image bundles at those domains via HTTP (so if your client supports SHA1 it can go to the URL http://sha1.bob.xmpp.org/ and retrieve the public images hosted there). Possibly. :) I prefer #2. We could possibly host on bob.xmpp.cz anyway. And since we use hash now, we don't need to cache per JID. Nifty. But we may if we don't want to check the hash or don't believe the hash functions (future consideration). Depends on the implementation and configuration. Actually the idea (I talked with Pavel by IM a bit) That's allowed. Not everything needs to happen on the list. :) is that client a) either uses hash, checks the incoming data and caches per hash or b) doesn't know the hash or hash wasn't used or doesn't support hashes and then caches per JID and per the unique string. I hope I got it right and clear :-). Yes, that seems good. I'll update the spec. /psa -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] LAST CALL: XEP-0231 (Bits of Binary)
On Fri, 15 Aug 2008 20:35:52 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Peter Saint-Andre wrote: Zenon Kuder jr. wrote: Actually the idea (I talked with Pavel by IM a bit) is that client a) either uses hash, checks the incoming data and caches per hash or b) doesn't know the hash or hash wasn't used or doesn't support hashes and then caches per JID and per the unique string. I hope I got it right and clear :-). Yes, that seems good. We might even want to harmonize BoB with User Avatar (XEP-0084). There we have: metadata xmlns='urn:xmpp:avatar:metadata' info bytes='size-of-image-data-in-bytes' height='image-height-in-pixels' id='SHA-1-hash-of-image-data' type='content-type-of-image-data' url='HTTP-URL-for-image-data' width='image-width-in-pixels'/ /metadata So hashes of user avatar images could be compared against BoB data, too (without changing XEP-0084, unless we want to add a 'cid' attribute there). Not sure if this is useful. But what we need to do is both specify the metadata format... and to specify how we compute the hash. I propose (as a possibility): For sha-1: h = sha-1 Generally: hashed_value = h( h(content-type) + h(content) ) where + stands for concatenation. If we include the metadata, it would be good to add it to the hash too (just as we concatenated hashes of content-type and content) in some way. This would ensure we get the same type, data and metadata for a particular hash :) which is nice ;). Pavel /psa -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] LAST CALL: XEP-0231 (Bits of Binary)
On Sat, 16 Aug 2008 08:38:26 +0200 Johansson Olle E [EMAIL PROTECTED] wrote: 15 aug 2008 kl. 23.45 skrev Peter Saint-Andre: Pavel Simerda wrote: Btw, what I didn't know before... I have looked into the CID/MID rfc and there's nothing about requiring the at-sign. It's only written in the common practice sections but there they use. And they do use local hstnames, not shared strings. But then xmpp.sha1.da39aee5e6b4b0d3255bfef95601890afd807099 (or similar syntax) is just as conforming as any other syntax. The interesting point of the RFC is that the CIDs must be globally unique but it apparently leaves it for the implementors to be clever enough not to have the same idea. It depends if you want to break common practice. I don't think that's right. Looking at RFC 2111 we find: content-id= url-addr-spec and url-addr-spec = addr-spec ; URL encoding of RFC 822 addr-spec Then consulting RFC 822 we find: addr-spec = local-part @ domain However, I think we don't have to use a UUID for the local-part, we could use a hash. The hostname is just useless for the XMPP purposes. But if we keep it for common practice, I'd suggest a constant one then (as it's useless anyway). I don't see a use for it now, but that doesn't mean it's useless. However, I'm OK with hardcoding it to bob.xmpp.org or something. Using domain or host here is like the recommendation to use it as part of the call ID or realm in SIP. Using your own domain ensures a unique namespace for you. Using a hostname ensures a unique namespace for your host. In both these cases, it doesn't have any other meaning - it's never parsed or resolved. It's just a way to ensure uniqueness in a simple way. Exactly. And this means the domain's owner is responsible for the uniqueness. But how can example.com owners be responsible for uniqueness of [EMAIL PROTECTED]'s own ids? If we specify a hashing approach, I would not use local domains in the CIDs just because we (xmpp.org) are who specified how to achieve the uniqueness. Pavel /O -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
On Fri, 15 Aug 2008 15:47:17 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: On Fri, 15 Aug 2008 08:55:28 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: But then what is an invitation for? You have to make someone a member and send him an invitation message. But for this, you have to be able to add members. I don't think the concept of an invitation-only room makes much sense, especially because we don't have ways of delivering secure invitations (right now invitations are more social interactions, not technical interactions, and I think we might want to leave it that way). But i thought I've seen some members-only rooms. Oh sure, one example is [EMAIL PROTECTED] :) /psa But that means we have some sort of room authorization :). And we should know what happens if you invite someone to a room that's members-only and he's not a member. Because just sending a direct invite is no good. Making him a member and sending a direct invite seems natural to me. Pavel -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
On Fri, 15 Aug 2008 08:55:28 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: On Thu, 14 Aug 2008 11:27:22 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: On Wed, 13 Aug 2008 08:18:43 -0500 XMPP Extensions Editor [EMAIL PROTECTED] wrote: http://www.xmpp.org/extensions/inbox/direct-invitations.html Hmm, good idea, this simple direct invitation protocol, it makes sense to send invitation to the people I invite. Well that's what we had in the old days (jabber:x:conference), but then we made something fancier in XEP-0045. Fancier isn't always better. Just a sidenote, couldn't venue be replaced with something more specific and well known in the XMPP community (e.g. conference). It might also come first in the example, as it's the only important (and REQUIRED) element. Sure, conference is fine with me. Also, more about authorization and relation to other XEPs would be nice. Passwords are IMO not a good *default* authorization technique for MUC rooms. I agree. But that's something we should define in XEP-0045 -- or even deprecate password-only rooms in favor of members-only rooms. It seems MUC authorization was removed from [xep 0235]. Isn't now the time to find a better place for it? Maybe. I'm not sure how useful MUC authorization is. A members-only room is an authorized MUC room - the list of members becomes the list of authorized entities. But then what is an invitation for? You have to make someone a member and send him an invitation message. But for this, you have to be able to add members. I don't think the concept of an invitation-only room makes much sense, especially because we don't have ways of delivering secure invitations (right now invitations are more social interactions, not technical interactions, and I think we might want to leave it that way). But i thought I've seen some members-only rooms. Peter -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] LAST CALL: XEP-0231 (Bits of Binary)
On Fri, 15 Aug 2008 12:57:12 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: On Thu, 14 Aug 2008 10:38:42 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: snip/ Since developers of Jabbim would like to use BoB for emoticons exchange (possibly in a way similar to the one used by Pidgin developers, might be neat to spec it out sometime), I'd like to ask whether it would be possible to reconsider using hashes instead the UUID for identification. We use hashes in XEP-0084 (User Avatar): http://www.xmpp.org/extensions/xep-0084.html So it might make sense to use them here as well. Yep, they would be good to incorporate in ConentID. Btw, the hash would be enough itself (without CID) but we want to use CID URIs. I agree that hashes would be enough (as in XEP-0084), but here we want to use CIDs for cross-referencing. Btw, what I didn't know before... I have looked into the CID/MID rfc and there's nothing about requiring the at-sign. It's only written in the common practice sections but there they use. And they do use local hstnames, not shared strings. But then xmpp.sha1.da39aee5e6b4b0d3255bfef95601890afd807099 (or similar syntax) is just as conforming as any other syntax. The interesting point of the RFC is that the CIDs must be globally unique but it apparently leaves it for the implementors to be clever enough not to have the same idea. It depends if you want to break common practice. I see a bit of information about that in RFC4122 but not a lot of details. It's all there, the notion of names or content is apparently left for the particular protocols/formats to define. They are only hash-based and they are (hopefully) unique to a particular sequence of bytes. They don't serve the same purpose as e.g. sha1 mostly because the full sha1 hash doesn't fit in UUID. I'll have to see where those are specified. snip/ http://tools.ietf.org/html/rfc4122 4.3. Algorithm for Creating a Name-Based UUID The concept of name and name space should be broadly construed, and not limited to textual names. That means it can even be a whole file or a combination of fields (e.g. the content type and the content). But the hashes are a better way if we want to actually check them. 2) Add one additional form of CID: hash-value@hash-function.xep0231.xmpp.org. (the concrete syntax serves as an example, not final syntax) The hash functions would be sha1, sha256 and possibly other ones too and the computed hash value would be based on both *content type* and *content data* (needs more precise spec.). This would also be an exception from forced per JID caching. Or if people define emoticon bundles then the images could be identified by the domain of the entity that hosts the bundle, perhaps an open-source project or whatever. /psa This would break the hash function use case. We want same data (including type) to have same ContentID uri for global sharing (most probably with a constant domain part). I don't see any big difference between: cid:hash@sha1.xep0231.xmpp.org and: cid:hash@sha1.open-emoticons.tld or: cid:hash@sha1.jabbim.cz or whatever. Why do we need centralization of the address space? /psa The hostname is just useless for the XMPP purposes. But if we keep it for common practice, I'd suggest a constant one then (as it's useless anyway). If we need metadata to specify the origin, we can add an additional optional metadata element inside the data/. Pavel -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] LAST CALL: XEP-0231 (Bits of Binary)
On Thu, 14 Aug 2008 13:26:00 +0200 Zenon Kuder jr. [EMAIL PROTECTED] wrote: Hello, I have a few questions regarding BoB which came up in our Jabbim client development room. I have read throught the mails regarding it in this list (more or less thoroughtfully, so please excuse me if I missed something), but haven't followed the chat sessions Pavel and Peter had. I'm sorry that the email didn't stay as brief as I planned ;-) I quote this mail here: http://mail.jabber.org/pipermail/standards/2008-July/019390.html 30 of July 2008 03:49:01 Peter Saint-Andre wrote: Pavel Simerda wrote: I further propose we add some informational section about generation of CIDs. Although it's specified elsewhere, I believe this XEP will be very useful and will be referenced from many future XEPs (and maybe improved as well - possibly some server caching etc). I think the informational section could suggest UUIDs generated by hashing the actual content. Yes I think that would be helpful. Since developers of Jabbim would like to use BoB for emoticons exchange (possibly in a way similar to the one used by Pidgin developers, might be neat to spec it out sometime), I'd like to ask whether it would be possible to reconsider using hashes instead the UUID for identification. You can use hash-based UUIDs. The use case is as follows: - There are/will be some databases full of emoticons, which people can download and use - When user sends an xhtml-im message containg img referencing a particular cId and the receiving entity doesn't have the image, it asks for it. - Advantage of using hash in this case would be that the same image would have the same identification, always and ever. Using unique random identifiers instead of hashes would complicate distribution of the same image through different channels and/or through chain of different users. You may use non-random UUIDs if this is the concern. - I'm not a crypto-geek, so I don't know about the poisoning possibility, but I believe that when we need to hash something like caps to increase security, we should hash binary data too ;-). Also, we have concerns about the domain part being sender's domain. Is it necessary only to satisfy some specifiactions needs (rfc2111?) or does it have some functionality? At first glance I thought the domain would be checked against stanza's from, but that would disallow sending emoticons into MUC rooms. One of the developers (Lolek) who, as I understood, showed interest in ressurecting emoticons XEP also thought that making someone's domain distributing across network (by resending the image to different users) doesn't seem right (although domain isn's anything secret after all). This could be solved by renaming the image when reusing it in the reciever's client. If the domain part is to be replaced in every hop I think this should be made more clear in the spec. (in case the domain part isn't removed completely from the spec) Yep, it should be. I'm afraid we can't just leave it out (CIDs are defined by a RFC, not this XEP). cache=unlimited - we suggest the client picks the longest time it allows (it could possibly cache some small pieces of data permanenty) Perhaps a commonly-used emoticon? Regarding caching, I agree with both of you that caching should be allowed for unlimited time (for emoticons in particular) and it seems this isn't in the current spec. Although rfc2965 defines Max-Age to be non-negative integer, I guess -1 for unlimited might be useful. Possibly. Or maxint which is compatible with the current spec. Secondly, caching per-JID seems to be breaking the principle of the emoticon distribution use case and I think that forementioned per-hash caching would remove the need to do that. (as long as applications check the hash) Yes, it's breaking this use case in favor of simplicity. We were not sure whether the global-sharing feature is wanted by the developer community and it can be added in a backwards-compatible matter. What I suggest to satisfy the Jabbim developers (and possibly others with similar needs) the following two modifications: 1) Only force UUID if we use the domain part of the JID and forbid re-using these names. 2) Add one additional form of CID: hash-value@hash-function.xep0231.xmpp.org. (the concrete syntax serves as an example, not final syntax) The hash functions would be sha1, sha256 and possibly other ones too and the computed hash value would be based on both *content type* and *content data* (needs more precise spec.). This would also be an exception from forced per JID caching. Thanks for your time and sorry if I ask for something answered before. Zenon Kuder jr. You're most welcome! Pavel -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] LAST CALL: XEP-0231 (Bits of Binary)
On Thu, 14 Aug 2008 15:40:14 +0200 Zenon Kuder jr. [EMAIL PROTECTED] wrote: Hi again, I came up with some more comments :-) From introductory text of section 2.1: [...] If the data is not cached, the recipient would then retrieve the data by sending an IQ-get to the sender (or potentially some other entity) [...] I think the potential other entity might be an interesting use case as well. As stated in my previous mail, I think about the emoticons use case. This time for example in a MUC room: -participant A sends an xhtml-im message to muc room containg the img element to reference an emoticon - participant B, C, D, E and F receive the message and since they don't have the referenced image, they want to retrieve it. - there exists a protocol to reference external resources, which these entities use to download the referenced data Maybe some example flows would help. Is this a comment to the current specs with some changes needed or just another use case? Advantages: - the sender isn't bloated by multiple requests for the file Who's contacted then? - receiver doesn't leak its jabber id to arbitrary room occupant This is usually possible to achieve in MUC communications. - receiver can have enabled downloads only from trusted jabber ID This is always possible, isn't it? (its servers emoticon service etc) Disadvantages: - I actually can't see what's better in this approach than in sending ordinary HTTP URL, but I thought it was worth discussing. Maybe advantage for clients with only one TCP connection possible (bombus)? HTTP reveals IP address. And the second TCP connection and protocol implementation servers as another example. Best regards, Zenon Kuder jr. -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] comments on section 8.3, draft-saintandre-rfc3920bis-06.html
On Wed, 13 Aug 2008 15:03:21 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: On Tue, 12 Aug 2008 00:31:00 -0700 Justin Karneges [EMAIL PROTECTED] wrote: On Monday 11 August 2008 14:04:22 Pavel Simerda wrote: On Mon, 11 Aug 2008 13:45:08 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Server DOM grovelling to look for the right extension? That doesn't sound very appealing to server developers. What about: A: presence type='meeting-request'/ I'm pretty sure any server developer who doesn't want to process the XML inside a presence stanza would also be against adding new presence types. I think if any extending goes on, it would have to be through child elements of the stanza. I believe if the type is really different from the usual availability (which the temporary availability is), we should not stick with the current set of presence types only because it has been like that for a long time. The flow of your protocol is good, though. Thanks. Current implementations would send it to the client (if not instructed to block everything) or no? It's hard to say what current servers would do. Presence stanzas are treated specially in servers, much more than message/iq which are usually just relayed as-is. It wouldn't surprise me if sending new/invalid presence types would cause the receiving server to drop the stanza. Still better than confusion with subscribe. We need two new XEPs: Temporary Presence Exchange (for exchanging caps/resource information with unknown/invisible entities), What more does that involve on top of directed presence containing caps? and Presence-based Privacy (which is TPE-aware). I feel a lot of hoops here. How about a way to send a presence subscription request but indicate that it's intended to be only temporary? presence type='subscribe' temporary/ /presence That'll get through without all sorts of server upgrades etc. That will, without a server upgrade be regarded as a subscription request by the server, which is not a good backwards-compatible scheme either. Or maybe it is a fine backwards-compatible scheme? Clients/servers unaware of temporary subscriptions would at least be able to set up a normal subscription. Which is IMO bad and confusing when you only want temporary presence session. This might even lead to the situation that people are angry because you want subscription and you aren't supposted to. What more, clients can do nothing to prevent it. If you want to extend something, it would be better if it's not subscriptions. We have enough problems with subscriptions without that. (They sometimes don't work as expected and servers sometimes store different subscription states for the same user relation.) Look, we're trying to work around presence blocking. Some servers will only let presence type='subscribe'/ through because of privacy lists (or what looks like a privacy list anyway, a la Google Talk), and a new value for the 'type' attribute won't help here. So either we use subscribe or it won't work anytime soon. Choose one. :) I don't like workarounds in the core specifications nor in the extensions. I personally would prefer waiting for fixed implementations over ugly workarounds. Personally I don't mind having a big roster, and I don't mind having people send me presence subscription requests, long-term or short-tterm, whatever. In fact I'd love to have a flag for short-tterm subscriptions when a presence subscription request comes in -- I'd be more likely to approve it, and maybe the short-term subscription turns into a long-lived subscription. I'm not sure how you present these options to the users (both the subscriber and the subscribee), but I think client developers can work on those issues and we can share those insights. Peter -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] XEP-0045: requesting a unique room name
On Thu, 14 Aug 2008 09:09:28 +0200 Yann Leboulanger [EMAIL PROTECTED] wrote: Peter Saint-Andre wrote: Yann Leboulanger wrote: Peter Saint-Andre wrote: Has any MUC implementation coded in support for the unique room name request feature described in Section 10.1.4 of XEP-0045? I think this feature is unnecessary and (in the interest of simplification) I would like to remove it from XEP-0045. In our client (Gajim), we use it for chat to muc convertion too. If it's not supported by MUC component, we do nickname + random number, but it's convenient to be sure we won't have a confict. But then you have a dependency on the server side, right? Why not just generate a UUID on the client side? Because we don't know all the rooms that are opened, and we can't be sure our room name will be unique. You can't be sure the server won't burn when generating the UUID either... and it would cause more harm. It's very improbable just as collisions in good UUIDs. -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] XEP-0045: requesting a unique room name
Nothing is guaranteed, in practice. On Thu, 14 Aug 2008 15:20:26 +0200 Remko Tronçon [EMAIL PROTECTED] wrote: Um, the whole point of a UUID is that it's universally unique, no? No, the point of a UUID is that everybody can generate an ID that has a (very) high probability of being unique; it's not, however, guaranteed to be unique. cheers, Remko -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] XEP-0045: requesting a unique room name
This seems to be a good reason to keep things as they work :). Pavel On Thu, 14 Aug 2008 15:21:22 +0200 Jonathan Schleifer [EMAIL PROTECTED] wrote: Am 14.08.2008 um 15:12 schrieb Kevin Smith: Well, in this case what I imagined was a server that's happy to host short-lived one-to-one-to-many-to-many chats at randomly selected room names, but doesn't want to be hosting public chat rooms such as [EMAIL PROTECTED], but it's probably unimportant. This is exactly what I also had in mind and is very desirable IMO. Anyway, why change it? It doesn't make it too much more complicated for the server and there are already clients using that. So why remove something that is already in use? -- Jonathan -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] LAST CALL: XEP-0231 (Bits of Binary)
On Thu, 14 Aug 2008 11:18:23 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Zenon Kuder jr. wrote: Dne Thursday 14 of August 2008 17:00:37 Pavel Simerda napsal(a): On Thu, 14 Aug 2008 15:40:14 +0200 Zenon Kuder jr. [EMAIL PROTECTED] wrote: Hi again, I came up with some more comments :-) From introductory text of section 2.1: [...] If the data is not cached, the recipient would then retrieve the data by sending an IQ-get to the sender (or potentially some other entity) [...] I think the potential other entity might be an interesting use case as well. As stated in my previous mail, I think about the emoticons use case. This time for example in a MUC room: -participant A sends an xhtml-im message to muc room containg the img element to reference an emoticon - participant B, C, D, E and F receive the message and since they don't have the referenced image, they want to retrieve it. - there exists a protocol to reference external resources, which these entities use to download the referenced data Maybe some example flows would help. Is this a comment to the current specs with some changes needed or just another use case? It's just an use case which came into my mind, which the current spec doesn't cover, but does mention it might be covered in the future. That's why I wanted to make sure it will be possible to add in the future. Sorry for the confusion. Right, I didn't want to disallow that kind of usage in the future. Advantages: - the sender isn't bloated by multiple requests for the file Who's contacted then? The potential other entity, possibly trusted service which user is not afraid to leak jabberID to. Right. - receiver doesn't leak its jabber id to arbitrary room occupant This is usually possible to achieve in MUC communications. Indeed. But if participant B wanted to request data from participant A, he would have to send an IQ, which would reveal his Jabber ID to user A. I don't remember how IQ queries and MUC work together (will have to learn more about MUC). - receiver can have enabled downloads only from trusted jabber ID This is always possible, isn't it? Yop, but to make it effective you need a way for [EMAIL PROTECTED] to reference an image at differenet JID (e.g. emoticonService.barserver.org). I don't think this is disallowed by the spec. But the syntax is not defined. (its servers emoticon service etc) Disadvantages: - I actually can't see what's better in this approach than in sending ordinary HTTP URL, but I thought it was worth discussing. Maybe advantage for clients with only one TCP connection possible (bombus)? HTTP reveals IP address. And the second TCP connection and protocol implementation servers as another example. Yes, that's my concern. But since the idea is mainly about enabling auto-download only from trusted emoticon services I neglected this issue. OK. Peter -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
On Thu, 14 Aug 2008 11:27:22 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: On Wed, 13 Aug 2008 08:18:43 -0500 XMPP Extensions Editor [EMAIL PROTECTED] wrote: http://www.xmpp.org/extensions/inbox/direct-invitations.html Hmm, good idea, this simple direct invitation protocol, it makes sense to send invitation to the people I invite. Well that's what we had in the old days (jabber:x:conference), but then we made something fancier in XEP-0045. Fancier isn't always better. Just a sidenote, couldn't venue be replaced with something more specific and well known in the XMPP community (e.g. conference). It might also come first in the example, as it's the only important (and REQUIRED) element. Sure, conference is fine with me. Also, more about authorization and relation to other XEPs would be nice. Passwords are IMO not a good *default* authorization technique for MUC rooms. I agree. But that's something we should define in XEP-0045 -- or even deprecate password-only rooms in favor of members-only rooms. It seems MUC authorization was removed from [xep 0235]. Isn't now the time to find a better place for it? Maybe. I'm not sure how useful MUC authorization is. A members-only room is an authorized MUC room - the list of members becomes the list of authorized entities. But then what is an invitation for? You have to make someone a member and send him an invitation message. But for this, you have to be able to add members. This needs a deep poke into the MUC and I didn't post yet other stuff I promised. /psa -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
On Wed, 13 Aug 2008 08:18:43 -0500 XMPP Extensions Editor [EMAIL PROTECTED] wrote: http://www.xmpp.org/extensions/inbox/direct-invitations.html Hmm, good idea, this simple direct invitation protocol, it makes sense to send invitation to the people I invite. Just a sidenote, couldn't venue be replaced with something more specific and well known in the XMPP community (e.g. conference). It might also come first in the example, as it's the only important (and REQUIRED) element. Also, more about authorization and relation to other XEPs would be nice. Passwords are IMO not a good *default* authorization technique for MUC rooms. It seems MUC authorization was removed from [xep 0235]. Isn't now the time to find a better place for it? Pavel -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] XEP-0045: requesting a unique room name
Hello, maybe you could use a hash function (or unique identifier) that has lower probability of random conflicts than the probability of random RAM errors :). Just joking, with computers, you can be never sure, so almost sure is usually good enough if it's just a matter of trying it again. (Btw, in my father's work, SAP got down because it sent the time 24:00 to the database :D, it happens rarely but happens.) I believe http://tools.ietf.org/html/rfc4122 is one of the possible ways to go :). Pavel On Wed, 13 Aug 2008 16:30:38 +0200 Remko Tronçon [EMAIL PROTECTED] wrote: How hard is it to generate a UUID or SHA hash? I suppose not all clients have access to such utilities... It's not generating the hash that was bothering me at the time, it was more that the hash is not unique in theory, and that you would still need to have conflict checking code in case it wasn't. But I guess the likelihood of that happening is immensely close to zero, and if you have a timestamp in there, it would be even closer to zero happening twice in a row (i.e. the Why didn't this work? I must have done something wrong, let me try again). So I suppose I should learn to live with imperfection ;-) cheers, Remko -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] comments on section 8.3, draft-saintandre-rfc3920bis-06.html
On Tue, 12 Aug 2008 00:31:00 -0700 Justin Karneges [EMAIL PROTECTED] wrote: On Monday 11 August 2008 14:04:22 Pavel Simerda wrote: On Mon, 11 Aug 2008 13:45:08 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Server DOM grovelling to look for the right extension? That doesn't sound very appealing to server developers. What about: A: presence type='meeting-request'/ I'm pretty sure any server developer who doesn't want to process the XML inside a presence stanza would also be against adding new presence types. I think if any extending goes on, it would have to be through child elements of the stanza. I believe if the type is really different from the usual availability (which the temporary availability is), we should not stick with the current set of presence types only because it has been like that for a long time. The flow of your protocol is good, though. Thanks. Current implementations would send it to the client (if not instructed to block everything) or no? It's hard to say what current servers would do. Presence stanzas are treated specially in servers, much more than message/iq which are usually just relayed as-is. It wouldn't surprise me if sending new/invalid presence types would cause the receiving server to drop the stanza. Still better than confusion with subscribe. We need two new XEPs: Temporary Presence Exchange (for exchanging caps/resource information with unknown/invisible entities), What more does that involve on top of directed presence containing caps? and Presence-based Privacy (which is TPE-aware). I feel a lot of hoops here. How about a way to send a presence subscription request but indicate that it's intended to be only temporary? presence type='subscribe' temporary/ /presence That'll get through without all sorts of server upgrades etc. That will, without a server upgrade be regarded as a subscription request by the server, which is not a good backwards-compatible scheme either. Or maybe it is a fine backwards-compatible scheme? Clients/servers unaware of temporary subscriptions would at least be able to set up a normal subscription. Which is IMO bad and confusing when you only want temporary presence session. This might even lead to the situation that people are angry because you want subscription and you aren't supposted to. What more, clients can do nothing to prevent it. If you want to extend something, it would be better if it's not subscriptions. We have enough problems with subscriptions without that. (They sometimes don't work as expected and servers sometimes store different subscription states for the same user relation.) Pavel -Justin -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] comments on section 8.3, draft-saintandre-rfc3920bis-06.html
On Mon, 11 Aug 2008 13:45:08 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Justin Karneges wrote: On Tuesday 05 August 2008 08:54:22 Pavel Simerda wrote: On Mon, 04 Aug 2008 16:59:50 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Right. Or XEP-0191. Effectively Google Talk (and other similar services) deploy a rule of forbid communications with people not on my roster on the user's behalf -- no need for fancy privacy rules managed by the user. But this also disallows chatting with people outside your roster, which is something I often do. I'm for any way that doesn't leak presence but allows chat sessions (or single messages)... without giving any presence info. It's nice to be able to decide about the non-roster people blocking separately. Some people would also like to use the invisible facility, that would also be orthogonal to the roster subscriptions. (I never used invisible personally.) Sorry if I'm just repeating the obvious. I've suggested using directed presence (which need not contain the same information as broadcasted presence, if any) for this. A related discussion is that we wanted a way to trade caps and resource information between unsubscribed/invisible contacts. Robert suggested sending directed presence with caps and a special field to indicate you want to trade capabilities and reveal each others' resource name. E.g.: presence from='contactA/Resource' to='contactB' tradewithme/ c ... // caps /presence I believe most clients drop unsolicited presence on the floor. What we'd need is for clients to notice the tradewithme element on these stanzas as a request to trade presence temporarily with the sender, but not necessarily form a subscription. So your client might say, User 'contactA' wishes to engage in communication with you. Is this okay? [Yes/No] If the user selects 'Yes', then your client would reply with the same kind of presence packet. Now, each party may determine disco information of the other, and they can chat, do file transfers, jingle, etc. Right. Seems good. Servers could then have a scheme where they block/bounce all communication except from contacts that have your presence. Presence is the key word here, not subscriptions, since if you login invisible you'd still want the bouncing effect on subscribed contacts that you've not revealed yourself to. I think presence is the most natural privacy control mechanism. More natural than presence subscriptions or the roster? I think so. There's just one problem, and this was brought up at the summit: if both parties forbid communication with people not in the roster (or, more appropriately, forbid communication with people who don't have their presence), then it would not be possible to trade directed presence. Oops! If this were implemented using privacy lists, your client could automatically update the default don't talk with strangers privacy list when you do presence sharing. But we'd still need a way to bootstrap. Hmm. Yep, you might use an external component for these 'rendez-vous' situations in cases where the privacy is too strict to allow one-to-one meeting bootstrap. IMO, for this to work we need to define some server exceptions. For example, GTalk will let presence type='subscribe' packets through. We'd want to take this a step further and let through any presence packet containing a tradewithme element. Server DOM grovelling to look for the right extension? That doesn't sound very appealing to server developers. What about: A: presence type='meeting-request'/ (A is waiting for B to join him, B may respond quickly, after a long time or never) B: presence type='meeting' show.../show status.../status /presence presence type='meeting-request'/ (B now looks meeting/some_status to A) A: presence type='meeting' show.../show status.../status /presence (A and B look now meeting/some_status to each other) A: message/ B: message/ A: iq/ ... ... (they did what they wanted) A: presence type='unavailable'/ B: presence type='unavailable'/ (meeting is over) Current implementations would send it to the client (if not instructed to block everything) or no? Future conforming implementations may choose to only allow only presence type=meeting-request/ or both presence type=meeting-request/ presence type=subscribe/ Is it a problem to provide a new presence type in a XEP and eventually sometime added to the RFC? We need two new XEPs: Temporary Presence Exchange (for exchanging caps/resource information with unknown/invisible entities), What more does that involve on top of directed presence containing caps? and Presence-based Privacy (which is TPE-aware). I feel a lot of hoops here. How about a way to send a presence subscription request but indicate that it's intended
Re: [Standards] UPDATED: XEP-0231 (Bits of Binary)
On Thu, 07 Aug 2008 20:39:19 -0500 XMPP Extensions Editor [EMAIL PROTECTED] wrote: Version 0.8 of XEP-0231 (Bits of Binary) has been released. Abstract: This specification defines an XMPP protocol extension for including or referring to small bits of binary data in an XML stanza. Changelog: Added section on determining support. (psa/ps) Diff: http://is.gd/1j1T URL: http://www.xmpp.org/extensions/xep-0231.html That's it :). -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] UPDATED: XEP-0231 (Bits of Binary)
On Fri, 08 Aug 2008 08:36:12 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: URL: http://www.xmpp.org/extensions/xep-0231.html That's it :). Super. So now I think we need to issue a second Last Call on XEP-0231, XEP-0221, and XEP-0158, because they have changed quite a bit since the previous Last Call. And I think now XEP-0231 and XEP-0221 will be more palatable to Council member Ralph Meijer, who did not like the inclusion of binary data in x:data forms. /psa Btw, I had to lookup 'palatable in a dictionary :). If he'll be more content with it, it's only good, it's a pity I didn't see any of his comments or concerns. Pavel -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] XEP-0071 v. 1.4pre1
None forbids their implementation, but do you think every client should implement them? Pavel On Wed, 6 Aug 2008 18:18:19 -0600 Joe Hildebrand [EMAIL PROTECTED] wrote: Implementation experience has shown that table and friends is strongly demanded by users, mostly because of copy/paste from Excel. I think we should consider their inclusion in the future, if we're going to open XEP-71 back up. On Aug 6, 2008, at 10:24 AM, Peter Saint-Andre wrote: In accordance with recent list discussion, I have provisionally modified XEP-0071 (XHTML-IM). Rendered text: http://www.xmpp.org/extensions/tmp/xep-0071-1.4.html Changelog: Encouraged support for several more structural elements from the text module (blockquote, cite, em, and strong); further clarified security considerations regarding fetching and presentation of images; modified several examples; clarified several points throughout the text. SVN diff: http://is.gd/1h2G /psa -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] About the messaging use-case of XEP-0231
On Thu, 7 Aug 2008 14:29:32 +0200 (CEST) Marcus Lundblad [EMAIL PROTECTED] wrote: Hi. I saw that the use-cases of XEP-0231 has been removed along with the service discovery features. I believe we just lost the service discovery on the way. But it will be the same case as with XHTML-IM where the discovery is not mandatory. (E.g. you can't discover if you don't have a presence, it maybe stored offine and you don't know the client features yet.) I'm for putting the feature back if Peter agrees and for making the discovery optional. Is the intention that this particular use-case will become a part of XEP-0071? I found the service discovery feature for using in-band images to be useful. This way we can send an emoticon as its shortcut in the case when the receiver can't handle BoB, instead of including an img/ with a cid: URI. I also just realized that the alt attribute has been removed from the data/ tag. This makes perfect sense to me :) I just need to make some changes in my code... +1 //Marcus -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] About the messaging use-case of XEP-0231
On Thu, 07 Aug 2008 10:15:16 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: On Thu, 7 Aug 2008 14:29:32 +0200 (CEST) Marcus Lundblad [EMAIL PROTECTED] wrote: Hi. I saw that the use-cases of XEP-0231 has been removed along with the service discovery features. I believe we just lost the service discovery on the way. But it will be the same case as with XHTML-IM where the discovery is not mandatory. (E.g. you can't discover if you don't have a presence, it maybe stored offine and you don't know the client features yet.) I'm for putting the feature back if Peter agrees and for making the discovery optional. I think the service discovery features are best defined in the specs that use BoB, such as XHTML-IM and file transfer, which is why I removed them from XEP-0231. Ok, I didn't notice this change was intentional. What about a short informational section when there's time for it? Is the intention that this particular use-case will become a part of XEP-0071? I found the service discovery feature for using in-band images to be useful. This way we can send an emoticon as its shortcut in the case when the receiver can't handle BoB, instead of including an img/ with a cid: URI. I also just realized that the alt attribute has been removed from the data/ tag. This makes perfect sense to me :) I just need to make some changes in my code... +1 Yes, we figured out that we don't need 'alt' for data/ because the description will be handled by img/ (in XHTML-IM) or whatever other protocol uses BoB. /psa -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] About the messaging use-case of XEP-0231
On Thu, 07 Aug 2008 14:52:23 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: On Thu, 07 Aug 2008 10:15:16 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: On Thu, 7 Aug 2008 14:29:32 +0200 (CEST) Marcus Lundblad [EMAIL PROTECTED] wrote: Hi. I saw that the use-cases of XEP-0231 has been removed along with the service discovery features. I believe we just lost the service discovery on the way. But it will be the same case as with XHTML-IM where the discovery is not mandatory. (E.g. you can't discover if you don't have a presence, it maybe stored offine and you don't know the client features yet.) I'm for putting the feature back if Peter agrees and for making the discovery optional. I think the service discovery features are best defined in the specs that use BoB, such as XHTML-IM and file transfer, which is why I removed them from XEP-0231. Ok, I didn't notice this change was intentional. What about a short informational section when there's time for it? Hmm. Do we really need those special service-discovery features? Perhaps all we need now is some text that says don't include [only] cid: URIs unless the recipient supports BoB. The reason we had the disco features is that we didn't want to spam people with in-band binary unless they said that was OK, but now we're pretty much forcing you to send the cid: URI and then the recipient can decide if they want to retrieve the binary. /psa That's what your original Service-Discovery section was about, no? As this is easier, I'm for allowing clients to handle URIs uniformly. And for announcing support for BoB in one Discovery Feature. This means you would just add back the Disco section :). Other suggestions from anyone? Pavel -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] UPDATED: XEP-0231 (Data Element)
On Tue, 05 Aug 2008 23:28:16 -0500 XMPP Extensions Editor [EMAIL PROTECTED] wrote: Version 0.4 of XEP-0231 (Data Element) has been released. Abstract: This specification defines an XMPP protocol extension for including small bits of binary data in an XML stanza. Changelog: Generalized text regarding inclusion of parameters in type attribute per RFC 2045; added max-age attribute, matching semantics from RFC 2965; added section on caching of data; more clearly specified generation of Content-ID. (psa) Diff: http://is.gd/1gmU Good Job. Thanks for including me in the acknowledgements. May I have still some comments to the letter of the XEP? * 3. Caching of Data As a hint regarding the suggested period for caching the data, the sending party SHOULD include a 'max-age' attribute whenever it sends a non-empty data/ element. The semantics of the 'max-age' attribute exactly matches that of the Max-Age attribute from RFC 2965. Wasn't the max-age element meant to be optional (the missing one interpreted as session-wide)? Also in the Defined Attributes table. * 4. Use Cases Are the use cases intended to standardize the particular use of Data Element. Example 2. A message with included data ... Once the data is provided, a subsequent message in the same session can refer to the data again without including the data itself. Example 3. A message with referenced data Example 3 could be made a primary example (without data/ element) and Example 2 might just show the possibility to include the data if desired and therefore follow the current Example 3. * Example 4. Audio Media Element Generally, the empty data/ should be IMO used for an occasional empty file. I know there's not many use-cases for sending empty files... but it might occasionally happen when one send several files and some of them just happen to be empty. I think we're unnecessarily changing the meaning, here. ... uri type='audio/mpeg' http://victim.example.com/challenges/speech.mp3?F3A6292C /uri data xmlns='urn:xmpp:tmp:data-element' alt='An audio file' type='audio/ogg; codecs=speex'/ /data ... Could be changed to: ... uri type='audio/mpeg' http://victim.example.com/challenges/speech.mp3?F3A6292C /uri uri type='audio/ogg; codecs=speex'/ cid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@shakespeare.lit /uri ... This would simplify things so that the data/ element would always belong to the top of the message/ stanza and allowing uniform handling. * Example 5. File transfer offer with preview file xmlns='http://jabber.org/protocol/si/profile/file-transfer' size='330527' name='image.png' data xmlns='urn:xmpp:tmp:data-element' alt='There be dragons!' cid='[EMAIL PROTECTED]' type='image/png' iVBORw0KGgoNSUhEUgAAADkAAABACAIvV0jbCXBIWXMAAA4mAAAOJgGi7yX8AAAc ... /data range/ /file I'm afraid the data/ element doesn't properly markup its meaning. I propose one of 1) preview cid=[EMAIL PROTECTED]/ 2) preview uri=cid:d8f904ac-636c-11dd-8a2f-001143d5d5db@montague.lit/ or similar. Furthermore, I believe this is out of the scope of this XEP and should be done in the FT one and within the FT namespace. * Position of the data/ For messages (and presence, if needed), I'd suggest to (of course OPTIONALLY) include one or more non-empty data/ elements directly in the message/ or presence/. For messages, this directly maps to the e-mail attachments and the use of CID references in e-mail messages (for single messages this could be actually showed as in e-mail programs). For IQ stanzas, where this is not possible, we can put it directly in the single child of iq/, maybe. * What's the alt attribute then for? If we don't use empty data/ elements at all (except the occasional empty files), then the 'alt' facility should be provided by the protocol that is using the URL not data/ elements themselves as it is done in HTML-IM. To have some user-readable description (e.g. for the cache management), I suggest removing 'alt' but adding e.g. 'desc' attribute for textual description. This way we avoid confusion between 'alt' in the presentation part and 'desc' in the data part. Note: similar examples are used in XEP-0221: Data Forms Media Element Pavel -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] XEP-0154: User Profile - enterprise vs. simple
On Mon, 04 Aug 2008 19:50:01 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: Hello Peter, this is just reactions to your post, I will later summarize what I have and include some examples so we can advance from theory to something real. Sounds good! On Thu, 31 Jul 2008 08:23:36 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: (citation shortened) 2) The simpler case - user publishes his xmpp-based profile Clients should be able to *set* at least the most basic information. We need PEP support, profile data structure knowledge and UI for setting the data. Just to remind... this means all information the client author implements. Note: No additional server requirements, PEP is ok for us. I would like to keep this as simple as possible, with no support from the server except PEP and client just reads/stores PEP data. Yes, I think that's a good goal. 3) The harder case - server publishes a pre-existing non-xmpp profile with its own structure on behalf of the user b) setting profile The server may or may not allow the user to set the profile data through Jabber. What's more, the server should be able to specify which fields are read-write and which read-only (or even absent in the data model). We can do this with x:data, because we can specify that some fields are *fixed*, for example: profile xmlns='urn:xmpp:tmp:profile' x xmlns='jabber:x:data' type='result' ... /x /profile You hit the point. Data forms do a good job for user interaction and forms. This is why we have them, isn't it? Moreover, as backend-based store *already requires* some complexity on the server, there is no problem in implementing it there. Some client authors, on the other hand, would not like to implement all this stuff. But there's a simple solution to that. Implement it on the server side and use what clients already can! * XEP-0050: Ad-Hoc Commands * XEP-0004: Data Forms This way we don't even need to specify the protocol. Though we may want to (I don't know) like it's done in XEP-0133: Service Administration The FORM_TYPE stuff (XEP-0068) is one way to scope the data form. Another approach is the wrapper element namespace as in User Profile. I see these as two ways of doing the same thing. But in PEP the wrapper element is more useful because PEP says that there is one node per namespace. 4) The controversy - model versus protocol In the simple case (2), we define a data model for user profiles. We also specify methods to retrieve them and publish them. Client authors design the UI. But in (3), we actually define an intermediate presentation layer so other clients understand the data and can present them in the UI. We omit or fix fields on the server-side and limit the flexibility we would otherwise offer. I don't see why the case of more complex data requires an intermediate presentation layer etc. Because we don't want to put SQL, LDAP and all other backend reperesentation into XMPP. By the word intermediate I mean the XMPP representation, because it sits between the backend (e.g. SQL) store and the client's user interface (e.g. a graphical window). Aha, ok. That makes sense. Actually it's not more complex data but more complex storage (something is in the backend store, something is in the PEP store. Many backend stores will only offer basic info and contacts. Shall we drop all other info sections and disallow any future extensions? I believe we should not! Agreed. 5) Possible solutions for profile setting I believe we agree on the need to split the user profile into several PEP nodes (groups of fields) to avoid unnecessary data flows. +1 Thanks for confirmation. We have to define fixed sets of fields (with value formats) to allow client authors to create usable viewing user interfaces. See above on field type='fixed' -- x:data helps us here. Fixed in a different meaning. Fixed sets of fields - the sections/groups of fields that are defined so that clients know what data they will get. Right. And we'll do that via namespacing the data buckets (basic, home contact data, work contact data, etc.). Exactement :). (You know Hercule Poirot, don't you?) When we start thinking about setting the profile, the controversy shows itself. a) We could require user profile setting implementation on both the client and server side and disallow PEP publishing (this is effectively what the current version does, it uses PEP syntax but requires special handling!). But this means that we cannot use User Profile without server support which is weird! We're only using PEP events but not publishing features. This also means the client implementation will be a bit more complicated than necessary for (2). The added server-side and client-side
Re: [Standards] comments on section 8.3, draft-saintandre-rfc3920bis-06.html
On Mon, 04 Aug 2008 16:59:50 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pedro Melo wrote: On Jul 22, 2008, at 2:12 AM, Ovidiu Craciun wrote: Excerpt from: http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-06.html Section: 8.3. Generation of Resource Identifiers A resource identifier can be security-critical. For example, if a malicious entity can guess a client's resource identifier then it may be able to determine if the client (and therefore the controlling principal) is online or offline, thus resulting in a presence leak as described under Section 15.13 (Presence Leaks). Traditionally, XMPP resource identifiers have been generated by clients in ways that are not secure (e.g., hardcoding the resource identifier to the name of the client or to a common location such as home or work). However, for the sake of proper security, a resource identifier SHOULD be random (see [RANDOM] (Eastlake, D., Schiller, J., and S. Crocker, “Randomness Requirements for Security,” June 2005.)). It is RECOMMENDED that the resource identifier incorporate a Universally Unique Identifier (UUID), for which the format specified in [UUID] (Leach, P., Mealling, M., and R. Salz, “A Universally Unique IDentifier (UUID) URN Namespace,” July 2005.) is RECOMMENDED. From the IMPP RFC I get that: X can read Y's presence info only (A) if Y's presence info is public domain, or (B) if Y previously allowed X to read it's presence. In this case, when a malicious entity, that can guess X's resource identifier, is be able to read X's presence only if (A) or (B) is true, in which case it is not a security threat, it is by default. What I am saying is that the presence leaks are not related with the easiness of guessing X's resource IDs but if the server is handling correctly the presence information for a given JID. I believe the above paragraph is not referring to presence leaks as a full presence stanza but just as a way for me to know if you are online or not. It might not be your full presence but it is still a leak. Yes, this is not a leak of presence/ stanzas, but it is effectively a leak of information about whether a particular resource is online. If I can guess your resource, I might trick your client into replying to an IQ or direct presence stanza. Any of those replies would mean that you are online at the moment, and therefore constitute a presence leak. Correct. Also, the requirement to have a resource identifier be random for the sake of proper security it is also a forced and unnecessary requirement. The server should guarantee the security by implementing correctly a secure protocol not by following recommendations. If you bind your sessions without a resource, the server will give you a random resource. For the server to enforce a proper security perimeter, it would have to filter (drop) IQ's directed to your JID from JIDs outside your roster. This would most likely prevent some normal (as in currently available and useful) workflows. Well, this is pretty much how Google Talk works, and it mostly functions just fine. Sometimes I chat with people that are not on my roster, including file transfer. That would be impossible with a server-side firewall. Of course, you can today implement such firewall with privacy lists, if your server supports them. Right. Or XEP-0191. Effectively Google Talk (and other similar services) deploy a rule of forbid communications with people not on my roster on the user's behalf -- no need for fancy privacy rules managed by the user. But this also disallows chatting with people outside your roster, which is something I often do. I'm for any way that doesn't leak presence but allows chat sessions (or single messages)... without giving any presence info. It's nice to be able to decide about the non-roster people blocking separately. Some people would also like to use the invisible facility, that would also be orthogonal to the roster subscriptions. (I never used invisible personally.) Sorry if I'm just repeating the obvious. Peter -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] presence priority -1 issues
On Tue, 05 Aug 2008 09:16:45 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Maciek Niedzielski wrote: Peter Saint-Andre wrote: I like the part that only client/* should be interpreted as IM-capable resources, but I don't know if that is too strict. That's probably too strict. At the least I think we'd say that the following identities are IM-capable: account/* client/* I always thought these two are independent - account/* defines... account, client/* describes particular connection. So for example, [EMAIL PROTECTED] is account/registered, [EMAIL PROTECTED]/calendar is automation/bot and [EMAIL PROTECTED]/chat is client/pc (yes, I know resources ids are supposed to be opaque, but it was easier to explain this way). IMHO you'd get account/* from a bare JID and client/* from a full JID. /psa But then account/* should never send presence, no? -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] Questions about xhtml-im
On Sat, 02 Aug 2008 21:40:49 +0200 Maciek Niedzielski [EMAIL PROTECTED] wrote: Jehan wrote: But still for most end users, the best is wysiwyg And this is why xhtml-im needs to be about formatting, not semantics: most end users want to get (and send) what they see. And they want you to see what they see. I see no point in forbidding the semantics! I personally turn off xhtml-im as I have no way to just turn off styling (it's annoying to let others configure my fonts and colors, especially if it doesn't really work). If you don't forbid semantics, I could turn off the styling and keep the seemantic part (styled to my own preferences). And... keeping the semantic markup doesn't do any harm to users that don't know about it. They'll just configure the fonts and colors, that I don't care about (and I won't see). Pavel -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] Questions about xhtml-im
On Fri, 1 Aug 2008 12:49:05 +0200 Jehan [EMAIL PROTECTED] wrote: Olivier Goffart;2116 Wrote: L It could also make use of a WIKI-like syntax Yes for my own, if really we are interested on client side text structuration, the wiki style is one of the best approach for technical users who don't like wysiwyg GUI, but still want to have full control of their structure. For my own, I find it very boring and slow to have to write xml tags em or strong for emphasing, whereas the wiki style is as powerful, but very fast to write (nearly no difference with unformated writing, and especially no special character like , , /, etc.), nice to read while still unsent, and accurate. Writing ''emphasing'' is better than writing ememphasing/em!!! And lists with * or # are so obvious, whereas ulolli boring to write and it is easy to make a mistake of unclosed tags. But still for most end users, the best is wysiwyg (they are not willing to learn formatting rules, even as obvious as wiki ones), so they don't care whether it is wiki or html under the skull. Therefore I guess xhtml is a good choice for the finale formatting inside the XMPP stream, because it is XML as XMPP, and wiki-style could be used client-side as an implementation choice (which would then be transformed into xhtml before sent). Wiki syntax can be easily converted to html by the client. That's an implementation issue that would at best reached Best Practice status. I'd be willing to relax our usage of the Text Module so that we encourage more structural markup. As far as I can see, the following elements would be most useful: blockquote cite em q strong yes. In some applications I could also see an argument for: abbr acronym code dfn h1 through h6 kbd pre Those are not forbidden in XHTML-IM right now, just not encouraged. But we could change that if we think it's a good idea. I'd say that code or pre is important too. and the ul/ol/li/ are quite usefull too. Also make the style attribute not REQUIRED, because it's probably the most complicated thing to implement. And the title attribute is interesting too on abbr/ and stuff, so OPTIONAL would be better. -- Olivier As for I, if I stay in the optics of pure IM (i.e. when you chat fast with people), I think the most interesting of them all are em, strong, blockquote (cite is not so useful, because when I cite stuffs mixed in my own sayings, in the context of IM, I would simply use quotes , This is a bit of personal preference. whereas blockquotes is very useful when you get a big text separated); then nice but less important are lists (ulolli) and links (a). List may be very good for multiline messages. Links are important, they should not be IMO automatic in HTML. code is nice also but for technical people mostly (and even for technical stuffs, if I had no access to code, I would use blockquote instead, so this is not so primordial). And if we get structure in a more general way (for notification, not only IM chatting), I would add all the title (h[1-6]) tags, and then I would add cite here. These are the main tags, at least as far as I am concerned. Jehan I personally am for structure as I would be the first one to turn off styling. Now I have to turn of the whole xhtml-im stuff. Pavel -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] XEP-0154: User Profile - enterprise vs. simple
Hello Peter, this is just reactions to your post, I will later summarize what I have and include some examples so we can advance from theory to something real. On Thu, 31 Jul 2008 08:23:36 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: (citation shortened) 2) The simpler case - user publishes his xmpp-based profile Clients should be able to *set* at least the most basic information. We need PEP support, profile data structure knowledge and UI for setting the data. Just to remind... this means all information the client author implements. Note: No additional server requirements, PEP is ok for us. I would like to keep this as simple as possible, with no support from the server except PEP and client just reads/stores PEP data. 3) The harder case - server publishes a pre-existing non-xmpp profile with its own structure on behalf of the user b) setting profile The server may or may not allow the user to set the profile data through Jabber. What's more, the server should be able to specify which fields are read-write and which read-only (or even absent in the data model). We can do this with x:data, because we can specify that some fields are *fixed*, for example: profile xmlns='urn:xmpp:tmp:profile' x xmlns='jabber:x:data' type='result' ... /x /profile You hit the point. Data forms do a good job for user interaction and forms. This is why we have them, isn't it? Moreover, as backend-based store *already requires* some complexity on the server, there is no problem in implementing it there. Some client authors, on the other hand, would not like to implement all this stuff. But there's a simple solution to that. Implement it on the server side and use what clients already can! * XEP-0050: Ad-Hoc Commands * XEP-0004: Data Forms This way we don't even need to specify the protocol. Though we may want to (I don't know) like it's done in XEP-0133: Service Administration 4) The controversy - model versus protocol In the simple case (2), we define a data model for user profiles. We also specify methods to retrieve them and publish them. Client authors design the UI. But in (3), we actually define an intermediate presentation layer so other clients understand the data and can present them in the UI. We omit or fix fields on the server-side and limit the flexibility we would otherwise offer. I don't see why the case of more complex data requires an intermediate presentation layer etc. Because we don't want to put SQL, LDAP and all other backend reperesentation into XMPP. By the word intermediate I mean the XMPP representation, because it sits between the backend (e.g. SQL) store and the client's user interface (e.g. a graphical window). Actually it's not more complex data but more complex storage (something is in the backend store, something is in the PEP store. Many backend stores will only offer basic info and contacts. Shall we drop all other info sections and disallow any future extensions? I believe we should not! Agreed. 5) Possible solutions for profile setting I believe we agree on the need to split the user profile into several PEP nodes (groups of fields) to avoid unnecessary data flows. +1 Thanks for confirmation. We have to define fixed sets of fields (with value formats) to allow client authors to create usable viewing user interfaces. See above on field type='fixed' -- x:data helps us here. Fixed in a different meaning. Fixed sets of fields - the sections/groups of fields that are defined so that clients know what data they will get. When we start thinking about setting the profile, the controversy shows itself. a) We could require user profile setting implementation on both the client and server side and disallow PEP publishing (this is effectively what the current version does, it uses PEP syntax but requires special handling!). But this means that we cannot use User Profile without server support which is weird! We're only using PEP events but not publishing features. This also means the client implementation will be a bit more complicated than necessary for (2). The added server-side and client-side complexity may extend the vcard-temp's usage and defer real-world implementation of XEP-0154. I think an application can specify some fields as fixed and ignore any changes generated by the client. But then the PEP service needs to be a bit specialized because it's not just publishing payloads but inspecting the XML of the payload to see if it matches some business rules. I don't think we should misuse PEP syntax for things it cannot do itself. That's why I don't like (a). I included it for completeness. b) As the setting method for the backend-based profiles is totally different, it follows we could just ignore it and leave it to a different protocol/extension. No required server support (except for backend-based
Re: [Standards] XEP-0231 (Data Element) - local caching
On Thu, 31 Jul 2008 08:07:04 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: On Wed, 30 Jul 2008 07:04:16 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: On Tue, 29 Jul 2008 19:49:01 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Ahoj Pavle! Pavel Simerda wrote: Hello, I have some suggestions for XEP-0231 (Data Element). Thanks for looking at this spec so thoroughly. I actually have some questions. First, lolek from the jabbim.cz project is going to propose a XEP for text emoticons. Similar to XEP-0038? We can bring that back if someone wants to maintain it. Similar but more powerful and not file-based but most probably based on Data Elements. There may be a lot of other extensive changes. If these changes can be made, I believe Martin would maintain it if he gets the chance. OK, great. I'm happy to help. Thanks, I'll invite him to jdev conference sometime next week. I like his ideas but I suggested him to use Data Element instead of a custom solution. +1 He still has doubts but I promised him to try to sort it out and to help him with language corrections of his document too. Great, thanks. I didn't find in the specs what should be used for domain ID in the CID. The examples apparently use the domain part of JID that is not unique for the clients. I looked at the RFC and still don't know a proper mapping to XMPP. His original idea was to use a cryptographic hash function and not a CID. I think your idea of a UUID followed by the domain part of the JID would work well. He also pointed out he misses a feature that would allow a client to advertise which mimetypes it supports. Yes we can add a disco feature for that. This is another questions... if it's just emoticons, should we just support png and mng types or add some accept-advertisement facility? I don't think it hurts to define a way to advertise what MIME types you support. We'll use the data element for things other than emoticons, but IMHO the simplest approach would be to advertise in general which MIME types you support, not I support these mime types for emoticons and I support these other mime types for file transfer thumbnails etc. Does anyone think that level of complexity is needed? I'm not sure. Let's wait for other comments. Well I'm not a fan of adding complexity if we don't need it. Agreed. Is there a written policy for image formats in XMPP extensions? Not yet. PNG for static raster images, MNG for animated raster images, SVG for vector images? That's something I would expect from every client. Sure. But some people think JPG and GIF are good too (e.g., I think JPG is the default in vCards or LDAP or somesuch). Yep, JPG is good for photos, I have forgotten because I was still thinking about the emoticons. GIF is good for nothing when we have static PNG and animated MNG that not only supersede it in all areas but also make a distinction between static and animated, which is good. (Just my opinion, others may or may not agree.) Let's move this out of discussion about XEP-0231... and discuss the image (and other) formats policy separately if needed. Right now, as the example shows: message from='[EMAIL PROTECTED]/castle' to='[EMAIL PROTECTED]' type='groupchat' bodyYet here's a spot./body html xmlns='http://jabber.org/protocol/xhtml-im' body xmlns='http://www.w3.org/1999/xhtml' p Yet here's a spot. img alt='A spot' src='cid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@shakespeare.lit'/ /p /body /html data xmlns='urn:xmpp:tmp:data-element' alt='A spot' cid='[EMAIL PROTECTED]' type='image/png' iVBORw0KGgoNSUhEUgoKCAYAAACNMs+9BGdBTUEAALGP C/xhBQlwSFlzAAALEwAACxMBAJqcGAd0SU1FB9YGARc5KB0XV+IA AAAddEVYdENvbW1lbnQAQ3JlYXRlZCB3aXRoIFRoZSBHSU1Q72QlbgAAAF1J REFUGNO9zL0NglAAxPEfdLTs4BZM4DIO4C7OwQg2JoQ9LE1exdlYvBBeZ7jq ch9//q1uH4TLzw4d6+ErXMMcXuHWxId3KOETnnXXV6MJpcq2MLaI97CER3N0 vr4MkhoXe0rZigBJRU5ErkJggg== /data /message Note: in this particular example the data is very short, this may not be the case in real world where people tend to ignore the size of data they send. Yes, that's just about the smallest image I could find. The spec says that the image should not be more than 8k (which is twice the suggested size of an IBB chunk) but we don't know if people will typically send images that are smaller or larger than 8k -- I think smaller but I don't know that yet. Might it be advertised by the client/server? And rejected if the other party tries to send a bigger one (just to force them to fix it)? I think that's handled at a different layer (e.g., rate limiting). But we do need to define better handling for stanzas that are too
Re: [Standards] presence priority -1 issues
On Thu, 31 Jul 2008 20:47:25 +0100 Dave Cridland [EMAIL PROTECTED] wrote: On Thu Jul 31 17:54:32 2008, Pedro Melo wrote: On Jul 31, 2008, at 5:21 PM, Dave Cridland wrote: On Thu Jul 31 17:17:40 2008, Pedro Melo wrote: Moving forward, this would allow clever clients to observe that it wasn't a IM client capable of handling calendaring requests, but a dumb calendaring bot working on behalf of the user. Not following. Clients could have an integrated calendaring app, allowing both chat and calendaring traffic to happen to the same full jid. Alternately, it may only do one or the other. Yes, but then you would only need to publish the proper feature. What makes a automated system try a certain protocol is the feature, not the identity. The identity automation/calender (per Peter example) is only needed to mark a resource as a non-IM resource. Right, except in the case of IM, features are advertised. But to advertise a lack of IM, we need to change the identity, since we don't have an IM feature. Of course, it'd really be automation/application, or automation/daemon, since what kinds of protocols it's an automaton for is, as you say, down to the features advertised. Protocols/features and the purpose of the application may be different. IMHO it depends on how much you want to distinguish. So a clever Calendar application that also allows chat would probably still announce itself with a client/pc but would also set feature to support cal-dav-over-xmpp, or whatever. Of course - but I'm somewhat against a negative feature, if there's any alternative. +1 Dave. Pavel -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] presence priority -1 use case
Hello, folks at jabbim.cz are working on a service for a single-contact webchat (visitors of your website may chat with you in a simple UI). There are various issues with the implementation on XMPP. Especially the JID of the web user. 1) It could be [EMAIL PROTECTED] The problem is with presence, as this JID is not subscribed. 2) Otherwise [EMAIL PROTECTED]/[nick] (I was told [service]/[nick] is not handled well by some clients, I can ask for more info if needed) Then they would use negative priority to prevent the user from sending messages to a different nick than he wants. This component actually mimics a chat client intended for recieving messages but priority -1 serves well. Pavel -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] Questions about xhtml-im
On Wed, 30 Jul 2008 13:04:33 +0200 Jehan [EMAIL PROTECTED] wrote: Peter Saint-Andre;1984 Wrote: Please quote the entire section: *** A user agent that implements this specification MUST conform to Section 3.5 (XHTML Family User Agent Conformance) of Modularization of XHTML. Many of the requirements defined therein are already met by Jabber clients simply because they already include XML parsers. However, ignore has a special meaning in XHTML modularization (different from its meaning in XMPP). Specifically, criteria 4 through 6 of Section 3.5 of Modularization of XHTML state: 4. W3C TEXT: If a user agent encounters an element it does not recognize, it must continue to process the children of that element. If the content is text, the text must be presented to the user. XSF COMMENT: This behavior is different from that defined by XMPP Core, and in the context of XHTML-IM implementations applies only to XML elements qualified by the 'http://www.w3.org/1999/xhtml' namespace as defined herein. This criterion MUST be applied to all XHTML 1.0 elements except those explicitly included in XHTML-IM as described in the XHTML-IM Integration Set and Recommended Profile sections of this document. Therefore, an XHTML-IM implementation MUST process all XHTML 1.0 child elements of the XHTML-IM html/ element even if such child elements are not included in the XHTML 1.0 Integration Set defined herein, and MUST present to the recipient the XML character data contained in such child elements. *** What I understand is that when I encounter a tag which I recognize as being xhtml, but which is not in the xhtml-im subset, then I must display it as is? Let's say you receive this: htmlbodypI like the Extensible Messaging and Presence Protocol (abbrXMPP/abbr)./p/body/html In this case you would display the XML character data of the abbr/ element even though it's not part of the XHTML-IM integration set. That's just one example. /psa Sorry I did not understand (or at least as much as the original). So when you write to display the XML character data, you mean that you just dump the tag element, and display its content (XMPP) ? So you display this: I like the Extensible Messaging and Presence Protocol (XMPP) This would look natural to me (and I think to have understood this is also how the W3C recommends it for the core xhtml . Or do you mean that you display the unknown (in xhtml-im subset) tag element itself to the simple user view, so this: I like the Extensible Messaging and Presence Protocol (abbrXMPP/abbr) So one will see unprocessed tag (and if the user does not know what is xhtml, it would look like strange unknown words)... I am sorry if I don't understand this... That's probably about word definition here where I am not sure about what you call the XML character data of an element: 1/ character data in XML being the normal text between the tag elements; That's it. 2/ or character data as a graphical character/pictogram in an alphabet (what we call a character set in computer science)? Thanks. Jehan P.S.: for the rest of my questions, thanks for the answers. I guess I shall read and try and understand the concept of modularization of xhtml, as you suggest. :-) Anyway for the part about semantic/structure versus style/display, probably there can be discussions about this (and you already had apparently), but even though I am completely partisan of structure, I understood well the two points here which are that this XEP is for IM, and that normal users cannot be asked to think about structure when they just care about style. Yet just to answer shortly about this point: The style should come from the meaning of the tag, like in the web! How so? Remember that we don't have external CSS here. In case where structure would have been chosen above style (even though, as I remind, I understand now why style is chosen in IM), there may be a small CSS just for the few available tags in xhtml-im on client side (then a user could even modify their personal CSS). I cannot talk for XHTML-IM as it's the first thing I turn off. But I generally like the idea of using em and strong and similar for structural markup even in instant messaging. It's markup vs. styling. I particularly dislike any styling... as this will be often misused to put bright colors or fancy fonts into the chatrooms which is annoying and... If you see it... it's bad. If you don't, you can't kick the people for huge font sizes, big fancy pictures. For me xhtml-im is just a headache. But... if I could disable the styling and use it for murkup like emphasizing, links or even structuring short documents (e.g. for single messages), I might be even using it (at least passively). So... I perfectly understand your point but it seems to be
Re: [Standards] XEP-0231 (Data Element) - local caching
On Wed, 30 Jul 2008 07:04:16 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: On Tue, 29 Jul 2008 19:49:01 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Ahoj Pavle! Pavel Simerda wrote: Hello, I have some suggestions for XEP-0231 (Data Element). Thanks for looking at this spec so thoroughly. I actually have some questions. First, lolek from the jabbim.cz project is going to propose a XEP for text emoticons. Similar to XEP-0038? We can bring that back if someone wants to maintain it. Similar but more powerful and not file-based but most probably based on Data Elements. There may be a lot of other extensive changes. If these changes can be made, I believe Martin would maintain it if he gets the chance. I like his ideas but I suggested him to use Data Element instead of a custom solution. +1 He still has doubts but I promised him to try to sort it out and to help him with language corrections of his document too. Great, thanks. I didn't find in the specs what should be used for domain ID in the CID. The examples apparently use the domain part of JID that is not unique for the clients. I looked at the RFC and still don't know a proper mapping to XMPP. His original idea was to use a cryptographic hash function and not a CID. I think your idea of a UUID followed by the domain part of the JID would work well. He also pointed out he misses a feature that would allow a client to advertise which mimetypes it supports. Yes we can add a disco feature for that. This is another questions... if it's just emoticons, should we just support png and mng types or add some accept-advertisement facility? I don't think it hurts to define a way to advertise what MIME types you support. We'll use the data element for things other than emoticons, but IMHO the simplest approach would be to advertise in general which MIME types you support, not I support these mime types for emoticons and I support these other mime types for file transfer thumbnails etc. Does anyone think that level of complexity is needed? I'm not sure. Let's wait for other comments. Is there a written policy for image formats in XMPP extensions? Not yet. PNG for static raster images, MNG for animated raster images, SVG for vector images? That's something I would expect from every client. Right now, as the example shows: message from='[EMAIL PROTECTED]/castle' to='[EMAIL PROTECTED]' type='groupchat' bodyYet here's a spot./body html xmlns='http://jabber.org/protocol/xhtml-im' body xmlns='http://www.w3.org/1999/xhtml' p Yet here's a spot. img alt='A spot' src='cid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@shakespeare.lit'/ /p /body /html data xmlns='urn:xmpp:tmp:data-element' alt='A spot' cid='[EMAIL PROTECTED]' type='image/png' iVBORw0KGgoNSUhEUgoKCAYAAACNMs+9BGdBTUEAALGP C/xhBQlwSFlzAAALEwAACxMBAJqcGAd0SU1FB9YGARc5KB0XV+IA AAAddEVYdENvbW1lbnQAQ3JlYXRlZCB3aXRoIFRoZSBHSU1Q72QlbgAAAF1J REFUGNO9zL0NglAAxPEfdLTs4BZM4DIO4C7OwQg2JoQ9LE1exdlYvBBeZ7jq ch9//q1uH4TLzw4d6+ErXMMcXuHWxId3KOETnnXXV6MJpcq2MLaI97CER3N0 vr4MkhoXe0rZigBJRU5ErkJggg== /data /message Note: in this particular example the data is very short, this may not be the case in real world where people tend to ignore the size of data they send. Yes, that's just about the smallest image I could find. The spec says that the image should not be more than 8k (which is twice the suggested size of an IBB chunk) but we don't know if people will typically send images that are smaller or larger than 8k -- I think smaller but I don't know that yet. Might it be advertised by the client/server? And rejected if the other party tries to send a bigger one (just to force them to fix it)? I think that's handled at a different layer (e.g., rate limiting). But we do need to define better handling for stanzas that are too large (there is a proto-XEP about it but the Council didn't accept it and I never incorporated their feedback). Hmm. I know that people at jabbim.cz use a roster-renaming utility (for icq transport). They wait a long time between stanzas and the renaming can often takes more than just several minutes. We send data once for every session (and omit for subsequent messages). In this case it's important to define session (see rfc321bis). Is it a chat session, a presence session, or something else? Exactly. This has two important implications: 1) The other entity may or may not cache it for the session and reuse it. That is good. 2) If an entity keeps the data for a longer time (e.g. for weeks or even permanently), this cache will never be used. As the sending entity always resends the data for a new session. What I
Re: [Standards] ICE/UDP and NAT
On Wed, 30 Jul 2008 17:21:43 +0200 Sylvain Mundialco [EMAIL PROTECTED] wrote: Hi. Can I have more clarity on these: We are implementing jingle and all is going all but the configuration NAT/Firewall for both peer is not working. I'm thinking to use relayed candidate but I know that there is a way of punching hole in Nat/Firewall. 1) Is it the possible to use the UDP firewall punching hole technique of waiting the NAT to map the inbound and outbound IP to allow comunication This is more of a question for your network/firewall administrator, not for XMPP people. For the XMPP part, refer to *XEP-0176: Jingle ICE-UDP Transport Method* 2) when should we use relay candidate in jingle negotiation. You should generally avoid it. 3) how with jingle can we get a usable pair of candidates behind firewall and NAT. I believe it's answered in (1). Sylvain. -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
