Re: [Standards] XMPP-UK Security MeetUp: London, 8th Dec 2016

[Steffen Larsen]

+1

/Steffen
> On 25 Nov 2016, at 11.37, Joachim Lindborg  wrote:
> 
> Totally agree perhaps som virtual hangarounds?
> 
> Written by Joachim Lindborg on a device running on solar energy from 
> watt-s.com 
> CTO, systems architect
> Sustainable Innovation  SUST.se  ,Tel +46 706-442270, 
> linkedin 
> Barnhusgatan 3 111 23 Stockholm
> 
> 2016-11-25 10:35 GMT+01:00 Stefan Strigler  >:
> That's great stuff, congratulations already to everyone involved. Wish I 
> could be there!
> 
> On Thu, Nov 24, 2016 at 9:57 PM Dave Cridland  > wrote:
> Folks,
> 
> If you're in or close to London in early December, we'd like to
> welcome to you this free event. This event is unaffiliated with the
> XMPP Standards Foundation, though quite a few members (including Board
> and Council) happen to be attending.
> 
> https://www.meetup.com/XMPP-UK-Meetup/events/235240643/ 
> 
> 
> ** Let's Talk About Security **
> 
> It seems like every Instant Messaging app these days is touting itself
> as having the latest security... But what about XMPP?
> 
> Is XMPP "secure"? From what? And what does that really mean, anyway?
> 
> Some of the leading experts in XMPP security - not just in the UK,
> either - are coming to talk to us about encryption, strong
> authentication, content controls and more, in an all-round great
> evening of talks and discussion - fuelled and followed by the odd
> glass of something.
> 
> We'll learn about XMPP's use of both well-established
> certificate-based technology and the bleeding edge of end-to-end
> encryption. We'll discover how XMPP is used securely across a vast
> array of wildly different ecosystems. And most importantly, there will
> be pizza.
> 
> Space is unfortunately very limited, so please let us know if you're
> coming - it's free to attend, all we want in return is your voice in
> the discussions.
> 
> ** Speakers **
> 
> Steve Kille - Content Marking
> 
> Steve has been working with Internet technologies for decades, and was
> present when the Internet arrived in the UK. CEO of Isode Ltd, one of
> the instigators behind LDAP, and a renowned expert in secure
> messaging, Steve will be giving us his expertise in Security
> Labelling.
> 
> Daniel Gultsch - End to End Cryptography
> 
> Daniel is lead developer of the popular Android client, Conversations,
> and also one of the authors of the OMEMO XEP bringing Double-Ratchet
> cryptography to XMPP. Currently serving on the XMPP Council, he has
> implemented three different forms of end-to-end encryption in
> Conversations, and will be discussing their strengths and weaknesses.
> 
> Dave Cridland - S2S Security
> 
> Dave has put bugs into many of the leading XMPP Servers, and is
> currently project lead for IgniteRealtime's Openfire, lead developer
> for Surevine's Metre, and serves on the XMPP Council. He'll be talking
> DANE, DNSSEC, PKIX, and Dialback and server to server security.
> 
> Kevin Smith - XMPP Trunking
> 
> Kev leads Isode's XMPP team, including both M-Link and Swift
> development, and has previously led development on the well-known Psi
> client. Currently serving on the XMPP Editor team managing the
> specifications, he has previously served a record length of time on
> the XMPP Council. He will be discussing non-traditional ways of
> linking XMPP servers.
> 
> Matthew Wild - Comparative Theology
> 
> Matthew currently serves on both the Board of the XMPP Standards
> Foundation and as project lead of Prosody, a leading XMPP server. He
> has previous served a number of years on the XMPP Council. He'll be
> comparing the security found in XMPP with other protocols.
> 
> 
> I'm really looking forward to this event, hope to see you there - and
> really, do sign-up (for the sign-up averse, let me know directly).
> 
> Dave.
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards 
> 
> Unsubscribe: standards-unsubscr...@xmpp.org 
> 
> ___
> 
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards 
> 
> Unsubscribe: standards-unsubscr...@xmpp.org 
> 
> ___
> 
> 
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscrib

Re: [Standards] "Self-destruct" message timeout deletion hints

[Steffen Larsen]

Yup - I've done something like this before using  AMP.

/Steffen


> On 19 Oct 2016, at 14.56, Brian Cully  wrote:
> 
> 
>> On 18-Oct-2016, at 17:58, Chris Ballinger  wrote:
>> 
>> Are there other scenarios that I'm missing? Would people be willing to 
>> implement this into their apps? Is formalized spec for this something that 
>> XSF would consider?
> 
>   In the finance world being able to time limit messages is handy, not 
> for security, but because the availability of a transaction is limited. We’d 
> almost certainly implement this, and probably will end up doing so even 
> without a standard.
> 
> -bjc
> 
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] [Members] Who's coming to FOSDEM / XMPP Summit 19?

[Steffen Larsen]

Hi Ralph,

What about hotel (Aloft)? I haven’t heard anything about this yet?. 
Otherwise I’ll book something else near grand place and Poechenellekelder. ;-)

-Cheers and see you guys soon!

/Steffen

 
> On 15 Jan 2016, at 15:08, Ralph Meijer  wrote:
> 
> Hi all,
> 
> Looking at the list of participants at for the upcoming Brusses summit at 
> , I notice that 12 people have signed up 
> to attend, so far. In order to plan Summit Lunches and the XSF Dinner, I have 
> to know how many people are coming.
> 
> If you do plan on attending, please sign up on this page, or drop me a line 
> at . Please do this *as soon as possible* but before the 
> end of day (*) 18 January. If you can provide any of the items on the gear 
> list, do let me know.
> 
> Note that 12 participants is much lower than previous years, and while I am 
> sure we can be (more?) productive with this group, we will probably need to 
> re-evaluate doing Summits in this style.
> 
> Similarly, the list of people in our community planning to attend FOSDEM as 
> listed at  is pretty short. I'm going 
> to assume that all people signed up for the Summit (bar Kevin) will be at 
> FOSDEM and spend some time at the Realtime Lounge and Devroom.
> 
> Cheers,
> 
> ralphm
> 
> *) I will be in San Francisco  on that day, so end-of-day UTC-7 is
>fine.

___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] [xmpp] [Summit] Fwd: [jdev] [CFP] FOSDEM 2016, RTC devroom, speakers, volunteers neeeded

[Steffen Larsen]

Everything is fine here. :-)

/Steffen

> On 21 Nov 2015, at 08:38, Daniel Pocock  wrote:
> 
> On 21/11/15 07:02, Arc Riley wrote:
>> I'm on email, it did not go to spam.
> 
> Can anybody else comment on whether they got it or not?
> 
> Does anybody who did or did not receive it see any headers indicating how 
> Google's spam filters are classifying the message?
> 
> I'm hearing far too many reports of these problems these days.  Somebody 
> suggested it may be triggered by 4 of the letters in my surname, although I 
> feel lucky not be in the same situation as these people:
> 
> http://www.theguardian.com/technology/2015/nov/18/facebook-thinks-im-a-terrorist-woman-named-isis-has-account-disabled
>  
> 
> 
> 

Re: [Standards] [IOT] Blocking messages from unsubscribed users

[Steffen Larsen]

Hi Joachim,

Yes I see potential threats in the IoT environments if no filters can be 
applied such as privacy lists or others. 
But for normal chat client this is also quite nice to avoid simple “spam” 
(although they mostly have to guess the user and resource). But sending to bare 
JID can also do annoying things if it sends to all the users resources or what 
ever the server implementation does.

The implementation and deployment I have done is typically that only 
subscribers and users them selves (resources) can “write” each other. And that 
admin can write to all users.
I have used privacy lists and it works great for me - I am not using a UI for 
reflecting that - but setting this up initially.

So for me it is quite static and one-off. 

/Steffen



> On 13 Oct 2015, at 08:10, Joachim Lindborg  wrote:
> 
> In the case of IoT i use it a lot devices only look at subscription requests 
> from unsubscribe do users. And I also have component that takes care of 
> devices blocking all messages from non subscribed 
> 
> Don't know if I need a xep for it or if its implementation specific for IoT 
> 
> I would like to be able to turn it on as default for myself receiving only 
> subscription requests just as I have setup Skype
> 
> måndag 12 oktober 2015 skrev Steffen Larsen  <mailto:zoo...@gmail.com>>:
> Hi Matthew,
> 
> Good call. The scenario I have used blocked commands was in a setup where I 
> actually needed configuration instead (setup once).
> So for me and the scenarios I have, the ad-hoc command config would be great!.
> 
> The only problem I see, is that every server would vary a lot.. and have 
> different policies.
> 
> /Steffen
> > On 12 Oct 2015, at 23:28, Matthew Wild > 
> > wrote:
> >
> > It seems a few people are requesting this. I'd like to understand the 
> > use-cases.
> >
> > For example, if this is something you want to be the default
> > behaviour, isn't it better as a deployment configuration? No protocol
> > needed.
> >
> > A per-user configuration would also be possible using ad-hoc commands.
> > Again, no extra XEPs needed.
> >
> > Just throwing things out there, I'd like to understand exactly what people 
> > want.
> >
> > Regards,
> > Matthew
> 
> 
> 
> -- 
> Regards
> Joachim Lindborg
> CTO, systems architect
> 
> Sustainable Innovation  SUST.se <http://sust.se/>
> Barnhusgatan 3 111 23 Stockholm
> Email: joachim.lindb...@sust.se <mailto:joachim.lindb...@sust.se>
> linkedin: http://www.linkedin.com/in/joachimlindborg 
> <http://www.linkedin.com/in/joachimlindborg>
> Tel +46 706-442270
> 
> ___
> IOT mailing list
> i...@xmpp.org
> http://mail.jabber.org/mailman/listinfo/iot

Re: [Standards] Blocking messages from unsubscribed users

[Steffen Larsen]

Hi Matthew,

Good call. The scenario I have used blocked commands was in a setup where I 
actually needed configuration instead (setup once).
So for me and the scenarios I have, the ad-hoc command config would be great!.

The only problem I see, is that every server would vary a lot.. and have 
different policies.

/Steffen
> On 12 Oct 2015, at 23:28, Matthew Wild  wrote:
> 
> It seems a few people are requesting this. I'd like to understand the 
> use-cases.
> 
> For example, if this is something you want to be the default
> behaviour, isn't it better as a deployment configuration? No protocol
> needed.
> 
> A per-user configuration would also be possible using ad-hoc commands.
> Again, no extra XEPs needed.
> 
> Just throwing things out there, I'd like to understand exactly what people 
> want.
> 
> Regards,
> Matthew

Re: [Standards] XMPP Myths

[Steffen Larsen]

Hi Just to add a bit more.

I’ve done a maritime safety data service for Cobham / Immersat satellites  
(http://www.inmarsat.com/service/maritime-safety/). This is based on XMPP and 
MUC and some other XEPs.
The work is done as a consultant so I have no other direct access for 
documentation.

/Steffen

> On 11 Aug 2015, at 09:06, Dominik Renzel  wrote:
> 
> Am 10.08.2015 um 22:11 schrieb Dave Cridland:
>> On 10 August 2015 at 18:37, Dominik Renzel 
>> wrote:
>> 
>>> Nice compilation, Dave.
>>> 
>>> As one of the guys from xmppresearch.org, I might add a bit from the
>>> academic side. There is quite a body of literature available on XMPP
>>> research (and - yes, we keep collecting!). We're currently working on a
>>> survey paper on a collection of XMPP research from 2003 till today. I can't
>>> reveal too much, but a little bit of overview allows me to wield the
>>> academagic battle-axe at least for two myths.
>>> 
>>> Myth Two:
>>> 
>>> Although I don't know if the scientific use of XMPP extensions mirrors
>>> practical deployment, I would assume that there are certain similarities.
>>> In response to a request during this year's summit in Diegem, Belgium, my
>>> dear colleague Daniel Schuster from TU Dresden created a tag cloud of the
>>> XEPs in scientific use, extracted from 250 different papers:
>>> http://www.xmppresearch.org/posts/xeps-used-in-xmpp-research/
>>> 
>>> 
>> That's awesome; I'll link to that in the Myth Two section.
>> 
>> 
>>> Myth Three:
>>> 
>>> There is quite some scientific evidence on the use of XMPP in
>>> bandwidth-critical, mobile settings, especially in the last five years.
>>> You find literature on mobile sensor networks, mobile apps, IoT, etc.,
>>> some of them applied in disaster scenarios with no or very impaired public
>>> communication infrastructure. Bandwidth-efficiency is hardly ever mentioned
>>> as a problem.
>>> 
>>> 
>> Yes, I'll poke about and see how much of the use-cases I'm aware of can be
>> talked about openly, since there's sectors using XMPP over low-bandwidth
>> for mission-critical messaging that are really eye-opening - and I didn't
>> even know about the disaster cases - links would be great.
> 
> About the disaster cases:
> 
> Klauck, Ronny; Gäbler, Jan; Kirsche, Michael; Schoepke, Sebastian (2011): 
> Mobile XMPP and Cloud Service Collaboration: An Alliance for Flexible 
> Disaster Management. In: 7th International Conference on Collaborative 
> Computing: Networking, Applications and Worksharing, CollaborateCom 2011, 
> Orlando, FL, USA, 15-18 October, 2011, pp. 201–210, IEEE, 2011.
> 
> Link: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6144805 
> 
> 
> Klauck, Ronny; Kirsche, Michael (2012): XMPP to the Rescue: Enhancing Post 
> Disaster Management and Joint Task Force Work. In: Pervasive Computing and 
> Communications Workshops (PERCOM Workshops), 2012 IEEE International 
> Conference on, pp. 752–757, IEEE, 2012.
> 
> Link: http://dx.doi.org/10.1109/PerComW.2012.6197613 
> 
> 
> Klauck, Ronny; Kirsche, Michael (2013): Combining Mobile XMPP Entities and 
> Cloud Services for Collaborative Post-Disaster Management in Hybrid Network 
> Environments. In: Mobile Networks and Applications - The Journal of SPECIAL 
> ISSUES on Mobility of Systems, Users, Data and Computing, 18 (2), pp. 253 – 
> 270, 2013.
> 
> Link: http://link.springer.com/article/10.1007%2Fs11036-012-0391-1 
> 
> 
> About Mobile & IoT applications of XMPP in research:
> 
> Go to http://www.xmppresearch.org/bibliography/ 
>  and check the tag cloud on top of 
> the page. "Mobile" is THE top tag (with 56 papers from 2004-now). For IoT we 
> collected 30 papers from 2009-now. By clicking on the tags, you get the full 
> list. By following links you at least get the abstracts. For reading the full 
> paper, you'll most likely slam against the paywall.
> 
> Best,
> Dominik
> 
>> 
>> 
>>> Best,
>>> Dominik
>>> 
>>> 
>>> 
>>> 
>>> Am 10.08.2015 um 18:02 schrieb Dave Cridland:
>>> 
 I've noticed that a large well-funded group have been attending a number
 of
 conferences and making unfortunately ill-informed statements about XMPP,
 in
 favour of their own solution in a number of spaces in which we overlap.
 
 In conformity with Napoleon's suggestion that one should never attribute
 to
 malice that which can adequately be explained by incompetence, I have
 tried
 to address these statements directly, but sadly while representatives of
 the organization were willing to agree they would correct their website,
 they have remained too incompetent to do so.
 
 This is terribly unfortunate, and so to help address this I knocked up
 some
 answers to specific "myths" on a Wiki page, intended (by me) 

Re: [Standards] XMPP Myths

[Steffen Larsen]

For interested parties, the myths can be found here http://matrix.org/blog/faq/

/Steffen 

> On 10/08/2015, at 18.02, Dave Cridland  wrote:
> 
> I've noticed that a large well-funded group have been attending a number of 
> conferences and making unfortunately ill-informed statements about XMPP, in 
> favour of their own solution in a number of spaces in which we overlap.
> 
> In conformity with Napoleon's suggestion that one should never attribute to 
> malice that which can adequately be explained by incompetence, I have tried 
> to address these statements directly, but sadly while representatives of the 
> organization were willing to agree they would correct their website, they 
> have remained too incompetent to do so.
> 
> This is terribly unfortunate, and so to help address this I knocked up some 
> answers to specific "myths" on a Wiki page, intended (by me) as a draft blog 
> post (but it could just as well stay on the Wiki, get reused as website 
> content, or whatever).
> 
> It's here: http://wiki.xmpp.org/web/index.php?title=Myths
> 
> Suggestions and corrections would be very much welcome; feel free to either 
> edit directly, or (possibly preferable) discuss in the XSF chatroom at 
> x...@muc.xmpp.org
> 
> Thanks!
> 
> Dave.

Re: [Standards] help with managment of strophe plugins

[Steffen Larsen]

+1 do a PR and also ask questions on GH (raise it as an issue).

/Steffen

> On 05 Jul 2015, at 16:55, Markus Kohlhase  wrote:
> 
> Hi Joachim,
> 
>> I cannot find a good mailinglist or a community discussion forum.
> as far as I know the main discussion is on github [1].
> 
>> I  would like to add two new plugins
> great :)
> 
>> and JCbrand (converse.js) mentioned that the current repository 
>> https://github.com/joachimlindborg/strophejs-plugins/tree/xmpp-iot_xep_323_325
>> where I have put them now. should be split into separate packages to 
>> facilitate better build scripts etc.
> I'd suggest to do a pull request and ask for ideas to organize your code.
> 
>> Is there any strophe interested people around? and where can we 
>> talk?
> you can contact me by mail or xmpp :)
> 
> cheers
> flosse
> 
> [1]: https://github.com/strophe/strophejs-plugins

Re: [Standards] XEP-0198 minor enhancement

[Steffen Larsen]

> On 29 May 2015, at 23:32, Matthew Wild  wrote:
> 
> On 29 May 2015 at 21:00, Dave Cridland  wrote:
>> What if, on a resumption failure, a server could include the 'h' attribute,
>> to mean "I can't actually resume your state, but I did get all the stanzas
>> up until H".
>> 
>> I think this allows servers to hold onto this small amount of state for
>> considerably longer than it's desirable to keep a disconnected session live,
>> and it also makes a halfway house between ack-only and full resumption
>> possible for other servers.
>> 
>> Thoughts?

+1 good idea

> 
> Definitely +1.
> 
>> Also, do you think we could add this attribute without a version bump?

No, I would go for a version bump, because it could break some clients.

> 
> If it's optional, yes. Theoretically a client could choke on an
> unexpected attribute, but the number of XEP-0198-capable clients that
> I know would do this is zero.
> 
> Regards,
> Matthew

Re: [Standards] OTR

[Steffen Larsen]

Hi, 

Yes a good idea. Maybe we could try to update this one: 
http://wiki.xmpp.org/web/OTR 

/Steffen

> On 02 Feb 2015, at 13:22, Hund, Johannes  wrote:
> 
> Hi,
> 
> while I cannot help with it, I would be very thankful and greatly welcome a 
> document on what is and how to use OTR.
> 
> Since it was undisclosed that even the NSA seems to have problems breaking 
> into OTR [1], it gained a lot of attention it seems and thus does a good deal 
> in supporting XMPP as a choice for applications with high requirements in 
> privacy and security as its often the case for IoT applications.
> 
> [1]: 
> http://www.spiegel.de/international/germany/inside-the-nsa-s-war-on-internet-security-a-1010361.html
> 
> Best Regards,
> Johannes
> 
> Von: Standards [mailto:standards-boun...@xmpp.org] Im Auftrag von Dave 
> Cridland
> Gesendet: Freitag, 7. November 2014 10:56
> An: XMPP Standards
> Betreff: [Standards] OTR
> 
> In an internal discussion at Surevine, OTR was mentioned, and it was moaned 
> that OTR usage in XMPP isn't actually documented anywhere we know of.
> 
> Is anyone willing to help work on a XEP to explain how to run OTR over XMPP, 
> and catalogue limitations etc?
> 
> Dave.

Re: [Standards] OTR

[Steffen Larsen]

A good discussion for the summit I would say. :-)

/Steffen

> On 26 Jan 2015, at 07:49, Bartosz Małkowski  wrote:
> 
> https://blog.thijsalkema.de/me/blog//blog/2015/01/23/multi-end-to-multi-end-encryption/
> 
> --
> Bartosz Małkowski
> Tigase Polska
> xmpp:bmal...@malkowscy.net
> 

Re: [Standards] Discussion topics for the summit

[Steffen Larsen]

You can present it at the summit - it would be a good discussion. 
PS: almost everything can be done via pub/sub - more or less verbose.. ;-)

/Steffen

> On 14 Jan 2015, at 10:59, Piotr Nosek  
> wrote:
> 
> Indeed it is somewhat "pub-subish" but with nodes where everyone is 
> publisher. I guess it could be implemented on top of 0060 too, but I think 
> that MUC stanzas are logically more fitting and are not unnecessarily verbose.
> There, you see? It has already provoked discussion. :)
> Please allow me to prepare the design of such solution (taking 0060 into 
> consideration too). In worst case everyone will tell me it's all worthless 
> after 2-minute discussion, right? :P
> 
> - Oryginalna wiadomość -
> Od: "Steven Lloyd Watkin" 
> Do: "XMPP Standards" 
> Wysłane: środa, 14 styczeń 2015 10:16:26
> Temat: Re: [Standards] Discussion topics for the summit
> 
> 
> 
> Sounds more like pub sub to me :) 
> On 14 Jan 2015 08:27, "Piotr Nosek" < piotr.no...@erlang-solutions.com > 
> wrote: 
> 
> 
> Hi everyone, 
> 
> I would like to discuss a functionality that we have implemented in the past 
> for mobile applications. It could become a new standard perhaps, because 
> there is quite high demand for it. 
> What I have in mind is a kind of presence-less MUC. People using e.g. 
> WhatsApp will know what I'm talking about. 
> The highlights of such solution are: 
> * No presence information - when you're in the group, you're visible for 
> everyone 
> * No hiding behind nicks 
> * Very simple role set: just owner and members 
> Internally we call this extension "MUC light" and if nobody disagrees, I 
> guess it's the name of the topic I propose. :) 
> 
> Regards, 
> Piotr 
> 
> - Oryginalna wiadomość - 
> Od: "Kevin Smith" < kevin.sm...@isode.com > 
> Do: "XMPP Standards" < standards@xmpp.org > 
> Wysłane: wtorek, 13 styczeń 2015 14:04:10 
> Temat: [Standards] Discussion topics for the summit 
> 
> Hi folks, 
> Council had a think about possible topics for the summit, and came up with 
> these. If you have thoughts about other things to discuss, please share them 
> (and hopefully we’ll capture them in the wiki before the summit). 
> 
> Social network interop (Buddlycloud/Movim/SåT), device-consistent chat (MAM, 
> Carbons, read markers, etc.), Distributed MUC, IoT. 
> 
> /K 
> 
> 
> 
> 

Re: [Standards] Discussion topics for the summit

[Steffen Larsen]

Heh I was about to write the same thing. Pub/Sub would probably be the answer 
here - except that the doc is somewhat long (not light).. 

/Steffen

> On 14 Jan 2015, at 10:16, Steven Lloyd Watkin  
> wrote:
> 
> Sounds more like pub sub to me :)
> 
> On 14 Jan 2015 08:27, "Piotr Nosek"  > wrote:
> Hi everyone,
> 
> I would like to discuss a functionality that we have implemented in the past 
> for mobile applications. It could become a new standard perhaps, because 
> there is quite high demand for it.
> What I have in mind is a kind of presence-less MUC. People using e.g. 
> WhatsApp will know what I'm talking about.
> The highlights of such solution are:
> * No presence information - when you're in the group, you're visible for 
> everyone
> * No hiding behind nicks
> * Very simple role set: just owner and members
> Internally we call this extension "MUC light" and if nobody disagrees, I 
> guess it's the name of the topic I propose. :)
> 
> Regards,
> Piotr
> 
> - Oryginalna wiadomość -
> Od: "Kevin Smith" mailto:kevin.sm...@isode.com>>
> Do: "XMPP Standards" mailto:standards@xmpp.org>>
> Wysłane: wtorek, 13 styczeń 2015 14:04:10
> Temat: [Standards] Discussion topics for the summit
> 
> Hi folks,
>   Council had a think about possible topics for the summit, and came up with 
> these. If you have thoughts about other things to discuss, please share them 
> (and hopefully we’ll capture them in the wiki before the summit).
> 
> Social network interop (Buddlycloud/Movim/SåT), device-consistent chat (MAM, 
> Carbons, read markers, etc.), Distributed MUC, IoT.
> 
> /K

[Standards] XMPP summit / FOSDEM

[Steffen Larsen]

Hi Guys,

I haven’t heard anything about this subject since Joachim wrote a while ago.
I am definitely coming and the summit is not many days from now. 

Have anyone looked at hotels and discounts etc?
When is the summit? The two days before FOSDEM like it normally is?

I think we should start organising it. The page is there: 
http://wiki.xmpp.org/web/Summit_17  , but 
we need some organisers. 

PS: I would gladly help I just need to be told what needs to be done. :-)

-Cheers and hope you all had a nice x-mas and new year!

/Steffen 

Re: [Standards] XEP-Proposal: Customizable Message Routing

[Steffen Larsen]

Hi Florian,

Great stuff. I’ve been talking for the last two year about the same subject at 
the summits. For me its always been a wonder that the bare JID routing is up to 
the server implementation and that the client have no understanding or no 
hinting for setting for it.
So perfect. I really like to contribute to this XEP if you need any help. Ive 
been using bare JID routing (all) a lot when doing IoT/M2M on set-top boxes and 
over the top second screen implementations.
So count me in!.

Just a couple of quick fixes:
  
* Links in general are missing for the RFC6121. And In section 4.1:  
* "Deliver top all ('urn:xmpp:cmr:all’)” should probably be ‘to’ instead of 
‘top’.

I’ll skim it a couple a more times and will return with some feedback. For 
implementation: I will probably implement it in tigase, if I get some more 
time. Because I am using bare JID routing all the time - and “hints” is also a 
great addition. Although I need to think a bit about what happens when bringing 
in offline line AMP etc. :-)

/Steffen

On 09 Sep 2014, at 17:14, Florian Schmaus  wrote:

> I'd like to gather some feedback before I send the XEP to the editors.
> 
> The idea behind "Customizable Message Routing" (CMR) originated from a
> Ignite Realtime forum thread [1]: A user asked about Openfire's
> message routing behavior when multiple resources where available and
> if a round-robin distribution of the messages to the resources would
> be possible. He wanted to distribute incoming stanzas, originating
> from sensors, evenly over nodes of a cluster collecting the data from
> the sensors. Every node of the cluster is connected using the same JID
> and has the same priority configured, but with a different resource of
> course.
> 
> So we find ourselves in a M2M scenario using XMPP, where many clients
> send their data to one XMPP entity which consists of multiple cluster
> nodes (note that this is *not* a clustered XMPP server). Traditionally
> the XMPP RFCs describe two possible routing algorithms in that case:
> 1. Route to all resources, or 2. Route to the "most available"
> resource. The newer RFC 6121 leaves it to the server implementation
> how to determine the "most available" resource.
> 
> That is where CMR jumps in, by exploiting this freedom of RFC 6121
> e.g. by defining the "most available" resource as the resource chosen
> by a round-robin algorithm.
> 
> The XEP of CMR can be found at
> 
> https://geekplace.eu/xeps/xep-cmr/xep-cmr.html
> 
> and the source is available at
> 
> https://github.com/Flowdalic/xeps/tree/master/xep-cmr
> 
> I don't consider the CMR specification finished. For example error
> handling is missing in some cases. I also wounder if 5.4 shouldn't go
> into an extra XEP.
> 
> Florian
> 
> 1: https://community.igniterealtime.org/message/242204



smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Autumn XMPP summit outside NA?

[Steffen Larsen]

Unfortunatly I can’t make it anyway. :-/ At that date Ive just come back from 
the Seychelles and probably a bit tired of travelling etc.
But I hope that you guys can arrange some remote participation. :-)

/Steffen

On 07 Aug 2014, at 10:01, Steven Lloyd Watkin  wrote:

> Sorry for the multiple cross posts, but this is relevant to this thread:
> 
> 
> 
> Hi all,
> 
> As per previous emails there we now have plans for an XSF summit in Berlin 
> during JSFest.
> 
> There is an event (for which there aren't much details) called 
> decentralize.js on the 9th of September so we're looking at 2 days from the 
> 10th / 11th / 12th September to hold a 1 day summit and a hackathon/barcamp 
> for the wider community (probably called xmpp.js).
> 
> We'd like to gauge numbers so we can book the correct amount of space and try 
> and organise a group booking. To that end I've created a doodle below. If you 
> are interested in coming please select your favoured two days and we'll pick 
> those with the most responses:
> 
> http://doodle.com/t5c6v6eth3vpw82u
> 
> If anyone would like to help out please let me know (especially if you are 
> from, or know, Berlin).
> 
> Cheers, Lloyd.
> ___
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Autumn XMPP summit outside NA?

[Steffen Larsen]

Yes I was actually thinking to join  the Decentralized.js and Rejct.js ..

/Steffen

On 24 Jul 2014, at 09:37, Steven Lloyd Watkin  wrote:

> Another alternative is mid-September around JSConfEU week (13th-14th 
> September) in Berlin, http://jsfest.berlin/
> 
> There's an event on the 9th called decentralize.js although I don't have any 
> additional details about it right now.
> 
> The main conference is sold out but the others still have tickets. 
> 
> We could probably talk to Mozilla about using their space as a venue for the 
> summit too.
> 
> If its going to be Europe then any easily reachable (for all) European city 
> would be ideal.
> 
> _
> 
> Steven Lloyd Watkin
> Software Engineer
> PHP ::: Java ::: Ruby ::: Node.js ::: XMPP
> ll...@evilprofessor.co.uk (email+jid) ::: http://www.evilprofessor.co.uk
> Facebook / Twitter / Flickr: lloydwatkin
> 
> Organiser of WORLD RECORD breaking charity event:
> Scuba Santas ::: http://www.scuba-santas.co.uk
> Supporting the RNLI & DDRC - 15th December 2013 - NDAC, Chepstow
> 
> 
> On 24 July 2014 07:13, Joachim Lindborg  wrote:
> Sweden Stockholm would be perfect :) happy to host you all.
> 
> Regards
> Joachim Lindborg
> CTO, systems architect
> 
> Sustainable Innovation  SUST.se
> Barnhusgatan 3 111 23 Stockholm
> Email: joachim.lindb...@sust.se
> linkedin: http://www.linkedin.com/in/joachimlindborg
> Tel +46 706-442270
> 
> 
> 2014-07-23 17:53 GMT+02:00 Sergey Dobrov :
> Hello folks,
> 
> We are wondering if anyone would be interested in autumn summit if we'd
> move it from North America to another place this year?
> 
> The possible places are welcome to be suggested.
> 
> Thanks!
> 
> --
> With best regards,
> Sergey Dobrov,
> XMPP Developer and JRuDevels.org founder.
> 
> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Autumn XMPP summit outside NA?

[Steffen Larsen]

That would be great. Or copenhagen. I could prob. find some sweet spots as 
well. :-)

/Steffen

On 24 Jul 2014, at 08:13, Joachim Lindborg  wrote:

> Sweden Stockholm would be perfect :) happy to host you all.
> 
> Regards
> Joachim Lindborg
> CTO, systems architect
> 
> Sustainable Innovation  SUST.se
> Barnhusgatan 3 111 23 Stockholm
> Email: joachim.lindb...@sust.se
> linkedin: http://www.linkedin.com/in/joachimlindborg
> Tel +46 706-442270
> 
> 
> 2014-07-23 17:53 GMT+02:00 Sergey Dobrov :
> Hello folks,
> 
> We are wondering if anyone would be interested in autumn summit if we'd
> move it from North America to another place this year?
> 
> The possible places are welcome to be suggested.
> 
> Thanks!
> 
> --
> With best regards,
> Sergey Dobrov,
> XMPP Developer and JRuDevels.org founder.
> 
> 



smime.p7s
Description: S/MIME cryptographic signature

[Standards] UPnP and XMPP

[Steffen Larsen]

I haven’t heard anything from the XMPP/UPnP Liaisons, but I just stumbled over 
this on the UPnP homepage (http://upnp.org/news/2014/): 
https://www.youtube.com/watch?v=V-QpNnQrT2U&list=UUY7zsGPIO9PRbUDv1obTBWQ

Personally I am hoping for some progress for Multi-Screen and XMPP which I have 
been working with for a while. Anyone know how I can get involved in this 
Committee? Any of you Liaisons that have been involved?

I thought it might be interesting for you guys. :-)

#Standards #XMPP #MUC #CLOUD 

-Cheers!
/Steffen

smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Namespace delegation and privileged component

[Steffen Larsen]

Heh funny enough, Ive been talking about this since Portland 2010 and been in 
my inbox for a while.

I actually also was thinking about a new component XEP or extension for the old 
XEP-114 XEP which gives you more access to the server.
I use almost XEP-0114 for every XMPP project I am doing (most business logic 
resides there) and it great for most of the purpose I’ve had so far, but 
sometimes it just don’t quite do the job I want. 

But also I want stream features for components, SASL, TLS and all the other 
good stuff which we have on S2S and C2S.
I could be great to use SALS and friends instead of handshaking and do roster 
access, db access and other stuff.
Maybe when defining this XEP, it could also be great to have different access 
level of the different components and NS delegations..

-Cheers!

/Steffen


On 08 May 2014, at 11:38, Steven Lloyd Watkin  wrote:

> Yes, this is exactly something I've talked about before (in Portland last 
> year and again at an XMPP UK event) and something Matthew Wild has partly 
> implemented somewhere (the "stanza hijacking" as I call it).
> 
> If you are putting something together please include me and I'll try and 
> throw in some ideas.
> 
> _
> 
> Steven Lloyd Watkin
> Software Engineer
> PHP ::: Java ::: Ruby ::: Node.js ::: XMPP
> ll...@evilprofessor.co.uk (email+jid) ::: http://www.evilprofessor.co.uk
> Facebook / Twitter / Flickr: lloydwatkin
> 
> Organiser of WORLD RECORD breaking charity event:
> Scuba Santas ::: http://www.scuba-santas.co.uk
> Supporting the RNLI & DDRC - 15th December 2013 - NDAC, Chepstow
> 
> 
> On 8 May 2014 10:09, Goffi  wrote:
> G'day,
> 
> I bring up this thread as we are currently having an interesting discussion
> with Binary and Edhelas.
> 
> Here is the main issue: components are really limited today, they're more
> something like server side clients, with very limited access (they can access
> entity roster for example, so a pubsub component can't manage roster access
> model).
> 
> We are thinking about two new XEPs to solve this issue:
> 
> - namespace delegation: a server delegate a full namespace to a component,
> e.g.  a component say "I want to manage 'vcard-temp'"
> 
> - privileged component: a component access everything a client can, in the
> name of the client. That's mean it can access an entity full roster without
> limitation, it's private storage, etc.
> 
> That would open XMPP to a huge new step in decentralisation, with these 2 XEPs
> you could host your own pubsub or PEP component at home. This is also better
> for security: you may want to host your own gateway because you don't want
> that the main server access your login/password for the legacy network.
> 
> An other huge advantage, would be the ability to overpass servers limitations:
> my server's internal PubSub service doesn't manage roster access ? No problem
> I had my own PubSub service as a privileged component. That's also mean quick
> development cycle when you want to try experimental stuff: you don't have to
> wait for server implementation to test something.
> 
> Here are the logs of our recents discussions: http://paste.debian.net/98158/
> 
> So we'll try to work on protoxep for this now, anybody interested in the
> subject please manifest yourself :)
> 
> Cheers
> Goffi
> 
> Le mercredi 13 novembre 2013, 18:35:45 Matthew Wild a écrit :
> > On 13 November 2013 18:12, Goffi  wrote:
> > > So, is it possible to remove these restrictions from the XEP ? Or at least
> > > to have an unsecure mode, and a secure mode with full access to roster ?
> >
> > This is related to something we discussed at the summit recently -
> > privileged components.
> >
> > I have half an implementation already, which allows components to
> > handle stanzas to the user's bare JID that the server would otherwise
> > handle (or reject). For example it's possible to handle standard vcard
> > queries in a component now.
> >
> > The point I got to was figuring out how the component should reply,
> > since the stanza needs to look like it came from the user.
> >
> > I'll also note here that Prosody at least already supports components
> > faking JIDs (ejabberd does too) when enabled by the admin. Prosody is
> > probably also happy with such components requesting the user's roster,
> > as well as other tasks. However this is definitely *not* in any
> > standard. I'd like to standardise this (in some form), and it seems
> > there are a number of people interested in it too.
> >
> > So we need to solve:
> >
> >   - Sending stanzas from the user
> >   - Sending stanzas to the user's account, and getting replies
> >
> > Someone put together a protoXEP :) (I already have enough XEP work on
> > my plate for the moment)
> >
> > Regards,
> > Matthew
> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Proposed XMPP Extension: Internet of Things - Discovery

[Steffen Larsen]

Hi Peter,

On 03 Apr 2014, at 14:03, Peter Waher  wrote:

> Hello Edwin & Co.
> 
>> You seem to confuse Historical with Deprecated.  Although the XEP is 
>> historical, the status is active.  Furthermore, all servers I have used so 
>> far support XEP-0114: this is a core feature of most implementations.
> 
> Actually, I do not. I am aware of the difference. What historical tells me, 
> apart from it being historical, i.e. part of the Jabber project before being 
> formalized, is that it:
> 
> * Is not sufficiently important to have been lifted and issues discussed and 
> fixed, to become draft or final (or RFC).
> * Any changes to it are not guaranteed to be backwards compatible.
> * It's future is unclear, which is also stated in the XEP.
> * It's use and implementation variants are unclear.
> * Security aspects are unclear.
> * It is not recommended by XSF or xmpp.org anywhere.
> 
> After having investigated XEP-0114 now in some more detail, there are various 
> aspects which concerns me. Since Jabber components seems to be a third way to 
> connect to an XMPP server (the other two being c2s and s2s), and a very 
> useful one at that I must agree, I think the XSF should take some time and 
> effort in formalizing this XEP a bit, and fixing some of its flaws. I'm told 
> that it uses an old version of XMPP (0.9), and I wonder if it is not in 
> everybody's interest to lift it to v1.0, and allow things such as starttls, 
> etc. to make it more secure. Today, there is no way for the client 
> (component) to validate that the server is who it pretends to be, which makes 
> MITM attacks quite easy. And since you get such a direct access to the 
> server, it looks very much like a backdoor to me.

I completely agree about making XEP-0114 (external components) more suitable 
and secure like any other S2S scenario. Lifting it to a XMPP version 1.0 stage 
would be great, but would also break a lot of implementations. 
> 
> Best regards,
> Peter Waher

-Cheers

/Steffen



smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Proposed XMPP Extension: Internet of Things - Discovery

[Steffen Larsen]

Hi Peter et. al.

Just a quick one about XE-0114 (external components): Most xmpp developers are 
putting their business logic there and its dead simple and every server out 
there supports it. + since its a protocol and can be run as client or server it 
makes it very portable and robust. :-)

/Steffen

On 02 Apr 2014, at 16:14, Peter Waher  wrote:

> Hello Philipp
> 
> Thanks for your insightful input. My response to the main item:
> 
 section 3.4:
 I don't think IBR should be recommended anymore.
>>> 
>>> IoT requires automatic account creation. However, I agree it must also be 
>>> secure, from the point of view of the server administrator, especially if 
>>> servers are publically available. I will post a separate XEP soon, that 
>>> provides a secure in-band registration mechanism that can be used by things.
>>> 
 section 3.5:
 I would recommend moving the discovery to standard disco#items and to use 
 components (xep-0114) -- those are not much harder to write than standard 
 clients and have many advantages in terms of managability.
>>> 
>>> Note sure here how this relates to 3.5. Was it a particular step you 
>>> referred to?
>> 
>> Basically I'd like to see the method #3 in 3.5 as the one and only way to do 
>> it, with examples. Basically a slightly expanded version of the "determining 
>> support" section:
>> disco#items to the server
>> then disco#info to each item to look for something which has a 
>> urn:xmpp:iot:discovery.
>> 
>> xep-0114 style components are just a very convenient way to do this in most 
>> server implementation, but I assumed that you had implemented this using a 
>> registry which was running over c2s. So I mixed up implementation comments 
>> and protocol comments :-/
>> 
>> I don't have a strong opinion whether that should be done before accepting 
>> it or afterwards. Might be handy to pretend the other methods never existed.
> 
> Ok. I will certainly have a look at the Jabber Components Protocol 
> (XEP-0114). Even though it is historical, it looks promising. Is there any 
> more recent information available than 
> http://xmpp.org/extensions/xep-0114.html?
> 
> One of the mayor problems is that in IoT architecture, we can in many cases 
> not choose the XMPP server. In some cases we do, but not in the most 
> important cases where for instance large operators or companies already have 
> their XMPP server chosen (their own in many cases). Since the XMPP server has 
> already been chosen by the operator in these cases, we need a solution that 
> can work regardless of XMPP server used.
> 
> This does not mean XEP-0114 is not a good idea to use, especially if 
> available. The problem is, this cannot be guaranteed. I will most certainly 
> explore this. However, is it possible that we do this during experimental 
> phase? This gives me some time to investigate how widespread the support for 
> XEP-0114 in the XMPP servers chosen for us is. It will also give us some 
> feedback if this can be said to be the main option, or a supplementary option 
> to use.
> 
> Ok?
> 
> Another concern is the following description in the introduction: "While this 
> component protocol is minimal and will probably be superseded by a more 
> comprehensive component protocol at some point".
> 
> Do you know anything about such plans for a future more comprehensive 
> component protocol?
> 
> Best regards,
> Peter Waher
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] deprecating in-band registration

[Steffen Larsen]

+1

/Steffen
On 02 Apr 2014, at 15:51, Kevin Smith  wrote:

> On Wed, Apr 2, 2014 at 2:35 PM, Peter Waher  wrote:
>> Hello Peter & community
>> 
>> As I mentioned before, I have an idea on how to make IBR secure. It would 
>> work as follows:
>> 
>> * A manufacturer, or responsible party, would create an account on the xmpp 
>> server, or have an account created for him by an operator. There he/she 
>> could be allowed to create a certain number of accounts automatically.
>> * The manufacturer would get a shared secret (say an "API Key") identifying 
>> the account.
>> * Each device or application wanting to perform IBR would have this key 
>> configured.
>> * When the device or app connects to the server, using IBR, it returns a 
>> registration form, as specified in IBR. But one (or two) of the fields would 
>> contain a challenge.
>> * The device or application fills in the response field according to the 
>> shared secret and the challenge. Perhaps using OAUTH.
>> * When registering, the new account would be discounted from the pool of 
>> accounts permitted by the key.
>> * If a shared secret gets to be known, the manufacturer or responsible party 
>> can just choose to generate a new shared secret (or key).
>> 
>> In this way operatos of the xmpp server can have control of who are trusted 
>> to create accounts automatically. And they in turn have control of how many 
>> accounts can be created, and monitor how many have been created. And it 
>> allows them to create devices without preprogrammed JID:s.
>> 
>> What do you think about such an approach?
> 
> If you're at the stage of putting shared secrets into the devices, why
> not generate certs for the devices, and do auto-provisioning of
> accounts based on the certs provided by clients? This doesn't require
> new protocol and allows fine-grained control.
> 
> /K



smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] deprecating in-band registration

[Steffen Larsen]

Hi Peter,

Provisioning or re-provisioning (buy/sell devices) “accounts” for IoT and M2M 
is actually one of the biggest “problems” / issues. So I think, that rethinking 
this problem will be the the best solution.

-Just my 50 cent
/Steffen

On 02 Apr 2014, at 05:01, Peter Saint-Andre  wrote:

> Several folks have commented on in-band registration (IBR, XEP-0077) 
> recently, wondering aloud whether we really want to recommend it for things 
> like registering devices in IoT environments.
> 
> I agree with the concerns that people have expressed. I suggest that we push 
> this line of thinking to its logical conclusion and strongly consider 
> deprecating and then obsoleting IBR. Perhaps - perhaps! - IBR was appropriate 
> in 1999 when we were trying to encourage people to easily try out this new 
> technology called Jabber. Those days are long gone.
> 
> 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, not reuse something that is 
> fundamentally flawed.
> 
> Peter
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] XEP-0134: XMPP Design Guidelines

[Steffen Larsen]

Yes, you are right Christian. I think that maybe the editor team will create 
some script that might reveal some of our XEPs that need to be updated into new 
states etc.

/Steffen

On 28 Feb 2014, at 09:10, Christian Schudt  wrote:

> Hi,
> 
> I always like up to date documents and specifications. So I vote yes :-)
> 
> In my opinion, there are (too) many "last-updated-2004" documents. (or at 
> least mid-2000s)
> Or generally documents, which are really long in Draft state. (XEP-0001 says 
> it can become Final after 6 months in Draft and 2 implementations, which 
> probably apply to most XEPs)
> 
> Or documents which feel strange, when reading them, e.g.
> XEP-0270 vs XEP-0302, which imply that XMPP isn't moving much since 2010.
> 
> Christian
> 
> 
> Am 28.02.2014 um 01:24 schrieb Peter Saint-Andre:
> 
>> Old, nay ancient, thread alert!
>> 
>> On 9/17/12, 2:31 PM, Philipp Hancke wrote:
>>> While searching for the design guideline that says "don't put big things
>>> inside a presence stanza, use PEP" I found XEP-0134 and it almost had
>>> what I was looking for:
>>> 
 Finally, as explained in XMPP Core, the  stanza exists to
 broadcast network and communications availability only; for more
 advanced information publishing, use Publish-Subscribe [7].
>>> 
>>> This is somewhat outdated, you'd use PEP for that. There are several
>>> other points where this is outdated. How comes nobody ever noticed that
>>> (Peter has an excuse -- he was expecting feedback)?
>>> 
>>> My effort may be in vain since google doesn't seem to consider 0134 to
>>> be important but I'll raise (some of) the issues anyway. Specifically:
>>> 2.1: XMPP is Sacred
>>>well, it's a hard process, but making changes is possible.
>>>The reference to XEP-0060 ought to be replaced by one to 0163
>>>obviously.
>>> 
>>> 2.2: how long has groupchat been deprecated? 8 years at least? Doesn't
>>> strike me as a good example these days.
>>> 
>>> 2.3: jingle/ice might be a better example.
>>> 
>>> 2.4.: oh, this section still calls it "Jabber" :-)
>>> 
>>> 2.5: again, jingle would be a better example.
>>> 
>>> Generally, i think this document is really 2004! Alot has changed since
>>> then. XEP-0115 (in it's current revision) certainly impacts the design
>>> of new extensions, as does PEP. Are things like SI (XEP-0095) still
>>> relevant?
>> 
>> Yes, that document is probably well out of date now. Do we feel it would be 
>> worth the effort to bring it into the modern world?
>> 
>> Peter
>> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] DRAFT: XEP-0152 (Reachability Addresses)

[Steffen Larsen]

Hi Joachim, 

I’ve written a small note here: http://wiki.xmpp.org/web/Editor_team

/Steffen

On 26 Feb 2014, at 11:52, Joachim Lindborg  wrote:

> Thats very good  could the team describe itself? 
> xmpp.org (http://xmpp.org/participate/become-a-member/)  work teams
> wiki.xmpp.org (http://wiki.xmpp.org/web/Main_Page) left hand menu comm_team 
> etc
> 
> Regards
> Joachim Lindborg
> CTO, systems architect
> 
> Sustainable Innovation  SUST.se
> Barnhusgatan 3 111 23 Stockholm
> Email: joachim.lindb...@sust.se
> linkedin: http://www.linkedin.com/in/joachimlindborg
> Tel +46 706-442270
> 
> 
> 2014-02-26 10:16 GMT+01:00 Dave Cridland :
> As a bit of a meta-note here, this message shows that the transition we've 
> undergone from a single Editor (Peter Saint-Andre) to a small XSF work team 
> is going really well (and impressively quickly - the setup meeting was only 
> yesterday). So to the volunteers on the team, thanks!
> 
> 
> On Tue, Feb 25, 2014 at 11:39 PM, XMPP Extensions Editor  
> wrote:
> Version 1.0 of XEP-0152 (Reachability Addresses) has been released.
> 
> Abstract: This document defines an XMPP protocol extension for communicating 
> information about how an entity can be reached temporarily using methods 
> other than the entity's normal JID.
> 
> Changelog: Per a vote of the XMPP Council, advanced specification from 
> Experimental to Draft. (XEP Editor (mm))
> 
> Diff: http://xmpp.org/extensions/diff/api/xep/0152/diff/0.6/vs/1.0
> 
> URL: http://xmpp.org/extensions/xep-0152.html
> 
> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] [IOT] IoT device Discovery XEP

[Steffen Larsen]

Hi Peter,

I would very munch be interested.

/Steffen

On 17 Feb 2014, at 23:30, Peter Waher  wrote:

> Hello
>  
> We’re planning to start writing a new XEP proposal for IoT device discovery. 
> I’ve received interest from a couple of people who wants to work on this. If 
> anybody is interested in participating in this work, please let me know.
>  
> The first proposal for the proto-XEP will be published in normal order on the 
> standards list for anybody to comment on.
>  
> Best regards,
> Peter Waher
>  
> ___
> IOT mailing list
> i...@xmpp.org
> http://mail.jabber.org/mailman/listinfo/iot



smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] SMS/Email Forwarding of Messages

[Steffen Larsen]

Yes exactly. Support of data forms etc. would be nice for setup and query.

/Steffen

On 17 Feb 2014, at 19:10, Simon Tennant  wrote:

> IMHO this is really something that should be in the push spec.
> configure with numbers/email addresses
> push events to "pusher component"
> Services like "knowing if delivery has gone through could be reflected in the 
>  to .
> 
> This is how we solved it on the Buddycloud "pusher" 
> https://github.com/buddycloud/buddycloud-pusher#add-or-configure-push-records
> 
> @Lance - do you need any help writing the XEP once you are finished with 
> Websockets and London?
> ᐧ
> 
> 
> On 17 February 2014 15:02, Spencer MacDonald 
>  wrote:
> Hi Steffen,
> 
> I was at the summit and also thought that it could be added to the push 
> notification XEP, but for SMS/Email you might want to:
> 
> - Know what telephone number or email address the message was forwarded on to.
> - Know if the message has been sent/received/opened
> - Opt in/Out of paying for forwarding (in the case of SMS).
> 
> So although it can be just another end point, I think you still need 
> additional logic when compared to push notifications.
> 
> Regards
> 
> Spencer
> 
> On 17 Feb 2014, at 13:51, Steffen Larsen  wrote:
> 
> > I think you might look at the stuff we were discussing at the XMPP summit, 
> > namely push notifications.
> > Lance stout have begun doing a XEP for this: 
> > http://legastero.github.io/customxeps/extensions/push.html
> >
> > It can prob. be used for SMS and email as well. Just another endpoint. :-)
> >
> > /Steffen
> >
> >
> > On 17 Feb 2014, at 14:47, Spencer MacDonald 
> >  wrote:
> >
> >> Is there any XEP that covers a message getting forwarded using another 
> >> transport e.g. SMS, Email?
> >>
> >> If not would there be any interest in making a standard one?
> >>
> >> My personal use case is if the recipient is offline, the message can be 
> >> forward to their phone as an SMS.
> >>
> >> Regards
> >>
> >> Spencer
> >
> 
> 
> 
> 
> -- 
> Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/tQgxP



smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] SMS/Email Forwarding of Messages

[Steffen Larsen]

I think you might look at the stuff we were discussing at the XMPP summit, 
namely push notifications.
Lance stout have begun doing a XEP for this: 
http://legastero.github.io/customxeps/extensions/push.html

It can prob. be used for SMS and email as well. Just another endpoint. :-)

/Steffen


On 17 Feb 2014, at 14:47, Spencer MacDonald  
wrote:

> Is there any XEP that covers a message getting forwarded using another 
> transport e.g. SMS, Email?
> 
> If not would there be any interest in making a standard one?
> 
> My personal use case is if the recipient is offline, the message can be 
> forward to their phone as an SMS.
> 
> Regards
> 
> Spencer



smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Push notification XEP

[Steffen Larsen]

Yes but the approach that this bodycloud component (XEP-0114) could easily be 
written into more or less a XEP.

/Steffen

On 21 Jan 2014, at 11:51, Daniele Ricci  wrote:

> I was thinking of a more specific (and simpler) approach to just using
> push notification services. Buddycloud is much more than that.
> 
> On Tue, Jan 21, 2014 at 11:30 AM, Abmar Barros  wrote:
>> It sounds like what we've been doing with the buddycloud pusher:
>> https://github.com/buddycloud/buddycloud-pusher.
>> 
>> We currently use it to send GCM and emails regarding buddycloud-related
>> events, as per its documentation, but it can be easily extended to push any
>> XMPP event to any pusher service, eg.: Apple's, SMS.
>> 
>> Regards,
>> Abmar
>> 
>> 
>> On Tue, Jan 21, 2014 at 7:58 AM, Daniele Ricci 
>> wrote:
>>> 
>>> Hello list,
>>> I was thinking of writing a XEP for sending a sender ID (Google Cloud
>>> Messaging) or a device token (Apple Push Notification Service) or any
>>> other push notification service token (that is, a generic one) to the
>>> server.
>>> Almost all push notification services works the same way: the server
>>> provides a provider ID to the client and the client provides a device
>>> token to the server.
>>> 
>>> I was thinking of using service discovery to advertise the service
>>> from a server:
>>> 
>>> 
>>>  >> node='http://jabber.org/extensions/presence#push'>
>>>
>>>
>>>
>>> 
>>> 
>>> 
>>> In the "node" attribute I'd put the provider ID I was talking about
>>> earlier.
>>> 
>>> Device token could be sent using a presence update from the client:
>>> 
>>> 
>>>  ...
>>>  ...
>>>  REGISTRATION-ID
>>> 
>>> 
>>> (that would need to be filtered by the server before broadcasting the
>>> presence update though, for security reasons).
>>> 
>>> Or an iq to the push notification address could be used:
>>> 
>>> 
>>>  >> xmlns='http://jabber.org/extensions/presence#push'>DEVICE-TOKEN
>>> 
>>> 
>>> I'd really appreciate some feedback. I think it would be a useful XEP.
>>> Regards,
>>> --
>>> Daniele
>> 
>> 
>> 
>> 
>> --
>> Abmar Barros
>> MSc in Computer Science from the Federal University of Campina Grande -
>> www.ufcg.edu.br
>> OurGrid Team Leader - www.ourgrid.org
>> Buddycloud Dev - www.buddycloud.org
>> Paraíba - Brazil
> 
> 
> 
> -- 
> Daniele



smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] OneM2M writes about the XMPP IoT extensions

[Steffen Larsen]

Interesting stuff..

/Steffen

On 13 Jan 2014, at 23:41, Peter Waher  wrote:

> Hello
>  
> Look at what OneM2M (& Cisco) writes about the XMPP IoT solution.
> ftp://ftp.onem2m.org/Work%20Programme/WI0008/oneM2M-TR-0009-Protocol_Analysis-V0_4_0.DOC
>  
> Best regards,
> Peter Waher



smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Updated: Event logging over XMPP

[Steffen Larsen]

Hi Mat,

Interesting the stuff you are doing, it seems that we are doing something 
similar. I was actually thinking in making a standard for TV (something like 
PEP et al.). Maybe we could join forces and share thoughts? What have you used 
XMPP for in the area of TVs? for Second screen handling, trick play etc or?

-Cheers and merry x-mas!

/Steffen

On 25 Dec 2013, at 02:50, mat henshall  wrote:

> Hi Joachim,
> 
> We have over the last few years developed a very rich set of XMPP protocols 
> fro working with Iot devices… From TV's to air conditioners to thermostats to 
> battery devices to lighting.. to…. I saw the XEP's you mention as they were 
> being developed, and unfortunately we were too far ahead in our own 
> definitions and implementations at the time they were being formulated. When 
> I last looked at them they were insufficient for the use cases our customers 
> wanted and we sadly did not have the bandwidth to help make them 'fit'. Which 
> I do regret.
> 
> We already had a couple of major brands adopting our protocol, and the 
> consequence of changing and working with you guys to make changes at that 
> time were high impact. Now doubly so :-( As is often the case, "executing 
> code always wins".
> 
> I am hoping next year to be able to more fully contribute to the open 
> standards in this area and also to have a road map for our protocol to adopt 
> the standards where appropriate.
> 
> As we work on the Eventlogging XEP implementation we will be sure to provide 
> any issues or feedback as we find it.
> 
> Mat
> 
> 
> 
> 
> On Tue, Dec 24, 2013 at 5:34 PM, Joachim Lindborg  
> wrote:
> Here is the latest https://github.com/joachimlindborg/XMPP-IoT
> 
> http://htmlpreview.github.io/?https://github.com/joachimlindborg/XMPP-IoT/blob/master/eventlogging.html
> 
> why not add the the two extensions for read and write of IoT devices to. So 
> your whole system is compliant?
> http://xmpp.org/extensions/xep-0323.html
> http://xmpp.org/extensions/xep-0325.html
> 
> Just send a note will be happy helping you out
> 
> 
> 
> Regards
> Joachim Lindborg
> CTO, systems architect
> 
> Sustainable Innovation AB
> Adress: Box 55998 102 16 Stockholm
> Besöksadress: Storgatan 31 (Malmgården)
> Email: joachim.lindb...@sust.se, www.sust.se
> linkedin: http://www.linkedin.com/in/joachimlindborg
> Tel +46 706-442270
> 
> 
> 2013/12/24 mat henshall 
> All - where is the latest draft of the event logging XEP?
> 
> We are going prototype it into our IOT framework and build a little event 
> logging client to receive and store…
> 
> Mat
> 
> 
> On Wed, Nov 13, 2013 at 2:58 PM, Peter Waher  wrote:
> Hello Ludovic
> 
> Excellent. Thanks for taking the time to read the document so carefully. It's 
> hard to see those details.
> 
> I've attached a new version of the document where this has been corrected.
> 
> Best regards,
> Peter Waher
> 
> -Original Message-
> From: Ludovic BOCQUET [mailto:lbx...@live.com]
> Sent: den 13 november 2013 19:34
> To: standards@xmpp.org
> Subject: Re: [Standards] Updated: Event logging over XMPP
> 
> Comments after:
> Le 13/11/2013 19:09, Peter Waher a écrit :
> > > type='normal' xml:lang='en'>
> >   
> >  Something happened.
> >   
> >   
> must be:
> 
>   
> 
> >  Something else happened.
> >   
> >
> 
> For be beautiful, all http://www.xmpp.org links must be http://xmpp.org.
> Example 
> 
> Regards,
> 
> BOCQUET Ludovic
> 
> 
> 
> 
> -- 
> 
> Mat Henshall
> Founder and CEO, Square Connect, Inc.
> San Jose, CA
> www.squareconnect.com
> cell: 650.814.7585
> 
> 
> 
> 
> -- 
> 
> Mat Henshall
> Founder and CEO, Square Connect, Inc.
> San Jose, CA
> www.squareconnect.com
> cell: 650.814.7585



smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP

[Steffen Larsen]

Hi,

On 18 Nov 2013, at 13:07, Andreas Kuckartz  wrote:

> Simon Tennant:
>> IMHO, e2e security would probably make more sense as a XEP and working
>> group that has the time to zoom into all the implementation details.
> 
> Can that be solved by an XEP ?
> 
> What about this IETF draft? (I still have to read it)
> 
> End-to-End Object Encryption and Signatures for the Extensible Messaging
> and Presence Protocol (XMPP)
> draft-miller-xmpp-e2e-06
> https://datatracker.ietf.org/doc/draft-miller-xmpp-e2e/
> 
> There exist people who mention XMPP as belonging to "faulty
> technologies" for which they want to create alternatives:
> http://youbroketheinternet.org/
> 
> And I try to find out what can be done to improve XMPP regarding
> security and privacy.
> 

Well you can “always” run XMPP on top of TOR if you like that, if it is the S2S 
routing that bothers you. :-)


> Cheers,
> Andreas
> 
>> On 18 November 2013 10:30, Andreas Kuckartz > > wrote:
>> 
>>Peter Saint-Andre some time ago wrote:
>>> On 7/16/13 4:27 AM, Carlo v. Loesch wrote:
 Since XMPP isn't suitable for keeping meta-data private I would
 presume that e2e privacy is out of scope for this mailing list,
 really.
>>> 
>>> True.
>> 
>>Where would the topic e2e privacy for XMPP be "in scope" ?
>> 
>>Cheers,
>>Andreas


/Steffen

smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Updated: Event logging over XMPP

[Steffen Larsen]

No problem Peter, You did all the hard job.. I am just commenting. :-)

/Steffen

On 13 Nov 2013, at 19:09, Peter Waher  wrote:

> Hello Steffen
> 
> Ok, I see. It might be, as you say, implementation specific. Our 
> implementation accepts any number of child elements. But that might not be 
> the case for everybody perhaps. I have no idea.
> 
> Anyway, I've added a section §3.9 (new version attached) to show how multiple 
> events can be sent in a single message to clarify that the receiving end 
> needs to support this. Good thinking to point this out. Thanks.
> 
> Best regards,
> Peter Waher
> 
> 
> -Original Message-
> From: Steffen Larsen [mailto:zoo...@gmail.com] 
> Sent: den 13 november 2013 12:47
> To: XMPP Standards
> Subject: Re: [Standards] Updated: Event logging over XMPP
> 
> Hi Peter,
> 
> I was thinking the same, that you could put multiple log elements into the 
> message.. But then client or component should in the other end always try to 
> "read" multiple  structures out of the message stanza.
> It should be possible, but on the other side how do we treat the other tags 
> inside the stanzas?  I mean most client parsers probably only expect one 
>  element.. I don't know if that multiple elements should be stated 
> explicitly.
> 
> -Cheers!
> 
> /Steffen
> 
> On 13 Nov 2013, at 14:58, Peter Waher  wrote:
> 
>> Hello Steffen
>> 
>> Thanks for the feedback. It's a good point that you might want to send 
>> multiple events in the same message. But would that not be accomplished with 
>> the current structure, but with multiple  elements? As so:
>> 
>>  > type='normal' xml:lang='en'>
>> 
>>Something happened.
>> 
>> 
>>Something else happened.
>> 
>>  
>> 
>> Or do client implementations suppose only one custom element is sent per 
>> message?
>> 
>> If the above would work, should I add an Implementation Note regarding this? 
>> 
>> Best regards,
>> Peter Waher
>> 
>> -Original Message-
>> From: Steffen Larsen [mailto:zoo...@gmail.com] 
>> Sent: den 13 november 2013 06:05
>> To: XMPP Standards
>> Subject: Re: [Standards] Updated: Event logging over XMPP
>> 
>> Hi,
>> 
>> I really think we have made some progress on this one. So cool Peter! :-)
>> Just want to add a small thing: I have some logging like this already on my 
>> clients, and when the information is not that important I sometime piggy 
>> back the event log into one message stanza.
>> So what I really would like to do is, to be able to have multiple  tags.
>> 
>> So maybe like this:
>> 
>>  > type='normal' xml:lang='en'>
>>  
>>  >  message='Something happened.'
>>  timestamp='2013-11-10T15:52:23Z' />
>>  >  message='Something else happened.'
>>  timestamp='2013-11-10T15:54:23Z' />
>>   
>>  
>> 
>> Is it totally crazy?
>> Coming back to the naming.. Now here is a log, consisting of multiple 
>> events..  
>> Of course I would only do this If the logged events are not that important 
>> and needed to be near real-time. :-)
>> 
>> -Just my 50 cent
>> /Steffen
>> 
>> 
>> On 12 Nov 2013, at 16:30, Peter Waher  wrote:
>> 
>>> Hello
>>> 
>>> I've updated the event logging proposal following the discussion with Dave. 
>>> I've made the message and stackTrace attributes into child elements 
>>> instead, better suited for multi-line text. I've also added some more 
>>> security considerations and reference to the publish/subscribe pattern.
>>> 
>>> I've attached the latest versions.
>>> 
>>> Best regards.
>>> Peter Waher
>>> 
>>> 
>>> 
>>> 
>> 
> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Updated: Event logging over XMPP

[Steffen Larsen]

Hi Peter,

I was thinking the same, that you could put multiple log elements into the 
message.. But then client or component should in the other end always try to 
“read” multiple  structures out of the message stanza.
It should be possible, but on the other side how do we treat the other tags 
inside the stanzas?  I mean most client parsers probably only expect one  
element.. I don’t know if that multiple elements should be stated explicitly.

-Cheers!

/Steffen

On 13 Nov 2013, at 14:58, Peter Waher  wrote:

> Hello Steffen
> 
> Thanks for the feedback. It's a good point that you might want to send 
> multiple events in the same message. But would that not be accomplished with 
> the current structure, but with multiple  elements? As so:
> 
>type='normal' xml:lang='en'>
>  
> Something happened.
>  
>  
> Something else happened.
>  
>   
> 
> Or do client implementations suppose only one custom element is sent per 
> message?
> 
> If the above would work, should I add an Implementation Note regarding this? 
> 
> Best regards,
> Peter Waher
> 
> -Original Message-
> From: Steffen Larsen [mailto:zoo...@gmail.com] 
> Sent: den 13 november 2013 06:05
> To: XMPP Standards
> Subject: Re: [Standards] Updated: Event logging over XMPP
> 
> Hi,
> 
> I really think we have made some progress on this one. So cool Peter! :-)
> Just want to add a small thing: I have some logging like this already on my 
> clients, and when the information is not that important I sometime piggy back 
> the event log into one message stanza.
> So what I really would like to do is, to be able to have multiple  tags.
> 
> So maybe like this:
> 
>type='normal' xml:lang='en'>
>   
>  message='Something happened.'
>   timestamp='2013-11-10T15:52:23Z' />
>  message='Something else happened.'
>   timestamp='2013-11-10T15:54:23Z' />
>
>   
> 
> Is it totally crazy?
> Coming back to the naming.. Now here is a log, consisting of multiple 
> events..  
> Of course I would only do this If the logged events are not that important 
> and needed to be near real-time. :-)
> 
> -Just my 50 cent
> /Steffen
> 
> 
> On 12 Nov 2013, at 16:30, Peter Waher  wrote:
> 
>> Hello
>> 
>> I've updated the event logging proposal following the discussion with Dave. 
>> I've made the message and stackTrace attributes into child elements instead, 
>> better suited for multi-line text. I've also added some more security 
>> considerations and reference to the publish/subscribe pattern.
>> 
>> I've attached the latest versions.
>> 
>> Best regards.
>> Peter Waher
>> 
>> 
>> 
>> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Dialback, authentication, and authorization

[Steffen Larsen]

ha ha ha… :-)

/Steffen

On 13 Nov 2013, at 14:57, Thijs Alkemade  wrote:

> 
> On 13 nov. 2013, at 14:51, Philipp Hancke  wrote:
> 
>>> Ejabberd's default key:
>>> C5:78:17:B1:34:90:54:D0:5A:16:A4:C6:71:80:6D:C3:F8:8B:F1:31:3D:64:BD:42:8F:1F:C5:D9:21:EB:99:BE
>> 
>> That is the CN=ejabberd? Likely the same one I saw back in
>> http://mail.jabber.org/pipermail/standards/2007-July/016086.html
> 
> No, the CN of all results with that public key is “Mickael Remond”, see for
> example https://xmpp.net/result.php?id=2179#certificates.
> 
> Thijs



smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Updated: Event logging over XMPP

[Steffen Larsen]

Hi,

I really think we have made some progress on this one. So cool Peter! :-)
Just want to add a small thing: I have some logging like this already on my 
clients, and when the information is not that important I sometime piggy back 
the event log into one message stanza.
So what I really would like to do is, to be able to have multiple  tags.

So maybe like this:

   
   

Re: [Standards] Updated XEP: Event Logging over XMPP

[Steffen Larsen]

Cool Peter!,

I’ll read it more thoroughly here the next couple of days for more feedback. 
Maybe we should put it into github before we ship it to the inbox?

/Steffen

On 10 Nov 2013, at 23:13, Peter Waher  wrote:

> 



smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Proposal: Event logging over XMPP

[Steffen Larsen]

On 10 Nov 2013, at 22:21, Mike Taylor  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 11/10/2013 02:58 PM, Steffen Larsen wrote:
>> Hi Peter,
>> 
>> First of all great work and perfect to bring this up.. I’ve done
>> this a while now, but haven’t brought it to a broader audience.
>> thumbs up!
> 
> indeed, good job and +1 for this
> 
>> So here is my first 50 cent on the doc:
>> 
>> Cool stuff with the tags.. This I can tel you will be valuable for
>> many people. I use these kind of tags all the time to piggy back
>> stuff, that could be valuable in the context.
>> 
>> I don’t like the tag “event”. I think it should be  tag
>> instead, no to confuse anybody. I have made several custom XMPP
>> components and client where they have event tag embedded, which
>> have a completely different meaning and context.
> 
> I also think that "event" is a bit too broad of a term here and would
> prefer "log" or even “eventlog"

+1 absolutely agree

> 
>> 
>> Type and Level? I think its too complicated. Only level should be 
>> present and with fewer clases.. Debug, Info, Notice… is way too
>> much. People tend to misuse and not think when they have a lot of
>> choices. :-)
> 
> I also think that this may be too many options and would prefer to see
> Level limited to a smaller set and have Type removed completely as it
> could be implemented as Tags.

Yes, limit it to Level and maybe only use debug, info, warning, error and 
critical. 
This is enough details.. Seen way to many systems trying to make it even more 
fine-grained and they failed miserable - because it is hard to understand as a 
human.. if e.g Alert is worse than Critical etc.. So people tend to misuse 
them.. So lets stick to few (5’ish) levels or so.


> 
> I do love that you've chosen to use words instead of numbers to
> represent the levels.

+1, ohh yes


> 
> Another item I wanted to bring up is can we just remove timezone
> worries completely and say "use UTC and only UTC"? IMO it is a best
> practice and would avoid the whole TZ issue (yea, yea, I know this one
> is going to be a long shot ;)
> 


Yes could be an idea,,


> thanks!
> 
>> 
>> -Cheers! /Steffen
>> 
>> On 10 Nov 2013, at 20:31, Peter Waher > <mailto:peter.wa...@clayster.com>> wrote:
>> 
>>> Hello all
>>> 
>>> First of all: Thank you to everybody providing both input and an 
>>> interest. It is clear the need for an extension in this area is 
>>> missing and both wanted and needed.
>>> 
>>> So I took the opportunity to write a first proposal based on all
>>> your comments and on our past experience as well, on how such an
>>> event logging extension could look like (attached). I’ve made
>>> sure Syslog events can be mapped onto such event log messages
>>> (being a standard and all), but extended it a bit to provide for
>>> things lacking in Syslog as well as adapting it to the world of
>>> XML where new possibilities exist.
>>> 
>>> The extension is made so that it can be used both by those who
>>> only want to send simple text events and by those who want to
>>> have a more controlled way of sending data (including data and
>>> types). Hopefully this is a good compromise. But as with all
>>> compromises, it has the possibility to offend people in both
>>> camps…
>>> 
>>> What do you think? If you have any questions, comments or
>>> suggestions please don’t hesitate to mail them.
>>> 
>>> Best regards, Peter Waher
>>> 
>>> 
>> 
> 
> 
> - -- 
> 
> bear
> xmpp agitator; ops curmudgeon; generalist
> http://bear.im/about
> http://bear.im/pubkey.txt
> 0A93 9BA7 8203 FCBC 58A9 E8B5 9D1E 0661 8EE5 B4D8
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQIcBAEBAgAGBQJSf/jwAAoJEJ0eBmGO5bTYSZQP/RU4RErKoT0I+5o9qNS8cu7q
> d5dh3oraLTZaKS+G9vB3qwjGHaeUYCzqzygZdekm6xmsh/X8OCd5sgHSqgwpCTuM
> reMicE7VW4xel/NVC9m7tyyEVeqepDB0AYQrlCSEMG7chpTuasqrf7Uv78M/ss04
> swartJSGNAuLx0hDtvBFkHnyh/JtMOiyigE1fNgLArV2YUsiN8wbCef/Gflo6l0k
> tP8Y/s3ZrRLnmE4Ay9+FoHHm/FuYff8ALxkLU0dfY4whnecOdAQWMhbrh8SBDys6
> 4bvGvVG7tyg/LbGLD3Bv8BmfU1tbo5b5HR/WPMGdAoNs9ldtYuBoA3+rxpFDIaUz
> aiQP6O5F5W1eA7MRkMWOw+W2sixVzaIIlJ/GvmYNTM9rX5UtIIxAIxbZfjkg8hC6
> cNRitUaPpZPDAnfNmSU1SXFg4dUS2U0Xf+HUTwKcFmcm5AN7lqQrVcG9Cw2K/61F
> 5cGUfETQue7f7W4Qrn9h9ixXux9u0UEvpivY2DgHWxOEnTv0W9tQziCQgn8n/Vto
> VpWqo2xzrxJv4epzI6K2HN1R+zdKlxbyuc2vLv6reTmL59ioEzOoQxk5fYwt9q6d
> 1TMDMMlJIgfG4w2E+FHPjdmJh8q8FCQMUClUVYX4t6kb2/nbwlKpFfN5bHnmiIIE
> zv0YlqAhtaGXFamqjSJM
> =kob/
> -END PGP SIGNATURE——

/Steffen




smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Proposal: Event logging over XMPP

[Steffen Larsen]

Hi Peter,

First of all great work and perfect to bring this up.. I’ve done this a while 
now, but haven’t brought it to a broader audience. thumbs up!
So here is my first 50 cent on the doc:

Cool stuff with the tags.. This I can tel you will be valuable for many people. 
I use these kind of tags all the time to piggy back stuff, that could be 
valuable in the context.

I don’t like the tag “event”. I think it should be  tag instead, no to 
confuse anybody. I have made several custom XMPP components and client where 
they have event tag embedded, which have a completely different meaning and 
context.

Type and Level? I think its too complicated. Only level should be present and 
with fewer clases.. Debug, Info, Notice… is way too much. People tend to misuse 
and not think when they have a lot of choices. :-)

-Cheers!
/Steffen

On 10 Nov 2013, at 20:31, Peter Waher  wrote:

> Hello all
>  
> First of all: Thank you to everybody providing both input and an interest. It 
> is clear the need for an extension in this area is missing and both wanted 
> and needed.
>  
> So I took the opportunity to write a first proposal based on all your 
> comments and on our past experience as well, on how such an event logging 
> extension could look like (attached). I’ve made sure Syslog events can be 
> mapped onto such event log messages (being a standard and all), but extended 
> it a bit to provide for things lacking in Syslog as well as adapting it to 
> the world of XML where new possibilities exist.
>  
> The extension is made so that it can be used both by those who only want to 
> send simple text events and by those who want to have a more controlled way 
> of sending data (including data and types). Hopefully this is a good 
> compromise. But as with all compromises, it has the possibility to offend 
> people in both camps…
>  
> What do you think? If you have any questions, comments or suggestions please 
> don’t hesitate to mail them.
>  
> Best regards,
> Peter Waher
>  
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Event Logging over XMPP

[Steffen Larsen]

Hi Peter,

I was actually not opting specifically for a JSON solution.. I was just 
responding on Bears mail about a possible solution using the log stash 
“protocol”.. But count me in if we need to define a XEP, I’ve done something 
like this before. :-)

/Steffen

On 10 Nov 2013, at 15:37, Peter Waher  wrote:

> Hello Steffen
>  
> I would prefer not to use JSON as I want to include this in resource 
> constrained environments. They already have sufficient problems implementing 
> XML parsers, and to include JSON parses as well (for no apparent reason) 
> would just be a waste of precious bytes in a small device. Furthermore, using 
> JSON is like check-mating the entire idea by using XML in XMPP in the first 
> place: plugability using namespaces, easy to validate (schema), search 
> (XPath) and version handling and transformations (XSLT). I understand 
> javascript clients are fond of JSON, but as a protocol to send tagged and 
> interoperable data, I would choose XML.
>  
> However, having said that, we should collect a set of appropriate 
> fields/attributes (as in your example) that must go into such a message for 
> it to be useful.
>  
> Best regards,
> Peter Waher
>  
>  
> From: Steffen Larsen [mailto:zoo...@gmail.com] 
> Sent: den 10 november 2013 07:19
> To: XMPP Standards
> Subject: Re: [Standards] Event Logging over XMPP
>  
> Hi Bear et al,
>  
> Yes I was thinking of the same thing. I’ve done it in a different way now, 
> but using log stash just means to embedded the JSON into the stanza. 
> Because I am using logstash/kibana (elastic search, 
> http://www.elasticsearch.org/overview/kibana/) for my customers so that would 
> be straight forward. Maybe a message stanza like this?:
>  
> 
> 
> 
> {
>   "@source":"stdin://jvstratusmbp.local/",
>  "@type":"stdin",
>  "@tags":[],
>  "@fields":{},
>  "@timestamp":"2012-07-02T05:20:16.092000Z",
>  "@source_host":"jvstratusmbp.local",
>  "@source_path":"/",
>  "@message":"test"
> }
> 
> 
> 
>  
> or if you do not want to embed it into the body but in a separate container 
> instead:
>  
> 
> 
> 
> 
> {
>   "@source":"stdin://jvstratusmbp.local/",
>  "@type":"stdin",
>  "@tags":[],
>  "@fields":{},
>  "@timestamp":"2012-07-02T05:20:16.092000Z",
>  "@source_host":"jvstratusmbp.local",
>  "@source_path":"/",
>  "@message":"test"
> }
> 
> 
> 
>  
> In the receiving part (log...@mydomain.tld) it could either be a component or 
> a simple bot, that either appended the embedded json into a file and 
> logstashd would take it, or a component that would queue it directly to 
> rabbitmq which in my example would feed it to logstash/kibana.
>  
>  
> I am already using logstash and graphite for my XMPP servers, its nice to 
> have a visual overview and graphs when handling large scale XMPP… H maybe 
> I could use that as a topic for FOSDEM?
>  
> -Cheers!
> /Steffen
>  
>  
> On 09 Nov 2013, at 21:20, Mike Taylor  wrote:
> 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 11/09/2013 03:13 PM, Robert Kosten wrote:
> 
> Hi, a Lurker here ;-)
> 
> I've had the same thought about two years ago as well so I
> implemented a small Monolog (PHP Logging Library) Handler that sent
> log messages as both formatted message (for standard chat clients)
> and a custom stanza for our status board. At the time I thought
> that pub/sub might actually be better though, because I didn't
> really want the logger to know who would receive the message...
> 
> Sadly that code belongs to a former company and I'm not certain I
> can remember everything about it (It was a quick'n'dirty
> solution), otherwise I'd attach it :-P
> 
> Regards, Robert Kosten
> 
> On 11/09/2013 09:08 PM, Steffen Larsen wrote:
> 
> No haven’t seen such a XEP, but I’ve implemented something like
> it to be able to remote debug set-top boxes etc. I’ve just did a
> dumb implementation based on message stanzas, where the client
> can send the log to diff. implementations like console, remote
> (xmpp), file etc. with different levels.
> 
> So I am interested as well. :-)
> 
> 
> I could see this happening by wrapping the "protocol" that Logstash uses.
> 
> 
> 
> /Steffen
> 
> On 09 Nov 2013, at 19:30, Matthew Wild  wrote:
> 
> 
> On 9 November 2013 18:24, Peter Waher
>  wrote:
> 
> Hello
>

Re: [Standards] Event Logging over XMPP

[Steffen Larsen]

Hi again,

Just thinking a bit more about it..

On 10 Nov 2013, at 11:18, Steffen Larsen  wrote:

> Hi Bear et al,
> 
> Yes I was thinking of the same thing. I’ve done it in a different way now, 
> but using log stash just means to embedded the JSON into the stanza. 
> Because I am using logstash/kibana (elastic search, 
> http://www.elasticsearch.org/overview/kibana/) for my customers so that would 
> be straight forward. Maybe a message stanza like this?:
> 
> 
> 
> 
> {
>   "@source":"stdin://jvstratusmbp.local/",
>  "@type":"stdin",
>  "@tags":[],
>  "@fields":{},
>  "@timestamp":"2012-07-02T05:20:16.092000Z",
>  "@source_host":"jvstratusmbp.local",
>  "@source_path":"/",
>  "@message":"test"
> }
> 
> 
> 
> 
> or if you do not want to embed it into the body but in a separate container 
> instead:
> 
> 
> 
> 
> 
> {
>   "@source":"stdin://jvstratusmbp.local/",
>  "@type":"stdin",
>  "@tags":[],
>  "@fields":{},
>  "@timestamp":"2012-07-02T05:20:16.092000Z",
>  "@source_host":"jvstratusmbp.local",
>  "@source_path":"/",
>  "@message":"test"
> }
> 
> 
> 
> 

This one could actually be used for piggy bagging. So if I am sending to a user 
(JID) anyways e.g.  us...@mydomain.td, I can also piggy bag the log stanza and 
the component could strip it off. In that way It might reduce the overhead of 
sending all the time. Of course it means that your client need to be a bit more 
clever and queue the logs and it depends if the log can wait or not (how real 
time it have to be).


> In the receiving part (log...@mydomain.tld) it could either be a component or 
> a simple bot, that either appended the embedded json into a file and 
> logstashd would take it, or a component that would queue it directly to 
> rabbitmq which in my example would feed it to logstash/kibana.
> 
> 
> I am already using logstash and graphite for my XMPP servers, its nice to 
> have a visual overview and graphs when handling large scale XMPP… H maybe 
> I could use that as a topic for FOSDEM?
> 
> -Cheers!
> /Steffen
> 
> 
> On 09 Nov 2013, at 21:20, Mike Taylor  wrote:
> 
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>> 
>> On 11/09/2013 03:13 PM, Robert Kosten wrote:
>>> Hi, a Lurker here ;-)
>>> 
>>> I've had the same thought about two years ago as well so I
>>> implemented a small Monolog (PHP Logging Library) Handler that sent
>>> log messages as both formatted message (for standard chat clients)
>>> and a custom stanza for our status board. At the time I thought
>>> that pub/sub might actually be better though, because I didn't
>>> really want the logger to know who would receive the message...
>>> 
>>> Sadly that code belongs to a former company and I'm not certain I
>>> can remember everything about it (It was a quick'n'dirty
>>> solution), otherwise I'd attach it :-P
>>> 
>>> Regards, Robert Kosten
>>> 
>>> On 11/09/2013 09:08 PM, Steffen Larsen wrote:
>>>> No haven’t seen such a XEP, but I’ve implemented something like
>>>> it to be able to remote debug set-top boxes etc. I’ve just did a
>>>> dumb implementation based on message stanzas, where the client
>>>> can send the log to diff. implementations like console, remote
>>>> (xmpp), file etc. with different levels.
>>>> 
>>>> So I am interested as well. :-)
>> 
>> 
>> I could see this happening by wrapping the "protocol" that Logstash uses.
>> 
>>>> 
>>>> /Steffen
>>>> 
>>>> On 09 Nov 2013, at 19:30, Matthew Wild  wrote:
>>>> 
>>>>> On 9 November 2013 18:24, Peter Waher
>>>>>  wrote:
>>>>>> Hello
>>>>>> 
>>>>>> Is anybody aware of event logging extensions for XMPP? XEP
>>>>>> 0163, 207 and 316 all relate to publish/subscript (personal)
>>>>>> events as I can see. What I’m looking for is system and
>>>>>> network events for system administrators, like Syslog, for
>>>>>> instance, but over XMPP.
>>>>> 
>>>>> No, but I have wished for such a XEP before now. I'd love to
>>>>> see a simple one that primarily defines a way t

Re: [Standards] Event Logging over XMPP

[Steffen Larsen]

Hi Bear et al,

Yes I was thinking of the same thing. I’ve done it in a different way now, but 
using log stash just means to embedded the JSON into the stanza. 
Because I am using logstash/kibana (elastic search, 
http://www.elasticsearch.org/overview/kibana/) for my customers so that would 
be straight forward. Maybe a message stanza like this?:




{
  "@source":"stdin://jvstratusmbp.local/",
 "@type":"stdin",
 "@tags":[],
 "@fields":{},
 "@timestamp":"2012-07-02T05:20:16.092000Z",
 "@source_host":"jvstratusmbp.local",
 "@source_path":"/",
 "@message":"test"
}




or if you do not want to embed it into the body but in a separate container 
instead:





{
  "@source":"stdin://jvstratusmbp.local/",
 "@type":"stdin",
 "@tags":[],
 "@fields":{},
 "@timestamp":"2012-07-02T05:20:16.092000Z",
 "@source_host":"jvstratusmbp.local",
 "@source_path":"/",
 "@message":"test"
}




In the receiving part (log...@mydomain.tld) it could either be a component or a 
simple bot, that either appended the embedded json into a file and logstashd 
would take it, or a component that would queue it directly to rabbitmq which in 
my example would feed it to logstash/kibana.


I am already using logstash and graphite for my XMPP servers, its nice to have 
a visual overview and graphs when handling large scale XMPP… H maybe I 
could use that as a topic for FOSDEM?

-Cheers!
/Steffen


On 09 Nov 2013, at 21:20, Mike Taylor  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 11/09/2013 03:13 PM, Robert Kosten wrote:
>> Hi, a Lurker here ;-)
>> 
>> I've had the same thought about two years ago as well so I
>> implemented a small Monolog (PHP Logging Library) Handler that sent
>> log messages as both formatted message (for standard chat clients)
>> and a custom stanza for our status board. At the time I thought
>> that pub/sub might actually be better though, because I didn't
>> really want the logger to know who would receive the message...
>> 
>> Sadly that code belongs to a former company and I'm not certain I
>> can remember everything about it (It was a quick'n'dirty
>> solution), otherwise I'd attach it :-P
>> 
>> Regards, Robert Kosten
>> 
>> On 11/09/2013 09:08 PM, Steffen Larsen wrote:
>>> No haven’t seen such a XEP, but I’ve implemented something like
>>> it to be able to remote debug set-top boxes etc. I’ve just did a
>>> dumb implementation based on message stanzas, where the client
>>> can send the log to diff. implementations like console, remote
>>> (xmpp), file etc. with different levels.
>>> 
>>> So I am interested as well. :-)
> 
> 
> I could see this happening by wrapping the "protocol" that Logstash uses.
> 
>>> 
>>> /Steffen
>>> 
>>> On 09 Nov 2013, at 19:30, Matthew Wild  wrote:
>>> 
>>>> On 9 November 2013 18:24, Peter Waher
>>>>  wrote:
>>>>> Hello
>>>>> 
>>>>> Is anybody aware of event logging extensions for XMPP? XEP
>>>>> 0163, 207 and 316 all relate to publish/subscript (personal)
>>>>> events as I can see. What I’m looking for is system and
>>>>> network events for system administrators, like Syslog, for
>>>>> instance, but over XMPP.
>>>> 
>>>> No, but I have wished for such a XEP before now. I'd love to
>>>> see a simple one that primarily defines a way to transport log
>>>> messages over XMPP (perhaps re-using syslog semantics).
>>>> 
>>>> Regards, Matthew
>>> 
> 
> 
> - -- 
> 
> bear
> xmpp agitator; ops curmudgeon; generalist
> http://bear.im/about
> http://bear.im/pubkey.txt
> 0A93 9BA7 8203 FCBC 58A9 E8B5 9D1E 0661 8EE5 B4D8
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQIcBAEBAgAGBQJSfpkBAAoJEJ0eBmGO5bTY2n0P/jA+ty1Gusx0utAolJtdEeKh
> 9sr7uOcO/TKr9ZZPPj4XeZOFNF981XPHaaGEF0rmPZa/Y3zn1gIhMHM3hxWAUw6b
> agev8fN3SZ+R3XtE6hlbgE7mMlI94vfaGj7E3yieTx0My2ePNeXrGgFifJa+MKlm
> mJDrfKnshlPaXz71JbpRJTFeqadq65FGKWuAZZHRYtHWJnUO8eWFpjxO/YEE1QaE
> YSwNMjVAVjIMM8S2c4dpmNdPXu2lqv7EU6cd9n2/J9EDomjRokss6nDY5MUwyp0k
> bhJES91KVLzFgSf0HlAIsur0mcfwYGsorccNDG9rr3Q/aat695VdzQWdSuRrmz00
> iiklx8zWA0d8DZvldVmguy+lSJfxgNZGGCdbbNHhyLzQH2tRp8w0QtHhVifLDWYa
> 9mvLCojpLB3fygwn5vsbC/aVi1VVVl+J5bwpRIx/vyd4dA08T7K2M2qHnD1U4w+g
> Vjc2QRjBNTwg4kTZCYV5DvLLK9E8ylcVRWCskd/ppSKGTWk/tUNslUCHYH+cDFMQ
> xpnLfto6bLEC7QMFP309HN+6g8VlCmnpLhRchAlpt4cd5tMm04I/MvfIhvtGJYtS
> +pHNbcVBgp5n8Hj7KNQWZV1Zbtr2Mp/8RWPeeYnLNtblOzR8Ot4iy4KL09l0JTIV
> kmlT9C19uTgl7tVT9PtM
> =FHXf
> -END PGP SIGNATURE-



smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Event Logging over XMPP

[Steffen Larsen]

No haven’t seen such a XEP, but I’ve implemented something like it to be able 
to remote debug set-top boxes etc. I’ve just did a dumb implementation based on 
message stanzas, where the client can send the log to diff. implementations 
like console, remote (xmpp), file etc. with different levels.

So I am interested as well. :-)

/Steffen

On 09 Nov 2013, at 19:30, Matthew Wild  wrote:

> On 9 November 2013 18:24, Peter Waher  wrote:
>> Hello
>> 
>> Is anybody aware of event logging extensions for XMPP? XEP 0163, 207 and 316
>> all relate to publish/subscript (personal) events as I can see. What I’m
>> looking for is system and network events for system administrators, like
>> Syslog, for instance, but over XMPP.
> 
> No, but I have wished for such a XEP before now. I'd love to see a
> simple one that primarily defines a way to transport log messages over
> XMPP (perhaps re-using syslog semantics).
> 
> Regards,
> Matthew



smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] WebRTC implementation with XMPP

[Steffen Larsen]

Thanks alot, Dave!

/Steffen

On Oct 18, 2013, at 11:06 PM, Dave Cridland wrote:

I've just pointed out this thread to Lance as he wandered by, and  
asked about recorded sessions; he wasn't sure about the latter.


I'll see what I can find out for you.

On 18 Oct 2013 14:00, "Steffen Larsen"  wrote:
Hi,

On Oct 18, 2013, at 10:55 PM, Peter Saint-Andre wrote:

On 10/18/13 2:52 PM, Jaussoin Timothée wrote:
Hi everyone !

I'm the main developer of the Movim project (http://movim.eu/) and we
plan in the new few months to implement the visio-conference in our  
web

client (using the Jingle XEP).
We are choosing the brand new WebRTC standard to do this.

I would like to know if someone here is actually working on a Jingle
implementation on WebRTC to :
- Know th tricks and get some help with my futur implementation
- Test the compatibility of our two solutions

I'm sure that Philipp Hancke and Lance Stout will chime in once  
they're

not so busy talking about their software at the Realtime Conference
today and tomorrow. :-)

Speaking of the realtimeconf, I can see that it is live broadcasted,  
but is accessible later on (recorded). Its hard to follow you guys  
when I am 9 hours ahead. :-)



Peter

P.S. You might want to join the jin...@xmpp.org list, where such  
matters

are discussed in more detail.

-Cheers!

/Steffen

Re: [Standards] WebRTC implementation with XMPP

[Steffen Larsen]

Hi,

On Oct 18, 2013, at 10:55 PM, Peter Saint-Andre wrote:


On 10/18/13 2:52 PM, Jaussoin Timothée wrote:

Hi everyone !

I'm the main developer of the Movim project (http://movim.eu/) and we
plan in the new few months to implement the visio-conference in our  
web

client (using the Jingle XEP).
We are choosing the brand new WebRTC standard to do this.

I would like to know if someone here is actually working on a Jingle
implementation on WebRTC to :
- Know th tricks and get some help with my futur implementation
- Test the compatibility of our two solutions


I'm sure that Philipp Hancke and Lance Stout will chime in once  
they're

not so busy talking about their software at the Realtime Conference
today and tomorrow. :-)


Speaking of the realtimeconf, I can see that it is live broadcasted,  
but is accessible later on (recorded). Its hard to follow you guys  
when I am 9 hours ahead. :-)




Peter

P.S. You might want to join the jin...@xmpp.org list, where such  
matters

are discussed in more detail.


-Cheers!

/Steffen

Re: [Standards] repository of xmpp academic papers & white papers

[Steffen Larsen]

Found my notes from the Summit, bear created : http://howto.xmpp.org . I think 
we should put it there.
Bear??

/Steffen

On Jul 16, 2013, at 7:27 AM, Steffen Larsen  wrote:

> Actually back in february (for the Summit), Bear created a subdomain 
> specifically for this, there should link or contain whitepapers for things 
> like scaling, mobility  etc.
> I can't remember what we called it, but the project have seemed to be stalled 
> a bit. 
> 
> I started making a small doc for scaling XMPP for web environments, but I 
> don't know where to put it.. Its a field we really could improve, and this 
> would really help answer peoples questions and yet again push and broaden 
> XMPP environments for people that might not dare to go that specific way, 
> because it seems complicated or other reasons..
> 
> /Steffen
> 
> 
> On Jul 15, 2013, at 10:52 PM, Peter Saint-Andre  wrote:
> 
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>> 
>> On 7/15/13 9:57 AM, Peter Waher wrote:
>>> Hello
>>> 
>>> 
>>> 
>>> Is there a repository of known academic papers & white papers
>>> related to XMPP somewhere? If not, would it not be of interest to
>>> have such a repository with such papers or links to them? Perhaps
>>> in some logical order.
>> 
>> We don't have such a repository. We've talked before about starting a
>> repo of whitepapers, but we never seem to have the energy to launch it.
>> 
>> Peter
>> 
>> - -- 
>> Peter Saint-Andre
>> https://stpeter.im/
>> 
>> 
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
>> Comment: GPGTools - http://gpgtools.orgetc
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>> 
>> iQIcBAEBAgAGBQJR5GEbAAoJEOoGpJErxa2p3+QP/3SXU5jCiwf4EnDGl2zk4jSp
>> cI4DoKBA5CptY8rsAT7ouIV2+/oCdAuouYX10FCE+kDn7GmdmzzVsz4tOj9ocObA
>> i2HuV9lZM0p7EWH3xoCNWsj+Ck16XJYfKmfUNKF0l8hjlhJGwY50vseO0DxHB9qX
>> 0Dhxz7I+fU6mtHMdeKISPYXmM4UOZuRhGaDVDkNux/N70/y8MZ3LCDyASZhTlmB1
>> rLJUykpCKTMJX9g1lsplZqaTG++J+3M8sp3HSYrcUEs9ujeQond6PqrqA7iI3bVy
>> ratMyXZDUY8fEiEcazY5gXB83s5+uqoXWj8nFU64z9kpGmT9K+SVJ1g1bEwPRsVe
>> UCney25QxlMsAAaTJYGeKQFFujpXnw91pdkrMqrElrhR3R/60lnBEIhZZUiDWxoX
>> mKBKjXzczaXdFVwn7ZhFFsKmNNxD4Si/4Q8wfHcDWQUpllWNtLJk63J1h815SYUx
>> wyjtan33cImWe5EPIpdAhDkfwAEsGPy20fOsbWfQWeRtfm4aGJ//zloIRCJdtYiJ
>> LMLEIZnXw2Io104k0bySahMXGPi2iriFA5W0FRa/eO1hTou6+cMG4KQyscG3VDVD
>> +tfIMF9AbZhD17tpqBjOnSNt9FCqcsF5kkKRw+mCX/cT78eO4XpH2dsYJay7Z2DV
>> 7hkAucrUZHCIG37TNKEB
>> =62Vy
>> -END PGP SIGNATURE-
> 

Re: [Standards] repository of xmpp academic papers & white papers

[Steffen Larsen]

Actually back in february (for the Summit), Bear created a subdomain 
specifically for this, there should link or contain whitepapers for things like 
scaling, mobility  etc.
I can't remember what we called it, but the project have seemed to be stalled a 
bit. 

I started making a small doc for scaling XMPP for web environments, but I don't 
know where to put it.. Its a field we really could improve, and this would 
really help answer peoples questions and yet again push and broaden XMPP 
environments for people that might not dare to go that specific way, because it 
seems complicated or other reasons..

/Steffen


On Jul 15, 2013, at 10:52 PM, Peter Saint-Andre  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 7/15/13 9:57 AM, Peter Waher wrote:
>> Hello
>> 
>> 
>> 
>> Is there a repository of known academic papers & white papers
>> related to XMPP somewhere? If not, would it not be of interest to
>> have such a repository with such papers or links to them? Perhaps
>> in some logical order.
> 
> We don't have such a repository. We've talked before about starting a
> repo of whitepapers, but we never seem to have the energy to launch it.
> 
> Peter
> 
> - -- 
> Peter Saint-Andre
> https://stpeter.im/
> 
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
> Comment: GPGTools - http://gpgtools.orgetc
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQIcBAEBAgAGBQJR5GEbAAoJEOoGpJErxa2p3+QP/3SXU5jCiwf4EnDGl2zk4jSp
> cI4DoKBA5CptY8rsAT7ouIV2+/oCdAuouYX10FCE+kDn7GmdmzzVsz4tOj9ocObA
> i2HuV9lZM0p7EWH3xoCNWsj+Ck16XJYfKmfUNKF0l8hjlhJGwY50vseO0DxHB9qX
> 0Dhxz7I+fU6mtHMdeKISPYXmM4UOZuRhGaDVDkNux/N70/y8MZ3LCDyASZhTlmB1
> rLJUykpCKTMJX9g1lsplZqaTG++J+3M8sp3HSYrcUEs9ujeQond6PqrqA7iI3bVy
> ratMyXZDUY8fEiEcazY5gXB83s5+uqoXWj8nFU64z9kpGmT9K+SVJ1g1bEwPRsVe
> UCney25QxlMsAAaTJYGeKQFFujpXnw91pdkrMqrElrhR3R/60lnBEIhZZUiDWxoX
> mKBKjXzczaXdFVwn7ZhFFsKmNNxD4Si/4Q8wfHcDWQUpllWNtLJk63J1h815SYUx
> wyjtan33cImWe5EPIpdAhDkfwAEsGPy20fOsbWfQWeRtfm4aGJ//zloIRCJdtYiJ
> LMLEIZnXw2Io104k0bySahMXGPi2iriFA5W0FRa/eO1hTou6+cMG4KQyscG3VDVD
> +tfIMF9AbZhD17tpqBjOnSNt9FCqcsF5kkKRw+mCX/cT78eO4XpH2dsYJay7Z2DV
> 7hkAucrUZHCIG37TNKEB
> =62Vy
> -END PGP SIGNATURE-

[Standards] Heml.is and federation..

[Steffen Larsen]

Hi,

I just stumbled upon https://heml.is, which is a new XMPP client for IOS and 
Android. Anyone knows these guys?

It uses XMPP and PGP for encryption, but do any of you guys know if they 
federate?.. What I can see from skimming their page, its yet another silo, due 
to the fact of PGP and their own infrastructure.
So federation and using your own domain does not seem feasible, right? Anyone 
want to discuss this and the alternatives besides OTR? Security labels?

When I see something like this I get exited to start with because I actually 
want something like this on the client/server part, but then later on gets down 
to earth when it seems out of the standards. Or is it just me?

--
Venlig hilsen / Best regards

Steffen Larsen, Founder & CEO
Mobile: +45 51 94 33 33
BrainTrust / http://www.braintrust.dk

Re: [Standards] XEP tagging idea..

[Steffen Larsen]

Hi,

On Jun 7, 2013, at 2:23 PM, Andreas Kuckartz  wrote:

> Dave Cridland:
>> We have, I think, dependency information in XEPs. We could in
>> principle build reverse dependencies, too. That won't achieve
>> everything you want, but it might achieve some of it.
> 
> Exactly, and I find those dependencies helpful.
> 
>> You're imposing more work on the XEP Editor, and the Council. I'm not
>> in favour of anything which increases their workloads without a known
>> corresponding gain. That's not to say I think this is a terrible
>> idea, I'm just saying it's speculative, and needs to be worked on
>> outside the main standards process workflow at least to begin with.
> 
> +1


not necessarily. I would for sure help. I have actually asked many times if the 
editors and infrastructure operation team needed any help, but none have 
replied at all. So I am not trying to push more work to the editors or council, 
I am just trying to reach out and come up with some new ideas to hear if they 
have any backing. 
> 
>>> Right now all the XEPs are files in a repo, so I don't know how we
>>> do this tagging and relavance index the smartest way.
>>> 
>> I think someone (you?) clones the repo and tries out some ideas.
> 
> There is no need to change the XEPs in any way. The dependencies can be
> collected independently and made available as Linked Open Data using
> JSON-LD, RDF or whatever.

Yes that might be an idea.


> 
> Cheers,
> Andreas

Re: [Standards] XEP tagging idea..

[Steffen Larsen]

Hi Ash!,

On Jun 7, 2013, at 9:41 AM, Ashley Ward  wrote:

> On 6 Jun 2013, at 20:58, Steffen Larsen  wrote:
>> I was wondering why we do not have any searchable tags on the different XEPs.
> 
> Sounds like a pretty good idea. It could also help people to find related 
> XEPs, e.g. all the XEPs relating to PubSub like 60, 248, 253, 163, etc.

Yes exactly what I am thinking.

> 
> Who would maintain the taxonomy on this. I guess it would be added to as new 
> XEPs are produced (or existing ones are edited). It would then be part of the 
> approval process of a ProtoXEP to check that the tags are sensible.

yes sounds reasonable.

> 
> --
> Ash

Right now all the XEPs are files in a repo, so I don't know how we do this 
tagging and relavance index the smartest way.

-Cheers!
/Steffen
 

[Standards] XEP tagging idea..

[Steffen Larsen]

Hi Guys,

Today I had an idea about our XEPs  
(http://xmpp.org/xmpp-protocols/xmpp-extensions/)
Have anyone ever thought about making search easier in our extensions?

I was wondering why we do not have any searchable tags on the different XEPs. I 
would be easier to find what you are looking for. 
So for example http://xmpp.org/extensions/xep-0166.html could have tags like:

jingle, video, conference, peer-to-peer, signalling etc.

I mean most of us can mostly find what we are looking for there, but beginners 
that are searching for stuff, might find it hard to find what they are looking 
for?

-Just an idea and my 50 cent! :-)

--
Venlig hilsen / Best regards

Steffen Larsen, Founder & CEO
Mobile: +45 51 94 33 33
BrainTrust / http://www.braintrust.dk

Re: [Standards] NetConf over XMPP

[Steffen Larsen]

Hi Michal,

I am not into NetConf, but is it not RPC calls? 
If so, you can probably use XEP-009: http://xmpp.org/extensions/xep-0009.html

-Cheers!
/Steffen

On May 30, 2013, at 9:04 AM, Michal 'vorner' Vaner  wrote:

> Hello
> 
> I'm working with protocol called NetConf (RFC 6241) now. The protocol can be
> used to configure devices remotely over something more standardized than web
> interface or ssh & command line utilities (which is good for people but not 
> for
> automated scripts).
> 
> The protocol uses XML messages and defines several transport layers to work on
> top of (SSH, TLS socket, …). It seems like a reasonable idea to define a
> transport over XMPP, which has several advantages (like you don't need 1000 
> ssh
> sessions to configure 1000 devices on your client, there's single point where 
> we
> could define who is allowed to do the configuration, etc).
> 
> Also, it could be used to configure software as well (XMPP bots, for example),
> with possibly better UI than the ad-hoc commands.
> 
> I brought the idea with my boss today that I'd like to do write the XEP and 
> some
> experimental implementation. I got an answer in the meaning of „That sounds 
> like
> a cool idea, though we need to finish the current project first“.
> 
> So, I will probably find the time to write the proposal XEP some time in the
> future. But if anyone is interested in a way to configure something remotely
> (either a device or a software), please contact me, we may want to exchange 
> some
> ideas.
> 
> Thank you
> 
> PS.: It seems the email didn't get through when sent from company email, so 
> I'm
> retrying with a personal one (which is subscribed to the list). Please ignore
> any possible duplicates.
> 
> -- 
> BOFH Excuse #452:
> Somebody ran the operating system through a spelling checker.
> 
> Michal 'vorner' Vaner

Re: [Standards] XMPP meetup July 27 in Berlin?

[Steffen Larsen]

Hi Peter!,

Super cool, Peter. 
I've been developing a bit on Tigase, but mostly on plugins, clustering, 
multitennant stuff etc. but I think that I'll join anyway!
Always a good thing to re-think / update our security model for certificate 
checking etc.
How about spam issues and trust? is that included as well? I think it's 
becoming a bigger and bigger issue when doing massive/multitennant hosting.

PS: Why are most north-amarican XMPP devs. there? Because of the IETF/WG 
meeting?

/Steffen


On May 14, 2013, at 12:33 AM, Peter Saint-Andre  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hey folks, I'm thinking about organizing a one-day XMPP hackathon and
> testfest in Berlin on Saturday, July 27, right before IETF 87. The
> IETF meeting will include an XMPP WG session and probably a "Birds of
> a Feather" meeting about POSH ("PKIX Over Secure HTTP") as a prooftype
> for server identity checking beyond just XMPP (IMAP, SMTP, SIP,
> iSchedule, etc.). Since some North American XMPP people will already
> be in Berlin at that time and there are lots of XMPP people within
> relatively close proximity to Berlin, a meetup might work well.
> 
> The idea is to do some hacking and testing (code, not specs!) about
> XMPP security and federation, including topics like certificate
> checking, DNSSEC, experimental POSH support, challenges in
> multi-tenanted and virtual hosting environments, and maybe even some
> topics related to attacks on the XMPP network (incident reporting,
> communication blocking, MUC flooding, etc.).
> 
> I'm hoping to recruit two primary audiences in Europe: (1) developers
> from XMPP server projects like ejabberd, M-Link, MongooseIM, Prosody,
> Tigase, and Wokkel, and (2) operators from service providers like
> Flosoft, GMX, Google, i-pobox.net, and WebEx. Of course, other folks
> would be welcome as well. :-)
> 
> Anyone interested? If so, I'll get to work on agenda and logistics...
> 
> Peter
> 
> - --
> Peter Saint-Andre
> https://stpeter.im/
> -BEGIN PGP SIGNATURE-
> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQIcBAEBAgAGBQJRkWoeAAoJEOoGpJErxa2pvdgQAKFxnsHoiIb+Fj4v5NVIEyh0
> uCanvZWV4UdNnmpmlHcqkiumRy1wIeVaQCc3pad3YmByz9ztjFM5ET3X3ssKXmuH
> TRApQzNsNMp+dFuoAebToyqUp7zC2GAsgtCbyPRLk+IHtjhyJe/k+kJvYvwUiqzl
> aMb12Ur3IqDlcE78w9+d7azHudgWwUY/mNjDUOOKloUcgl7hbOEi2Xi78hD1mCxr
> vGEJxg0Vzt7E/mZCgHys9elkbuDmmsW2dakTvNqG8gvescefwwv5YmenKl8APqco
> BDq+uXsU9LoXG5J4Iu6UY/j9efYdfg0kFlaN4Re1pQymMj1SnvIhn7oFs/wTUzWj
> /14MdSn3jXIh3TPc1eZIi8HdFdG+J8Aj51q8RBS43dUMxtUv5N+q0s999y54/xCO
> 0hRRwb9B2opLfwR7rmUN/yEiDSFIkeSxRQhUBX8RRVQgTy3mxo9PZ+oUm0Y+QIOf
> uoBlPXZVF4D7OxrXotm9FIb1X9SQgElmio92If1pk+g2SXeapZCSnRFsk+eZ6JvM
> C0FI94SWBwYn/vVug7AKnjtCwLKjxTDedrvYWvI1QuX9gNsnvoV+5kwlU/v9YbJR
> CaxZrrH+qXt4LA6bAMXnsY9d/CzEpu6r780gPkitBx17mUah9u3lN4ScTB/2Ex+D
> kp1IrZoRQl2w5lzqsazX
> =va06
> -END PGP SIGNATURE-

Re: [Standards] Proposed XMPP Extension: HTTP over XMPP transport

[Steffen Larsen]

+1, Me too. If you need any help to clean up the specs, just say so. :-)

/Steffen

On May 7, 2013, at 8:38 PM, Simon Tennant  wrote:

> 1. Collect $2000 per member
> 2. buy .lit TLD
> ... 
> 4. $$$ profit?
> 
> My next grumpy-old-man comment is the residual use of "Jabber" in the specs. 
> I'd love to submit a pull request in to fix this (via Github).
> 
> S. 
> 
> 
> On 7 May 2013 20:31, Peter Saint-Andre  wrote:
> On 5/7/13 12:18 PM, Simon Tennant wrote:
> > My point is that it's a bit weird for a standards organisation to be
> > pointing at someone else's domain. Unless of course capulet.com
> >  and montague.net  are
> > registered and reserved by the XSF.
> 
> That's why I typically use domains with .lit -- but with the TLD
> expansion those won't be safe either. (Some of the old specs used things
> like capulet.com and montague.net, and we haven't cleaned them.)
> 
> Peter
> 
> 
> 
> 
> -- 
> Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/tQgxP

Re: [Standards] PEP - Public PubSub subscribed list

[Steffen Larsen]

Hi,


On Feb 12, 2013, at 10:13 AM, Sergey Dobrov  wrote:

> On 02/12/2013 02:34 PM, Simon Tennant wrote:
>> I understand that you want to do lookup in PEP. I'd be very wary of
>> depending on it to build a full scaled social platform.
>> 
>> We tried using PEP to build buddycloud. We created a bunch of nodes for
>> each and would push out updates based on presence. This kinda worked
>> with the following caveats::
>> - it was server specific (any changes to PEP had to be made to each
>> server)/you loose the portability of XMPP components
> If the features will be described in XEPs any server will be able to
> implement them. But they are needed to be interested in it. The interest
> may be cause with interesting and powerful user applicable protocols
> like XEP-277. But we are really need to make XEP-60 and PEP more usable
> for this kind of things.
> 
> Also, I already told that we need a standard that will allow services
> like PEP to be external like XEP-114 allows gateways to be external. I
> still thing this is the most priority task for pubsub development.
> 
>> - scaling and performance (this could have been an issue with ejabberd
>> at the time).
> Yeah, this is an ejabberd issue they are hoping to fix in 3.0.
> Unfortunately, we are waiting for 3.0 too long.

yes scaling and performance issues in 2.x is quite known… And I don't even 
think that Ejabberd 3.0 will be open sourced. You should take a look at 
mongooseIM, that is an erlang solutions open source fork.

> 
>> - difficult to build any extra business logic into PEP. For
>> example:"this set of users can reply to my posts"
> I don't see the problem here technically. This is impossible with
> current standards but technically it's not a problem at all.
> 
>> 
>> I think that the OneSocialWeb guys ran into similar issues with their
>> PEP-based service.
>> 
>> Our XMPP architecture for buddycloud has shifted: build as much as
>> possible outside of the XMPP server core. We use components to scale out
>> services and use the XMPP server just as a router (the famous "xmpp
>> middleware" topic). The benefit of using components for your service is
>> that running Movim will have the ability to switch out their XMPP server
>> as their needs change.
>> 
>> One solution that might give you some milage: using DISCO to point to a
>> pub sub component that is nominated for social activities? (Something
>> like https://buddycloud.org/wiki/XMPP_XEP#buddycloud_Server_Discovery).
>> This will give you much more flexibility in the future and nto tie your
>> solution to a particular XMPP server vendor.
>> 
>> S.
> 
> 
> -- 
> With best regards,
> Sergey Dobrov,
> XMPP Developer and JRuDevels.org founder.

Re: [Standards] Fwd: [Summit] BOSH actions

[Steffen Larsen]

True true,
Ive been looking on some other client implementations as well, and they do not 
implements it as well. So I think it seems sane to remove it.

/Steffen

On Feb 5, 2013, at 12:24 PM, Ashley Ward  wrote:

> We don't use it in emite either.
> 
> Also clients which do implement it should fall back gracefully to utf-8
> anyway.
> 
> --
> Ash
> 
> On 04/02/2013 21:57, "Stefan Strigler"  wrote:
> 
>> JSJaC doesn't either. And at least the old implementation of ejabberd's
>> mod_http_bind didn't as well.
>> 
>> .Steve
>> 
>> Am 04.02.2013 um 22:39 schrieb Steffen Larsen :
>> 
>>> Just checked strophe, and it does not use it. I'll check some more
>>> implementations that uses BOSH for transport. Maybe that would give us
>>> an indication.
>>> 
>>> /Steffen
>>> 
>>> On Feb 4, 2013, at 10:06 PM, "Peter Saint-Andre (psaintan)"
>>>  wrote:
>>> 
>>>> That sounds sensible.
>>>> 
>>>> Sent from mobile, might be terse
>>>> 
>>>> On Feb 4, 2013, at 1:26 PM, "Ashley Ward" 
>>>> wrote:
>>>> 
>>>>> It would be great to keep them consistent, but is it worth potentially
>>>>> breaking implementations? I think the main problem with accept was
>>>>> that
>>>>> the example was inconsistent with the text.
>>>>> 
>>>>> In fact, I very much doubt anyone should be using that option as xmpp
>>>>> mandates the use of utf-8, and I doubt anyone's using bosh for
>>>>> anything
>>>>> other than xmpp. Perhaps we should just look at getting rid of that
>>>>> attribute?
>>>>> 
>>>>> --
>>>>> Ash
>>>>> 
>>>>> On 04/02/2013 10:30, "Steffen Larsen"  wrote:
>>>>> 
>>>>>> Cross-posted from the summit list (sorry making noise).
>>>>>> Here are my small notes to the BOSH action list (embedded).
>>>>>> 
>>>>>> 
>>>>>> /Steffen
>>>>>> 
>>>>>> Begin forwarded message:
>>>>>> 
>>>>>>> From: "Peter Saint-Andre (psaintan)" 
>>>>>>> Subject: Re: [Summit] BOSH actions
>>>>>>> Date: February 2, 2013 10:18:01 PM GMT+01:00
>>>>>>> To: XMPP Summit 
>>>>>>> Cc: Bidirectional Streams Over Synchronous HTTP ,
>>>>>>> XMPP
>>>>>>> Summit 
>>>>>>> Reply-To: XMPP Summit 
>>>>>>> 
>>>>>>> Maybe it would be better to take the technical discussion to the
>>>>>>> standards@ list?
>>>>>>> 
>>>>>>> Sent from mobile, might be terse
>>>>>>> 
>>>>>>> On Feb 2, 2013, at 4:32 PM, "Steffen Larsen" 
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> Hey,
>>>>>>>> 
>>>>>>>> Just saw the issue with the accept attribute. How about charset?
>>>>>>>> It is
>>>>>>>> currently space separated in the example  (and it also says) - but
>>>>>>>> should we not comma separate that like the accept attribute?
>>>>>>>> 
>>>>>>>> Its on 7.2 in http://xmpp.org/extensions/xep-0124.html:
>>>>>>>> charsets='ISO_8859-1 ISO-2022-JP'
>>>>>>>> -Just my 50 cent
>>>>>>>> 
>>>>>>>> /Steffen
>>>>>>>> 
>>>>>>>> On Feb 2, 2013, at 4:18 PM, Winfried Tilanus 
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> Hi all,
>>>>>>>>> 
>>>>>>>>> I updated the BOSH issues page with the results & and who will be
>>>>>>>>> writing patches.
>>>>>>>>> http://wiki.xmpp.org:12480/web/BoshIssues
>>>>>>>>> 
>>>>>>>>> I only forgot who will be writing the patch for the first issue
>>>>>>>>> (remove
>>>>>>>>> Pipelining). Plz check if your name pops up at the correct places
>>>>>>>>> and
>>>>>>>>> ping me if there are any problems!
>>>>>>>>> 
>>>>>>>>> happy patch-writing!
>>>>>>>>> 
>>>>>>>>> Winfried
>>>>> 
>>>>> 
>>> 
>> 
> 
> 

Re: [Standards] Fwd: [Summit] BOSH actions

[Steffen Larsen]

Just checked strophe, and it does not use it. I'll check some more 
implementations that uses BOSH for transport. Maybe that would give us an 
indication.

/Steffen

On Feb 4, 2013, at 10:06 PM, "Peter Saint-Andre (psaintan)" 
 wrote:

> That sounds sensible. 
> 
> Sent from mobile, might be terse 
> 
> On Feb 4, 2013, at 1:26 PM, "Ashley Ward"  wrote:
> 
>> It would be great to keep them consistent, but is it worth potentially
>> breaking implementations? I think the main problem with accept was that
>> the example was inconsistent with the text.
>> 
>> In fact, I very much doubt anyone should be using that option as xmpp
>> mandates the use of utf-8, and I doubt anyone's using bosh for anything
>> other than xmpp. Perhaps we should just look at getting rid of that
>> attribute?
>> 
>> --
>> Ash
>> 
>> On 04/02/2013 10:30, "Steffen Larsen"  wrote:
>> 
>>> Cross-posted from the summit list (sorry making noise).
>>> Here are my small notes to the BOSH action list (embedded).
>>> 
>>> 
>>> /Steffen
>>> 
>>> Begin forwarded message:
>>> 
>>>> From: "Peter Saint-Andre (psaintan)" 
>>>> Subject: Re: [Summit] BOSH actions
>>>> Date: February 2, 2013 10:18:01 PM GMT+01:00
>>>> To: XMPP Summit 
>>>> Cc: Bidirectional Streams Over Synchronous HTTP , XMPP
>>>> Summit 
>>>> Reply-To: XMPP Summit 
>>>> 
>>>> Maybe it would be better to take the technical discussion to the
>>>> standards@ list?
>>>> 
>>>> Sent from mobile, might be terse
>>>> 
>>>> On Feb 2, 2013, at 4:32 PM, "Steffen Larsen"  wrote:
>>>> 
>>>>> Hey,
>>>>> 
>>>>> Just saw the issue with the accept attribute. How about charset? It is
>>>>> currently space separated in the example  (and it also says) - but
>>>>> should we not comma separate that like the accept attribute?
>>>>> 
>>>>> Its on 7.2 in http://xmpp.org/extensions/xep-0124.html:
>>>>> charsets='ISO_8859-1 ISO-2022-JP'
>>>>> -Just my 50 cent
>>>>> 
>>>>> /Steffen
>>>>> 
>>>>> On Feb 2, 2013, at 4:18 PM, Winfried Tilanus 
>>>>> wrote:
>>>>> 
>>>>>> Hi all,
>>>>>> 
>>>>>> I updated the BOSH issues page with the results & and who will be
>>>>>> writing patches.
>>>>>> http://wiki.xmpp.org:12480/web/BoshIssues
>>>>>> 
>>>>>> I only forgot who will be writing the patch for the first issue
>>>>>> (remove
>>>>>> Pipelining). Plz check if your name pops up at the correct places and
>>>>>> ping me if there are any problems!
>>>>>> 
>>>>>> happy patch-writing!
>>>>>> 
>>>>>> Winfried
>> 
>> 

[Standards] Fwd: [Summit] BOSH actions

[Steffen Larsen]

Cross-posted from the summit list (sorry making noise).
Here are my small notes to the BOSH action list (embedded).


/Steffen

Begin forwarded message:

> From: "Peter Saint-Andre (psaintan)" 
> Subject: Re: [Summit] BOSH actions
> Date: February 2, 2013 10:18:01 PM GMT+01:00
> To: XMPP Summit 
> Cc: Bidirectional Streams Over Synchronous HTTP , XMPP Summit 
> 
> Reply-To: XMPP Summit 
> 
> Maybe it would be better to take the technical discussion to the standards@ 
> list?
> 
> Sent from mobile, might be terse 
> 
> On Feb 2, 2013, at 4:32 PM, "Steffen Larsen"  wrote:
> 
>> Hey,
>> 
>> Just saw the issue with the accept attribute. How about charset? It is 
>> currently space separated in the example  (and it also says) - but should we 
>> not comma separate that like the accept attribute?
>> 
>> Its on 7.2 in http://xmpp.org/extensions/xep-0124.html:
>>   charsets='ISO_8859-1 ISO-2022-JP'
>> -Just my 50 cent
>> 
>> /Steffen
>> 
>> On Feb 2, 2013, at 4:18 PM, Winfried Tilanus  wrote:
>> 
>>> Hi all,
>>> 
>>> I updated the BOSH issues page with the results & and who will be
>>> writing patches.
>>> http://wiki.xmpp.org:12480/web/BoshIssues
>>> 
>>> I only forgot who will be writing the patch for the first issue (remove
>>> Pipelining). Plz check if your name pops up at the correct places and
>>> ping me if there are any problems!
>>> 
>>> happy patch-writing!
>>> 
>>> Winfried
>> 

Re: [Standards] example files

[Steffen Larsen]

Hey,

I don't know if we have it yet. But can we not make a continuous  
integration project that takes these extracts of the XEPs and compiles  
them, by making a xml lint?
In that way we should be able to ensure that the XML is syntactically  
correct for our XEPs.


-Ciao! :-)

/Steffen

On Sep 23, 2008, at 11:32 PM, Peter Saint-Andre wrote:

BTW, I've created a small XSLT that extracts all the examples from a  
XEP

and puts them into a dedicated file. These files may assist developers
in checking the examples against the schemas, etc. You can find the
files here:

http://www.xmpp.org/extensions/examples/

In fact, I just checked the file for XEP-0166 and found some errors,
which I quickly corrected. I have not yet generated files for all the
existing specs, but may do that soon.

Enjoy!

Peter

--
Peter Saint-Andre
https://stpeter.im/