[Standards] XEP-184: Message Delivery Receipts - Message Type of Ack Messages
georg at op-co.de
Mon Apr 13 16:00:35 UTC 2015
* Joe Hildebrand (jhildebr) <jhildebr at cisco.com> [2015-04-13 17:39]:
> Headline also has the nice property that servers doing offline SHOULD
> NOT hold on to headlines; that seems to fit the intent here. Probably
> needs some testing in the real world.
I see value in offline storing of ACKs, as it provides (visual) feedback
to the original sender that their message reached the destination and
does not need to be repeated/resent.
While we are at it, I also see value in caron-copying ACKs, as it allows
the mobile client to see if a message from your desktop reached the
destination (yaxim actually parses and displays that in the UI).
> >"The message is a standalone message that is sent outside the context
> >of a one-to-one conversation or groupchat, and to which it is
> >expected that the recipient will reply“
> >(And no reply is expected to receipt messages)
While this is true, I think that the whole "Type Attribute" section of
the RFC fails to accommodate software-to-software messages. The CSN XEP
explicitly writes that the type SHOULD be 'chat' or 'groupchat', but
they are *chat* state notifications after all.
I'm inclined to use the 'normal' type because ACKs do not fall into any
of the described categories, and because of the implication that
'headline' messages might not be stored on servers.
|| http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++
|| gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ ||
|| Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y? ||
++ IRCnet OFTC OPN ||_________________________________________________||
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 811 bytes
Desc: Digital signature
More information about the Standards