LAST CALL: XEP-0333 (Displayed Markers (was: Chat Markers))
This message constitutes notice of a Last Call for comments on XEP-0333. Title: Displayed Markers (was: Chat Markers) Abstract: This specification introduces a method to let the sender, or multiple participants in a group chat, know that a client has displayed messages up to a certain point. URL: https://xmpp.org/extensions/xep-0333.html This Last Call begins today and shall end at the close of business on 2024-04-08. Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? 2. Does the specification solve the problem stated in the introduction and requirements? 3. Do you plan to implement this specification in your code? If not, why not? 4. Do you have any security concerns related to this specification? 5. Is the specification accurate and clearly written? Your feedback is appreciated!
I very much think we should stop the trend of adding other comments in the title. This is better than a funny joke, but it's still something that's going to show up in citations. Let's just stick "note that this was previously known as Chat Markers" in the introduction somewhere and call it good. Otherwise, this spec is useful and widely implemented, so let's go for it. —Sam On 3/25/24 15:16, Daniel Gultsch wrote:
This message constitutes notice of a Last Call for comments on XEP-0333.
Title: Displayed Markers (was: Chat Markers) Abstract: This specification introduces a method to let the sender, or multiple participants in a group chat, know that a client has displayed messages up to a certain point.
URL: https://xmpp.org/extensions/xep-0333.html
This Last Call begins today and shall end at the close of business on 2024-04-08.
Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list:
1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
2. Does the specification solve the problem stated in the introduction and requirements?
3. Do you plan to implement this specification in your code? If not, why not?
4. Do you have any security concerns related to this specification?
5. Is the specification accurate and clearly written?
Your feedback is appreciated! _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
-- Sam Whited sam@samwhited.com
We use Chat Markers extensively. For what it's worth, I think that it was a bad idea to remove <received/> to not replicate XEP-0184, because reading one spec is better for developers than reading two, and I'd rather revert changes back to 0.4 and deprecated 0184 instead. Also, Displayed Markers (was: Chat Markers) is rather unfortunate name. I understand the desire to share some infamy <https://twitter.com/tomgara/status/1587640766696140800> with Google and their app naming practices, but protocol names should better be closer to the point. On Tue, 26 Mar 2024 at 16:12, Sam Whited <sam@samwhited.com> wrote:
I very much think we should stop the trend of adding other comments in the title. This is better than a funny joke, but it's still something that's going to show up in citations. Let's just stick "note that this was previously known as Chat Markers" in the introduction somewhere and call it good.
Otherwise, this spec is useful and widely implemented, so let's go for it.
—Sam
On 3/25/24 15:16, Daniel Gultsch wrote:
This message constitutes notice of a Last Call for comments on XEP-0333.
Title: Displayed Markers (was: Chat Markers) Abstract: This specification introduces a method to let the sender, or multiple participants in a group chat, know that a client has displayed messages up to a certain point.
URL: https://xmpp.org/extensions/xep-0333.html
This Last Call begins today and shall end at the close of business on 2024-04-08.
Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list:
1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
2. Does the specification solve the problem stated in the introduction and requirements?
3. Do you plan to implement this specification in your code? If not, why not?
4. Do you have any security concerns related to this specification?
5. Is the specification accurate and clearly written?
Your feedback is appreciated! _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
-- Sam Whited sam@samwhited.com _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Hi Sam and Andrew, I agree on the name. I felt like it was important that for the first major update after 7 years and for the last call notification people know what XEP we are talking about. However I will change the name either on the move to stable or on the next update (which ever happens first) On Tue, Mar 26, 2024 at 12:53 PM Andrew Nenakhov <andrew.nenakhov@redsolution.com> wrote:
For what it's worth, I think that it was a bad idea to remove <received/> to not replicate XEP-0184, because reading one spec is better for developers than reading two, and I'd rather revert changes back to 0.4 and deprecated 0184 instead.
The XEP has a section that explains why 184 was kept. It's not just a different XEP it's a different semantic that many people prefer. cheers Daniel
participants (3)
-
Andrew Nenakhov -
Daniel Gultsch -
Sam Whited