Re: [Standards] [standards] Changes to XEP-0077: In-Band Registration
W dniu 08.07.2016, pią o godzinie 17∶28 +0530, użytkownik vaibhav singh napisał: > XMPP XEP's. In Band registration was something that caught my eye, as > the XEP itself said that it is utterly insecure and recommended > people not to use it. I don't see that wording in XEP. You are probably misinterpretting: "11. Security Considerations [...] The registration methods defined herein are known to be insecure and SHOULD NOT be used unless the channel between the registrant and the entity that accepts registration has been secured." This only means that the channel (i.e. TCP connection) you are doing in-band registration has to be secured (i.e. TLS encrypted). > 1.) Is there anything else people can use in XMPP to bootstrap users > quickly, apart from in-band registration? out-of-band registration. For example - a web based registration form that creates XMPP account - integrating XMPP accounts with some other system accounts See "5. Redirection" [1] for a way of redirecting IBR user to other system for registration. > 2.) If in-band registration is so insecure, and (from the looks of > it) so important (atleast a really good feature to have) why are > there no alternative work flows people can use? IBR is by design extensible [2] so there is no need for competing solution. [1] http://xmpp.org/extensions/xep-0077.html#redirect [2] http://xmpp.org/extensions/xep-0077.html#extensibility -- /o__ (_<^' If you are too busy to read, then you are too busy. signature.asc Description: This is a digitally signed message part ___ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Easy XMPP
W dniu 07.06.2016, wto o godzinie 17∶04 +0200, użytkownik Georg Lukas napisał: > in the last weeks we've seen that XMPP is too hard for the WhatsApp > generation. Instead of blaming them for not understanding federation, > we should make it as easy as possible to use XMPP (IM) in a secure > fashion. We recently had similar conversation on the JDev list: http://mail.jabber.org/pipermail/jdev/2016-April/thread.html There are some thoughts worth considering there. -- smoku @ http://abadcafe.pl/ @ http://xiaoka.com/ signature.asc Description: This is a digitally signed message part ___ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Images in chat
W dniu 11.03.2016, pią o godzinie 15∶33 +0100, użytkownik Peter Waher napisał: > What is the preferred way of sending an image in chat today? XEP-0137 Describes publishing SI-FT advertisement using [1]. In such case I display a button in the chat window, allowing user to download the file, unless the mime-type of SI-PUB is image - in that case I fetch the image without asking and display it directly instead of button. [1] http://xmpp.org/extensions/xep-0137.html#usecase.publish -- /o__ (_<^' I don't do it for the money. ___ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] MUC: Opt-out of presence broadcasting
W dniu 29.02.2016, pon o godzinie 18∶30 +0100, użytkownik Fabian Beutel napisał: > When joining a room, the user could include some kind of flag in the > initial presence stanza that prevents the server from sending all the > other presences and goes straight to sending back the new occupants > presence (as confirmation for a successful join). This may be just a MUC server policy implemented on the room level. There is no need for client to be involved - existing clients would just-work if a MUC room works like you described. -- /o__ (_<^' Live long and prosper. ___ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Deprecating IBR
Dnia 2015-11-10, wto o godzinie 17:10 -0600, Sam Whited pisze: > > What do you suggest to replace it with? > > I suggest we replace it with nothing. Closing the network is not the answer. People need a way of joining the network. If we deprecate the existing widely deployed standards, people will come up with own ways of doing things. I'm afraid this will lead to further fragmentation of the network. Devs (both client and server) are already complaining we have to many standards competing for each feature. Could we turn all these "let's scrap X and Y because I feel these suck" calls into analyses what exact issues we have with X and Y and how can we fix them? -- /o__ (_<^' If you are too busy to read, then you are too busy. signature.asc Description: This is a digitally signed message part
Re: [Standards] Deprecating IBR
Dnia 2015-11-04, śro o godzinie 09:44 +, Kevin Smith pisze: > is it time to deprecate (and obsolete) 77 and send a clear > message that this should not be being used on open networks? What do you suggest to replace it with? -- /o__ "Yes, it's the right planet, all right, " he said again. (_<^' "Right planet, wrong universe. " signature.asc Description: This is a digitally signed message part
Re: [Standards] ProtoXEP: SRV records for XMPP over TLS
Dnia 2015-11-09, pon o godzinie 17:33 -0500, Travis Burtrum pisze: > That seems like a ridiculous question to me. If not, why even bother > with STARTTLS/TLS in the first place? It *could* be used for > circumventing security policies after all. Your own words from the XEP: "at least equal and perhaps increased security and privacy over using STARTTLS. It also provides an easy way for clients to bypass restrictive firewalls that only allow HTTPS, and for servers to host multiple protocols/services on a single port" I'm pointing that: - designing to bypass security policies may not be a well received reasoning - hosting multiple protocols on a single port is a job of protocol level multiplexer - standard _tcp records are just fine here - if your admin wants to block you on protocol level (not simple port blocking), it is just as "trivial" to target DNS, ALPN etc. as to target XMPP protocol blocking Could you elaborate how TLS instead of STARTTLS may perhaps increase security, as this is not clear to me? -- /o__ (_<^' The heart is not a logical organ. signature.asc Description: This is a digitally signed message part
Re: [Standards] ProtoXEP: SRV records for XMPP over TLS
Dnia 2015-11-09, pon o godzinie 15:29 -0500, Travis Burtrum pisze: > accepting raw xmpp along with https on 443 is not a good option > because it's obviously xmpp and can be trivially blocked Should XSF work on technologies targetted on circumventing security policies? And if so, what about blocking _tls SRV record resolution? -- /o__ And it should be the law: If you use the word `paradigm' without knowing (_<^' what the dictionary says it means, you go to jail. No exceptions. signature.asc Description: This is a digitally signed message part
Re: [Standards] ProtoXEP: SRV records for XMPP over TLS
Dnia 2015-11-05, czw o godzinie 12:45 -0500, Travis Burtrum pisze: > Rendered version can be found at > https://burtrum.org/xeps/tls-srv.html Isn't smart proxy like sslh[1] better suited for the use case? [1] http://www.rutschle.net/tech/sslh.shtml -- /o__ (_<^' Love sometimes expresses itself in sacrifice. signature.asc Description: This is a digitally signed message part
Re: [Standards] LAST CALL: XEP-0186 (Invisible Command)
Dnia 2014-06-20, pią o godzinie 02:59 +, XMPP Extensions Editor pisze: > 1. Is this specification needed to fill gaps in the XMPP protocol stack or to > clarify an existing protocol? No. > 2. Does the specification solve the problem stated in the introduction and > requirements? It appears so, but has numerous issues. > 3. Do you plan to implement this specification in your code? If not, why not? No. I feel uncomfortable providing my users with something that only appears to work, but is known to fail and be exploitable. My opinion is that it's better to have none sense of security, than having a false one. I already implemented XEP-0191 in jabberd2, which I see as far better solution to providing this feature. > 4. Do you have any security concerns related to this specification? Yes. It has been demonstrated over time, that there are numerous way of probing real user presence. Also the specification has issues already mentioned in this thread. > 5. Is the specification accurate and clearly written? Yes. -- Tomasz Sterna @ http://abadcafe.pl/ @ http://xiaoka.com/
Re: [Standards] deprecating in-band registration
Dnia 2014-04-01, wto o godzinie 21:01 -0600, Peter Saint-Andre pisze: > I suggest that we push this line of thinking to its logical conclusion > and strongly consider deprecating and then obsoleting IBR. [...] > If we feel that we'd like to have some kind of method for account > provisioning over XMPP - and I'm not convinced that we do - then I > feel that we need to rethink the whole problem, [...] We have this notion of obsoleting existing protocols without providing alternatives. People do not like this approach and I've been defending XMPP over the years, but to this, I have no answer. Hell... I don't like this approach. IMO the correct order is: 1. Do we want to obsolete IBB or maybe fix its issues? 2. If we want to obsolete, we need to design its replacement. It's easy now, since we identified its deficiencies in 1. 3. Propose replacement for IBB and test-drive it. 4. Obsolete IBB. -- Tomasz Sterna @ http://abadcafe.pl/ @ http://www.xiaoka.com/
Re: [Standards] XEP-323 vs XEP-325
Dnia 2014-01-14, wto o godzinie 11:30 +0100, Joakim Eriksson pisze: > > ... > I can understand omitting unit and momentary [...] I can't understand omitting the unit. You need to know up front what unit does the control expect. There's a room for misinterpretation and mistakes like ie. frying/freezing your plants. When you specify the unit, at least you give a chance to err-out on unhandled unit if the control is unable to convert. -- Tomasz Sterna @ http://abadcafe.pl/ @ http://www.xiaoka.com/
Re: [Standards] presence TTL
Dnia 2013-07-16, wto o godzinie 14:24 -0700, Justin Karneges pisze: > > I'm assuming that you're doing direct client to client connections > for this (eg, link local, etc)? Otherwise the server should ensure > that the presence is kept up to date. > > You're correct in that a typical client should not be using this. It > could be used by servers on behalf of clients, or by components that > must do presence management themselves. I don't like the opt-out nature of this proposal. I'm afraid that if we would standardize this, many of desktop clients would implement it to "ensure" their presence "stability". That would damage XMPP's suitability for mobile use even more, which has poor reputation already.
Re: [Standards] XMPP as peer-to-peer protocol (Was: XMPP URI usage in "HTTP over XMPP")
Dnia 2013-07-10, śro o godzinie 03:53 +, Peter Waher pisze:
> I've attached the latest revision for your revision.
Quote: "The XMPP protocol however does not have the same problems as
HTTP in these regards. It's a peer-to-peer protocol naturally allowing
communication with applications and devices behind firewalls."
I disagree with this premise.
XMPP is not (by its nature) a peer-to-peer protocol.
It's a federated server based protocol, driving all its traffic through
dedicated servers.
Pushing traffic other than IM through these servers need to address the
same concerns as XMPP based file transfer protocols; i.e. establishing
direct client-to-client connections, negotiating/detecting server
enforced policies regarding used bandwidth and stanza size, etc.
--
Tomasz Sterna:(){ :|:&};:
Instant Messaging ConsultantOpen Source Developer
http://abadcafe.pl/ http://www.xiaoka.com/portfolio
[Standards] Answering directed probe
Quoting from RFC6121: 4.3.2. Server Processing of Inbound Presence Probe "If there is a resource matching the full JID and the probing entity has authorization via a presence subscription to see the contact's presence, then the server MUST return an available presence notification, which SHOULD communicate only the fact that the resource is available (not detailed information such as the , , , or presence extensions)." May I ask what is the rationale behind this? Why the server should not answer with the presence stanza of the probed resource? -- Tomasz Sterna Instant Messaging Consultant : Open Source Developer http://tomasz.sterna.tv/ http://www.xiaoka.com/portfolio
[Standards] XEP-0198 unclear wording
"2. Stream Feature After negotiating use of TLS and authenticating via SASL, the receiving entity returns a new stream header [...]" This is a bit unclear to me. Does it mean that XEP-0198 requires using TLS encryption and authentication? What if the client does not want (or cannot due to resource constraints) to use TLS encryption? What about S2S links? These are mostly not SASL authenticated. -- Tomasz Sterna Instant Messaging Consultant : Open Source Developer http://tomasz.sterna.tv/ http://www.xiaoka.com/
Re: [Standards] Stanza namespaces
Dnia 2010-04-27, wto o godzinie 15:56 +0100, Artur Hefczyc pisze: > My understanding of this is that: the server supports both > jabber:client and > jabber:server namespaces. > 'OR' returns false if both sides of the OR are false. Therefore, if > the server > receives jabber:client packet over s2s stream it should still be > acceptable > because this 'first-level child element' is supported by the server > which fulfils > the first requirement. This is also how jabberd2 is handling incoming packets. Is there a real advantage of not accepting jabber:client packets on S2S connection, while still blindly converting jabber:server to jabber:client?
Re: [Standards] NEW: XEP-0279 (Server IP Check)
Dnia 2010-03-20, sob o godzinie 12:48 +0200, Väisänen Teemu pisze: > The server knows client's IP address, so what if the server would also > check country, operator, etc. and send some (location) related > information back to the client, if the client requested these types of > information, not just an IP address? Once the client obtains its IP address its able to request this information itself - does not need servers help to do this.
Re: [Standards] A "broadcast" attribute to ?
Dnia 2010-03-12, pią o godzinie 11:52 +0100, Laurent Eschenauer pisze: > In onesocialweb, our use cases imply that all connected resources > should receive a message when sent to the bare JID. You should use packet instead of . Presence packets are routed to all available resources.
Re: [Standards] NEW: XEP-0279 (Server IP Check)
Dnia 2010-03-08, pon o godzinie 16:18 +, Matthew Wild pisze: > How would you propose to do it without "tight coupling"? http://delta.affinix.com/specs/xmppstream.html#myip Some may say it is spamming all clients with a feature that may or may not be useful. But it is a case of offering every other stream feature: TLS for non-TLS clients, stream-compression for clients not supporting compression, etc. Unfortunately we do not have client-initiated stream features negotiation and server needs to offer everything it has for client to cherry-pick wanted ones.
Re: [Standards] NEW: XEP-0279 (Server IP Check)
Dnia 2010-03-08, pon o godzinie 14:56 +0100, Remko Tronçon pisze: > > The clean separation of RFC 3920 and RFC 3921 allows this. > > XEP-0279 breaks this and causes tight coupling of these layers. > > On the other hand, if your server implementation has a hard time > figuring it out, don't support it. I always thought that the Standards JIG was created to come up with the best protocols possible through exchange of technical arguments. So called "meritocracy". "If you don't like it, then don't use it." is not a technical argument. I pointed a deficiency in the tight coupling approach. This is not an immediate danger, but a possibility of hurting us in the future. On the other hand, not every XMPP protocol extension needs to be blessed by XSF and published as XEP. Google has no problems with adding own extensions to the protocol without asking us for acceptance. Dnia 2010-03-08, pon o godzinie 15:10 +, Matthew Wild pisze: > Yay, I'm not alone in thinking that each implementation need not > support *every* published XEP :) Unfortunately this point of view is not shared by software users. They tend to compare implementations by counting features. This leads to a race of implementing every possible XEP, no matter how silly or useless the idea is.
Re: [Standards] NEW: XEP-0279 (Server IP Check)
Dnia 2010-03-05, pią o godzinie 12:53 -0600, XMPP Extensions Editor pisze: > XEP-0279 (Server IP Check) has been released. This protocol is hard to implement in servers with strong separation of client connection handling and client session handling (jabberd14, jabberd2, Tigase AFAIK). In these architectures the entity responsible for handling IQ requests knows only XMPP and is oblivious of the transport layer. The entity responsible for XMPP to TCP binding is separate, knows only XMPP-Core and nothing about XMPP-IM. The clean separation of RFC 3920 and RFC 3921 allows this. XEP-0279 breaks this and causes tight coupling of these layers.
Re: [Standards] NEW: XEP-0279 (Server IP Check)
Dnia 2010-03-05, pią o godzinie 12:53 -0600, XMPP Extensions Editor pisze: > Version 0.1 of XEP-0279 (Server IP Check) has been released. > URL: http://xmpp.org/extensions/xep-0279.html Yet Another Way? jabberd2 supports http://delta.affinix.com/specs/xmppstream.html#myip for some time now. XEP-0279 requires additional round-trip. P.S. Did we get rid of security-mafia from our ranks and revealing its IP address to client is no longer evil? ;-)
Re: [Standards] DEFERRED: XEP-0232 (Software Information)
Dnia 2010-03-05, pią o godzinie 07:01 -0600, XMPP Extensions Editor pisze: > XEP-0232 (Software Information) has been Deferred because of > inactivity. What stops it from moving to Proposed?
Re: [Standards] upcoming XEP deferrals
Dnia 2010-01-22, pią o godzinie 21:15 -0700, Peter Saint-Andre pisze: > > 2. XEP-0232: Software Information >http://xmpp.org/extensions/xep-0232.html > > I think this is dead in the water, given how strongly Council members > and others resisted it last time. However, be aware that people still > want this feature, and will use XEP-0092 instead forever For the record: jabberd2 implements it and it works alongside XEP-0092. -- Tomasz Sterna Instant Messaging & EDI Consultant Open Source Developer http://tomasz.sterna.tv/ http://www.xiaoka.com/
Re: [Standards] [jdev] RFC 3921 message to RFC 5322 message conversion
Dnia 2010-01-05, wto o godzinie 14:14 +0100, Tomasz Sterna pisze: > > > 3. converts directly to References: > > I'm not sure thread *does* convert, given that thread is a single > > string for all messages within a thread, whereas References is a > list > > of message ids. > > Right. I misunderstood RFC 5322 on this. Actually I didn't (almost). ;-) RFC 822 did not require it to be msg-ids list. It could be any unique string. Does anyone have experience how does it work in The Wild Internet? And what does popular IMAP servers expect of it? -- Tomasz Sterna Xiaoka.com
Re: [Standards] [jdev] RFC 3921 message to RFC 5322 message conversion
Dnia 2010-01-05, wto o godzinie 12:30 +, Dave Cridland pisze: > > 1. How do i store 'from' and 'to' fields of the XMPP message? > > > I'd opt for a simple tranformation of the address into an email > compatible form. Alexey may have some good advice here, as he's been > heavily involved in EAI. Pete Resnick, who edited RFC 5322, may also > have some good ideas, and he's familiar with XMPP, having co-chaired > the original XMPP WG. Well... I _do_ have an e-mail<->jabber gateway, so I could convert to the gateway compatible form: user%email@email.jabber.srv It has the advantage that replying to such message using MUA would work. But I am also thinking about the case when MUA gets XMPP support eventually, and would be able to: a) answer the message directly over XMPP b) show the 'from' contact status (if subscribed) These use-cases would suggest another header fields for the e-mail message to make this information available easily. > > 3. converts directly to References: > I'm not sure thread *does* convert, given that thread is a single > string for all messages within a thread, whereas References is a list > of message ids. Right. I misunderstood RFC 5322 on this. This makes building IMAP THREAD hard. :-( > > 4. Should I generate Message-ID header? If so, how? Maybe it would > > You could synthesize it, yes - which'd also solve the > issue. I'm not even sure it needs to be consistently synthesized - > that is, given the same input, different implementations could > generate different mids. What makes it even trickier, is that it gets lost on the SMTP/XMPP boundary. So I'm beginning to doubt it's worth synthesizing. > For preservation of the original, I'd be inclined to use > multipart/alternative, with text/plain, possibly text/html (for > XHTML-IM), and a new application/xmpp-msg+xml type to contain the > original message stanza in full. It's much, much simpler than trying Good idea. I like it very much. :-) -- Tomasz Sterna Xiaoka.com
[Standards] RFC 3921 message to RFC 5322 message conversion
Hello. I am working on accessing jabber message archive with IMAP and a normal MUA with IMAP backend. This begs a question: How do I convert RFC 3921 message, to RFC 5322 message to store in IMAP store. (But it may also be useful for Jabber/E-Mail gateway.) 1. How do i store 'from' and 'to' fields of the XMPP message? RFC 5322 defines From: as mailbox-list and To: as address-list which in turn reduces to addr-spec which does not include schema and is assumed to be in SMTP domain. ":" is used to delimiter group names so we cannot use XMPP URI there. - Should I add X- header for preserving XMPP 'from' field? What exact? - Should I fill From: and To: fields to maka maile readers usable? 2. Subject: header is straightforward 3. converts directly to References: - what if there is no ? Should I supplement it? How? 4. Should I generate Message-ID header? If so, how? Maybe it would be useful to base it on some of the message characteristics? -- Tomasz Sterna Xiaoka.com
[Standards] XMPP server certificate
What is a recommended way of getting an X.509 certificate for my XMPP server installation today? http://xmpp.net/ says that XMPP ICA has ceased operations. I tried going to http://www.startssl.com/ and creating an account there, but they apparently have broken registration process which borks me during the verification code entry with a "first_auth not callable" error. Should I just forget the "XMPP Federation" thingy and proceed with self-signed certificate? -- Tomasz Sterna Instant Messaging & EDI Consultant Open Source Developer http://tomasz.sterna.tv/ http://www.xiaoka.com/
Re: [Standards] Call for Experience: XEP-0203 (Delayed Delivery)
Dnia 2009-08-12, śro o godzinie 15:51 -0600, Peter Saint-Andre pisze: > 1. Who has implemented XEP-0203? Please note that the protocol must be > implemented in at least two separate codebases (and preferably more). jabberd2 is supporting XEP-0203 since 2007-09-05 I had no problems with the protocol, nor with the XEP text. It works fine parallely to XEP-0091 support. -- Tomasz Sterna Instant Messaging & EDI Consultant Open Source Developer http://tomasz.sterna.tv/ http://www.xiaoka.com/
Re: [Standards] Call for Experience: XEP-0202 (Entity Time)
Dnia 2009-08-12, śro o godzinie 15:50 -0600, Peter Saint-Andre pisze: > 1. Who has implemented XEP-0202? Please note that the protocol must be > implemented in at least two separate codebases (and preferably more). jabberd2 is supporting XEP-0202 since 2007-09-05 I had no problems with the protocol, nor with the XEP text. It works fine parallely to jabber:iq:time support. -- Tomasz Sterna Instant Messaging & EDI Consultant Open Source Developer http://tomasz.sterna.tv/ http://www.xiaoka.com/
Re: [Standards] XEP-0080: User Location
Should we still stick to GPS only? Or be GPS-independant? Should we add some fields to reflet the different other technologies? Will new ones appear in the future? (highly probable?) Does it matter where you get your geographical coordinates from? -- Tomasz Sterna Instant Messaging & EDI Consultant Open Source Developer http://tomasz.sterna.tv/ http://www.xiaoka.com/
[Standards] PEP implementation question
Hello. Psi-Devel list ignored this question, so I am reposting it here: I am testing my PEP implementation with Psi 0.13-rc3. http://xmpp.org/extensions/xep-0163.html#support "client SHOULD determine whether the account owner's server supports PEP; to do so, it MUST send a Service Discovery [17] information request to its own bare JID" But when I watch Psi XML stream during login, I see disco#info only to a server JID. There is no disco#info query to the account bare JID. Psi menu options for Mood and Avatar are grayed-out. Am I doing something wrong, or is this a problem with Psi? -- Tomasz Sterna Instant Messaging & EDI Consultant Open Source Developer http://tomasz.sterna.tv/ http://www.xiaoka.com/
[Standards] XEP-0267: Server Rosters
Could authors of XEP-0267: Server Rosters explain what is the rationale of the MUST: "Upon receiving such a presence subscription request, the XMPP server software running at the peer MUST prompt the server administrator(s) to approve the request, rather than automatically approving it." jabberd2 server implements "server presences" for more than a year now and automatically approves subscribes and answers probes to anyone interested. Additionally it advertises server-based services via server resources like: - example.com/echo - example.com/help - example.com/announce I see no reason for the administrator approval of these presences. Nor did I have any complaint from jabberd2 users (server administrators) that their server exposes the server presence to anyone. What is the meaning of denying this subscription? Interested party knows anyway whether the server is "online" just because it is processing XMPP packets. -- Tomasz Sterna Instant Messaging & EDI Consultant Open Source Developer http://tomasz.sterna.tv/ http://www.xiaoka.com/
Re: [Standards] Roster changes
On czw, 2009-07-16 at 16:14 +0100, Kevin Smith wrote: > I'd like to hang arbitrary payloads off roster entries. This probably > doesn't require any particular protocol work apart from a namespaced > element, and I'll knock up a short spec together with anyone else > that's interested. Basically, you want to resurrect the roster items subelements that were implemented in jabberd14 and jabberd2? Friend Aixie3Suele2Xee1Lah1fohw This usage was pushed out to XEP-0049 private data storage without respect to protests of the users of the clients that made extensive usage of this feature - ex. JAJC client. You are one of the authors of XEP-209 which phased metacontacts to private XML. Could you explain what had changed since, that you now favor the roster items eXtensions? -- Tomasz Sterna Instant Messaging & EDI Consultant Open Source Developer http://tomasz.sterna.tv/ http://www.xiaoka.com/
Re: [Standards] XEP-0237 Roster Versioning question
On wto, 2009-07-14 at 13:21 -0600, Peter Saint-Andre wrote: > Agreed -- there is no harm if the server always includes 'ver'. I'll > update the spec to say that. We once banned non-standard subelements from roster items and now wish to allow non-standard ver attribute? Isn't it a bit hypocritical? If it was in a separate namespace, there would be no doubt it is allowed. But it isn't. -- Tomasz Sterna Instant Messaging & EDI Consultant Open Source Developer http://tomasz.sterna.tv/ http://www.xiaoka.com/
Re: [Standards] XEP-0237 Roster Versioning question
On wto, 2009-07-14 at 04:40 +0200, Jiří Zárevúcky wrote: > I agree specs should be strict, but someone not capable of deducing > this actually implementing the spec? That is a ridiculous idea > (considering all the examples). I've seen XMPP implemented by "XML console deduction", so I am expecting the worse. -- Tomasz Sterna Instant Messaging & EDI Consultant Open Source Developer http://tomasz.sterna.tv/ http://www.xiaoka.com/
Re: [Standards] XEP-0237 Roster Versioning question
On pon, 2009-07-13 at 15:42 -0600, Peter Saint-Andre wrote: >Whether or not the roster has been modified since the version >ID enumerated by the client, the server MUST either return the >complete roster as described in RFC 3921 (including a 'ver' >attribute that signals the latest version) or ... Peter, I don't want to be picky, but this raises a question: - Where should I put the 'ver' attribute? This is a technical document after all, so it should be strict and leave no place for doubt. Even at the cost of over explaining. -- Tomasz Sterna Instant Messaging & EDI Consultant Open Source Developer http://tomasz.sterna.tv/ http://www.xiaoka.com/
Re: [Standards] XEP-0237 Roster Versioning question
On sob, 2009-07-11 at 20:42 +0200, Jiří Zárevúcky wrote: > > How do I send to the client current roster version when sending > complete > > roster? > > I guess I should add ver attribute to the iq-result query item, but > that > > is only a guess. > > > > A correct one. Cool. :-) So, the code is already in jabberd2 SVN repository. :-) > Seems the example on full result has been left out. > Maybe it needs a sentence or two about that. I think so. -- Tomasz Sterna Instant Messaging & EDI Consultant Open Source Developer http://tomasz.sterna.tv/ http://www.xiaoka.com/
[Standards] XEP-0237 Roster Versioning question
I am implementing XEP-0237 in jabberd2 and I have a question. """ 2.3 Server Response Whether or not the roster has been modified since the version ID enumerated by the client, the server MUST either return the complete roster as described in RFC 3921 or return an empty IQ-result [...] """ How do I send to the client current roster version when sending complete roster? I guess I should add ver attribute to the iq-result query item, but that is only a guess. -- Tomasz Sterna Instant Messaging & EDI Consultant Open Source Developer http://tomasz.sterna.tv/ http://www.xiaoka.com/
Re: [Standards] Voice clips
Dnia 2008-06-23, pon o godzinie 20:20 +0200, Dag Odenhall pisze: > Voice clips are popular on MSN/Live Messenger. Yet, I can't find any > XEP for anything like it, nor can I find much at all on the topic for > Jabber. XEP-0038: http://www.xmpp.org/extensions/xep-0038.html 4.4. Objects "There may be one or multiple elements in an , such as for alternative file formats (such as GIF vs. PNG), or multiple objects to use at the same time (such as graphic and sound files)." We have some .jisp's with sounds bundled with http://www.hapi.pl/ -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [Standards] rfc3921bis: subscribing to a full JID
Dnia 2008-06-09, pon o godzinie 08:57 -0600, Peter Saint-Andre pisze: > > But even though, presence MUST be handled by bare JID of this roster > > item. > > So, if a user's client sends a subscription request to a full JID, > should the user's server ignore the resource and send the request to > <[EMAIL PROTECTED]> instead of <[EMAIL PROTECTED]/resource>? And if > the contact's server receives a subscription request for a full JID, > should it also ignore the resource? Exactly. > I have some text to that effect in > my working copy now (but I think it is MAY, not SHOULD or MUST). I think it should be SHOULD. :-) -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [Standards] Proposed XMPP Extension: The /me Command
Dnia 2008-06-09, pon o godzinie 22:32 -0500, XMPP Extensions Editor pisze: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: The /me Command > > Abstract: This specification defines recommended handling of the /me > command in XMPP instant messaging clients. -1 This is a crude hack and I'm against encouraging it. If we really want to have IRC actions on MUC let's do it properly, i.e. shrugs child of message. -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [Standards] rfc3921bis: subscribing to a full JID
Dnia 2008-06-05, czw o godzinie 15:39 -0600, Peter Saint-Andre pisze: > Should we allow subscriptions to a full JID instead of a bare JID? We should disallow full JID based subscriptions. This introduces many inconsistencies and doubts in presence handling. > I know people have said there are legitimate scenarios when you might > want to do that, but I've never found them compelling. There are legitimate scenarios to have full JIDs on roster, though. I.e. 'server.tld/echo' on default user roster, to hint user how to test the connection (like Skype's echo service). But even though, presence MUST be handled by bare JID of this roster item. -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [Standards] MUC History clearing
Dnia 2008-05-15, czw o godzinie 11:21 +0200, Andreas Monitzer pisze: > Well, no, not just bots. In a typical chat client, you have a list > of > users in the channel and would like to click on them, then activate > "kick" from some list/some button/etc and don't have to fill out > some > form for that. Isn't this an UI issue? -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [Standards] stream restarts
Dnia 2008-04-29, wto o godzinie 20:51 +, Gaston Dombiak pisze: > In our case, the server was not keeping any information about the > session [...] Even the parser state? This is AFAIR the only thing I need to reset in jabberd. -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
[Standards] jabber:iq:private update pushes [Was: Extending private-storage]
Dnia 2008-04-28, pon o godzinie 12:42 +0200, Tomasz Sterna pisze: > I was thinking more along the lines of roster and privacy-list pushes after > item update. So, I implemented it today, in jabberd 2 trunk, similarly to XEP-0016 and XEP-0191 notification/update pushes: http://jabberd2.xiaoka.com/changeset/559/ It works like this: 1. After every successful Private Data "set" method, the full XML stanza of the set request is pushed to every interested, connected resource. 1.1. These pushes need to be confirmed by standard, empty iq 'result' packet. (or appropriate error message when not supported) 2. Interested resource is every resource that requested Private Data of the 'jabber:iq:private' child namespace, in question. AD.1. This is a full Private Storage stanza (not an empty notify), because the resource is known to be interested in this data, so this saves a round-trip of pulling it from server. -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [Standards] Extending private-storage [Was: Meta-Contacts: implementation notes]
Dnia 2008-04-28, pon o godzinie 17:07 +0100, Pedro Melo pisze: > To whom would you push? Please read Roster Management section of XMPP IM RFC to see how roster pushes work and Editing a Privacy List section of XEP-0016 to see how privacy lists pushes work. > Also, even if you instantly deploy that feature to all XMPP servers > in the world, clients wouldn't know what hit them. They are not > expecting that push. The nice side-effect of pushes is that handling of these IQ sets is already implemented in clients. > would it be better to redeploy them with something that has a vast > range of usages (pubsub) instead of something that has limited use > (private-storage)? I really believe in Unix philosophy of small tools that do one thing but do it well. For storing private data on server we have private-storage. PubSub is for publishing information to subscribed entities, not a Swiss Army Knife to put anything in, just because we can. -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [Standards] Extending private-storage [Was: Meta-Contacts: implementation notes]
Dnia 2008-04-28, pon o godzinie 11:15 +0100, Pedro Melo pisze: > > I think his point was that implementing PEP just to get update > > notification for private storage is a bit heavy, and that he juts > > wanted to fix private storage instead. Exactly. > I think that "just implementing notification for private storage" > will end quite similar to PIP in the end. Not at all. I was thinking more along the lines of roster and privacy-list pushes after item update. -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
[Standards] Extending private-storage [Was: Meta-Contacts: implementation notes]
Dnia 2008-03-29, sob o godzinie 19:44 +, Pedro Melo pisze: > Using private storage is not a big > problem, except for the lack of notification on update. Why didn't we pursue this yet? The "Let's use PEP for this" hype is over, so maybe it's time to bring the subject back? IIRC there are two things with private storage people find annoying. 1. Lack of partial updates. 2. Lack of notification on element change. AD. 1. This is IMO not a problem really. But I may be wrong. Does anyone have a good, real life example of the situation, that this really is an issue? (real-life example, not some hypothetical abstract "problem") AD. 2. This is fairly easy to fix. One/two evenings work, to add it to jabberd2. Is anyone willing to work with me on the protocol for updates? -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [Standards] Meta-Contacts: implementation notes
Dnia 2008-03-29, sob o godzinie 19:44 +, Pedro Melo pisze: > there is a fallback > protocol that requires only the usual roster to keep meta-contacts. > If we assume that roster items with the same name + groups > (basically, if the tag algorithm above yields the same hash for your > roster entries) belong to the same meta-contact, we can implement > meta-contacts without the need of any extra storage, just the roster. This approach is IMO far superior than the artificial meta-contacts XEP. I always advocated use of roster names to merge contacts into one contact list item. The meta-contacts XEP is a good example of over-engineering things that have good-enough real life solutions already. -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [Standards] Meta-Contacts: implementation notes
Dnia 2008-04-03, czw o godzinie 12:13 +0100, Pedro Melo pisze: > I don't like the term lower-case. I prefer some sort of > case-ignoring > stuff, but I'll leave that for native speakers to sort out. The > point > is to compare ignoring case. I think we should use our stringprep profiles. I.e. folding aąAĄ to a etc. Eventually we could use slugify ;-) -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [Standards] TLS compression (was: Re: Council on Stanza Repeaters without Multicast)
Dnia 2008-04-03, czw o godzinie 11:36 +0200, Magnus Henoch pisze: > Does anyone know why? (Are there any public non-ejabberd servers to > test with nowadays?) [EMAIL PROTECTED]:~$ gnutls-cli -p 443 chrome.pl Resolving 'chrome.pl'... Connecting to '217.173.160.48:443'... - Certificate type: X.509 - Got a certificate list of 2 certificates. [...] - Peer's certificate issuer is unknown - Peer's certificate is NOT trusted - Version: TLS 1.0 - Key Exchange: RSA - Cipher: AES 256 CBC - MAC: SHA - Compression: DEFLATE - Handshake was completed [...] -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [Standards] Labeling Roster Items
Dnia 2008-03-30, nie o godzinie 20:53 -0700, anders conbere pisze: > Right now I'm struggling to find an number of > clients that let me keep users in multiple groups, or at least give > me ui to group in a tagging like behavior. Gajim does support contacts in multiple groups for the very long time now. And it's group assigning interface works just like tagging interfaces seen in the wild. > That in and of itself might seem to be reason at least to create a new > semantic grouping. -1 The fact that that our roster "tags" are called "group" does not justify creating yet another standard. This is a client interface implementation issue. -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [Standards] XEP-136 and XEP-59 implementation comments
Dnia 2008-03-30, nie o godzinie 13:20 +0300, Alexander Tsvyashchenko pisze: > There's one other idea I have, but it may break backward > compatibility > and I'm not sure if it doesn't break something else: what if JIDs > like > 'domain.com' are treated like 'wildcards' (like it is now), but > '@domain.com' are considered to be exact matches of domain JID (so, > basically, JID with empty user name)? > > The same for resources: '[EMAIL PROTECTED]' is treated like wildcard, > but '[EMAIL PROTECTED]/' is exact match of bare JID? I think it is counter-intuitive. Logic would hint that domain.com is exact match and @domain.com is a wild match. Similar with [EMAIL PROTECTED] is exact match and [EMAIL PROTECTED]/ is wild match. -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [Standards] XEP-0175: Contact Addresses
Dnia 2008-02-26, Wt o godzinie 16:05 +0100, Maciek Niedzielski pisze: > If I remember well, disco + data forms were choosen to make this very > easy to implement (using basic XEPs), because this information was > considered very important. This is _the_ point. Pedro, have you read the Standards-JIG archives on the topic? This could answer many of your concerns. -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [Standards] Proposed XMPP Extension: Stream Compression with Efficient XML Interchange
Dnia 2008-02-16, So o godzinie 11:18 +0100, Fabio Forno pisze: > Did some homework about EXI. I don't know if handling it as a > compression method it's the best way, since it forces the client to > have both an xml parser just for the first stanzas before features > (indeed it could be done with some string search, but it's an ugly > hack) and the exi parser. EXI streams, instead, have a starting header > whose first two bits allow understanding whether the data is encoded > with EXI or text xml, so a client wanting to use it could open the > stream directly with EXI. If the servers doesn't understand it can > reply with an error. One does not exclude the other. Once you have EXI implemented XEP-0138 extension, it would be trivial to detect EXI header on incoming streams and enable EXI using the same implementation. wpjabber server does similiar for SSL. It supports SSL wrapped streams by detecting compressed stream instead of listening on special wrapper port. > AFAIK in RFC 3920 there aren't restrictions in this sense. And it's good. Transport layer should be transparent. -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [Standards] Proposed XMPP Extension: XMPP Nodes
Dnia 2008-02-12, Wt o godzinie 08:49 -0700, Peter Saint-Andre pisze: >[EMAIL PROTECTED]/resourcepart > > These are just parts of an address, after all, and have no real > meaning > on their own. Well... domain on its own is a valid JID. -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [Standards] RFC 3921bis Managing Presence Subscriptions based on full JIDs serious issue
Dnia 2008-02-08, Pt o godzinie 20:54 +, Richard Dobson pisze: > But surely in those cases the JIDs would be something like: > > [EMAIL PROTECTED] > [EMAIL PROTECTED] > [EMAIL PROTECTED] What I _really_ don't like with it, is mapping one namespace to many namespaces in XMPP domain. [EMAIL PROTECTED] is the same thing that @orange. and @tmobile. This is similiar case with transports, that map one legacy names to many XMPP JIDs, depending where the gateway is, causing very abstract problems... "I just switched my transport from gw..com to gw.y.net. How do I migrate my contacts of [EMAIL PROTECTED] Oh, btw, I do want to keep the chat history so this strange thingy JRU is no good..." And with different gateways we loose the fallback to try Gateway2 when selected Gateway1 resource is not available (default highest priority resource message routing fallback). -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [Standards] RFC 3921bis Managing Presence Subscriptions based on full JIDs serious issue
Dnia 2008-02-07, Cz o godzinie 15:48 +0100, Ralph Meijer pisze: > > I still see a very good use case for having full JIDs on the roster: > > to communicate with different facets of the same thing. > > Ex. chrome.pl/echo and chrome.pl/broadcast > > or [EMAIL PROTECTED]/Gateway1 > > and [EMAIL PROTECTED]/Gateway2 > > You can communicate just fine with different resources directly, even > if > just the bare JID is on your roster or not on it at all. If you > receive > presence, you'll know about their availability, too. Sure. But why do you enforce me to choose the resource every time (instead of just double clicking the contact) when I know that I will always be wanting to communicate only with the given one? -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [Standards] RFC 3921bis Managing Presence Subscriptions based on full JIDs serious issue
Dnia 2008-02-07, Cz o godzinie 14:45 +0100, Ralph Meijer pisze: > If your particular use case desires that you can subscribe to the > presence of two different things (and not two facets of the same > thing), > why not make two different bare JIDs for them? Why not have > [EMAIL PROTECTED], or [EMAIL PROTECTED] This is a valid argument and I see your point. And in a post [EMAIL PROTECTED] I expressed a reasoning with the similar conclusion. I agree that presence should be based on bare JIDs. I still see a very good use case for having full JIDs on the roster: to communicate with different facets of the same thing. Ex. chrome.pl/echo and chrome.pl/broadcast or [EMAIL PROTECTED]/Gateway1 and [EMAIL PROTECTED]/Gateway2 -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [Standards] RFC 3921bis Managing Presence Subscriptions based on full JIDs serious issue
Dnia 2008-02-03, N o godzinie 16:12 +0100, Alexander Gnauck pisze: > why are you not running this services on subdomains echo.chrome.pl > and > webstatus.chrome.pl. These are in sm services. I could rephrase the question, to why I am not running disco.chrome.pl or vcard-temp.chrome.pl... -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
[Standards] Managing Presence Subscriptions based on full JIDs
Dnia 2008-02-03, N o godzinie 10:43 +0100, Tomasz Sterna pisze: > So I actually need full JID based subscriptions. I did some thinking and come to conclusion that it would be hard to allow full JID based presence subscriptions. Especially 3.1.5. Server Processing of Outbound Subscription Approval would be problematic. How does one differ full JID or bare JID based approval? Or 2.5. Deleting a Roster Item - shall the subscription 'unsubscribe' be send where there is another full JID based contact item,or not? But it would still be possible to add full JIDs to the roster and use them for server related stuff handling, like sending/answering probes, and by clients for opening chatwindows to the specific resources (we have an SMS gateway that uses resources to select which web gateway one wants to use: [EMAIL PROTECTED]/Gateway1 and [EMAIL PROTECTED]/Gateway2 both send SMS to the same telephone number, but using different web gateways, so user can add one or another to send SMS using specific gateway just by clicking the contact). During the research I found: 2.3. Adding a Roster Item Note: When the item added represents another IM user, the value of the 'jid' attribute MUST be a bare JID <[EMAIL PROTECTED]> rather a full JID <[EMAIL PROTECTED]/resource>, since the desired result is for the user to receive presence from all of the contact's resources, not merely the particular resource specified in the 'to' attribute. Which concludes subscription handling difficulties I described. But removing the full JID based roster items would disable many good use cases I described in the thread... :-( -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [Standards] RFC 3921bis Managing Presence Subscriptions based on full JIDs serious issue
Dnia 2008-02-01, Pt o godzinie 00:17 +0100, Tomasz Sterna pisze: > I found e serious issue with FC 3921bis Managing Presence Subscriptions. > [...] Shall I take no answers to my post as: - nobody is really interested in the issue ? - I already am on all list members KILLFILEs ? > I think we need to resolve this before RFC 3921bis goes "live". > Let's disallow full JID based subscriptions or fully document it. > Either way is OK with me, but the current, unclear situation is a no > go. Actually, I take it back... I do care what we do and it's not the first option. I do run some services on server resources. For example, a public server based (not bot or component), web presence tracker and indicator on: 'chrome.pl/webstatus' You need to add 'chrome.pl/webstatus' to send your presence updates, to the service and you may then use http://www.chrome.pl/status/JID url to show your presence status on the web. I also add 'chrome.pl/echo' to all my users rosters on user creation. It resembles them the Skype echo service contact, and they all love it - they have a way of testing theirs newly created jabber account right away, without searching for real people. So I actually need full JID based subscriptions. -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [Standards] Jingle "implementability"
Don't we have 'jdev' list for this kind of discussion?
[Standards] RFC 3921bis Managing Presence Subscriptions based on full JIDs serious issue
I found e serious issue with FC 3921bis Managing Presence Subscriptions. Reading through section 3. Managing Presence Subscriptions, we find a requirement, that server MUST stamp every outbound (un)subscribe(d) presence stanza with bare JID of the user in the 'from' attribute of presence stanza. We find nothing about the 'to' attribute. Now the problem: Historically Jabber allowed full JID based subscriptions. One could request full JID subscription and have full JID in the roster item. This indicates that one is interested in only one resource of the contact, not all of them. Server conforming to RFC 3921bis, when asked for [EMAIL PROTECTED]/resource subscription will accept it from [EMAIL PROTECTED], resulting in uncertainty at the requesting server side: - treat as request acceptance? but it does not match the roster item - ignore it as unrequested? this leaves the user with permanent 'ask' roster item Situation gets worse with probes. Let's assume that the receiving server was upgraded to RFC 3921bis compatible release. It now gets presence probes directed to [EMAIL PROTECTED]/resource. How should it answer when [EMAIL PROTECTED]/otherresource is connected? - send [EMAIL PROTECTED]/otherresource presence? but requestor is not interested in it - send presence unsubscribed not finding the probed item on roster? but it will send it from bare JID, the requesting server will not match it against the roster items to and just ignore it - ignore it? there is no such option in RFC I think we need to resolve this before RFC 3921bis goes "live". Let's disallow full JID based subscriptions or fully document it. Either way is OK with me, but the current, unclear situation is a no go. -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [Standards] XMPP Protocol Flows for Inter-Domain Federation
On Śr, 2008-01-23 at 20:48 -0700, Peter Saint-Andre wrote: > I'd like some feedback from server developers. Will it be helpful for > me > to finish defining these protocol flows? If so, I will complete a > first > draft of this document and ask the Council to approve it as a XEP. I think it will be much help for the newcomers. As every best-practices XEP. At a first glance it looks ok. I have only one request so far: The literature references ale nice in most of our XEPs. But here I find them confusing. Every time I see a 'verona.lit' reference in scenario flow, I need to look-up Table 1 and remember which type the server is. It will be more readable as 'type1.org' or at least 'verona-1.lit'. -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [Standards] Proposed XMPP Extension: Client Information
On Śr, 2008-01-23 at 08:24 -0700, Peter Saint-Andre wrote: > >> URL: http://www.xmpp.org/extensions/inbox/clientinfo.html > > > > I've implemented it in jabberd 2. > > You may check current SVN trunk, or see it live on chrome.pl server. > > What does it mean for a server to implement client info? ;-) xmpp:chrome.pl?disco;type=get;request=info and see for yourself. :-) -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [Standards] Proposed XMPP Extension: Client Information
On Pn, 2008-01-21 at 21:56 -0600, XMPP Extensions Editor wrote: > Abstract: This document specifies an XMPP protocol extension for > including detailed data about an XMPP client in service discovery > responses. > > URL: http://www.xmpp.org/extensions/inbox/clientinfo.html I've implemented it in jabberd 2. You may check current SVN trunk, or see it live on chrome.pl server. -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [Standards] Proposed XMPP Extension: Client Information
On Wt, 2008-01-22 at 15:43 -0700, Peter Saint-Andre wrote: > A question: should this clientinfo extension include the software name, > or do we assume that is provided properly in the service discovery > identity? If the latter, I'll make that clear in the extension spec. (It > seems preferable to have the same information in only one place!) -1 I think, the service identity name is the name of the service, not the software powering the service. ex: -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [Standards] XEP-0115 and RFC3921bis
On N, 2008-01-20 at 13:37 -0700, Joe Hildebrand wrote: > > As if XEP-0115 redux won't break it? ;-) > If that's a joke, I don't get it. If you're saying there's a > backwards-compatibility issue, please state it, so we can fix it. Yes it was meant as a joke. Please don't mind it - I got lost in the XEP-0115 noise a month ago or so. -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [Standards] XEP-0115 and RFC3921bis
> On Jan 19, 2008, at 8:20 PM, Peter Saint-Andre wrote: > > Well the idea behind the bis drafts is to clarify the core features, > > correct errors, update our usage of technologies like TLS and SASL > > (there are updated RFCs for those now), etc. -- but not to add new > > features. We added Binding Multiple Resources to RFC3920bis. Let RFC3921bis be no different ;-) > On So, 2008-01-19 at 20:47 -0700, Joe Hildebrand wrote: > As well, removing the namespace would break backwards-compatibility, > which we've been bending over backwards to avoid. As if XEP-0115 redux won't break it? ;-) -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [Standards] generic query protocol (was: XEP-0115 redux)
On Pt, 2008-01-18 at 12:02 +0100, Alexander Gnauck wrote: > We also have jabber:iq:time, which is more useful for me than the os > when talking to people in other timezones. And there is many other > stuff > which people want to render on their roster. > > I agree with Joe here, don't break a good protocol because of some > info > which is useful for some people only. I vote for a new XEP where we > can > add all this information people want. Some kind of generic query protocol? Where you can ask for version, time, geoloc, mood and any other thing you're interested in, in one packet, and get reply in one packet too. -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [Standards] XEP-0115 and RFC3921bis
On Cz, 2008-01-17 at 13:08 -0700, Peter Saint-Andre wrote: > > element to RFC3921bis allowed 4.7.2. Child Elements to drop off the long xmlns='http://jabber.org/protocol/caps' string? -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
[Standards] IQ set semantics
Hi. I was looking for an information whether the IQ-set sent on ones behalf (to change its own settings) may or may not have the "to" attribute and how should it be processed by the server. http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-04.html#stanzas-attributes-to-c2s "2. A stanza sent from a client to a server for direct processing by the server (e.g., presence sent to the server for broadcasting to other entities) SHOULD NOT possess a 'to' attribute." It says that it SHOULD NOT posses a 'to' attribute. But what to do if it does? Let's search further... http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-04.html#rules-local-node "3. If the JID is of the form <[EMAIL PROTECTED]> and there exists at least one connected resource for the node, the recipient's server SHOULD deliver the stanza to at least one of the connected resources if the stanza is a message or presence stanza and SHOULD handle it directly on behalf of the node if the stanza is an IQ stanza." OK. This says that the server should process the IQ on behalf of the "to" entity instead of forwarding to the client for processing. But I still am not sure what to do if the "to" is client's own bare JID. The real life case is XEP-0054: "A user may update his or her vCard by sending an IQ of type "set" to the server, following the format in the previous use case. If a user attempts to perform an IQ set on another user's vCard, the server MUST return a 403 "Forbidden" error." The "previous use case" does not contain a "to" attribute, so jabberd2 implementation checks whether it is not set. If it is - returns forbidden-error. Logic says that for IQs if "to" attribute is set to ones bare JID it should be handled like "to" was not set. But I cannot find a rule that says so in our protocol documentation. "In the face of ambiguity, refuse the temptation to guess." - PEP-0020 -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [Standards] Proposed XMPP Extension: Service Discovery Notifications
On Pt, 2008-01-04 at 06:52 -0700, Peter Saint-Andre wrote: > > URL: http://www.xmpp.org/extensions/inbox/disco-notifications.html > > When I woke up this morning I thought of an alternate way to do this: I like the implicit method better. > 3. Responding entity sends standard disco#items response. I think it should be tagged somehow, for requesting entity to know that the subscription is active and it does not need to requery for items. -- /\_./o__ Tomasz Sterna (/^/(_^^' Xiaoka.com ._.(_.)_ XMPP: [EMAIL PROTECTED]
Re: [Standards] HTTP Authentication with XMPP (Concern over XEP-70)
On Cz, 2007-12-20 at 15:16 -0800, anders conbere wrote: > Ah I think there's some confusion here. When I say "jabber server > requests user credentials" I really mean that it expects an http post > with jid and password in it. I would NEVER give my jabber account password to some site out there! That's why token authentication systems like Kerberos or OpenID were designed. You give a thirdparty only your ID. You do not give it your full credentials (like password). You give it only to your trusted authentication provider(jabber server or OpenID server) to prove that you are you, and it tells the thirdparty, that you proved that you are you, and it may let you in. -- /\_./o__ Tomasz Sterna (/^/(_^^' Xiaoka.com ._.(_.)_ XMPP: [EMAIL PROTECTED]
Re: [Standards] [Fwd: I-D Action:draft-saintandre-rfc3920bis-04.txt]
On Cz, 2007-12-20 at 15:40 -0700, Peter Saint-Andre wrote: > The gory details for > exactly how to handle a given subscription-related stanza at a given > point in the state chart are in Appendix A. > > Would it help to add pointers to Appendix A more often? I think that stating this, at the beginning of the chapter could help. That this is only one most common scenario designed to help understanding and for full implementation details one should skip to Appendix A. There are no conditionals in the narration, so it's kind of misleading in this is "the only way". We need to remember that most times people do not read the documentation from the beginning to the end. They tend to jump directly in, using chapter anchors, text search etc. So "for full details see..." pointers are very helpful. -- /\_./o__ Tomasz Sterna (/^/(_^^' Xiaoka.com ._.(_.)_ XMPP: [EMAIL PROTECTED]
Re: [Standards] [Fwd: I-D Action:draft-saintandre-rfc3920bis-04.txt]
On Cz, 2007-12-20 at 15:14 -0700, Peter Saint-Andre wrote: > Which is better? > > (1) Allow a denial of service attack. > (2) Strictly adhere to the letter but not the spirit of the RFC. I really don't know... That's why I'm asking here. -- /\_./o__ Tomasz Sterna (/^/(_^^' Xiaoka.com ._.(_.)_ XMPP: [EMAIL PROTECTED]
Re: [Standards] [Fwd: I-D Action:draft-saintandre-rfc3920bis-04.txt]
On Cz, 2007-12-20 at 07:58 -0700, Peter Saint-Andre wrote: > Maybe this is something we can recommend > in XEP-0205 (Best Practices to Discourage Denial of Service Attacks) > but > I don't think it belongs in the RFC. And what if that protective action directly violates RFC? Ie. RFC says server MUST deliver the stanza... -- /\_./o__ Tomasz Sterna (/^/(_^^' Xiaoka.com ._.(_.)_ XMPP: [EMAIL PROTECTED]
Re: [Standards] [Fwd: I-D Action:draft-saintandre-rfc3920bis-04.txt]
On Śr, 2007-12-19 at 17:35 -0700, Peter Saint-Andre wrote: > > You may flood online user with presence-subscriptions, making her go > > offline to protect from the flood. > > Yes, you may. But I think that's a slightly different problem, which > should be solved using Privacy Lists Why should that involve client reaction? Isn't "simple clients, complex servers" actual anymore? -- /\_./o__ Tomasz Sterna (/^/(_^^' Xiaoka.com ._.(_.)_ XMPP: [EMAIL PROTECTED]
Re: [Standards] [Fwd: I-D Action:draft-saintandre-rfc3920bis-04.txt]
On Pt, 2007-10-05 at 16:33 -0600, Peter Saint-Andre wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. Another question: 3.1.5. Server Processing of Outbound Subscription Approval "The contact's server then MUST send a roster push to all of the contact's interested resources." This does not differentiate whether the contact first asked for subscription. You always get a new roster item with subscription='from'. This stays in contrary to the 3.1.3.3. "pre-approval" that should create new item of ask='subscribed' not subscription='from'. 3.1.5. also does not take into account if the item already have subscription='from' and pushes unneeded presence packet to the wire. -- /\_./o__ Tomasz Sterna (/^/(_^^' Xiaoka.com ._.(_.)_ XMPP: [EMAIL PROTECTED]
Re: [Standards] [Fwd: I-D Action:draft-saintandre-rfc3920bis-04.txt]
On Pt, 2007-10-05 at 16:33 -0600, Peter Saint-Andre wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. I have question about 3.1.3. Server Processing of Inbound Subscription Request A) 3.1.3.5 "and MUST deliver only one of the requests when the contact next has an interested resource" to protect from SPIM. Why does 3.1.3.4 does not have such protection? Only offline users are protected? You may flood online user with presence-subscriptions, making her go offline to protect from the flood. -- /\_./o__ Tomasz Sterna (/^/(_^^' Xiaoka.com ._.(_.)_ XMPP: [EMAIL PROTECTED]
Re: [Standards] Messages to unsubscribed contacts and resources
On Wt, 2007-12-11 at 15:59 -0500, Greg Hudson wrote: > It's not what clients do currently, though. I'm not sure whether it's > wise to encourage such a fundamental change at this point. It's not a change... yet. There are clients that do one, and others that do the other, by the authors preference. RFC3921bis will be encouraging only one approach. And then it will be hard to change it. -- /\_./o__ Tomasz Sterna (/^/(_^^' Xiaoka.com ._.(_.)_ XMPP: [EMAIL PROTECTED]
Re: [Standards] Messages to unsubscribed contacts and resources
On Wt, 2007-12-11 at 13:10 -0700, Peter Saint-Andre wrote: > Because that's what it means to be in a chat session with someone -- > you have a FullJID-to-FullJID connection, as it were. This is kind of "it is like this, because it is like this" answer. And as Robin pointed "a chat session" is a very fuzzy "definition". I still se no advantage in this approach. And Robin and I pointed a few advantages of bare JID messaging. > And remember that these messages are not necessarily human-readable > text. What if you're sending a file via In-Band Bytestreams? Does half > the file go to one resource and half to another? Ick. Is a IBB a "chat session"? Really? This makes "chat session" definition even more fuzzy... And I have a feeling of deja-vu. We had this talk before and IIRC concluded that bare JID messaging is better and is what we should recommend it and discourage the existing full JID binding. Instead, we documented the full JID binding in RFC3921bis and encourage it even more... :-/ -- /\_./o__ Tomasz Sterna (/^/(_^^' Xiaoka.com ._.(_.)_ XMPP: [EMAIL PROTECTED]
Re: [Standards] Messages to unsubscribed contacts and resources
On Wt, 2007-12-11 at 10:28 -0700, Peter Saint-Andre wrote: > You should keep sending to the bare JID until you receive a reply from > a full JID, then start sending to the full JID. What is the rationale for this behavior? I mean, what advantage does it have over sticking to bare JID sending? -- /\_./o__ Tomasz Sterna (/^/(_^^' Xiaoka.com ._.(_.)_ XMPP: [EMAIL PROTECTED]
Re: [Standards] s2s blocking of abusive users
On Wt, 2007-12-04 at 16:27 +0100, Jesus Cea wrote: > All traffic between two xmpp servers is transmitted using a single TCP > connection. You can't "delay" a single remote user. You "delay" all of them. I am very aware of that. > In fact, if I would program a xmpp server, I would enqueue in RAM and > cut the connection when buffer >X MB or I'm unable to flush the buffer > after Y seconds. I'm aware that the connection oriented TCP layer is very good at it and I do not need to reinvent it at the application layer. > In some circunstances the server simply can't choose to not generate new > traffic. Let's say, I'm a user sending "normal" traffic to two other > users. One of them is receiving just fine. The other one annnounces a > closed TCP window (closed flow control) to the server, so traffic in > being enqueued in tcp layer and, later, in the application. Server > shouldn't block me, because that would impact my "normal" traffic with > the responsive user. Why would dropped packets affect the flowing ones? > So flow control at TCP layer is of no help to the server. And less so > when the stream coming is multiplexing traffic by several different > (innocent) users. That is the case for S2S connections. I am very aware of that. > I think stpeter is talking more in the line of "I'm receiving abusing > traffic from [EMAIL PROTECTED] I don't want to punish ALL @ users. And if you would reread my statements I'm against it. It's the abuser server role to take care of the abuser, not the abused one. And if it does not taking care, all of it's users will hurt. Experience shows that collective responsibility is good at enforcing policies. > So, no TCP queues or delays to care of. You don't ever need to take care of the TCP queues manually. They "just work". :-) -- /\_./o__ Tomasz Sterna (/^/(_^^' Xiaoka.com ._.(_.)_ XMPP: [EMAIL PROTECTED]
Re: [Standards] s2s blocking of abusive users
Dnia 28-11-2007, Śr o godzinie 01:05 +0100, Jesus Cea pisze: > > The TCP buffering, timeouts and retransmission will handle the rest, > > thus you will effectively enforce the peer to transmit no faster > than > > 10kbps. > > Then you add "lag" to the connection, but you will "eat" the bytes > sonner or later :-/ TCP buffers are not infinite and congestion control kicks very soon and takes care of excessive bytes. Wikipedia has some good articles of it. Please read http://en.wikipedia.org/wiki/TCP_congestion_avoidance_algorithm -- /\_./o__ Tomasz Sterna (/^/(_^^' Xiaoka.com ._.(_.)_ XMPP: [EMAIL PROTECTED]
Re: [Standards] Nodeprep question
Dnia 20-11-2007, Wt o godzinie 13:04 +0300, Sergei Golovan pisze: > Any checks for the forbidden characters in stringprepped string is > performed after unicode normalization (see sections 4 and 5 of RFC > 3454). Oh. So it is a side-effect. So, you're right. :-) -- /\_./o__ Tomasz Sterna (/^/(_^^' Xiaoka.com ._.(_.)_ XMPP: [EMAIL PROTECTED]
Re: [Standards] Nodeprep question
Dnia 20-11-2007, Wt o godzinie 09:37 +0300, Sergei Golovan pisze: > > > Some libraries extend it to caracters such as c/o (8453). The > rational > > > behind that is that it contains a fraction. > > > > I think they do wrong. > > You forgot about Unicode normalization. So what? Resource separator is 0x2F slash, not any other 'normalized' slash. -- /\_./o__ Tomasz Sterna (/^/(_^^' Xiaoka.com ._.(_.)_ XMPP: [EMAIL PROTECTED]
Re: [Standards] Nodeprep question
Dnia 19-11-2007, Pn o godzinie 22:27 +0100, Mickaël Rémond pisze: > Nodeprep adds forbidden characters to usual stringprep tables. Among > those characters we find "/" (47). IIUC the only reason that slash '/' character is forbidden in a node part is, that it is a resource delimiter. So encountering '/' in the JID means that the resource has just started. > Some libraries extend it to caracters such as c/o (8453). The rational > behind that is that it contains a fraction. I think they do wrong. -- /\_./o__ Tomasz Sterna (/^/(_^^' Xiaoka.com ._.(_.)_ XMPP: [EMAIL PROTECTED]
Re: [Standards] XHML + GPG
Dnia 18-11-2007, N o godzinie 23:59 +0100, Yann Leboulanger pisze: > XEP 27 (GPG) doesn't say anything on the way to encrypt XHML messages. NOTICE: This Historical specification provides canonical documentation of a protocol that is in use within the Jabber/XMPP community. [...] XEP-0027 documents for Historical and iteroperability reasons, a protocol that evolved in the Jabber community and is still in use. When GPG came into Jabber there was no XHTML-IM yet. ;-) -- /\_./o__ Tomasz Sterna (/^/(_^^' Xiaoka.com ._.(_.)_ XMPP: [EMAIL PROTECTED]
Re: [Standards] s2s blocking of abusive users
Dnia 12-11-2007, pon o godzinie 23:48 +0100, Alexander Gnauck pisze: > I assume they > used multiple accounts to overcome the karma settings. So the per user > karma does not help here. What about per connection karma, I had describe? -- /\_./o__ Tomasz Sterna (/^/(_^^' Xiaoka.com ._.(_.)_ XMPP: [EMAIL PROTECTED]
Re: [Standards] Proposed XMPP Extension: Data Element
Dnia 12-11-2007, pon o godzinie 15:05 -0700, Peter Saint-Andre pisze: > So if I once sent you the emoticon (or I sent you my > favorite emoticon library via file transfer last week) I can refer to > an > icon and you don't need to retrieve it every time. And what if I had change client in the meantime, reinstalled the system or just purged the caches? How would you know if you need to send me the file again, or you just could reuse the CID? -- /\_./o__ Tomasz Sterna (/^/(_^^' Xiaoka.com ._.(_.)_ XMPP: [EMAIL PROTECTED]
Re: [Standards] Proposed XMPP Extension: Data Element
Dnia 09-11-2007, Pt o godzinie 16:55 -0700, Peter Saint-Andre pisze: > And there's always > http://wiki.jabber.org/index.php/XHTML_Inband_Images > too (I haven't looked at that in a while, but we might want a way to > refer to the element from within the same stanza via a sid of > some kind). Well... This was the first idea we had when designing Inband Images (thus the name), that we just attach BASE64 image to the and refer it from xhtml part. But it would prevent the reuse of already got images, and sender would waste bandwidth by sending the same smiley all over again. Thus we dropped the idea, and moved to the file transfer based method. -- /\_./o__ Tomasz Sterna (/^/(_^^' Xiaoka.com ._.(_.)_ XMPP: [EMAIL PROTECTED]
Re: [Standards] [Fwd: I-D Action:draft-cridland-sasl-tls-sessions-00.txt]
Dnia 09-11-2007, Pt o godzinie 23:34 +, Dave Cridland pisze: > In particular, think of it in terms of a (mythical?) server that > supports XEP-0198 as well. jabberd 2.1 supports XEP-0198 although only on the very basic level. -- /\_./o__ Tomasz Sterna (/^/(_^^' Xiaoka.com ._.(_.)_ XMPP: [EMAIL PROTECTED]
Re: [Standards] s2s blocking of abusive users
Dnia 09-11-2007, Pt o godzinie 15:58 -0700, Peter Saint-Andre pisze: > > I meant rate limiting (simply stopping reading is enough - TCP will > > handle the rest :). > > Yes that is the most radical form of rate limiting. :) Oh. I realized that I'm being to sparse. I meant, "stopping reading for a while". If you allow 10kb per second, you just read no more than 10kb in a second and pause. Then after one second read another no more than 10kb. The TCP buffering, timeouts and retransmission will handle the rest, thus you will effectively enforce the peer to transmit no faster than 10kbps. -- /\_./o__ Tomasz Sterna (/^/(_^^' Xiaoka.com ._.(_.)_ XMPP: [EMAIL PROTECTED]
Re: [Standards] Binary data over XMPP
Dnia 09-11-2007, Pt o godzinie 10:23 -0800, Justin Karneges pisze: > Each session is given a unique id. There is no "guessing" for the > server to > do, because no two sessions would be given the same id. Right. I've reread the XEP and there is no confusion for me anymore. > Why is this thread still going? :) I think, the amount of text and its formatting in XEP-0198 is overwhelming. All the people I talked about it with said, that it's very hard to grasp and we almost need to methodically decipher it. ;-) -- /\_./o__ Tomasz Sterna (/^/(_^^' Xiaoka.com ._.(_.)_ XMPP: [EMAIL PROTECTED]
Re: [Standards] s2s blocking of abusive users
Dnia 09-11-2007, Pt o godzinie 13:42 -0700, Peter Saint-Andre pisze: > Hmm. By "throttled me" do you mean "shut down s2s entirely" or "rate > limited s2s"? I meant rate limiting (simply stopping reading is enough - TCP will handle the rest :). But as you mention, dropping the stream with clear abuse-related error could work too. The abuser server will probably log the error and administrator could see it. > I agree that proactive is better. So are you suggesting > that how the jabber.org admins handled this last time was OK and that > we don't need better mechanisms for reporting abuse? When you couldn't reach the admin of the abusing server, it was the right thing to do. > One thing that would help is better communication among the admins who > run XMPP IM services. Shouldn't XEP-0157 help with that? We should take some serious actions to promote and encourage its adoption. > Like a real community of admins who have to deal > with the day-to-day issues [...] Does SMTP have this community of admins? I think we're quickly reaching the adoption point, when we just cannot know "all the guys" and learn how to live and deal with it. -- /\_./o__ Tomasz Sterna (/^/(_^^' Xiaoka.com ._.(_.)_ XMPP: [EMAIL PROTECTED]
Re: [Standards] OpenID for XMPP (Was: Authorization over HTTP)
Dnia 09-11-2007, Pt o godzinie 07:39 -0800, anders conbere pisze: > This is exactly why I'm talking about, and why openID is not a good > solution here. OpenID is fantastic at "prooving you're the user you > say you are" this means that we could safely /Authenticate/ with a > jabber server. but we want to do more than that, we want to grant a > client continued access to those restricted api's (in this case roster > add / remove / request and maybe message sending). How very untrue... http://openid.net/specs/openid-attribute-exchange-1_0-07.html This is the protocol my OpenID gives my e-mail addresses, birthdate, gender, avatar, PO address, my JIDs and other IM IDs, and many more, to the requesting parties. During first login to the site with OpenID I'm informed which pieces of information the external party requested, and I'm able to choose which I want to give, and the period that the acceptance is valid (one-time, until some date or forever). -- /\_./o__ Tomasz Sterna (/^/(_^^' Xiaoka.com ._.(_.)_ XMPP: [EMAIL PROTECTED]
