[Standards] Re: Council (and what it does, and what it should do)
Quoting Goffi : For the record, we'll have a meeting in Berlin next month (thanks to Debacle), to work exactly on that: interoperability issue with OMEMO (and A/V). I like to add: It is an open sprint, so everybody is invited to work on whatever they like :-) Please, everyone, register yourself, if chances are ≥ 1 % that you come to Berlin: https://wiki.xmpp.org/web/Sprints/2024-07_Berlin#Attendees Cheers ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: XEP-0440 and tls-server-end-point
Dear all, coincidentally I was implementing `tls-server-end-point` channel binding for go-sendxmpp this morning. As a client can choose the method to use I don't see an issue here. I just prefer `tls-exporter` if TLSv1.3 is used and `tls-unique` otherwise and only use `tls-server-end-point` when it's the only method offered. As Holger and Andrzej pointed out there might be cases where the better methods are not available and using a weaker one is still better than no channel binding at all. Best regards, Martin signature.asc Description: PGP signature ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Signing PubSub items (Proposed XMPP Extension: OpenPGP for XMPP Pubsub)
> Title: OpenPGP for XMPP Pubsub [...] > Specifies an OpenPGP for XMPP (XEP-0373) profile for the pubsub use > case. > > URL: https://xmpp.org/extensions/inbox/pubsub-encryption.html I hoped that the XEP would provide a way to sign blog posts or other data, but it does not, at least not explicitely. Use case: Help to prevent things like "Twitter: Fake Elon Musk scam spreads after accounts hacked" on Libervia or Movim. Is this out of scope? Cheers ¹ https://www.bbc.com/news/technology-46097853 (2018-11-05) (Reminder to myself: Fake Elon Musk on Libervia with his announcement, he were up to buy Salut-à-toi. Sell my SàT shares, before people dare to check the OpenPGP signature. Become rich.) ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Clarify meaning of pubsub#item_expire: creation or modification?
On 2021-09-17 13:22, goffi wrote: > there is no notion of "modification" in XEP-0060: an item with an > existing ID is overwritten by a new item with same ID, not > modified. The notion of modification has been introduced in XEP-0413 > (Order-By) that I've authored, because it's useful, but it's not part > of XEP-0060. > > Thus, in the case of pubsub#item_expire, it can only reference the > date of items creation (so if item A' with the same ID as item A is > published, it's the date of A' creation which is used, and A doesn't > exist anymore). Oh, I see. Thanks for the explanation! Then the patch might not be necessary for XEP-0060. XEP-0413 does not mention expiration, which is fine. I still think, it might be useful to clarify the issue *somewhere*, just to avoid any doubts. Cheers ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Clarify meaning of pubsub#item_expire: creation or modification?
Hi, this question came up when discussing the server side implementation of pubsub#item_expire: Is expiry relative to original creation or to last modification? It looks like both options can make sense, but in most cases, last modification is more useful, e.g. when a singleton node is updated or in case of redacted blog posts. Also, the standard already says, that re-publication were equivalent to modification: > Note: If a publisher publishes an item with an Item ID and the ItemID > matches that of an existing item, the pubsub service MUST NOT fail the > publication but instead MUST overwrite the existing item and generate > a new event notification (i.e., re-publication is equivalent to > modification). To implement an absolute deadline of an item, the expiry time is not useful anyway, because it is a per node option, not a per item one. In such cases, the publisher should remove the node when time comes. In any case, the standard should clear about what is intended. Patch attached. Cheers, Martin diff --git a/xep-0060.xml b/xep-0060.xml index 09638a6b..d5ea9ce7 100644 --- a/xep-0060.xml +++ b/xep-0060.xml @@ -3569,7 +3569,7 @@ And by opposing end them? 10 + label='Time after which to automatically purge items after last modification. `max` for no specific limit other than a server imposed maximum.'> 604800 10 + label='Time after which to automatically purge items after last modification. `max` for no specific limit other than a server imposed maximum.'> 604800 + label='Number of seconds after which to automatically purge items after last modification. `max` for no specific limit other than a server imposed maximum.'/> ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Fwd: [Uta] STARTTLS vulnerabilities
Quoting Kim Alvefur : We were always at war with STARTTLS? The world is at war with both ports < 443 and ports > 443. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP Modernization Roundtable Results
On 2021-06-22 16:51, Sam Whited wrote: > * XEP-0138: Stream Compression, XEP-0229: Stream Compression with LZW > * MattJ: everyone is streaming video on mobile devices so XML > is not a big > resource hog that we need to worry about anymore XML compression is probably not worthwhile for the IM use case and even has privacy issues, but it might be very useful for IoT and similar applications. Some without any privacy needs. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Announcing Slummit 2021
On 28.01.2021 09:28, Sam Whited wrote: If we're streaming any of this for public consumption please let's also stream it on YouTube. We need to meet people where they're at, and for video streaming that's YouTube. We can of course do PeerTube too if people want that, but most of the public are on YouTube. —Sam I agree on this. Afaik Jitsi-Meet is able to stream to YouTube so the people who are participating in the talk could join the Jitsi-Meet room and the audiance watch via YouTube. In a recent training at my company we also had a good experience with muting all participants except the hosts and writing questions in the chat. One host who was not busy with the presentation was monitoring the chat, collecting questions and forwarding them to the presenter when it was suitable. Worked pretty good for us, maybe we could have a similar procedure with Jitsi-Meet, YouTube-Streaming and a MUC. Best regards, Martin signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0381 (Internet of Things Special Interest Group (IoT SIG))
On 2020-12-01 18:37, Jonas Schäfer wrote: > 1) Do you think that the SIG is a good addition to the XMPP Community? If so, > why? If not, why not? As a user of XMPP in IoT, I'm happy about a SIG working on the relevant XEPs. And I'm thankful to flow and MattJ for managing xmpp:i...@muc.xmpp.org?join > 2) Would you join that SIG? If not, why not? Yes. > 3) Do you have any additional comments on that SIG, its mission or goals? No. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0443 (XMPP Compliance Suites 2021)
Dear all, I would like to also have XEP-0425: Message Moderation [1] added to the XMPP Compliance Suites 2021 as spam messages to MUCs are happening more often. Would you consider adding it to advanced client and advanced server? Best regards, Martin [1] https://xmpp.org/extensions/xep-0425.html signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0060: max #max_items
Quoting Tedd Sterr : Alternatively, I presume 31 bits would be a safe* maximum positive integer value (max='2147483647'). * Limits are 'bad,' but I don't see anyone realistically needing 2 billion entries, nor a server storing them. Maybe in IoT use cases (sensor data) this limit can be hit in a few years. I had PEP nodes configured to 2.7 million items (number of seconds in one month) for that, only 800 times less. This was only in a PoC project and we will use a much lower value in production, but it is certainly not completely unrealistic. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Call for Experience: XEP-0198: Stream Management
On 2020-02-21 09:23, Daniel Gultsch wrote: > Only someone who hasn't been on a German high speed train can say with > confidence that desktop and web clients don't need stream management. Yes, mobile ≠ Android/iOS! Many notebook computers are connected to Wifi or "mobile internet" and used in public transport, (over-) crowded places, or rural areas with flaky connections. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Simple JSON Messaging
On 2020-02-19 00:33, Dave Cridland wrote: > It is normal, outside this group. That train has left the station, and > there is little point in closing the stable door after the ship has sailed. Correction: "The train has left the bike shed". (Back to work, where we start to use XEP-0335: JSON Containers, which seems to be sufficient for our simple use case. Still, we thought about XEP-: CSV Containers.) ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Message Reactions
Quoting Dave Cridland : On Fri, 19 Jul 2019 at 15:52, Georg Lukas wrote: 4. Limitation to Emoji ... Loose agreement here, but also, I suspect people will rapidly want to react in custom ways not expressible in Unicode, so we might want URls or inline media to be possible too. We already see, the emojis get less important here and there and are replaced by "stickers". Which is already supported in XMPP by XEP-0231 (bits of binary, BoB). This allows even more childish and silly reactions! XMPP reactions should support that. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Council Voting Summary 2019-03-31
Quoting Dave Cridland : * But this is creating our own cryptography, and the XSF should not be doing that. If I understand ATT correctly, it's not cryptography in itself, but automation of key "trust state" copying. More a kind of convenience function. Please CMIIW. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] One true final way to mark up messages
Quoting Sam Whited : IM isn't the web, I agree. IM messages are - in general - short. Named URLs allow shorter messages, that are better readable esp. by non-technical people. In the context of 0393, I suggest something like: [http://shakespeare.mit.edu/macbeth/ The Tragedy of Macbeth] and [xmpp:x...@chat.yax.im?join Off-topic MUC] ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] One true final way to mark up messages
Quoting Sam Whited : What is the use case for hyper links and who does it benefit? I keep hearing people say they want them, but I don't really understand why they're necessary over just auto linking things that look like URLs. Thanks. URLs are sometimes readable to me, sometimes not. For most non-geek people URLs are never readable. Therefore, HTML has an anchor element with content and not just auto linking. Mainly an aesthetical question. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] One true final way to mark up messages
Quoting Ненахов Андрей : XHTML is deprecated, This, unfortunately, is the case. I'm not completely convinced of the arguements against 0071. and all other proposals are not in usable shape. 0393 is not bad, IMHO. It might need two or three additions, esp. hyperlinks, but most typical use cases are covered. For anything more complex there is 0071. It only needs to be resurrected. Like Lazarus. Cheers ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0335 (JSON Containers)
On 2019-02-04 19:17, Jonas Schäfer wrote: > 5. Is the specification accurate and clearly written? Minor clarification would be nice: It was not immediately clear to me, that the json element must contain exactly one JSON object. And that for multiple JSON objects one must either use multiple json elements in a row or construct a JSON object containing others. Cheers ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Best practices for GDPR compliant deployment of XMPP
On 2018-05-25 09:13, Winfried Tilanus wrote: > Beside that informative XEP, I (or a group of people willing to do so) > publish an own document discussing XMPP & the GDPR in detail. Having XEPs explaining best practices for - retrieving all data belonging to one user - removing all data of a particular user - agreeing to terms of service and withdrawing again - etc. is certainly needed by many people in an outside the EU. It is not necessary to even mention GDPR in those XEPs. Informal documents (even blogs) could then link the XEPs to GDPR or other, similar laws. Just my 2€¢. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Disappearing timers for OMEMO proposal
On 2018-05-13 13:05, W. Martin Borgert wrote: > I would prefer > > > ... > > > Everybody can just us the attribute or ignore it. ^e ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Disappearing timers for OMEMO proposal
On 2018-05-13 12:38, Jonas Wielicki wrote: > On Samstag, 12. Mai 2018 19:55:52 CEST Paul Schaub wrote: > > > > > > This is an ephemeral message > > > > > > This is awful. It will require the message to carry a non-empty to > deal with the MAM/Carbons mess (and also to help users of clients which do > not > support this feature). I would prefer ... Everybody can just us the attribute or ignore it. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Disappearing timers for OMEMO proposal
Quoting Alexander Krotov : Disappearing messages without end-to-end encryption and forward secrecy are useless at best. They give the user false sense of security. That is why Telegram implements timers for "secret" chats only I believe, as I said in the first message. I respectfully disagree. Timers (or "ephemeral messages") are not a security feature, but only a means of data hygiene. Therefore it is orthogonal to any encryption and it does also not matter, whether your peer or one of your peers devices or resources does implement the feature or not. No need to check. As sender, just use the timers and let the problem of deleting messages to the recipient. Cheers ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Disappearing timers for OMEMO proposal
On 2018-05-10 14:31, VanitasVitae wrote: > I'd also rather not tie it to OMEMO. The same principle of disappearing > messages could also be applied with other crypto in mind, or even no crypto > at all. Remember, this functionality is not designed to give you any > (serious) security improvements. Its rather a function which teenagers find > neat and which was implemented in Signal for some reason. D'accord with not coupling ephemeral messages to encryption. I would find it especially practical for unimportant messages with friends. We just don't want all the nonsense cluttering our archives. No need to check other sides client for that feature, of course. It's their problem if they really like to store the noise. Cheers ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)
Quoting Matthew Wild : The whole point of the autojoin logic was to keep clients synchronised. Either we want clients in sync or we don't. And I think we do. Sometimes yes, sometimes no. I would like to have some rooms autojoined when I'm at home, but not when at work. And vice versa. (I'm using different accounts for work and private stuff, but maybe not everyone uses multiple accounts.) Still, between the options "always synced" and "never synced", I prefer the former. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0394: too weak to replace XEP-0071
Quoting Jonas Wielicki : If you are doing graphics/text design/publishing with your IM client, you’re doing it wrong, in my opinion. But XMPP is not only IM. What about blogging or social networks like Movim or Salut à Toi or before Jappix, which present a rich web interface? No need for specific fonts or colours, I agree, but people want probably a little bit more output control then in the IM world. Cheers ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] [STANDARDS] XEP-0394: too weak to replace XEP-0071
Quoting Kozlov Konstantin : The problem of XEP-0393 is that markup mixed with plain text and it's hard to purge it from it. That's why I prefer Markdown (or RST, it's almost the same): It is more or less readable as plain text to most of us. Cheers ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] [STANDARDS] XEP-0394: too weak to replace XEP-0071
On 2018-03-15 10:22, Kozlov Konstantin wrote: > I don't want to discuss XEP-0393, 'cause the whole idea of using LML in IM > sounds bad. Flaws if it is obvious, so it's needless to mention them again. I disagree. Yes it is ugly, but having a widely used LML, such as Markdown (in contrast to some strange homebrew) in XMPP would be a pragmatic approach, IMVHO. Many people know Markdown syntax nowadays, there are parsers for it in many different programming languages, and we already know how ugly and illogical it is. Just needs a new XEP :~) > According to my UX, XEP-0071 functionality mostly used for: I agree with all your points. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] [OT] Meetup in Berlin on Friday
On 2018-03-12 23:08, Holger Weiß wrote: > If you'd like to talk to us, you can join our MUC room: > > berlin-mee...@conference.conversations.im And we even have a pubsub node you can subscribe to: https://de.movim.eu/?node/pubsub.movim.eu/berlin-xmpp-meetup ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0283 Moved - Security and Usability
Quoting Georg Lukas : b) have a tool that will perform "account migration", i.e. you enter the credentials to your old account and to your new account and the tool will automatically move all your contacts from A to B. Only contacts or as much of personal data as possible? What about bookmarks? Or anything that is in PEP? That would be very useful. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] 0174 Serverless Messaging: Discovering Capabilities
Quoting Peter Saint-Andre : Well, it worked OK at small conferences when universal connectivity wasn't so common in the pre-smartphone days (folks had a lot of fun using it in Adium and iChat back then), but I haven't seen it used since 2010 or so. It went to Draft and Final quickly (perhaps we were more efficient about moving things forward back then), but it doesn't seem relevant anymore. I didn't use this feature for some years, but I can imagine, that it might be a relevant niche. Having a protocol that can survive certain desasters like "no mobile internet available" still sounds interesting and worthwhile to me. Might even be interesting in the field of humanitarian aid or when privacy is more relevant. Cheers ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Adding logo to MUC and PubSub node
Quoting Jonas Wielicki : On Donnerstag, 8. Februar 2018 14:34:12 CET W. Martin Borgert wrote: I had another idea before coming up with the configuration variable, but I find it very ugly, but maybe others might find some beauty (or pragmatism) in it: A PubSub node could have a "magic" node We need to get this terminology straight. When you say "PubSub node", do you in fact mean a pubsub node (i.e. a specific @node value on a specific pubsub service with JID X) or a PubSub service with JID X? I hope to get the terminology right this time: A PubSub node could have a "magic" item. A PubSub service could have a "magic" node. Does this make sense? For e.g. Movim both a logo for service and for a node seems to be useful. I think specifying avatars for each PubSub *node* could be tricky. For services (which I assume you meant) see below. If there were a "magic" item on a node, it never must be removed automatically, but only on user request, right? The "magic id" (again, only for PubSub services, not for individual nodes) is obvious, I’d simply use the same the XEP-0084 uses. That could even work magically with client code. Nice! ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Adding logo to MUC and PubSub node
Quoting Daniel Gultsch : polling is a terrible idea traffic wise and very nontransparent for the user. I don't have an opinion on pubsub. I had another idea before coming up with the configuration variable, but I find it very ugly, but maybe others might find some beauty (or pragmatism) in it: A PubSub node could have a "magic" node, i.e. with the magic id "pubsub_logo". This node contains the logo, it can be upgraded and notification to users would be immediate. But a "magic id"? Like "favicon.ico"? ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Adding logo to MUC and PubSub node
Quoting Timothée Jaussoin : In the end I don't think that it's a big issue to have those info requested manually, having a cache of a few hours on the clients is an OK solution for me at the moment. Maybe a refresh or poll rate of e.g. 12..24 hours can "officially" be suggested? Not really nice, but better than not having logos or invent something complicated that will never be implemented... ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Adding logo to MUC and PubSub node
Hi, this is an idea mainly for the "social network" aspect of XMPP: A logo for a MUC or for a PubSub node, similar to a user avatar. Such a logo, emblem, or symbol can be a good indicator for users to find the right MUC or PubSub node in a social network application or graphical XMPP client. How about introducing two configuration variables, one in https://xmpp.org/extensions/xep-0045.html#registrar-formtype-owneronfig: var='muc#muc_logo' And the second one in https://xmpp.org/extensions/xep-0060.html#owner-configure: var='pubsub#node_logo' The value should be a element from https://xmpp.org/extensions/xep-0221.html. IMHO, the value should be restricted to 1. images, or would a sound make sense? Maybe... 2. inline data, so that a link to a web resource cannot be abused for snitching IP addresses What do you think? TIA & Cheers ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Expected behavior when blocking all unknown JIDs
Quoting Goffi : Instead of blocking unconditionally unknown users (which is not an option for me), would not it make sense to use some kind of challenge (e.g. captcha or computational challenge) ? This would not block everything, but probably a good amount of SPAM/SPIM. For email, there is greylisting. IIRC, the receiving server says "try again later" on the first contact. This will be done by any legitimate server, but for spammers holding the message for e.g. one hour is too expensive. Any further messages will be delivered immediately. Neither sender nor receiver notice anything, only a one hour delay of the first message. In my experience, this method doesn't prevent all email spam, but a large part of it. Would this SMTP error 450/451 be applicable to XMPP? ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] 33C3 talk on Signal and current XMPP issue in providing a similar UX
On 2016-12-29 23:32, Tobias Markmann wrote: > After > registration, they need to easily/secure/privacy-enforcing fill up their > roster with contacts based on known contact information like phone number > or e-mail address. I suggest to popularise the idea of identical email and XMPP address. While this is, of course, optional, it makes contact matching even more easy than with phone numbers. As long as 98.7% of the planets email population happen to use the same provider and this very provider dropped XMPP support, it is, unfortunately, difficult to achieve. Btw: You can reach me as {mailto,xmpp}:deba...@debian.org :~) Btw': Thanks for your notes, Tobias! ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] "Self-destruct" message timeout deletion hints
Quoting Dave Cridland : That's not the case in an open ecosystem - someone's client could just ignore the request, and might even have a setting to do so. It is very probable that many clients will offer this setting, so users will be rapidly aware of it - and that their peer has it, too! The question is: Should this be a "convenience" feature or a "security" feature. I see it as the former, and that way it is fine. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Easy XMPP
Pardon, this was meant to sent privately :~) Usability issue in Horde, I assume, or lack-of-brain problem between keyboard and chair. Here in English: Germany and probably other countries like to make anonymous SIMs illegal. Relying on phone numbers would make anonymous "Easy XMPP" illegal, too, which is probably not a goal. And: What is XEP-PARS? TIA! Quoting "W. Martin Borgert" : Hi, eine private Bemerkung und eine Frage: Quoting Georg Lukas : 2. Use of phone numbers: unfortunately this is an unsolved problem yet. Da demnächst anonyme SIM-Karten in Deutschland (und vermutlich auch anderen Staaten) outlawed werden - egal wie erfolgversprechend man das einschätzt - wäre mit Telephonnummern als Id auch anonymes "Easy-XMPP" illegal. Das kann das Ziel nicht sein. - XEP-PARS: creation and full handling of links with preauth element Was ist das für ein XEP? Hast Du einen Link für mich? Danke! Cheers ___ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___ ___ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Easy XMPP
Hi, eine private Bemerkung und eine Frage: Quoting Georg Lukas : 2. Use of phone numbers: unfortunately this is an unsolved problem yet. Da demnächst anonyme SIM-Karten in Deutschland (und vermutlich auch anderen Staaten) outlawed werden - egal wie erfolgversprechend man das einschätzt - wäre mit Telephonnummern als Id auch anonymes "Easy-XMPP" illegal. Das kann das Ziel nicht sein. - XEP-PARS: creation and full handling of links with preauth element Was ist das für ein XEP? Hast Du einen Link für mich? Danke! Cheers ___ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0115 Entity Capabilities - clarifications
Alban Crequy wrote: Le Sun, 15 Aug 2010 23:05:49 +0100, Martin Morrison a écrit : I've recently been implementing XEP-0115 Entity Capabilities, both the latest and the legacy versions, and have a few issues that I feel should be clarified in the latest version of the spec: 1. The legacy version of the spec explicitly says (in 4.2, below example 8): [...] 2. The spec only uses the word "SHOULD" when specifying how the Disco 'node' attribute is formed. A receiving entity that supports both Entity Capabilities and has multiple disco#items nodes thus has somewhat of a dilemma in deciding how to respond to a disco#info request for an unknown node. Should it return an error, or assume that the remote entity has used some other mechanism to construct the 'node' attribute in the request, and return the base capabilities as if the node was empty? I think is best: sending an empty capability in this case is bad because the hash will not match and the client will discard the reply. This assumes that the receiving entity re-extracts the hash from the node on reply. If I write a client that chooses to generate uuids for the node attribute, then I am fully compliant with XEP-0115, but your client will never tell me your capabilities. If what you've suggested is the recommended behaviour, shouldn't the specification use "MUST" when specifying "node#hash" as the value of the 'node' attribute? 3. Related to item 2, the following race condition can occur: - ro...@shakespeare.lit sends Presence to jul...@shakespeare.lit with an Entity Capabilities hash - In response, juliet sends a disco#info request with the "node#hash" as the 'node' attribute - Meanwhile, romeo changes the feature set of his client (e.g. turns on his camera) - Upon receiving the disco#info request, what does romeo do? As the 'node' attribute has been formed using the recommended method, Romeo can establish that the hash doesn't match his current capabilities. Should he return an error, or ignore the contents of the 'node' attribute completely and just return his current capabilities (which will be accepted, since he will already have pushed an updated hash via Presence)? Either way, I think it would help if the spec specified what was expected. For this race, it was suggested to just send in this thread: http://mail.jabber.org/pipermail/standards/2008-May/018713.html Sending will work: Juliet will receive the new hash a bit later and she will send a new disco request with the new hash. Alternatively, Telepathy-Gabble keeps a cache mapping hash->capabilities. So with this implementation, Romeo will send the *previous* capabilities corresponding with the requested hash. Juliet will ask the capabilities again anyway when she receives the new hash if she wants to know the new capabilities. This requires Romeo to keep track of the hashes of every combination of capabilities he has every published. It also doesn't sit well IMO with the existence of multiple hashing algorithms - the "node#hash" 'node' attribute doesn't tell you what the hashing algorithm is, making it even harder to know what capabilities to return (albeit on the very unlikely off-chance that two different capabilities hash to the same string under two different supported algorithms). Disco queries in XEP-0115 are not "what are your current caps?" but "what are the caps corresponding to this hash?". It is up to the clients to keep track of hashes and to make new disco requests when they receive a new hash if they want to know the capabilities. If they really are, as you say, "what are the caps corresponding to this hash?" then shouldn't the request mirror that, by explicitly specifying the hash algorithm and hash string? Currently the request on-the-wire would be interpreted as "what are the caps of the node known as 'node#hash'?", with nothing to differentiate this from a plain XEP-0030 request. I agree with the sentiments of your points, but the current specification feels like its trying to pander to the legacy format too much, resulting in multiple ambiguities overall. Cheers, Martin Alban
[Standards] XEP-0115 Entity Capabilities - clarifications
I've recently been implementing XEP-0115 Entity Capabilities, both the latest and the legacy versions, and have a few issues that I feel should be clarified in the latest version of the spec: 1. The legacy version of the spec explicitly says (in 4.2, below example 8): "Note: The set of features that a given entity advertises in response to a "client#version" request and all "client#extension" requests MUST be equivalent to the response it gives to a disco#info request with no 'node' attribute". The latest revision of the spec does not have a similar clause (for "client#hash" == no 'node'). I assume this what is intended though, and feel it could do with being made explicit. 2. The spec only uses the word "SHOULD" when specifying how the Disco 'node' attribute is formed. A receiving entity that supports both Entity Capabilities and has multiple disco#items nodes thus has somewhat of a dilemma in deciding how to respond to a disco#info request for an unknown node. Should it return an error, or assume that the remote entity has used some other mechanism to construct the 'node' attribute in the request, and return the base capabilities as if the node was empty? 3. Related to item 2, the following race condition can occur: - ro...@shakespeare.lit sends Presence to jul...@shakespeare.lit with an Entity Capabilities hash - In response, juliet sends a disco#info request with the "node#hash" as the 'node' attribute - Meanwhile, romeo changes the feature set of his client (e.g. turns on his camera) - Upon receiving the disco#info request, what does romeo do? As the 'node' attribute has been formed using the recommended method, Romeo can establish that the hash doesn't match his current capabilities. Should he return an error, or ignore the contents of the 'node' attribute completely and just return his current capabilities (which will be accepted, since he will already have pushed an updated hash via Presence)? Either way, I think it would help if the spec specified what was expected. Cheers, Martin