From 6eed8f92f697afaa79c183a150a4303d39d30255 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Wed, 19 Jun 2013 20:21:11 -0600 Subject: [PATCH] 0.0.1 --- inbox/message-processing-hints.xml | 129 +++++++++++++++++++++++++++++ 1 file changed, 129 insertions(+) create mode 100644 inbox/message-processing-hints.xml diff --git a/inbox/message-processing-hints.xml b/inbox/message-processing-hints.xml new file mode 100644 index 00000000..ffc25d91 --- /dev/null +++ b/inbox/message-processing-hints.xml @@ -0,0 +1,129 @@ + + +%ents; +]> + + +
+ Message Processing Hints + This document defines a way to include hints to entities routing or receiving a message. + &LEGALNOTICE; + xxxx + ProtoXEP + Standards Track + Standards + Council + + XMPP Core + + + + NOT_YET_ASSIGNED + &mwild; + + 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.
    • +
+ + + +

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. +

+ + + + +

The <no-permanent-storage/> 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-storage/> 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. +

+ + + +

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;.

+ + + + + + + + + + + + + + + + + + ]]> + +