Message Processing Hints

%ents; ]>

Message Processing Hints This document defines a way to include hints to entities routing or receiving a message. &LEGALNOTICE; 0334 Deferred 2017-03-01 2017-02-22 Standards Track Standards Council XMPP Core hints &mwild; 0.3.0 2018-01-25 XEP Editor (jwi) Defer due to lack of activity. 0.2 2015-09-01 dg

Fixed the wrong use of no-storage instead of no-store

Added a message hint <store/>

0.1 2013-07-11 psa

Initial published version approved by the XMPP Council.

0.0.1 2013-06-18 mw

First draft.

Message types ('normal', 'chat', 'headline', etc.) provide an existing framework for determining how an entity should deliver or handle a message. For example &xmppim; defines that messages of type 'headline' should not be stored offline by the server, and that messages of type 'groupchat' must not be directed to other resources.

However this framework of rules is quite inflexible, and new extensions are being developed that push at the boundaries of what is capable of. This specification defines a more flexible approach that allows the sender to add finer-grained 'hints' to messages, which can be used as a generic mechanism for XMPP entities to handle messages.

A similar but much more extensive framework is defined in &xep0079; for applications that need it.

This specification aims to solve the following common problems, and allow a sender to hint to the recipient:

Whether to store a message (e.g. for archival or as an 'offline message').
Whether to copy a message to other resources.
Whether to store a message that would not have been stored under normal conditions

Suppose that Romeo and Juliet are avoiding the surveillance of Prince Escalus and communicating using a session-based encryption protocol between their laptops. In order to prevent Juliet's tablet computer that uses &xep0280; from receiving copies of the encrypted messages (and not being able to decrypt them), Romeo inserts the <no-copy/> hint into the messages he sends. Since it is also useless for these messages to be archived, he additionally adds the <no-store/> hint:

V unir avtug'f pybnx gb uvqr zr sebz gurve fvtug

]]>

Some automated notifications may be transient, and there would be no purpose in delaying their delivery. Such messages may be marked with the <no-store/> hint.

A sender may want to indicate their preference to have no permanent record of a message (also known as "off the record" messages), but may be happy for it to be stored temporarily as a normal part of delivery (e.g. if the recipient is offline at the time of sending). Such a message can be marked with the <no-permanent-store/> hint.

Offline storage and &xep0313; can define their own rules on what messages to store and usually only store messages that contain a body element. However a sender may want to indicate that a message is worth storing even though it might not match those rules (e.g. an encrypted message that carries the payload outside the body element). Such a message can be marked with a <store/> hint.

The <no-permanent-store/> hint informs entities that they shouldn't store the message in any permanent or semi-permanent public or private archive (such as described in &xep0136; and &xep0313;) or in logs (such as chatroom logs).

A message containing a <no-store/> hint should not be stored by a server either permanently (as above) or temporarily, e.g. for later delivery to an offline client, or to users not currently present in a chatroom.

Messages with the <no-copy/> hint should not be copied to addresses other than the one to which it is addressed, for example through &xep0280;.

This hint MUST only be included on messages addressed to full JIDs and explicitly does not override the behaviour defined in &xmppim; for handling messages to bare JIDs, which may involve copying to multiple resources, or multiple occupants in a &xep0045; room.

A message containing the <store/> hint that is not of type 'error' SHOULD be stored by the entity.

It is important to note that message hints are, as the name implies, just hints. Implementations MUST NOT rely on other entities interpretation of the hints for any particular purpose.

This specification introduces no known security considerations.

This document requires no interaction with &IANA;.

This document requires no interaction with ®ISTRAR;.

]]>