> On 28 Jan 2017, at 17:25, XMPP Extensions Editor <edi...@xmpp.org> 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 Delivery Receipts - As noted earlier, I think this needs much more thought. 9. Probably needs a statement here about dealing with markers with unexpected content (unknown ids, etc.) too. /K _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
