[Standards] XEP-0322: EXI for constrained processing environments
Hello, I was happy to run into XEP-0322, explaining a path of integration for the compact XML representation of EXI. The fully specified path assumes starting off with fullblown XML and then switching to EXI; this is a scenario that would work when the viewpoint is saving bandwidth. Another usecase, where EXI serves the relative simplicity of a client, is not really dealt with under the usual clarity. I am thinking of constrained processing environments, such as clients on microcontrollers. These may want to use EXI to avoid having to deal with the full XML notation, and they would most certainly not be serviced if they have to go through an initial handshake based on XML. Although 2.4 gives some ideas and possibilities, its style sounds informative (ex. and e.g.) rather than normative, which means that there is non real certainty to be drawn. I am writing to emphasise that this should IMHO be cleared up before finalising this XEP. As for the EXI cookie, is it an idea to use a processing instruction and/or XML declaration that would be sent to the server? That would be in line with common XML syntax without adding the burden of XML parsing onto the (constrained) client. A few forms could be used, and in all honesty, may be better standardised as part of EXI than as part of XEP-0322 because it would occur everywhere EXI is used: ?xml version=1.0 syntax=exi? (illegal 1.0 syntax) ?xml version=1.0-exi? (illegal 1.0 syntax) ?xml version=1.0 exi=1.0?(illegal 1.0 syntax) ?xml version=1.1?(breaks with 1.0 requirements) ?exi version=1.0? (after ?xml...? -- upon recognition, respond with the same string, would otherwise ignored?) Ref: http://www.w3.org/TR/REC-xml/#sec-pi and http://www.w3.org/TR/REC-xml/#sec-prolog-dtd This approach would save from specifying another port, and it would be easy to send/process in a constrained environment. Adding NS negotiation might be possible along the same lines, but would already be more complex. Still, not having to build an XML processor to be able to switch to EXI seems like a really good usecase to me. I hope this is useful! Cheers, -Rick
Re: [Standards] MUC2
On 25 Jun 2015, at 11:11, Daniel Gultsch dan...@gultsch.de wrote: As I understand this MUC2 should not rely replace the current MUC but provide an alternative. Not really, the aim is to fix the issues MUC has, and produce something better that can be used in its place in the future. Someone who needs the full IRC-like feature set (large groups mostly with people you don't know personally) can still use MUC1. Well, they can’t, because that’s one of the things that MUC1 scales quite badly at, with all the presences and traffic at login. Fixing that in MUC2 would be good. Yes. Plus that gives us the ability to not have private messages which are always a mess (carbons) - not sure if this is what you meant by addressing messes. One of several things, yes. /K
Re: [Standards] MUC2
Hi, 2015-06-25 10:27 GMT+02:00 Kevin Smith kevin.sm...@isode.com: Thinking a bit about the MUC2 stuff. MUC1 had Anon/semianon/nonanon. We’ve pretty much killed off fully anonymous rooms in MUC1. Can people share their thoughts on usecases for semi-anon, please? It’s not entirely clear to me what these are (users who want anonymity seem to already be using throw-away JIDs to achieve that, instead of relying on MUC configuration). As I understand this MUC2 should not rely replace the current MUC but provide an alternative. Someone who needs the full IRC-like feature set (large groups mostly with people you don't know personally) can still use MUC1. Therefore we shouldn't be afraid to really limit the feature set of MUC2 to something that a majority of people will actually use. There seems to be some significant merit in having MUCs always be non-anonymous in MUC2, to solve some of the addressing messes we’ve found ourselves in. Yes. Plus that gives us the ability to not have private messages which are always a mess (carbons) - not sure if this is what you meant by addressing messes. And we can do proper PEP for avatars and other stuff. cheers Daniel
Re: [Standards] MUC2
On Thu, Jun 25, 2015 at 3:27 AM, Kevin Smith kevin.sm...@isode.com wrote: Can people share their thoughts on usecases for semi-anon, please? It’s not entirely clear to me what these are (users who want anonymity seem to already be using throw-away JIDs to achieve that, instead of relying on MUC configuration). It's not clear to me that there are *any* use cases. Maintaining two methods of having 1:1 conversations (normal 1:1's, and the anon-MUC version of 1:1's) just makes everything more complicated for no real benefit. There seems to be some significant merit in having MUCs always be non-anonymous in MUC2, to solve some of the addressing messes we’ve found ourselves in. Agreed; MUC2 should absolutely remove the semi-anon capabilities. This will ensure that the MUC2 specification is kept clean and simple. If a user wants to keep their JID private (for some reason), joining an anonymous MUC is not the way to do it anyways (since admins can still see it, and/or the server admin could always make the MUC public and you probably wouldn't even notice), so (as you said) people are going to end up using burner JID's anyways. Having them always be non-private also serves the added benefit of providing some sort of assurance that you're actually talking to the same person two days in a row (eg. Alice talks to Bob on day 1, the next day she talks to Bob but it's someone else who claimed the same nick... now she can verify that the JID is the same, so it's at least someone with access to Bob's account). Of course, this can already be better achieved with PGP, but let's be honest, that never works (going slightly OT with that line of reasoning though). I'm very much hoping that MUC2 will be one of the hot topics at the North American Summit this October. —Sam -- Sam Whited pub 4096R/54083AE104EA7AD3 https://blog.samwhited.com
Re: [Standards] MUC2
On 25 jun. 2015, at 10:27, Kevin Smith kevin.sm...@isode.com wrote: Thinking a bit about the MUC2 stuff. MUC1 had Anon/semianon/nonanon. We’ve pretty much killed off fully anonymous rooms in MUC1. Can people share their thoughts on usecases for semi-anon, please? It’s not entirely clear to me what these are (users who want anonymity seem to already be using throw-away JIDs to achieve that, instead of relying on MUC configuration). 1. Privacy. 2. To not turn public MUCs into treasure troves for spam bots. All of these JIDs have an active client signed in, so they are great targets. 3. Best practices currently dictate that resources should be random, as they are privacy-sensitive. That’s almost opposite of revealing it to everyone in a room. Thijs
Re: [Standards] MUC2
On Thu, Jun 25, 2015 at 9:39 AM, Kevin Smith kevin.sm...@isode.com wrote: On 25 Jun 2015, at 15:28, Peter Saint-Andre - yet pe...@andyet.net wrote: Semi-anonymous rooms are like IRC channels. Draw your own conclusions for whether that's good or bad. I don’t think that’s true, is it? Having or not having @ in a particular channel doesn’t affect your ability to whois a user on IRC to the best of my knowledge. It's true in the sense that a nick in IRC (or a semi-anonymous MUC) is effectively an ephemeral identity. Eg. if you're talking to someone on IRC and they part and then join again, you can't be sure it's actually the same user (unless they've registered the nick; let's ignore the fact that you can probably whois and snag their IP address... maybe it's dynamic and it changes between your conversations). However, once you throw JIDs into the mix it doesn't matter if the nick is ephemeral, you can always see that the JID is the same, meaning that whomever you're speaking with at least has access to the same account. —Sam -- Sam Whited pub 4096R/54083AE104EA7AD3 https://blog.samwhited.com
Re: [Standards] MUC2
On 25.06.2015 17:09, Thijs Alkemade wrote: On 25 jun. 2015, at 10:27, Kevin Smith kevin.sm...@isode.com wrote: Thinking a bit about the MUC2 stuff. MUC1 had Anon/semianon/nonanon. We’ve pretty much killed off fully anonymous rooms in MUC1. Can people share their thoughts on usecases for semi-anon, please? It’s not entirely clear to me what these are (users who want anonymity seem to already be using throw-away JIDs to achieve that, instead of relying on MUC configuration). 1. Privacy. 2. To not turn public MUCs into treasure troves for spam bots. All of these JIDs have an active client signed in, so they are great targets. To hide your contact data should never and can't be the answer against SPAM. I stopped obfuscating my Mail address a few years ago. It's available in a few dozen places over the net. Yet I don't have an issue with SPAM. That same should be true for my JID. 3. Best practices currently dictate that resources should be random, as they are privacy-sensitive. That’s almost opposite of revealing it to everyone in a room. Ack. MUC2 (or similar protocols) should be designed to only show the bare JID of the participants. - Florian signature.asc Description: OpenPGP digital signature
Re: [Standards] MUC2
On 25 Jun 2015, at 15:28, Peter Saint-Andre - yet pe...@andyet.net wrote: On 6/25/15 2:27 AM, Kevin Smith wrote: Thinking a bit about the MUC2 stuff. MUC1 had Anon/semianon/nonanon. s/had/has/ I think ‘had’ was right. Anonymous rooms were removed in 0.6 by a certain “PSA” :) Now it has semianon and nonanon. Can people share their thoughts on usecases for semi-anon, please? Semi-anonymous rooms are like IRC channels. Draw your own conclusions for whether that's good or bad. I don’t think that’s true, is it? Having or not having @ in a particular channel doesn’t affect your ability to whois a user on IRC to the best of my knowledge. It’s not entirely clear to me what these are (users who want anonymity seem to already be using throw-away JIDs to achieve that, instead of relying on MUC configuration). We didn't have throw-away JIDs (well, SASL anonymous JIDs anyway) in the old days. I didn't mean SASL ANONYMOUS when I said throw-away JIDs, I meant that people are registering single-purpose JIDs. There was a brief discussion in xsf@ earlier that if people wanted anonymity they’d be better served by someone writing an anonymising proxy. The only use case we came up with so far that wasn’t better served with throw-away/singleuse JIDs (at first glance; I’m happy to admit I’m missing things here) was a company-internal one where an anonymising proxy would probably be appropriate. There seems to be some significant merit in having MUCs always be non-anonymous in MUC2, to solve some of the addressing messes we’ve found ourselves in. I do think that a system needing anonymity (say, a helpline) can handle that using anonymous JIDs, not anonymous roomnicks. Great. /K
Re: [Standards] MUC2
On 25 Jun 2015, at 15:48, Sam Whited s...@samwhited.com wrote: On Thu, Jun 25, 2015 at 9:39 AM, Kevin Smith kevin.sm...@isode.com wrote: On 25 Jun 2015, at 15:28, Peter Saint-Andre - yet pe...@andyet.net wrote: Semi-anonymous rooms are like IRC channels. Draw your own conclusions for whether that's good or bad. I don’t think that’s true, is it? Having or not having @ in a particular channel doesn’t affect your ability to whois a user on IRC to the best of my knowledge. It's true in the sense that a nick in IRC (or a semi-anonymous MUC) is effectively an ephemeral identity. Eg. if you're talking to someone on IRC and they part and then join again, you can't be sure it's actually the same user (unless they've registered the nick; let's ignore the fact that you can probably whois and snag their IP address... maybe it's dynamic and it changes between your conversations). However, once you throw JIDs into the mix it doesn't matter if the nick is ephemeral, you can always see that the JID is the same, meaning that whomever you're speaking with at least has access to the same account. I think that says “Ignore the bit that makes it untrue” is probably detrimental to this argument :) In my mind, the closest analogy to MUC nicks is IRC nicks, and the closest analogy to JIDs is the whois result. It’s not a clean mapping to start with, because just having someone’s nick (especially on registered-nick services) is enough to be able to identify someone across the whole service, they’re not per-MUC. /K
Re: [Standards] MUC2
On 25 June 2015 at 15:28, Peter Saint-Andre - yet pe...@andyet.net wrote: On 6/25/15 2:27 AM, Kevin Smith wrote: Thinking a bit about the MUC2 stuff. MUC1 had Anon/semianon/nonanon. s/had/has/ We’ve pretty much killed off fully anonymous rooms in MUC1. I think those were never supported. Can people share their thoughts on usecases for semi-anon, please? Semi-anonymous rooms are like IRC channels. Draw your own conclusions for whether that's good or bad. It’s not entirely clear to me what these are (users who want anonymity seem to already be using throw-away JIDs to achieve that, instead of relying on MUC configuration). We didn't have throw-away JIDs (well, SASL anonymous JIDs anyway) in the old days. There seems to be some significant merit in having MUCs always be non-anonymous in MUC2, to solve some of the addressing messes we’ve found ourselves in. I do think that a system needing anonymity (say, a helpline) can handle that using anonymous JIDs, not anonymous roomnicks. I vaguely recall that many years ago we discussed that individuals have anonymity requirements, and not rooms. If you predicate the existence of services which act as pseudonymizers (if you're one of the ancients, anon.penet.fi), then chaining a few of these together gives much stronger assurances than an anonymous MUC room ever could. Peter -- Peter Saint-Andre https://andyet.com/
Re: [Standards] MUC2
On 6/25/15 8:39 AM, Kevin Smith wrote: On 25 Jun 2015, at 15:28, Peter Saint-Andre - yet pe...@andyet.net wrote: On 6/25/15 2:27 AM, Kevin Smith wrote: Thinking a bit about the MUC2 stuff. MUC1 had Anon/semianon/nonanon. s/had/has/ I think ‘had’ was right. Anonymous rooms were removed in 0.6 by a certain “PSA” :) Now it has semianon and nonanon. Ah, I thought you were talking about XEP-0045 in the past tense. ;-) Can people share their thoughts on usecases for semi-anon, please? Semi-anonymous rooms are like IRC channels. Draw your own conclusions for whether that's good or bad. I don’t think that’s true, is it? Having or not having @ in a particular channel doesn’t affect your ability to whois a user on IRC to the best of my knowledge. True. It’s not entirely clear to me what these are (users who want anonymity seem to already be using throw-away JIDs to achieve that, instead of relying on MUC configuration). We didn't have throw-away JIDs (well, SASL anonymous JIDs anyway) in the old days. I didn't mean SASL ANONYMOUS when I said throw-away JIDs, I meant that people are registering single-purpose JIDs. There was a brief discussion in xsf@ earlier that if people wanted anonymity they’d be better served by someone writing an anonymising proxy. The only use case we came up with so far that wasn’t better served with throw-away/singleuse JIDs (at first glance; I’m happy to admit I’m missing things here) was a company-internal one where an anonymising proxy would probably be appropriate. Something like an undernet for a company? There seems to be some significant merit in having MUCs always be non-anonymous in MUC2, to solve some of the addressing messes we’ve found ourselves in. I do think that a system needing anonymity (say, a helpline) can handle that using anonymous JIDs, not anonymous roomnicks. Great. Violent agreement. Peter -- Peter Saint-Andre https://andyet.com/
Re: [Standards] MUC2
On 25 Jun 2015, at 16:59, Dave Cridland d...@cridland.net wrote: Removing a widely deployed feature doesn't strike me as a viable option. Well, if we s/widely deployed/widely required/ then I agree. But not baking something into the MUC2 core doesn’t necessarily mean removing the feature. If we’re going to try to blank-canvas a MUC replacement, I’d like to try and look at options as widely as we can. For example, (assuming semi-anonymousness is a requirement) is it possible to not require anything other than non-anonymous in MUC2, but discuss (either in spec or out of spec) how one would do anonymising if one wanted to? I don’t know. I would like us to Get This Right, though. People have been mumbling about replacing MUC for years, and I’ve always been resistant; the discussions at the summit this year persuaded me that we finally have requirements that MUC1 can’t easily meet, but I really do not want us to do MUC2 now and MUC3 in 2017 to fix the stuff we got wrong in MUC2. /K
Re: [Standards] MUC2
On 25 Jun 2015 18:05, Kevin Smith kevin.sm...@isode.com wrote: On 25 Jun 2015, at 16:59, Dave Cridland d...@cridland.net wrote: Removing a widely deployed feature doesn't strike me as a viable option. Well, if we s/widely deployed/widely required/ then I agree. But not baking something into the MUC2 core doesn’t necessarily mean removing the feature. If we’re going to try to blank-canvas a MUC replacement, I’d like to try and look at options as widely as we can. Well, what you're trying to avoid is addressable occupants, correct? That removes private messages, rather than anonymity, I think. Private messages do cause problems in a variety of interesting ways, but equally I find it interesting that they provide me with an immediate indicator of where someone has found me. For example, (assuming semi-anonymousness is a requirement) is it possible to not require anything other than non-anonymous in MUC2, but discuss (either in spec or out of spec) how one would do anonymising if one wanted to? I don’t know. Maybe the better idea is to look at how chatrooms are actually used, and run UX interviews with people who are regular users. It's not very technical, I admit, but I find it very hard to gauge whether some of these features are desirable or confusing, since I've simply got used to this being the way things work. People keep telling us that Slack has ask these things right, but aside from having a nice user interface and plenty of integration, I'm not clear if there's anything else that makes it a clear winner. I would like us to Get This Right, though. People have been mumbling about replacing MUC for years, and I’ve always been resistant; the discussions at the summit this year persuaded me that we finally have requirements that MUC1 can’t easily meet, but I really do not want us to do MUC2 now and MUC3 in 2017 to fix the stuff we got wrong in MUC2. /K
Re: [Standards] MUC2
On 25 June 2015 at 09:27, Kevin Smith kevin.sm...@isode.com wrote: Thinking a bit about the MUC2 stuff. MUC1 had Anon/semianon/nonanon. We’ve pretty much killed off fully anonymous rooms in MUC1. Can people share their thoughts on usecases for semi-anon, please? It’s not entirely clear to me what these are (users who want anonymity seem to already be using throw-away JIDs to achieve that, instead of relying on MUC configuration). There seems to be some significant merit in having MUCs always be non-anonymous in MUC2, to solve some of the addressing messes we’ve found ourselves in. Some thoughts: I think almost every MUC room I'm in is semi-anonymous. The only exception I could immediately find was the Openfire chatroom, open_c...@conference.igniterealtime.org - it seems pretty unlikely that this is by accident, but perhaps every server does this by default, and none of the admins have ever noticed. Removing a widely deployed feature doesn't strike me as a viable option. I (personally, mind you) would be happy if pseudonymized users in chatrooms reduced available features. For example, it seems bizarre that in the typical [semi-]anonymous MUC, I can query a vCard of an anonymous user. So for example I can join the XSF chatroom, and while I cannot discover Zash's jid, I can find his real name and email address. This strikes me as nuts. I also suspect that if we promoted the usage of anonymizers as a day-to-day way to shield one's jid, this might have detrimental effects on chatroom abuse. Dave.
Re: [Standards] guest access
On Jun 25, 2015, at 4:51 PM, Peter Saint-Andre - yet pe...@andyet.net wrote: Has anyone else deployed this kind of pattern? If so, how did you solve the problem of service endpoint discovery? [BA] For WebRTC apps, the guest service is typically configured on the web server (e.g. In a config.js file) and pushed down to the WebRTC JS app, so no discovery is required.
Re: [Standards] guest access
On Jun 25, 2015, at 8:13 PM, Bernard Aboba bernard.ab...@gmail.com wrote: On Jun 25, 2015, at 4:51 PM, Peter Saint-Andre - yet pe...@andyet.net wrote: Has anyone else deployed this kind of pattern? If so, how did you solve the problem of service endpoint discovery? [BA] For WebRTC apps, the guest service is typically configured on the web server (e.g. In a config.js file) and pushed down to the WebRTC JS app, Sorry, I should have mentioned that Lance and I were thinking about mobile apps, not web apps. Peter
[Standards] guest access
Lance Stout and I had a conversation the other day about what we call guest access to an XMPP application. As example, consider a chat service (text, video, what have you) that has registered users and the ability for registered users to invite ad-hoc users to a session or meeting. This kind of functionality is quite common with applications like video conferencing (Talky, Jitsi Meet, WebEx, etc.). If this kind of application is based on XMPP, the invited user needs to gain access to the network (i.e., authenticate somehow) in order to join the conference. However, for security and scaling reasons it makes sense to have these ad-hoc users authenticate at a different place than the registered users. (Often, but not always, the ad-hoc users might authenticate using the SASL ANONYMOUS mechanism, but other methods are possible such as token auth.) Thus we need a way for a client to discover where it can authenticate as an ad-hoc or guest user. We don't want to use a DNS SRV Service name of xmpp-client because that will point clients to the service endpoint for registered users. What we came up with was to use a new DNS SRV Service name of xmpp-guest, which would point to the service endpoint for guest access. Has anyone else deployed this kind of pattern? If so, how did you solve the problem of service endpoint discovery? Would you find it helpful to have a DNS SRV Service name for this kind of access? If there is wide enough interest, I'd be happy to write a spec and pursue registration of the service name with our friends at IANA. Thanks, Peter -- Peter Saint-Andre https://andyet.com/
[Standards] MUC2
Thinking a bit about the MUC2 stuff. MUC1 had Anon/semianon/nonanon. We’ve pretty much killed off fully anonymous rooms in MUC1. Can people share their thoughts on usecases for semi-anon, please? It’s not entirely clear to me what these are (users who want anonymity seem to already be using throw-away JIDs to achieve that, instead of relying on MUC configuration). There seems to be some significant merit in having MUCs always be non-anonymous in MUC2, to solve some of the addressing messes we’ve found ourselves in. /K
