Re: [Standards] Council Minutes 2020-04-15
On Tue, 28 Apr 2020 at 18:28, Georg Lukas wrote: > * Tedd Sterr [2020-04-22 16:46]: > > https://logs.xmpp.org/council/2020-04-15?p=h#2020-04-15-515165c7293c9539 > > > > 4a) Proposed XMPP Extension: Room Activity Indicators - > https://xmpp.org/extensions/inbox/room-activity-indicators.html > > I'm actually very much torn on this. I can understand that you have a > certain use case in mind, and that your use case probably defines all > the parameters that are vague in the XEP text. As it stands, I as a > client developer don't see why or how I should implement this. That > said, I see multiple practical issues with it: > > It is not quite clear which aspects of this are user (account) specific > and which are client (full-JID?) specific, and how the MUC service is > supposed to track individual clients. > > The vague business rules don't provide a hint on whether to expect one > RAI notification a day or one per second, and what the client is > supposed to do with it - display an "unread" marker? Auto-join the room? > Fetch MAM for the room? Something else? > > I hope we can figure out all these during Experimental, so +1 > > > 4b) PR #924 - XEP-0191: Change service discovery flow to use account > instead of server - https://github.com/xsf/xeps/pull/924 > > While not strictly a vote, I think that the right approach here would be > to introduce the new syntax while demanding from servers to support the > old one, for the next ten years or so. > > > 4c) Advance XEP-0357 (Push Notifications) - > https://xmpp.org/extensions/xep-0357.html > > -1 > > This XEP really needs significant improvement. I agree with Daniel that > starting from scratch might be the best idea. We might use regular > message syntax or maybe IQs for the notifications, and we need a better > introduction into the involved roles and what components this XEP > addresses. And finally, we need to change the semantics to allow the > push service to send different kinds of notifications. I think the > stanza-skeleton approach is a good one to finally implement. > If you want people to start from scratch, is it worth accepting the XEP onto Draft and then obsoleting it once a replacement is done? I didn't see any concerns regarding security etc which might be blockers to that strategy. Dave. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] UPDATED: XEP-0389 (Extensible In-Band Registration)
Version 0.4.0 of XEP-0389 (Extensible In-Band Registration) has been released. Abstract: This specification defines an XMPP protocol extension for in-band registration with instant messaging servers and other services with which an XMPP entity may initiate a stream. It aims to improve upon the state of the art and replace XEP-0077: In-Band Registration by allowing multi-factor registration mechanisms, and account recovery. Changelog: * Add OOB challenge type. * Add IQ query for flows. * Add a glossary. * Make challenge listings more consistent. * Cleanup and expand the registrar considerations section. * Clarifications and typo fixes throughout the text. (ssw) URL: https://xmpp.org/extensions/xep-0389.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Council Minutes 2020-04-15
* Tedd Sterr [2020-04-22 16:46]: > https://logs.xmpp.org/council/2020-04-15?p=h#2020-04-15-515165c7293c9539 > > 4a) Proposed XMPP Extension: Room Activity Indicators - > https://xmpp.org/extensions/inbox/room-activity-indicators.html I'm actually very much torn on this. I can understand that you have a certain use case in mind, and that your use case probably defines all the parameters that are vague in the XEP text. As it stands, I as a client developer don't see why or how I should implement this. That said, I see multiple practical issues with it: It is not quite clear which aspects of this are user (account) specific and which are client (full-JID?) specific, and how the MUC service is supposed to track individual clients. The vague business rules don't provide a hint on whether to expect one RAI notification a day or one per second, and what the client is supposed to do with it - display an "unread" marker? Auto-join the room? Fetch MAM for the room? Something else? I hope we can figure out all these during Experimental, so +1 > 4b) PR #924 - XEP-0191: Change service discovery flow to use account instead > of server - https://github.com/xsf/xeps/pull/924 While not strictly a vote, I think that the right approach here would be to introduce the new syntax while demanding from servers to support the old one, for the next ten years or so. > 4c) Advance XEP-0357 (Push Notifications) - > https://xmpp.org/extensions/xep-0357.html -1 This XEP really needs significant improvement. I agree with Daniel that starting from scratch might be the best idea. We might use regular message syntax or maybe IQs for the notifications, and we need a better introduction into the involved roles and what components this XEP addresses. And finally, we need to change the semantics to allow the push service to send different kinds of notifications. I think the stanza-skeleton approach is a good one to finally implement. Georg signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Council Minutes 2020-04-15
On Wed, Apr 22, 2020 at 02:45:59PM +, Tedd Sterr wrote: > https://logs.xmpp.org/council/2020-04-15?p=h#2020-04-15-515165c7293c9539 > > 1) Roll Call > Present: Daniel, Jonas, Zash, Georg > Apologies: Dave > > 2) Agenda Bashing > No additions. > > 3) Editor's Report > * Expired calls: None > * Calls in progress: > - LC for XEP-0357 (Push notifications) ends at 2020-04-15 > * New ProtoXEP: Room Activity Indicators > > 4a) Proposed XMPP Extension: Room Activity Indicators - > https://xmpp.org/extensions/inbox/room-activity-indicators.html > Daniel: [on-list] > Jonas: [on-list] > Georg: [on-list] > Zash: [on-list] > Dave: [pending] +1 > 4c) Advance XEP-0357 (Push Notifications) - > https://xmpp.org/extensions/xep-0357.html > Daniel: -1 (unaddressed feedback) > Jonas: -1 (arguments against this using PubSub syntax, making it > unnecessarily hard to understand, are sound) > Georg: [pending] > Zash: [pending] > Dave: [pending] -1 Has issues and unaddressed feedback. -- Kim "Zash" Alvefur 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-0353 (Jingle Message Initiation)
Am Do., 29. Aug. 2019 um 11:26 Uhr schrieb Andrew Nenakhov : >> We have implemented this specification on iOS client, and discovered that it >> is unsuitable in real life scenarios. We have updated it with additional >> callback routine, the changes and stanza format is described here: >> https://docs.google.com/document/d/1geR2-VlKkjwqFftstV7O1cYfGqKQy-eEUepgRrge0ow/edit Ignoring the session-still available check here for a second (which I think should at least be optional and only done when catching up from MAM) why is this changing the proceed to an accept? cheers Daniel ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
