[Standards] 2019-11-14 XSF Board of Directors, weekly meeting
2019-11-14 XSF Board of Directors, weekly meeting ralphm bangs gavel at 15:31 Full house: everyone is present 1. Minute taker Nyco 2. Post-Election Hand-Over Phase https://mail.jabber.org/pipermail/members/2019-November/009028.html Debate happens... Motion: move date to Jan 1st, rejected 3. Web team CommTeam manages website repo, iTeam and board also have permissions 4. AOB Mediawiki upgrade for iTeam 5. Date of Next +1W ralphm bangs gavel at 16:05 Logs: https://logs.xmpp.org/xsf/2019-11-14#2019-11-14-36b0069be768e993 -- Nicolas Vérité (Nÿco) ᐧ ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] CS-2019 Badges - Who Cares?!
Indeed, the poll is on members@, and we have 17 responses so far. I'll bring that to the board meeting on Thursday. ᐧ On Mon, Jul 22, 2019 at 5:43 PM Dave Cridland wrote: > B, E, F. > > Also G - the poll was on members@ rather than here, and it might actually > be interesting to poll the wider standards community and/or jdev. Maybe. > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _______ > -- Nicolas Vérité (Nÿco) ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XMPP Compliance Badges, prototype feedback requested.
Hi all, So we'd like to collect your qualitative feedback, as much as possible. We'll proceed to a poll later. What do you think of these three options? Thanks a lot Regards ᐧ On Thu, May 23, 2019 at 1:03 PM Guus der Kinderen < guus.der.kinde...@gmail.com> wrote: > Hello, > > There's an effort under way to have developed visual badges associated to > the XMPP Compliance Suites. > > To my knowledge, three variants of badges are under development: > >- https://op-co.de/tmp/xmpp-compliance-badges/ >- https://bitbucket.org/mrtedd/compliance-badges/src >- > > https://opensourcedesign.net/jobs/jobs/2019-03-19-design-of-badges-for-different-xmpp-compliance-levels > > We're looking for feedback on the visual quality and content of these > prototypes. Anything that will help the authors to improve them, as well as > for us to eventually choose between them, is highly appreciated. > > Kindly provide feedback. :) > > Regards, > > Guus > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > -- Nicolas Vérité (Nÿco) ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] On making "Compliance Suite 20xx" a Non-XEP
On Wed, Feb 8, 2017 at 10:29 AM, Dave Cridland wrote: > On 7 February 2017 at 16:25, Georg Lukas wrote: > Also, who gets to make changes? How are those agreed? > Council, like all XEPs, not much doubt about it. Right? > All a XEP is, is simply a document with a process wrapped around it. > And it’s good, let’s just keep it, and have on doubt about it? > I'm *all* in favour of linking directly into it, and our boilerplate > sections are all down at the bottom so they're quick to dive into. > > We shouldn't be referring to XEP-0375, really, we should be referring > to the (deliberately) "Marketing" terms of "Core Server 2017" and so > on - that's why we created those terms. These need links on the > website directly into the document, and perhaps some user > documentation around them. > Yes, it is all about lowering the barrier of entry for server+client+… devs. -- Nicolas Vérité (Nÿco) ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] On making "Compliance Suite 20xx" a Non-XEP
On Tue, Feb 7, 2017 at 5:33 PM, Sam Whited wrote: > On Tue, Feb 7, 2017 at 10:25 AM, Georg Lukas wrote: > > Can we make the "Compliance Suite" a stand-alone document that is not an > > XEP? > > There is a lot of process around publishing and updating an XEP. It > requires discussion, approval from the council or board (once draft > status is reached), etc. I think this is good for the compliance > suites. It reduces the agility, but also means changes are well vetted > by the community (a wiki page or some other document may not do that). > > I'd be all for a BCP style document that acts as a pointer to the > compliance suites, but I don't personally want to try and set up > infrastructure for maintaining those documents, or try to figure out > what the procedures look like for publishing them, etc. it sounds like > a lot of work for very little benefit to me. Oops, confusions around that: the CS would still undergo a XEP process. Only it would be published in a more visible place, probably with more readability. > - having this as a non-XEP might increase the maintenance burden or > > reduce the "credibility" of the document > > I agree. > > I don't want to completely shut down the discussion, but I'm not sure > it's useful. While I'm writing these I'm just going to submit new > documents. If someone else wants to take over and figure out a > different way, I'm happy to let them work on it instead. > > —Sam > Once again, trying to clarify the discussion: * still keep and apply the XEP process (it’s awesome) * make it easier to discover and adopt -- Nicolas Vérité (Nÿco) ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] MSN does XMPP
On Thu, Sep 15, 2011 at 18:05, Coyo Stormbringer wrote: > bow chicka wow w-- *AHEM* > > probably meaning chat.facebook.com. > > On 9/15/2011 11:00 AM, Justin Karneges wrote: >> >> On Thursday, September 15, 2011 02:09:20 AM dmex wrote: >>> >>> Microsoft has been doing XMPP for the last 6 months or so with facebook >>> via >>> an xmpp service running at 'beta.xmpp.messenger.live.com' and it looks >>> like >>> its now public. >> >> What do you mean "with facebook" ? Yes, they have apparently the same approach: offering border gateway, to their internal chat system, still running on proprietary protocol. -- Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com Jabber ID : xmpp:n...@jabber.fr
Re: [Standards] MSN does XMPP
On Wed, Sep 14, 2011 at 20:52, Peter Saint-Andre wrote: > On 9/14/11 12:49 PM, Dave Cridland wrote: >> Running some >> interop tests > > Perhaps it's time for another online interop test? Perhaps it's time to go further than these interop tests? -- Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com Jabber ID : xmpp:n...@jabber.fr
[Standards] MSN does XMPP
Hi, Thanks for those of you who twitted it: http://www.liveside.net/2011/09/14/messenger-connect-is-now-live-connect-new-apis-for-skydrive-and-hotmail-calendar/ XMPP Interface : You can integrate Messenger into your Web-based, desktop, or mobile instant messaging products by connecting to our XMPP service. It's Microsoft! Quite a sign... but... Now, what we may see is cheating on the protocol, interop risks. What do we have to prevent this? Nothing. Certification is far too complex and costly (for all). Simple tests (like ACID) may be a good way: with public testing and results, it lets the communities booh the cheaters. I think it's the most important task we have now. What is your opinion? -- Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com Jabber ID : xmpp:n...@jabber.fr
Re: [Standards] Correcting last message
On Tue, Jul 20, 2010 at 11:19, Kevin Smith wrote: > Following a discussion in jdev, I've thrown together the skeleton of a > XEP for correcting previous messages. > I'll clean it up before submitting, but the rough gist is at: > http://www.doomsong.co.uk/extensions/render/xep-correct.html > Discussion welcome. Additionally, we can also forbid, or deeply advice to forbid, message deletion. -- Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com Jabber ID : xmpp:n...@jabber.fr
Re: [Standards] Correcting last message
2011/3/25 Mark Rejhon : > It also operates in chat too. Back in 1992, I created the equivalent > of Unix 'talk' that allowed cursor up/down, going back even to the > beginning of the conversation. > > The real time text standard also allows representation as either a > traditional IM conversation, and splitscreen, so the same effect can > be achieved. > > That said, all the concerns about not allowing deep retroactivity is > valid, and that is why I leave it out. However, I did like the deep > retroactive feature during conversations -- it was useful, and due to > the cursor movement capability (which also exists in the real time > text standard), it allows the remote person to backscroll too -- so > was useful for showing me stuff I missed, too. > > Mark Rejhon Having experienced chat clients with editing features, I can oppose two clearly different behaviours: 1/ only one edit, only last message: ** no cheat, users feel safe with other's chat messages ** you know what you can do or not, and learn to live with 2/ infinite edits, all messages: ** you just restrict yourself, because you deeply know it's wrong to edit everything every time ** users do not trust the client, nor the contact ** lots of unwanted side-effects in histories and logs ** uncompatible clients suffer ** etc. If it does not appear as mandatory in the XEP, it needs at least to be strongly adviced. > On 3/25/11, Nicolas Vérité wrote: >> Please just don't forget that chat is completely different text _editing_... >> >> On Fri, Mar 25, 2011 at 16:42, Mark Rejhon wrote: >>> Hello, >>> >>> I am authoring the Real Time Text, along with members of >>> realtimetext.org (Gunnar, etc). The old draft is at >>> http://www.realjabber.org/realtimemtext.html ... but is currently >>> being rewritten and simplified for 0.02 resubmission. >>> >>> I have a private extension to my real time text standard that allows >>> unlimited retroactive editing via indexing the message line via a >>> "msg" parameter. >>> >>> It would have been useful for: >>> - critical writing where deep-retroactive edits are desirable. >>> - Real time transcription of court reporting >>> - Real time captioning workflows where a caption editor works at the >>> same time as a transcriber on adjacent computers. >>> - it is MUC compatible (although not supported by my 0.02 spec except >>> as a private extension) for one-to-many transmission, like to multiple >>> audience members or several TV stations, that needs a hook into the >>> feed. They can reject or accept edits before X lines automatically, >>> as needed... >>> >>> Logging would have been done by: >>> - Retransmitting any changed lines in a body element, everytime Enter >>> is hit, or cursor arrow up/down goes out of bounds of the current line >>> (cursor moves to adjacent line) >>> >>> Edits prievious to the current line can be automatically color-coded >>> and highlighted automatically, to make it much harder to miss edits. >>> My real time text standard also includes support for cursor position >>> transmissions (which can be optionally rendered for a visible cursor) >>> which makes it even easier to watch somebody make an edit. >>> >>> The retroactive editing feature is not an official part of my real >>> time text standard as I had decided to leave it out, but to allow it >>> to be added on as a private extension, if needed. >>> >>> Please be noted all of this is being left out of 0.02 of my real time >>> text standard for simplicity. >>> >>> However, it would be worth some thought how your retroactive edit >>> standard, may help (or interfere) with my technique of retroactive >>> editing, and to make sure that our standards are compatible. >>> >>> Thanks! >>> Mark Rejhon >>> (Authoring the XMPP Real Time Text Standard) >>> >>> On 3/25/11, Remko Tronçon wrote: >>>>> Only the latest message seems overly restrictive (especially if the last >>>>> message you send it "oops"). I'd say a buffer of, say, the last 5 >>>>> messages might be appropriate. >>>> >>>> For the same reason, I think that only one edit is overly restrictive. >>>> I have needed several edits to get a one-sentence IM message right :-) >>>> >>>> I don't see a reason to put in arbitrary restrictions in the protocol >>>> (different use cases can warrant different limits); i wouldn't mind >>>> recommendations, though. >>>> >>>> As long as the client indicates that a message has been edited X times >>>> (and provides the original message), i don't really see any issues. >>>> >>>> cheers, >>>> Remko >>>> >>> >>> -- >>> Sent from my mobile device >>> >> >> >> >> -- >> Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com >> Jabber ID : xmpp:n...@jabber.fr >> > > -- > Sent from my mobile device > -- Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com Jabber ID : xmpp:n...@jabber.fr
Re: [Standards] Correcting last message
On Fri, Mar 25, 2011 at 17:01, Florian Zeitz wrote: > Am 25.03.2011 16:48, schrieb Kevin Smith: >> On Fri, Mar 25, 2011 at 3:41 PM, Nicolas Vérité >> wrote: >>> On Fri, Mar 25, 2011 at 16:30, Kevin Smith wrote: >>>> On Fri, Mar 25, 2011 at 2:53 PM, Nicolas Vérité >>>> For only one edit, I'm not sure this is necessary for interop (and >>>> therefore to include in the spec) - but clients are free to not render >>>> an edit as an edit if they feel they don't want to for some reason. >>> >>> Drrring. Wrong. This is a strong user demand, maybe the strongest. It >>> is mandatory to clearly state an edit as an edit. Or show the original >>> along with the corrected (strike formatting, or whatever, if you >>> want). >> >> Right, clients are free to render this however they want to. Perhaps I >> should add an "I wasn't willing to render this as an edit" error? >> >> That way if a client wanted to reject edits after the first one, it >> could, and if it wanted to allow them, it could. >> >> Does that work for your user requirements (your users would never send >> a subsequent message, of course, so would never encounter the error - >> but would send it if a more liberal client were try and edit >> something)? >> > Since I have a feeling there might be a slight misunderstanding here I'm > gonna ask: > By "Not render this as an edit" do you mean: > a) Ignore the stanza an pretend there was no edit > b) Do the edit, but provide no visible feedback of this > > I suspect you meant a), but Nicolas thought you meant b). Ah, seems like native English speaker do understand themselves, as much as non-native English speakers understand each other... ;-) -- Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com Jabber ID : xmpp:n...@jabber.fr
Re: [Standards] Correcting last message
Please just don't forget that chat is completely different text _editing_... On Fri, Mar 25, 2011 at 16:42, Mark Rejhon wrote: > Hello, > > I am authoring the Real Time Text, along with members of > realtimetext.org (Gunnar, etc). The old draft is at > http://www.realjabber.org/realtimemtext.html ... but is currently > being rewritten and simplified for 0.02 resubmission. > > I have a private extension to my real time text standard that allows > unlimited retroactive editing via indexing the message line via a > "msg" parameter. > > It would have been useful for: > - critical writing where deep-retroactive edits are desirable. > - Real time transcription of court reporting > - Real time captioning workflows where a caption editor works at the > same time as a transcriber on adjacent computers. > - it is MUC compatible (although not supported by my 0.02 spec except > as a private extension) for one-to-many transmission, like to multiple > audience members or several TV stations, that needs a hook into the > feed. They can reject or accept edits before X lines automatically, > as needed... > > Logging would have been done by: > - Retransmitting any changed lines in a body element, everytime Enter > is hit, or cursor arrow up/down goes out of bounds of the current line > (cursor moves to adjacent line) > > Edits prievious to the current line can be automatically color-coded > and highlighted automatically, to make it much harder to miss edits. > My real time text standard also includes support for cursor position > transmissions (which can be optionally rendered for a visible cursor) > which makes it even easier to watch somebody make an edit. > > The retroactive editing feature is not an official part of my real > time text standard as I had decided to leave it out, but to allow it > to be added on as a private extension, if needed. > > Please be noted all of this is being left out of 0.02 of my real time > text standard for simplicity. > > However, it would be worth some thought how your retroactive edit > standard, may help (or interfere) with my technique of retroactive > editing, and to make sure that our standards are compatible. > > Thanks! > Mark Rejhon > (Authoring the XMPP Real Time Text Standard) > > On 3/25/11, Remko Tronçon wrote: >>> Only the latest message seems overly restrictive (especially if the last >>> message you send it "oops"). I'd say a buffer of, say, the last 5 >>> messages might be appropriate. >> >> For the same reason, I think that only one edit is overly restrictive. >> I have needed several edits to get a one-sentence IM message right :-) >> >> I don't see a reason to put in arbitrary restrictions in the protocol >> (different use cases can warrant different limits); i wouldn't mind >> recommendations, though. >> >> As long as the client indicates that a message has been edited X times >> (and provides the original message), i don't really see any issues. >> >> cheers, >> Remko >> > > -- > Sent from my mobile device > -- Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com Jabber ID : xmpp:n...@jabber.fr
Re: [Standards] Correcting last message
On Fri, Mar 25, 2011 at 16:30, Kevin Smith wrote: > On Fri, Mar 25, 2011 at 2:53 PM, Nicolas Vérité > For only one edit, I'm not sure this is necessary for interop (and > therefore to include in the spec) - but clients are free to not render > an edit as an edit if they feel they don't want to for some reason. Drrring. Wrong. This is a strong user demand, maybe the strongest. It is mandatory to clearly state an edit as an edit. Or show the original along with the corrected (strike formatting, or whatever, if you want). -- Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com Jabber ID : xmpp:n...@jabber.fr
Re: [Standards] Correcting last message
2011/3/25 Remko Tronçon : >> Only the latest message seems overly restrictive (especially if the last >> message you send it "oops"). I'd say a buffer of, say, the last 5 >> messages might be appropriate. > > For the same reason, I think that only one edit is overly restrictive. > I have needed several edits to get a one-sentence IM message right :-) > > I don't see a reason to put in arbitrary restrictions in the protocol > (different use cases can warrant different limits); i wouldn't mind > recommendations, though. > > As long as the client indicates that a message has been edited X times > (and provides the original message), i don't really see any issues. Well, the Standards ML and the Council can do what it wants of the implementor and user feedback... Who else has implemented a correction feature? What user have said about it? Don't forget that we are in the proces of allowing to modify (a) past message(s)... it is a huge trickery concern. Also, what do you want to do with encrypted messages? -- Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com Jabber ID : xmpp:n...@jabber.fr
Re: [Standards] Correcting last message
On Fri, Mar 25, 2011 at 15:59, Peter Saint-Andre wrote: > On 3/25/11 8:53 AM, Nicolas Vérité wrote: > >> Just one common feedback from our most technical users: >> we should: >> 1/ forbid the edition/correction of other messages than the last >> 2/ authorize the correction only once >> Because otherwise: >> A/ you could mess up with client and servers histories/logs >> B/ you could have a real time conversation with someone, but >> afterwards correct everything >> >> Summary: >> * only one edit >> * only the latest message > > Only the latest message seems overly restrictive (especially if the last > message you send it "oops"). I'd say a buffer of, say, the last 5 > messages might be appropriate. In fact, no, it's not too restrictive. Besides, it is really a common user feedback we had in our private alpha period. People want restrictions. Or else, they fear that the history is changed. We thought like you before, but we had to listen to our users. If you were wrong, just don't say "oops", just correct you message... 5 messages is far too many, since it could totally change a discussion. More than one edit, is also too many. OK, let's think this stupid example (sorry, I got no imagination): Nyco: Hi Peter, how are you? Peter: I'm fine, thank you Nyco: and how is your work? Peter: it is fine too Nyco: OK, bye Peter has left the conversation Now since I'm malicious, I'll change my messages. Here is the modified history: Nyco: Hi Peter, how are you since you were painted in blue? Peter: I'm fine, thank you Nyco: and how about being dressed in green penguin with tentacles? Peter: it is fine too Nyco: wow, then Peter has left the conversation How can we prevent this? (because we must prevent this... do you disagree?) -- Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com Jabber ID : xmpp:n...@jabber.fr
Re: [Standards] Correcting last message
On Fri, Mar 25, 2011 at 15:46, Kevin Smith wrote: > On Fri, Mar 25, 2011 at 2:43 PM, Nicolas Vérité > wrote: >> On Tue, Jul 20, 2010 at 11:19, Kevin Smith wrote: >>> Following a discussion in jdev, I've thrown together the skeleton of a >>> XEP for correcting previous messages. >>> I'll clean it up before submitting, but the rough gist is at: >>> http://www.doomsong.co.uk/extensions/render/xep-correct.html >>> Discussion welcome. >> >> Hi all, >> >> Not much discussion on this, it either means it is perfect... or >> no-one has interest in it. ;-) >> >> We are nearing a release of OneTeam Desktop beta2, with a real UI/UX >> for the correction feature. For now we are just sending and >> interpreting a substitution string à la vi (s/wrong/right/). It can be >> considered a fallback to this XEP. So we are ready to implement it. >> >> Can we advance this XEP? > > Or turn it into a XEP, even. > > Council have roughly agreed (two weeks ago, I think) to publish this > as soon as I finish off a couple of details that I now forget. I've > just been pretty busy. I will move it up my priority pile. Ah, good news, excellent! Then maybe we can start implementing it. Just one common feedback from our most technical users: we should: 1/ forbid the edition/correction of other messages than the last 2/ authorize the correction only once Because otherwise: A/ you could mess up with client and servers histories/logs B/ you could have a real time conversation with someone, but afterwards correct everything Summary: * only one edit * only the latest message We could also suggest client and logger implementors to provide a UI to switch back and forth to the original and corrected messages. -- Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com Jabber ID : xmpp:n...@jabber.fr
Re: [Standards] Correcting last message
On Tue, Jul 20, 2010 at 11:19, Kevin Smith wrote: > Following a discussion in jdev, I've thrown together the skeleton of a > XEP for correcting previous messages. > I'll clean it up before submitting, but the rough gist is at: > http://www.doomsong.co.uk/extensions/render/xep-correct.html > Discussion welcome. Hi all, Not much discussion on this, it either means it is perfect... or no-one has interest in it. ;-) We are nearing a release of OneTeam Desktop beta2, with a real UI/UX for the correction feature. For now we are just sending and interpreting a substitution string à la vi (s/wrong/right/). It can be considered a fallback to this XEP. So we are ready to implement it. Can we advance this XEP? Regards -- Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com Jabber ID : xmpp:n...@jabber.fr
Re: [Standards] NEW: XEP-0286 (XMPP on Mobile Devices)
It is a 404. On Wed, Sep 15, 2010 at 22:46, XMPP Extensions Editor wrote: > Version 0.1 of XEP-0286 (XMPP on Mobile Devices) has been released. > > Abstract: This document provides background information for XMPP implementors > concerned with mobile devices operating in a cellular network such as 3G. > > Changelog: Initial published version. (psa) > > Diff: N/A > > URL: http://xmpp.org/extensions/xep-0286.html > > -- Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com Jabber ID : xmpp:n...@jabber.fr http://linuxfr.org/ - http://fr.wikipedia.org/ - http://www.jabberfr.org/ http://xmpp.org - http://april.org/ - http://qsos.org/
[Standards] Apple's FaceTime uses XMPP
Hi all, This Twitter status says: http://twitter.com/williamsjoe/status/18388944778 http://bit.ly/cuHUFE http://bit.ly/9wf14R http://bit.ly/bUKO8b (via @melgray) [ed. interesting stuff, FaceTime uses HTTPS, SIP, STUN & XMPP] Let's follow the links: http://www.packetstan.com/2010/07/special-look-face-time-part-1.html http://www.packetstan.com/2010/07/special-look-face-time-part-2-sip-and.html http://www.packetstan.com/2010/07/special-look-face-time-part-3-call.html -- Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com Jabber ID : xmpp:n...@jabber.fr http://linuxfr.org/ - http://fr.wikipedia.org/ - http://www.jabberfr.org/ http://xmpp.org - http://april.org/ - http://qsos.org/
Re: [Standards] SXE redux
We may also need to talk with Fabien Cazenave and Sonny Piers: http://x-home.hd.free.fr/projects/sxEdit/report/index.html On Tue, Jun 15, 2010 at 22:15, Arc Riley wrote: > Is there any effort to collaborate with the Infinote developers? > > http://gobby.0x539.de/trac/wiki/Infinote > > On Wed, Jun 9, 2010 at 1:53 PM, Peter Saint-Andre > wrote: >> >> Over the last few months I've been working with Tom Pusateri on some >> updates to the Shared XML Editing spec, based on his implementation >> experience. As a result, we have updated the proposal: >> >> http://xmpp.org/extensions/inbox/sxe.html >> >> At its next meeting, I will ask the XMPP Council to consider accepting >> this as an official XEP. >> >> Peter >> >> -- >> Peter Saint-Andre >> https://stpeter.im/ >> >> >> > > -- Nicolas Vérité - ProcessOne http://process-one.net Mobile: +33 6 20 88 63 04
Re: [Standards] NEW: XEP-0279 (Server IP Check)
On Fri, Mar 12, 2010 at 14:22, thiagoc wrote: > This is indeed a trivial XEP Maybe too trivial? ;-) I wouldn't say naive... ;-) >, for Audio, it can help know if the > client is behind a NAT, yes. I would rather say it might help. The chances it helps are quite low as I understand it now. Do we want that overhead for just adding a few chances? Please tell me if I am pessimistic ;-) > Does it says it is the same NAT to be > used when user places a Voice Call over UDP? Absolutely not. But I'm > quite convinced that it can give hints. > > But I still see a point on it, which is when we may have deployment of > XMPP Servers, which can have provide Hints about NAT, without STUN > requirement. (Yes, we all know STUN is more reliable for UDP). > The goal for me is not to have the retrieve IP as Jingle Candidate, > but how will I describe my local address type. This is specially > useful for gateway between Jingle and SIP for instance. Where u can > have a hint, that the call should be proxies as the client knows for > sure he is behind a NAT. (Considering 99% of all SIP deployments does > not support ICE properly) > > Unfortunately we still need to think about SIP deployment compatibility. STUN? (joking... ;-) ) -- Nicolas Vérité - ProcessOne http://process-one.net Mobile: +33 6 20 88 63 04
Re: [Standards] XEP-0279 (Server IP Check)
On Fri, Mar 12, 2010 at 13:39, thiagoc wrote: > Hi, > > I'm satisfied with current XEP, as it solves most demand and necessities. > Client sending its IP to server without per requests is odd, as the > XMPP server already have such information. (Which is not trusted > anyway, though) > The IQ request is nice and current I make use of it, for several other > reasons like throttle, network profile etc... Can you please detail that? > I'm happy with the current one, if major servers have that. would > already be a great first step. > > Regards, > Thiago -- Nicolas Vérité - ProcessOne http://process-one.net Mobile: +33 6 20 88 63 04
Re: [Standards] NEW: XEP-0279 (Server IP Check)
On Fri, Mar 12, 2010 at 14:02, Matthew Wild wrote: > On 12 March 2010 10:37, Nicolas Vérité wrote: >> On Fri, Mar 5, 2010 at 19:53, XMPP Extensions Editor wrote: >>> Version 0.1 of XEP-0279 (Server IP Check) has been released. >>> >>> Abstract: This specification defines a simple XMPP extension that enables a >>> client to discover its external IP address. >>> >>> Changelog: Initial published version. (psa) >>> >>> Diff: N/A >>> >>> URL: http://xmpp.org/extensions/xep-0279.html >> >> I am really confused here: Are we reinventing the wheel? Why add this >> entropy? STUN is there, well thought out, coded and strongly tested, >> though maybe a bit complex. If we (improve and) accept this XEP, then >> what CAN/SHOULD/MUST clients and/or servers implement then? STUN >> and/or SIC? > > If they're looking for media relay candidates, STUN. You meant TURN? This has not much to do with our thread here. > I think the XEP needs to be updated to make this clear. Could the > people interested in seeing this XEP implemented perhaps suggest some > alternative text for the introduction? The intro might not be the place to work out most in this phase. I believe we first need to address philosophy issues (iq or stream feature?), then setup rules for clients and servers developers saying what to use first, and what else as a fallback. -- Nicolas Vérité - ProcessOne http://process-one.net Mobile: +33 6 20 88 63 04
Re: [Standards] A "broadcast" attribute to ?
On Fri, Mar 12, 2010 at 12:07, Dave Cridland wrote: > On Fri Mar 12 10:52:06 2010, Laurent Eschenauer wrote: >> >> Am I missing a point ? Any other work or proposal already tackling this ? > > http://xmpp.org/internet-drafts/draft-ietf-xmpp-3921bis-05.html#message-syntax-type > > * headline -- [...] The receiving server SHOULD deliver the message to all > of the recipient's available resources.HTH, Well, this is a "SHOULD" that only appears in the bis version of RFC3921. As far as I know, for headline messages, servers are generally respecting the priority and resource routing rules, and are not broacasted to all resources disregarding their priorities.Still as far as I know, the routing is handled the same way with chat and headline, at least in ejabberd I believe it is the case. What about other servers? In GTalk, headlines result in feature-not-implemented, but are still delivered. I believe any first message chat/headline is delivered to all resources disregarding the priorities. -- Nicolas Vérité - ProcessOne http://process-one.net Mobile: +33 6 20 88 63 04
Re: [Standards] A "broadcast" attribute to ?
On Fri, Mar 12, 2010 at 12:07, Dave Cridland wrote: > On Fri Mar 12 10:52:06 2010, Laurent Eschenauer wrote: >> >> Am I missing a point ? Any other work or proposal already tackling this ? > > http://xmpp.org/internet-drafts/draft-ietf-xmpp-3921bis-05.html#message-syntax-type > > * headline -- [...] The receiving server SHOULD deliver the message to all > of the recipient's available resources.HTH, It will not be an offline message though, right? -- Nicolas Vérité - ProcessOne http://process-one.net Mobile: +33 6 20 88 63 04
Re: [Standards] NEW: XEP-0279 (Server IP Check)
On Fri, Mar 5, 2010 at 19:53, XMPP Extensions Editor wrote: > Version 0.1 of XEP-0279 (Server IP Check) has been released. > > Abstract: This specification defines a simple XMPP extension that enables a > client to discover its external IP address. > > Changelog: Initial published version. (psa) > > Diff: N/A > > URL: http://xmpp.org/extensions/xep-0279.html I am not quite also what would happen with BOSH: if there's separate BOSH CMs and/or reverse proxies in the middle... -- Nicolas Vérité - ProcessOne http://process-one.net Mobile: +33 6 20 88 63 04
Re: [Standards] A "broadcast" attribute to ?
On Fri, Mar 12, 2010 at 11:52, Laurent Eschenauer wrote: > Hi everyone, > > In onesocialweb, our use cases imply that all connected resources > should receive a message when sent to the bare JID. It is simple to > understand why: although your desktop client may be open, you may > still want your phone to vibrate when a new updates come in, and you > absolutely one that update to be visible in your 'inbox' when you pick > up your phone at a later time. > > Today, we can achieve this by using server specific logic (in > openfire: route.all-resources=true) but that has an impact on all > messages from all services (and we may want to keep the usual behavior > for chat, or whatever else). > > I was wondering if there was any possibility for the sender (client or > server) to specify that the message being sent should ideally be > broadcasted to all resources (having positive priority to complain > with the rest of the spec). > http://xmpp.org/rfcs/rfc3921.html#rules > > So, what about an additional "broadcast" message attribute for this ? > I think there are more uses cases where you may want to use XMPP as a > "messaging bus" between the connected resources of a user. > > Am I missing a point ? Any other work or proposal already tackling this ? > > Thanks for the feedback ! > > -Laurent There is XEP-0033: Extended Stanza Addressing that might partially address your need: http://xmpp.org/extensions/xep-0033.html Also I'm not sure, but if you control all your client connections, you might want all resources to connect with the same priority (dirty hack?). -- Nicolas Vérité - ProcessOne http://process-one.net Mobile: +33 6 20 88 63 04
Re: [Standards] NEW: XEP-0279 (Server IP Check)
On Mon, Mar 8, 2010 at 14:33, Tomasz Sterna wrote: > 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. I believe this a cleaner solution, both on the number of required round trips, as well as at a protocol cleanness point of view: this should not be inside an iq, but at the stream level. -- Nicolas Vérité - ProcessOne http://process-one.net Mobile: +33 6 20 88 63 04
Re: [Standards] NEW: XEP-0279 (Server IP Check)
On Sat, Mar 6, 2010 at 05:24, Evgeniy Khramtsov wrote: > XMPP Extensions Editor wrote: >> >> Version 0.1 of XEP-0279 (Server IP Check) has been released. >> >> Abstract: This specification defines a simple XMPP extension that enables >> a client to discover its external IP address. >> >> Changelog: Initial published version. (psa) >> >> Diff: N/A >> >> URL: http://xmpp.org/extensions/xep-0279.html > > Why not use STUN? Am I mistaking, or this question has not been answered on this thread? -- Nicolas Vérité - ProcessOne http://process-one.net Mobile: +33 6 20 88 63 04
Re: [Standards] NEW: XEP-0279 (Server IP Check)
On Fri, Mar 5, 2010 at 19:53, XMPP Extensions Editor wrote: > Version 0.1 of XEP-0279 (Server IP Check) has been released. > > Abstract: This specification defines a simple XMPP extension that enables a > client to discover its external IP address. > > Changelog: Initial published version. (psa) > > Diff: N/A > > URL: http://xmpp.org/extensions/xep-0279.html I am really confused here: Are we reinventing the wheel? Why add this entropy? STUN is there, well thought out, coded and strongly tested, though maybe a bit complex. If we (improve and) accept this XEP, then what CAN/SHOULD/MUST clients and/or servers implement then? STUN and/or SIC? -- Nicolas Vérité - ProcessOne http://process-one.net Mobile: +33 6 20 88 63 04
Re: [Standards] XEP-0048 bookmarks
On Mon, Mar 8, 2010 at 13:36, Kevin Smith wrote: > On Mon, Mar 8, 2010 at 11:28 AM, Nicolas Vérité > wrote: >> Clients: >> I believe most clients, if no all, support XEP-0049. I believe only a >> few clients support bookmarks over XEP-0223 (I don't know of any). >> Servers: >> I believe too few servers support PubSub. I believe none supports >> HTTP/WebDAV. > >> Any best practice or hint? Or w're stuck on a historical XEP? > > I think the sensible thing for clients to do is to use 223 if it's > available, and fall back to 49 if it's not. Agree... > For servers, I think there > is merit in exposing the same data through both -49 and -223 for stuff > like this, where that's feasible. Offering both will not encourage the clients migration, right? -- Nicolas Vérité - ProcessOne http://process-one.net Mobile: +33 6 20 88 63 04
[Standards] XEP-0048 bookmarks
Hi all, The main difference between versions 1.0 and 1.1 of the bookmarks XEP is the previous use of XEP-0049: Private XML Storage, and the new recommandation of use of XEP-0223: Persistent Storage of Private Data via PubSub. The section 3 even mentions other storage methods, such as HTTP/WebDAV. http://xmpp.org/extensions/attic/xep-0048-1.0.html http://xmpp.org/extensions/xep-0048.html http://xmpp.org/extensions/xep-0048.html#storage How are clients and servers supposed to manage the transition and/or synchronization from one to another? Clients: I believe most clients, if no all, support XEP-0049. I believe only a few clients support bookmarks over XEP-0223 (I don't know of any). Servers: I believe too few servers support PubSub. I believe none supports HTTP/WebDAV. Any best practice or hint? Or w're stuck on a historical XEP? -- Nicolas Vérité - ProcessOne http://process-one.net Mobile: +33 6 20 88 63 04
Re: [Standards] Fwd: Meeting minutes 2010-02-15
On Thu, Feb 18, 2010 at 14:51, Peter Saint-Andre wrote: >> 2. Compression makes multicast structures unnecessary. > > It does? A lot of people are skeptical about the argument "oh don't > worry about how verbose this is, compression will solve the problem". Maybe that's true from a C2S bandwidth consumption point of view, but from a server routing mechanism perspective, it makes sense, if not mandatory for scalability. I wouldn't be completely sure about that. >> 4. This indeed is the worst of IRC brought to XMPP. > > Nice! What's needed to bring the *best* of IRC to XMPP? At least, by reproducing netsplits, the folks over there would feel confortable like at home. Is this what we need to bring their strength and support to an open federated network? Or else, ther's also the Poezio XMPP client, a console-based software that completely mimics the IRC-styme anonymosity and channels (no one-to-one chat, no presence, no roster, etc.): http://codingteam.net/project/poezio -- Nicolas Vérité - ProcessOne http://process-one.net Mobile: +33 6 20 88 63 04
Re: [Standards] XEP-0136 modifications
On Wed, Feb 3, 2010 at 20:10, Peter Saint-Andre wrote: > On 2/3/10 12:06 PM, Yann Leboulanger wrote: >> Peter Saint-Andre wrote: >>> Yann, I agree. I'd rather work to reduce complexity in XEP-0136 than to >>> increase complexity. Any suggestions? :) >>> >>> Peter >>> >> >> I'm not sure we can reduce complexity. In fact this XEP does 2 things: >> ability to save logs in server, and ability for clients to store their >> archiving preferences (for who we want to log, what to log, etc). But >> those 2 things are linked, so it's hard to reduce complexity to handle >> all cases. > > I've come to that conclusion, too, but I was hoping you could provide a > new perspective. :) Why not adding more complexity... to archive also Jingle calls, and file transfers? -- Nicolas Vérité - ProcessOne http://process-one.net Mobile: +33 6 20 88 63 04
[Standards] Confusing RFCbis
Hi there, Which one is the good one? http://tools.ietf.org/html/draft-ietf-xmpp-3921bis version 3 from November 17th http://tools.ietf.org/html/draft-saintandre-rfc3921bis version 8 from March 8th This is confusing since both are referenced by search engines. There's no such confusion for RFC3020bis. Thx -- Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com Jabber ID : xmpp:n...@jabber.fr http://linuxfr.org/ - http://fr.wikipedia.org/ - http://www.jabberfr.org/ http://xmpp.org - http://april.org/ - http://qsos.org/
Re: [Standards] PDFs!
On Mon, Nov 2, 2009 at 12:31, Kevin Smith wrote: > On Mon, Nov 2, 2009 at 11:30 AM, Tobias Markmann > wrote: >>> Since I don't have a clue, I'm asking here: >>> color coding rocks, would that be possible to have the same color code >>> in the XHTML version of the XEPs? >> Sure it's possible, the question is whether we want it. > > I think we do. Yes, the indentation is fine, and well documented. However, my eyes are not trained enough when code is monocolor. But they thank me when I read the PDF's code ;-) -- Nicolas Vérité - ProcessOne http://process-one.net Mobile: +33 6 20 88 63 04
Re: [Standards] PDFs!
On Wed, Oct 21, 2009 at 18:52, Peter Saint-Andre wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Thanks to great work by Tobias Markmann, the XSF now publishes PDF > versions of its specifications. You can find them here: > > http://xmpp.org/extensions/ > > We're still working out a few glitches here and there, so your feedback > is appreciated. Since I don't have a clue, I'm asking here: color coding rocks, would that be possible to have the same color code in the XHTML version of the XEPs? -- Nicolas Vérité - ProcessOne http://process-one.net Mobile: +33 6 20 88 63 04
[Standards] Registrar, Service Discovery Identities: StatusNet/Laconica and Twitter
Hi all, In the Service Discovery, we are missing the StatusNet/Status.net (formely known as Laconica/Laconi.ca) and Twitter: http://xmpp.org/registrar/disco-categories.html#gateway This would add: These are the two main micro-blogging software and services, it would be useful to add them. On the other hand, maybe it's not useful to list the lesser-known ones, like Jaiku, Pownce, Yahoo! Meme, Yammer, Plurk, Present.ly, Tumblr... Non-exhaustive list, of course. What do you think of it? Regards -- Nicolas Vérité - ProcessOne http://process-one.net Mobile: +33 6 20 88 63 04
Re: [Standards] XEP-0080: User Location
On Tue, Jul 21, 2009 at 4:23 PM, Tomasz Sterna wrote: >> 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? IMHO no, and that's the point. In the XEP, we only use GPS. Do we want to be it: - exhaustive (and add, GSM, wifi, etc.) - technology-agnostic (and remove GPS) ? -- Nicolas Vérité - ProcessOne http://process-one.net Mobile: +33 6 20 88 63 04
Re: [Standards] Issue tracker for XEPs?
Sorry to ask, but has something been done? Is a Jira accessible somewhere yet? Need some more help? 2009/7/7 Jiří Zárevúcky : > 2009/7/7 Peter Saint-Andre : >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 7/7/09 1:06 PM, Kevin Smith wrote: >>> 2009/7/7 Peter Saint-Andre : >>>>>> Sure. Indeed I prefer it. I just figured I'd test the issue tracker >>>>>> since that's what the IETF Tools Team has given us. :) >>>>> Have you thought about setting up an issue tracker for XEPs? >>>>> I think it would be very nice. Various small problems can get easily >>>>> forgotten and lost in the amount of emails posted in threads dedicated >>>>> to bigger ones. >>>> We have a license from Atlassian for FishEye, so I'm sure we could use >>>> Jira for that. Want to help set it up? :) >>> >>> I've just set Jira up at work, I'm happy to give it a go if you want. >> >> Sure, sounds good. Thanks! >> >> Peter >> > > I'd also be glad to help, in case there is something I can help with. > :) But as it seems quite easy for one person and I have no experience > with it, I'll probably help more just by filling it. :D > -- Nicolas Vérité - ProcessOne http://process-one.net Mobile: +33 6 20 88 63 04
[Standards] XEP-0080: User Location
Hi all, In http://xmpp.org/extensions/xep-0080.html XEP-0080: User Location the table in 3. Data Format http://xmpp.org/extensions/xep-0080.html#format has errors: speed and uri have their columns in a different order. That said, this XEP has been designed with GPS in mind. We have now other geolocation technologies, like GSM (cell-id) and wifi (less accurate). 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?) Regards, Nÿco -- Nicolas Vérité - ProcessOne http://process-one.net Mobile: +33 6 20 88 63 04
Re: [Standards] reliable messaging
On Tue, Jun 16, 2009 at 10:47 PM, Peter Saint-Andre wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Someone just poked me offlist about reliable messaging in XMPP. I > replied as follows. Perhaps it makes sense to write this up a bit more > formally? Definitely! > 2. What if your client went offline but your server hasn't figured that > out yet? Your server can use whitespace pings over the XML stream to > figure out if you're online or offline: > > http://tools.ietf.org/html/draft-ietf-xmpp-3920bis-00#section-5.7.3 This is not a ping mechanism, but a keepalive mechanism: a ping is a request-response back-and-forth communication. This is why we should change the bis spec from WHITESPACE PING to WHITESPACE KEEPALIVE. In this section we say that whitespace is a space character, which is inconsistent with section 1.3. Conventions, which says: The term "whitespace" is used to refer to any character that matches production [3] content of [XML], i.e., any instance of SP, HT, CR, and LF. http://tools.ietf.org/html/draft-ietf-xmpp-3920bis-00#section-1.3 Besides we mention that an entity can send whitespace keepalive, but we don't recommend how to handle them on the receiving entity. We could consider that the absence of reception of regular whitespace keepalive means you have lost the stream, but it's contrary on the above recommandations that say we should maintain the stream. In order to be strict, we could write a specific mechanism that says how to send and handle received keepalives, but it will be resource-consuming... Regards. -- Nicolas Vérité - ProcessOne http://process-one.net Mobile: +33 6 20 88 63 04
[Standards] PubSub Security considerations
Dear all, In the "Security considerations" section of the PubSub spec, shouldn't we warn of the possible presence leaks, since subscribers (possibly not in the user's roster) are instantly notified of a user's publication? Regards, Nÿco -- Nicolas Vérité - ProcessOne http://process-one.net Mobile: +33 6 20 88 63 04
Re: [Standards] Monthly XMPP Meeting tomorrow
On Tue, Jun 9, 2009 at 1:06 AM, Peter Saint-Andre wrote: > Just a reminder that we will hold our Monthly XMPP Meeting tomorrow > (Tuesday) at 19:00 UTC. The topics will focus on operational issues, > communication among XMPP server deployments, building a site like > mailradar.com for the XMPP network, etc. Details here: Just a quick note, because I won't be present at that meeting. For the mailradar-like site: Could we reuse these ideas and services? * MUC Search: http://search.wensley.org.uk/ * IM Trends: http://www.process-one.net/en/imtrends/ And a question: is it the role of the XSF to put up such a service? Regards. -- Nicolas Vérité - ProcessOne http://process-one.net Mobile: +33 6 20 88 63 04
[Standards] inbox and "abandonned"?
Hi, In http://xmpp.org/extensions/ there is a link to http://xmpp.org/extensions/inbox/ which points to non-yet XSF XEP. Some of them are waiting for approval, but some of them are abondonned: could we move them to a http://xmpp.org/extensions/abadonned/ directory? Thx Nÿco -- Nicolas Vérité - ProcessOne http://process-one.net Mobile: +33 6 20 88 63 04
Re: [Standards] Idle sreams in RFCbis
What about that small proposed change? On Mon, May 25, 2009 at 11:31 AM, Nicolas Vérité wrote: > Hi, From: > "The sending of such a space character is called a WHITESPACE PING." To: > "The sending of such a whitespace is called a WHITESPACE KEEPALIVE." -- Nicolas Vérité - ProcessOne http://process-one.net Mobile: +33 6 20 88 63 04
Re: [Standards] Idle sreams in RFCbis
On Mon, May 25, 2009 at 12:40 PM, Mickael Remond < mickael.rem...@process-one.net> wrote: > Hello, > > Artur Hefczyc wrote: > > Only when you attempt to send some data, even a single character, the > > TCP/IP > > stack tries to deliver it to the destination address. Of course if the > > connection > > is broken, the attempt fails and an error is returned to sending > > application. > > No, it is not correct. If you try to send a character, the application > will send that data to the TCP/IP layer, that will put the data in the > TCP/IP cache. The data will have left the application and the send will > be successfull. It does not mean that the receiving party has received > it. It is an asynchronous process. > The client connection will have a failing TCP send only if the TCP/IP > buffer is full after a given timeout. > > Now, the TCP/IP connection can be broken and the TCP/IP stack might > struggle for quite a long time (resending, etc), before knowing / > acknoledging it is actually broken). Under some condition, the OS layer > will not issue a TCP connection close event, until a time out is > reached. > In this case it will take a long time before the application > know the connection is lost. > > The more specific equiment you have to pass, the more the problem can > happen (for example on mobile where this is built-in to make the device > more tolerant to loss of connection). > My point was the spec RFCbis: how should we update it? Apparently, the whitespace keepalive is used in Psi and Gajim as a sending entity, at least, and maybe in other clients, especially mobile ones, I don't know for the server-side behaviour(s). -- Nicolas Vérité - ProcessOne http://process-one.net Mobile: +33 6 20 88 63 04
[Standards] Idle sreams in RFCbis
Hi, I would like to provide feedback on these two sections: 5.7.3. Handling of Idle Streams http://xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-09.html#streams-close-idle 12.7. Whitespace http://xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-09.html#xml-whitespace In 5.7.3, it says: "The typical method for detecting an idle TCP connection is to send a space character (U+0020) over the TCP connection between XML stanzas, which is allowed for XML streams as described under Section 12.7 (Whitespace)." Strictly speaking: - the sending entity does not detect the loss of connection when it sends whitespaces - the receiving entity detects the loss of connection only if it has a mechanism that detects the absence of whitespaces Thus I propose this change: "The typical method for maintaining a TCP connection is to send a space character (U+0020 [...]" What do you think ot it? Then, we have: "The sending of such a space character is called a WHITESPACE PING." Strictly speaking: - a ping mechanism is a request-response mechanism, it waits for a "pong" response, so this is not a ping, and I think this should better be named a "keepalive" (or sort of) - s/space character/whitespace/ because: 1.3. Conventions http://xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-09.html#intro-conventions "The term "whitespace" is used to refer to any character that matches production [3] content of [XML], i.e., any instance of SP, HT, CR, and LF." Thus I propose this change: "The sending of such a whitespac is called a WHITESPACE KEEPALIVE." What do you think ot it? Regards -- Nicolas Vérité - ProcessOne http://process-one.net Mobile: +33 6 20 88 63 04
[Standards] XEP-0191: Simple Communications Blocking
Hi, XEP-0191: Simple Communications Blocking http://xmpp.org/extensions/xep-0191.html IMHO, as a non-english native (o not), the mapping with Privacy lists (XEP-0016) needs a little bit of clarification: "A service SHOULD map the blocklist to the default privacy list, where each blocked JID is represented as a privacy list item of type "jid" and action "deny". [4] If this is done and none of the user's clients ever use the privacy lists protocol, then the blocklist will always apply." "The priority of blocked (jid+deny) items in the privacy list SHOULD be such that they come first in the privacy list." Is it a question of message, presence (in/out) or iq? Or all stanza types? Nÿco -- Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com Jabber ID : xmpp:n...@jabber.fr http://linuxfr.org/ - http://fr.wikipedia.org/ - http://www.jabberfr.org/ - http://qsos.org/ Adhérez à l'April : http://april.org/
Re: [Standards] Proposed XMPP Extension: Incident Reporting
On Tue, Apr 28, 2009 at 03:32, XMPP Extensions Editor wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Incident Reporting > > Abstract: This specification defines methods for incident reporting among > XMPP server deployments. > > URL: http://www.xmpp.org/extensions/inbox/incident-reporting.html > > The XMPP Council will decide at its next meeting whether to accept this > proposal as an official XEP. I read rapidly: "relateds"? I'm a bit surprised by the plural... 3. Incident Reports Original: Multiple elements MAY be included, each with a different 'xml:lang' value. Proposal: Multiple elements MAY be included, each MUST have a different 'xml:lang' value. Nÿco -- Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com Jabber ID : xmpp:n...@jabber.fr http://linuxfr.org/ - http://fr.wikipedia.org/ - http://www.jabberfr.org/ - http://qsos.org/ Adhérez à l'April : http://april.org/
[Standards] Small typos in ad-hoc commands (XEP-0050)
Hi, There are small typos in XEP-0050: Ad-Hoc Commands: http://xmpp.org/extensions/xep-0050.html :%s/X-Windows/X-Window/g http://en.wikipedia.org/wiki/X_Window_System ;-) -- Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com Jabber ID : xmpp:n...@jabber.fr http://linuxfr.org/ - http://fr.wikipedia.org/ - http://www.jabberfr.org/ - http://qsos.org/ Adhérez à l'April : http://april.org/
Re: [Standards] XEP-0224 Attention
On Tue, Apr 14, 2009 at 15:56, Peter Saint-Andre wrote: > On 4/14/09 3:36 AM, Jiří Zárevúcký wrote: >> 2009/4/14 Nicolas Vérité : >> >>> In 5th bullet point, I propose a change to >>> "The attention extension MUST NOT use stanzas, since use this >>> feature is part of the conversation." >>> >> >> No objections against that. There's a typo though, "since use *of* >> this feature" (it's in the original text, too). > > How about this? > > "The attention extension MUST NOT be sent in stanzas, since use of > this feature is part of a messaging conversation." Better of course, thanks. -- Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com Jabber ID : xmpp:n...@jabber.fr http://linuxfr.org/ - http://fr.wikipedia.org/ - http://www.jabberfr.org/ - http://qsos.org/ Adhérez à l'April : http://april.org/
Re: [Standards] XEP-0224 Attention
2009/4/14 Jiří Zárevúcký : > 2009/4/14 Nicolas Vérité : >> In 3rd bullet point of section 4, >> http://xmpp.org/extensions/xep-0224.html#rules imho, a user could well >> receive a delayed 'attention', though I propose the change from MUST >> to SHOULD. > > That's nonsense. When user receives your delayed attention request, > you could very well be in work, school, with girlfriend, etc by then. > Attention is a way to get him to talk to you immediately. Not so nonsense: I wish I had the passed attention requests when I get back to my client... It is a worthwhile information, even if it's too late. That way, I could contact back the guy that tried to get my attention. -- Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com Jabber ID : xmpp:n...@jabber.fr http://linuxfr.org/ - http://fr.wikipedia.org/ - http://www.jabberfr.org/ - http://qsos.org/ Adhérez à l'April : http://april.org/
[Standards] XEP-0224 Attention
Hi, Small typo in http://xmpp.org/extensions/xep-0224.html#intro s/Notificaitons/Notifications/ In 3rd bullet point of section 4, http://xmpp.org/extensions/xep-0224.html#rules imho, a user could well receive a delayed 'attention', though I propose the change from MUST to SHOULD. In 5th bullet point, I propose a change to "The attention extension MUST NOT use stanzas, since use this feature is part of the conversation." Regards, Nÿco -- Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com Jabber ID : xmpp:n...@jabber.fr http://linuxfr.org/ - http://fr.wikipedia.org/ - http://www.jabberfr.org/ - http://qsos.org/ Adhérez à l'April : http://april.org/
Re: [Standards] XEP boilerplate
On Thu, Mar 19, 2009 at 5:51 PM, Peter Saint-Andre wrote: > FYI, last night I adjusted the XEP boilerplate so that it shows a bit > more information at the top. Load any XEP to see. > > Peter Clean and synthetic, I like it! Thx! I don't see anything to add/remove... Nÿco -- Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com Jabber ID : xmpp:n...@jabber.fr http://linuxfr.org/ - http://fr.wikipedia.org/ - http://www.jabberfr.org/ - http://qsos.org/ Adhérez à l'April : http://april.org/
Re: [Standards] User Profile/Relationship/Project/Resume (was: MUC avatar/logo)
2009/3/18 Remko Tronçon : >> I think a VCard is exactly what you mean, or what do you mean by User >> Profile? > > He means XEP-154, but that one is dying anyway. [Yes, I meant that, answered offlist not to pollute] OK, I learn that XEP-0154 is being abandoned, so what about cutting and restrcturing all the info in User Profile in different PEP stuff? Like the user's relationships, projects, resume... I evoked the subject in: http://mail.jabber.org/pipermail/standards/2009-March/021218.html Nÿco -- Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com Jabber ID : xmpp:n...@jabber.fr http://linuxfr.org/ - http://fr.wikipedia.org/ - http://www.jabberfr.org/ - http://qsos.org/ Adhérez à l'April : http://april.org/
Re: [Standards] MUC avatar/logo
On Wed, Mar 18, 2009 at 2:27 PM, Jonathan Schleifer wrote: > Am 18.03.2009 um 13:20 schrieb Dave Cridland: > >> Options include: >> >> 1) An extended Disco feature of a URI to the room's logo. >> >> 2) An extended Disco feature of the room's logo (base64 encoded or >> something). >> >> 3) Define a pubsub root node for rooms, and PEP-for-MUC (MEP, as has been >> suggested). Then use XEP-0084 on rooms. >> >> 4) All of the above. > > > 5.) Create a VCard for the MUC that allows it to have even more than just an > avatar :). > > This might actually work in some clients out of the box. Or "MUC Profile"? Like "User Profile"? Nÿco -- Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com Jabber ID : xmpp:n...@jabber.fr http://linuxfr.org/ - http://fr.wikipedia.org/ - http://www.jabberfr.org/ - http://qsos.org/ Adhérez à l'April : http://april.org/
[Standards] MUC avatar/logo
Hi, I was just wondering... Is it possible/easy/XEPable to have an image/avatar/logo that symbolizes a MUC? Just a funny wannabe gadget... though no doubt a killer-feature for some. Nÿco -- Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com Jabber ID : xmpp:n...@jabber.fr http://linuxfr.org/ - http://fr.wikipedia.org/ - http://www.jabberfr.org/ - http://qsos.org/ Adhérez à l'April : http://april.org/
[Standards] User *
Hi all, I was wondering if these few PEP-based "User *" XEPs ideas were relevant: * User Friends or Relationships Using XFN and/or FOAF to describe relationships http://gmpg.org/xfn/ http://www.foaf-project.org/ * User Project Using DOAP http://trac.usefulinc.com/doap * User Carrier Using DOAC or hResume http://ramonantonio.net/doac/ http://microformats.org/wiki/hresume They all are already specified, it should not be long to XEpify and implement them? User Mood is already quite well deployed, these new PEP entries are much more usefull... Besides they could well replace good parts of User Profile. Nÿco -- Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com Jabber ID : xmpp:n...@jabber.fr http://linuxfr.org/ - http://fr.wikipedia.org/ - http://www.jabberfr.org/
[Standards] Liberty Alliance ID-SIS 1.0 Specifications
Hi, FYI, here is the "Liberty Alliance ID-SIS 1.0 Specifications": http://www.projectliberty.org/resource_center/specifications/liberty_alliance_id_sis_1_0_specifications This deals with XMPP for presence, I don't know anything else. Nÿco -- Nicolas Vérité (Nÿco) mailto:[EMAIL PROTECTED] Jabber ID : xmpp:[EMAIL PROTECTED] http://linuxfr.org/ - http://fr.wikipedia.org/ - http://www.jabberfr.org/ - http://qsos.org/ Adhérez à l'April : http://april.org/
Re: [Standards] C2C TLS
On Mon, Nov 24, 2008 at 6:28 PM, Jonathan Schleifer <[EMAIL PROTECTED]> wrote: > As the discussion was already month ago now and it was said there will be > many clients at the end of the year (which we have now), I wanted to ask a > few things: > > 1.) What is the current state of the XEP? Is it even a XEP now? > 2.) How many clients implement it? If any, which? > 3.) If there are clients, do they use direct connections or use Jingle's > inband mode? > 4.) How was the SAS problem solved, if it was solved at all? If not, how > will it be solved? > 5.) How much work was it to implement it? Was it really "just 5 minutes of > work" as some said in the discussion before? > 6.) I predicted that it will still take a long time until C2C TLS will reach > the state ESessions now has. To me, it seems my prediction was right. > Anything I overlooked? > > -- > Jonathan It's still in inbox (no XEP number): http://xmpp.org/extensions/inbox/xtls.html Nÿco -- Nicolas Vérité (Nÿco) mailto:[EMAIL PROTECTED] Jabber ID : xmpp:[EMAIL PROTECTED] http://linuxfr.org/ - http://fr.wikipedia.org/ - http://www.jabberfr.org/ - http://qsos.org/ Adhérez à l'April : http://april.org/
Re: [Standards] Event for the 10th birthday of XMPP
Of course I'm interested in it (as I told you). I offer you my help. Worldwide events could take the same shape as Mozilla, Ubuntu and Mandriva do. IMHO, a central place (like the XSF) should be the place where we collaborate, and decline locally, as the organizers wish/can. We can rely on User Groups of course, like Linux/Unix and free/opensource software User Groups, and also maybe companies working around XMPP. Nÿco On Mon, Nov 17, 2008 at 11:03 AM, Jehan <[EMAIL PROTECTED]> wrote: > > Hi, > > noone is interested by this idea on this list? Or is it that we should > really discuss this elsewhere? Maybe I will try to forward this to jdev > as proposed by Matthew. > > Jehan > > > -- > Jehan > > Jehan's Profile: http://www.jabberforum.org/member.php?userid=16911 > View this thread: http://www.jabberforum.org/showthread.php?t=1073 > > -- Nicolas Vérité (Nÿco) mailto:[EMAIL PROTECTED] Jabber ID : xmpp:[EMAIL PROTECTED] http://linuxfr.org/ - http://fr.wikipedia.org/ - http://www.jabberfr.org/ - http://qsos.org/ Adhérez à l'April : http://april.org/
Re: [Standards] XEPs in Pretty Colours.
On Wed, Nov 12, 2008 at 10:40 PM, Remko Tronçon <[EMAIL PROTECTED]> wrote: >> I appreciate that this is almost inexcusably trivial, but bear with me. > > I say, let's put these hip state-of the art 4-color (or more!) > displays finally to work! Color-coding is not enough: it is not accessible for the blinds or visually impaired. We need more printed text (meta)data. Nÿco -- Nicolas Vérité (Nÿco) mailto:[EMAIL PROTECTED] Jabber ID : xmpp:[EMAIL PROTECTED] http://linuxfr.org/ - http://fr.wikipedia.org/ - http://www.jabberfr.org/ - http://qsos.org/
[Standards] XMPP Reports
Hi, I've created this page: http://wiki.xmpp.org/web/XMPP_Report_2 Since the Jabber Journal is dead and the XMPP Report #1 is taking the relay and has been published on the "Extended Conversation" blog at http://blog.xmpp.org/ on september, I would like to contribute to the next releases, as maybe some other people. So the wiki is a place where to contribute. Nÿco -- Nicolas Vérité (Nÿco) mailto:[EMAIL PROTECTED] Jabber ID : xmpp:[EMAIL PROTECTED] http://linuxfr.org/ - http://fr.wikipedia.org/ - http://www.jabberfr.org/ - http://qsos.org/
[Standards] OpenSocial
Hi all, I think you have all heard about the OpenSocial buzz... Do some of you consider making XMPP compatible/interoperable with this API? Is it useful/necessary/worth? Nÿco -- Nicolas Vérité (Nÿco) mailto:[EMAIL PROTECTED] Jabber ID : xmpp:[EMAIL PROTECTED] http://linuxfr.org/ - http://fr.wikipedia.org/ - http://www.jabberfr.org/
Re: [Standards] XEP licensing
On 10/22/07, Remko Tronçon <[EMAIL PROTECTED]> wrote: > Why would they want to modify RFCs? To "embrace and extend"? (and extinguish) -- Nicolas Vérité (Nÿco) mailto:[EMAIL PROTECTED] Jabber ID : xmpp:[EMAIL PROTECTED] http://linuxfr.org/ - http://fr.wikipedia.org/ - http://www.jabberfr.org/
