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: [email protected]
_______________________________________________
