Re: [Standards] LAST CALL: XEP-0333 (Chat Markers)
On Sat, Jan 28, 2017 at 11:25 AM, XMPP Extensions Editor wrote: > This message constitutes notice of a Last Call for comments on XEP-0333 (Chat > Markers). Daniel has taken over maintaining the XEP and the last call has expired without a vote. At his request I've moved it back to experimental while he makes some changes; a new last call may be issued after the changes are complete and feedback is incorporated. Thanks for all your feedback! —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0333 (Chat Markers)
On Wed, Feb 15, 2017 at 6:45 PM, Sam Whited wrote: > I have reached out to the author to give them a chance to address > feedback, and to find out if they are still interested in maintaining > this XEP. > To give them time to respond, the LC has been extended until 2017-02-22. I spoke with the original author and they indicated that they would like me to find a steward for this document. Daniel Gultsch volunteered, and control of XEP-0333 has been passed on to him. To allow for him to make changes, and to allow for more feedback, the LC has been extended again to 2017-03-01. Best, Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0333 (Chat Markers)
On Sat, Jan 28, 2017 at 11:25 AM, XMPP Extensions Editor wrote: > This Last Call begins today and shall end at the close of business on > 2017-02-11. I have reached out to the author to give them a chance to address feedback, and to find out if they are still interested in maintaining this XEP. To give them time to respond, the LC has been extended until 2017-02-22. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0333 (Chat Markers)
Hi,
> 1. Is this specification needed to fill gaps in the XMPP protocol stack or to
> clarify an existing protocol?
Yes.
> 2. Does the specification solve the problem stated in the introduction and
> requirements?
Yes.
> 3. Do you plan to implement this specification in your code? If not, why not?
Yes.
> 4. Do you have any security concerns related to this specification?
No.
> 5. Is the specification accurate and clearly written?
There are some sentences and terms which feel weird, e.g. "mark a markable
message".
It's not immediately clear, that the requester sends only "markable" messages,
while the receiver sends only "displayed", "acknowledged" or "received"
messages.
References to the thread Id could be ommited, because it's out of scope (it's
XEP-0201) and distracts the reader with too much information. Similarly the
note, that the server may add further extension like Delayed Delivery.
"Messages MUST include the 'markable' element to use Chat Markers."
better =>
"Messages MUST include the 'markable' element to request Chat Markers."
"Less/more Significant Chat Markers" is unclear.
"Chat Markers MUST only move forward." is unclear.
"If a Chat Maker is received for an earlier message than the current Chat
Marker, it MUST be ignored by the client."
typo ("Maker")
Why should chat markers for earlier messages be ignored? The user could simply
read earlier (sent) messages later or not all, e.g. if the client only displays
the latest X messages. Would actually unread/undisplayed messages be assumed to
be read by the sender, if a newer chat marker is received, although in reality
they were never displayed?
-- Christian
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
Re: [Standards] LAST CALL: XEP-0333 (Chat Markers)
> On 28 Jan 2017, at 17:25, XMPP Extensions Editor wrote: > > This message constitutes notice of a Last Call for comments on XEP-0333 (Chat > Markers). > > Abstract: This specification describes a solution of marking the last > received, displayed and acknowledged message in a chat. > > URL: http://xmpp.org/extensions/xep-0333.html > > This Last Call begins today and shall end at the close of business on > 2017-02-11. > > 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? Yes, although the 184 duplication needs to be sorted. > 2. Does the specification solve the problem stated in the introduction and > requirements? Not as-is, although it’s getting there. See feedback in (5). > 3. Do you plan to implement this specification in your code? If not, why not? Maybe once it’s tidied up, but not as-is. > 4. Do you have any security concerns related to this specification? Maybe. I’m not sure that the thread marking can’t be used to do odd things if a client believes it instead of correlating to the original messages. > 5. Is the specification accurate and clearly written? Some issues and comments: 5.1. Sending a markable without knowing if it’s supported seems fine. Surely a marker should only be sent in response to a markable? 5.2. Given carbons, archives, offline messaging, etc., I think sending markable to resources that don’t support it is probably sensible 6. displayed and acknowledged seem like sensible additions. ‘received’ seems to be duplicating 184 in a lossy way. It should probably decide if it wants to replace 184 or not. 6. I’m not sure that it’s sensible to use the message id for this (see issues around 184, 308), and might be better off putting an id in the markable element. 6. I don’t understand why the thread is needed - if it’s tied to a message, doesn’t that already imply that it’s within a thread (or not) based on the source message? 6. marking ‘up to’. This might make sense for displayed (which can be correlated back to delivered), but doesn’t for delivered (as stanzas can be lost from the middle of the stream, and showing delivery confirmation for lost stanzas is probably worse than not showing delivery confirmation at all), and certainly not for an explicit acknowledgement of a message. 6. 'If recipient does not support the Chat Markers protocol it SHOULD NOT return an error.’ probably makes sense to reword, as this isn’t a new requirement, it’s consistent with all other handling of unknown payloads in messages in XMPP. 6. 'When the recipient sends a Chat Marker, it SHOULD ensure that the message stanza contains only the Chat Marker child element and optionally (when appropriate) a thread child element.’ I’m not convinced about this - I don’t see what’s harmful about having other payloads, especially as the following sentence says that recipients will be receiving multiple elements anyway. 7. 'Clients SHOULD use Message Carbons (XEP-0280) [6] to support multiple online resources.’. Carbons are a good idea, but I’m not sure why they’re needed for 333 more than anything else. 7. There’s a subtle hidden server requirement here, in what looks like a client-only XEP. I think this needs calling out. 7. "Chat Markers MUST only move forward.” I understand what this is trying to say, but I don’t think it’s this. Markers might be received (as it says immediately after) that ‘move backwards’, I think this is a comment on the ordering a client may send markers, and needs tightening up. What do ‘earlier’ and ‘moving forward’ mean when stanzas aren’t timestamped and may be delivered out of order (if coming from multiple endpoints). 7. "Chat Markers for unknown messages MUST be ignored by the client. A client MAY store the Chat Marker” I think storing it is immediately not ignoring it, so likely the MUST needs more care here. It’s also not clear to me in what situation this out-of-order delivery could happen in XMPP, so giving an example would probably be helpful. 8.1 'Less Significant Chat Markers…’ I think the term ‘significant’ is only used in this one sentence, without reference to what it’s meant to mean in this context. Again, I think ‘later’ might do with some tightening up here - it mentions only doing stuff if the messages’ timestamps are later, but most messages won’t have a timestamp on them. 8.1 'To avoid sending redundant Chat Markers while retrieving archived messages…’ I think I understand what this is trying to say, and why, but it needs tightening up as it’s not clear. 8.3 'Clients MAY mark a sent or received message’. Why would you want to tell a contact’s client that you have read a message that you (not they) have sent? (I think the answer is ‘you wouldn’t’, which makes the purpose of this section unclear. 8.4 Interaction with
Re: [Standards] LAST CALL: XEP-0333 (Chat Markers)
On 29 January 2017 at 04:25, XMPP Extensions Editor wrote: > This message constitutes notice of a Last Call for comments on XEP-0333 (Chat > Markers). > > Abstract: This specification describes a solution of marking the last > received, displayed and acknowledged message in a chat. > > URL: http://xmpp.org/extensions/xep-0333.html > > This Last Call begins today and shall end at the close of business on > 2017-02-11. > > 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? Yes > 2. Does the specification solve the problem stated in the introduction and > requirements? Yes > 3. Do you plan to implement this specification in your code? If not, why not? No support required outside of clients. > 4. Do you have any security concerns related to this specification? No > 5. Is the specification accurate and clearly written? Yes > > Your feedback is appreciated! ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
