Re: [Standards] Call for Experience: XEP-0184: Message Delivery Receipts
Am Di., 3. März 2020 um 21:19 Uhr schrieb Andrew Nenakhov < andrew.nenak...@redsolution.com>: > > I think this XEP should be obsoleted in favour of XEP-0333 Chat > Markers, which does all that XEP-0184 does, plus something more. > > Why would someone depreacte a spec that is implemented in nearly every client in existence, for something that does, best case, exactly the same? Regards ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] [Council] XMPP Council Agenda for 2020-03-04
H all, Unfortunately I can't make tomorrow's meeting due to an appointment I'd completely forgotten about. I may not make the week after (though I think I've timed things to allow it). Included here are votes which I'm not sure I can do yet. On Tue, 3 Mar 2020 at 17:51, Jonas Schäfer wrote: > Hi everyone, > > The next XMPP Council Meeting will take place on 2020-03-04 at 16:00Z in > xmpp:coun...@muc.xmpp.org?join. Everyone is welcome to join and give > comments. > > This agenda is composed from: > > - Editor notifications to standards@ > - xsf/xeps GitHub PRs marked as Needs Council > - Suggestions directly sent to me (see below) > > Agenda as follows: > > 1) Roll Call > > 2) Agenda Bashing > > * Feel free to pre-bash on-list or directly to me if you think something > is > missing. > > 3) Editor’s Update > > - ProtoXEP: Reminders > - Expired calls: LC on XEP-0402 > - Calls in progress: > > - CFE: XEP-0066 (Out of Band Data), ends: 2020-03-10 > - CFE: XEP-0184 (Message Delivery Receipts), ends: 2020-03-17 > > (Thank you very much for this bit - very useful) > > 4) Items for voting > > 4a) Proposed XMPP Extension: Reminders > URL: https://xmpp.org/extensions/inbox/reminders.html > Abstract: > This specification provides a way to set up reminders. > > I think this is probably better done as ad-hoc, and a future-delivery concept that Marvin suggests might also be a better approach, but if this were widely deployed as-is it wouldn't do any harm to the network, so I'm +1 for adopting it. If it transforms utterly on the way through Experimental that'll be entertaining. > > 4b) Decide on advancement of XEP-0402 > Title: PEP Native Bookmarks > URL: https://xmpp.org/extensions/xep-0402.html > Abstract: > This specification defines a syntax and storage profile for keeping a list > of > chatroom bookmarks on the server. > > (The last call ends today, so be sure to send in your feedback if you > haven’t > already.) > > I think this is unlikely to see further changes requiring a namespace bump, and should be taken into close change control by the Council, so +1 for draft. > > 4c) PR#898 > Title: XEP-0060: Specify that empty are invalid on publish > URL: https://github.com/xsf/xeps/pull/898 > > If a node is configured not to persist items, and to notify without the payload, does this mean we now have to supply a mandatory payload that is only ever seen by the publisher and the service? Tentative -1, though I could be persuaded into a -0. > > 5) Outstanding Votes > > - There are a few, check the Spreadsheet of Doom and vote on-list as > needed. > > 6) Date of Next > > 7) AOB > > 8) Close > > End of Agenda. > > Note that I am aiming for 30 minutes, but meetings may be extended as > necessary if all council members agree. > > Meetings are normally held every Wednesday at 1600 UTC in the > xmpp:coun...@muc.xmpp.org?join chatroom. > Meetings are open, and anyone (XSF Member or not) may attend, though only > XMPP > Council members may vote. Relevant comments from the floor are welcomed. > > Using your web browser, you can join anonymously via > https://xmpp.org/chat?council > > Note that conversations in the room are logged publicly at > https://logs.xmpp.org/council/ > > If you have suggestions for an agenda item, you can message me via XMPP > or > email at this address or at jo...@zombofant.net. > > I aim to publish the Agenda on the day before the Council meeting before > 20:00Z. > > > Thanks everyone, > Jonas > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Call for Experience: XEP-0184: Message Delivery Receipts
We have it implemented in 'read' mode, so all our clients can receive delivery receipts, but never send them. I think this XEP should be obsoleted in favour of XEP-0333 Chat Markers, which does all that XEP-0184 does, plus something more. вт, 3 мар. 2020 г. в 22:46, Jonas Schäfer : > > The XEP Editor would like to Call for Experience with XEP-0184 before > presenting it to the Council for advancing it to Final status. > > > During the Call for Experience, please answer the following questions: > > 1. What software has XEP-0184 implemented? Please note that the > protocol must be implemented in at least two separate codebases (at > least one of which must be free or open-source software) in order to > advance from Draft to Final. > > 2. Have developers experienced any problems with the protocol as > defined in XEP-0184? If so, please describe the problems and, if > possible, suggested solutions. > > 3. Is the text of XEP-0184 clear and unambiguous? Are more examples > needed? Is the conformance language (MAY/SHOULD/MUST) appropriate? > Have developers found the text confusing at all? Please describe any > suggestions you have for improving the text. > > If you have any comments about advancing XEP-0184 from Draft to Final, > please provide them by the close of business on 2020-03-17. After the > Call for Experience, this XEP might undergo revisions to address > feedback received, after which it will be presented to the XMPP > Council for voting to a status of Final. > > > You can review the specification here: > > https://xmpp.org/extensions/xep-0184.html > > Please send all feedback to the standards@xmpp.org discussion list. > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XMPP Council Agenda for 2020-03-04
Hi everyone, The next XMPP Council Meeting will take place on 2020-03-04 at 16:00Z in xmpp:coun...@muc.xmpp.org?join. Everyone is welcome to join and give comments. This agenda is composed from: - Editor notifications to standards@ - xsf/xeps GitHub PRs marked as Needs Council - Suggestions directly sent to me (see below) Agenda as follows: 1) Roll Call 2) Agenda Bashing * Feel free to pre-bash on-list or directly to me if you think something is missing. 3) Editor’s Update - ProtoXEP: Reminders - Expired calls: LC on XEP-0402 - Calls in progress: - CFE: XEP-0066 (Out of Band Data), ends: 2020-03-10 - CFE: XEP-0184 (Message Delivery Receipts), ends: 2020-03-17 4) Items for voting 4a) Proposed XMPP Extension: Reminders URL: https://xmpp.org/extensions/inbox/reminders.html Abstract: This specification provides a way to set up reminders. 4b) Decide on advancement of XEP-0402 Title: PEP Native Bookmarks URL: https://xmpp.org/extensions/xep-0402.html Abstract: This specification defines a syntax and storage profile for keeping a list of chatroom bookmarks on the server. (The last call ends today, so be sure to send in your feedback if you haven’t already.) 4c) PR#898 Title: XEP-0060: Specify that empty are invalid on publish URL: https://github.com/xsf/xeps/pull/898 5) Outstanding Votes - There are a few, check the Spreadsheet of Doom and vote on-list as needed. 6) Date of Next 7) AOB 8) Close End of Agenda. Note that I am aiming for 30 minutes, but meetings may be extended as necessary if all council members agree. Meetings are normally held every Wednesday at 1600 UTC in the xmpp:coun...@muc.xmpp.org?join chatroom. Meetings are open, and anyone (XSF Member or not) may attend, though only XMPP Council members may vote. Relevant comments from the floor are welcomed. Using your web browser, you can join anonymously via https://xmpp.org/chat?council Note that conversations in the room are logged publicly at https://logs.xmpp.org/council/ If you have suggestions for an agenda item, you can message me via XMPP or email at this address or at jo...@zombofant.net. I aim to publish the Agenda on the day before the Council meeting before 20:00Z. Thanks everyone, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Call for Experience: XEP-0184: Message Delivery Receipts
The XEP Editor would like to Call for Experience with XEP-0184 before presenting it to the Council for advancing it to Final status. During the Call for Experience, please answer the following questions: 1. What software has XEP-0184 implemented? Please note that the protocol must be implemented in at least two separate codebases (at least one of which must be free or open-source software) in order to advance from Draft to Final. 2. Have developers experienced any problems with the protocol as defined in XEP-0184? If so, please describe the problems and, if possible, suggested solutions. 3. Is the text of XEP-0184 clear and unambiguous? Are more examples needed? Is the conformance language (MAY/SHOULD/MUST) appropriate? Have developers found the text confusing at all? Please describe any suggestions you have for improving the text. If you have any comments about advancing XEP-0184 from Draft to Final, please provide them by the close of business on 2020-03-17. After the Call for Experience, this XEP might undergo revisions to address feedback received, after which it will be presented to the XMPP Council for voting to a status of Final. You can review the specification here: https://xmpp.org/extensions/xep-0184.html Please send all feedback to the standards@xmpp.org discussion list. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Council Minutes 2020-02-26
Oops! Sorry about that. (Sorry I'm psychic?) >> Zash: -1 (haven't read that thread yet) > > (Should have been on-list?) > > Anyways, after catching up on that thread I'm -1. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Council Minutes 2020-02-26
On Sun, Mar 01, 2020 at 01:12:18AM +, Tedd Sterr wrote: > 4b) Advance XEP-0198 (Stream Management) - > https://xmpp.org/extensions/xep-0198.html > Georg is unsure, but it's doing its job, expect for the unclear resume host > connection mechanism. > Dave noted a comment on s2s, possibly from MattJ, which he has yet to > consider, but s2s is under-specified at best. > Jonas doesn't think it's possible to move forward if there are zero s2s > implementations; Dave doesn't think any were explicitly mentioned, which > would itself be a procedural reason for not advancing. > Zash mentions that mod_smacks for Prosody does support XEP-0198 in s2s, > though not resumption, and it's disabled by default - Dave thinks it's > unclear what resumption would do for s2s. > > Zash: -1 (haven't read that thread yet) (Should have been on-list?) Anyways, after catching up on that thread I'm -1. -- Kim "Zash" Alvefur ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Reminders
On 3 March 2020 14:49:13 CET, Florian Schmaus wrote: >On 3/2/20 5:18 PM, Jonas Schäfer wrote: >> On Montag, 2. März 2020 11:56:58 CET Marcos wrote: >>> thanks for your comments, Florian. >>> Florian Schmaus writes: I think creating/canelling a reminder should rather be an ad-hoc >command and not an IQ. This way, clients do not need to implement another >IQ protocol-flow, but can re-use their (potentially) existing ad-hoc infrastructure. >>> >>> This probably escapes from my current understandings of the >protocol, so >>> thanks for pointing it out and I'll try to have a read over IQ >handling >>> logic, specially at client side (an issue Andrew already exposed). >> >> Ad-Hoc commands would definitely be a way to do this. Using a >specified >> command name (like XEP-0401 does) would allow for automated entities >to >> interact with this and also gives immediate basic client support for >clients >> which already support Ad-Hoc commands. >> >> For clients which do not, and which also do not support Data Forms at >all, >> this will be more of a pain to implement even without offering >extensive user >> interaction. > >I doubt that it will be much pain, and even if, I would consider >implementing data forms and ad-hoc commands are worth the pain. > >> This is always a trade-off, and I’ve stated elsewhere that I consider >data >> forms a bad thing to have due to their lack of supporting arbitrary >structured >> and dynamic data. > >I don't think I agree with that. They are flexible enough to serve a >large portion of data-exchange use-cases. I am also not sure why they >shouldn't support dynamic data. > >> And this specification needs timestamps, which are a kind of >structured data. > >Right. I would suggest to use xep122 "data forms validation" to provide >a client with the hint that this form field is a xep82 data time >format. >Clients could use this to show a data/time picker UI when this form >field is selected. > >> For a naive Ad-Hoc client, specifying the timestamp in XEP-0082 >format will be >> massively annoying for the user. > >Agreed, especially if no xep112 hint (cf. xep112 example 2) is used. >But >still better than a naive client not being able to participate at all >IMHO. Not sure how massive the annoyance for the user would be, though. >Guess it depends on the user. > >> For a client which adds specific support for >> this ProtoXEP, the cost of doing so is likely less high than adding a >custom >> IQ support > >Correct: For a client (library) already supporting data forms, >implementing an ad-hoc/data-form based protocol is far easier then >implementing a pure IQ based protocol. Also § 5.2 / Example 7 "Server sends a reminder" should include >just a , and not invent another -like extension element >(). >>> >>> Makes sense. >>> The 'timezone' attribute in is not necessary, xep82 >data-time profiles already encode the timezone (the 'Z' at the end of the >String). >>> >>> Indeed, this slipped in from an early write up where no reference to >>> XEP-0082 was yet present. It has been already amended. >> >> Actually, timezones is a good keyword.For timestamps in the future, >it is >> generally better to use localtime+timezone specifier instead of a UTC > >> timestamp. After all, if you are in the Europe/Berlin timezone and >set a >> reminder for a year from now and Europe switches to UTC+2 all year >round, you >> don’t want your reminder to fire at the wrong hour. > >Fair point, but I believe the timezone is unnecessary and hence >contributes to protocol bloat and potentially causes confusion. Clients >could just set the right future timestamp taking the timezone into >account. A note about this in the XEP sure would be sensible. No, because the timezone definitions may (and they often enough do, look at the tzdata version history) change between when the client sets the reminder and the reminder fires. Hence my example about EU deciding to abolish DST. > >- Florian >___ >Standards mailing list >Info: https://mail.jabber.org/mailman/listinfo/standards >Unsubscribe: standards-unsubscr...@xmpp.org >___ -- Sent from my mobile device. Please excuse my brevity. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Reminders
On 3/2/20 5:18 PM, Jonas Schäfer wrote: > On Montag, 2. März 2020 11:56:58 CET Marcos wrote: >> thanks for your comments, Florian. >> Florian Schmaus writes: >>> I think creating/canelling a reminder should rather be an ad-hoc command >>> and not an IQ. This way, clients do not need to implement another IQ >>> protocol-flow, but can re-use their (potentially) existing ad-hoc >>> infrastructure. >> >> This probably escapes from my current understandings of the protocol, so >> thanks for pointing it out and I'll try to have a read over IQ handling >> logic, specially at client side (an issue Andrew already exposed). > > Ad-Hoc commands would definitely be a way to do this. Using a specified > command name (like XEP-0401 does) would allow for automated entities to > interact with this and also gives immediate basic client support for clients > which already support Ad-Hoc commands. > > For clients which do not, and which also do not support Data Forms at all, > this will be more of a pain to implement even without offering extensive user > interaction. I doubt that it will be much pain, and even if, I would consider implementing data forms and ad-hoc commands are worth the pain. > This is always a trade-off, and I’ve stated elsewhere that I consider data > forms a bad thing to have due to their lack of supporting arbitrary > structured > and dynamic data. I don't think I agree with that. They are flexible enough to serve a large portion of data-exchange use-cases. I am also not sure why they shouldn't support dynamic data. > And this specification needs timestamps, which are a kind of structured data. Right. I would suggest to use xep122 "data forms validation" to provide a client with the hint that this form field is a xep82 data time format. Clients could use this to show a data/time picker UI when this form field is selected. > For a naive Ad-Hoc client, specifying the timestamp in XEP-0082 format will > be > massively annoying for the user. Agreed, especially if no xep112 hint (cf. xep112 example 2) is used. But still better than a naive client not being able to participate at all IMHO. Not sure how massive the annoyance for the user would be, though. Guess it depends on the user. > For a client which adds specific support for > this ProtoXEP, the cost of doing so is likely less high than adding a custom > IQ support Correct: For a client (library) already supporting data forms, implementing an ad-hoc/data-form based protocol is far easier then implementing a pure IQ based protocol. >>> Also § 5.2 / Example 7 "Server sends a reminder" should include just a >>> , and not invent another -like extension element (). >> >> Makes sense. >> >>> The 'timezone' attribute in is not necessary, xep82 data-time >>> profiles already encode the timezone (the 'Z' at the end of the String). >> >> Indeed, this slipped in from an early write up where no reference to >> XEP-0082 was yet present. It has been already amended. > > Actually, timezones is a good keyword.For timestamps in the future, it is > generally better to use localtime+timezone specifier instead of a UTC > timestamp. After all, if you are in the Europe/Berlin timezone and set a > reminder for a year from now and Europe switches to UTC+2 all year round, you > don’t want your reminder to fire at the wrong hour. Fair point, but I believe the timezone is unnecessary and hence contributes to protocol bloat and potentially causes confusion. Clients could just set the right future timestamp taking the timezone into account. A note about this in the XEP sure would be sensible. - Florian ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
