Abstract: | This document defines a way to include hints to entities routing or receiving a message. |
Author: | Matthew Wild |
Copyright: | © 1999 - 2015 XMPP Standards Foundation. SEE LEGAL NOTICES. |
Status: | Experimental |
Type: | Standards Track |
Version: | 0.1 |
Last Updated: | 2013-07-11 |
WARNING: This Standards-Track document is Experimental. Publication as an XMPP Extension Protocol does not imply approval of this proposal by the XMPP Standards Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems are advised to carefully consider whether it is appropriate to deploy implementations of this protocol before it advances to a status of Draft.
1. Introduction
2. Requirements
3. Use Cases
3.1. Session-based stanzas
3.2. Notifications
3.3. Sensitive messages
4. Hints
4.1. No permanent storage
4.2. No storage
4.3. No copies
5. Business Rules
6. Security Considerations
7. IANA Considerations
8. XMPP Registrar Considerations
9. XML Schema
Appendices
A: Document Information
B: Author Information
C: Legal Notices
D: Relation to XMPP
E: Discussion Venue
F: Requirements Conformance
G: Notes
H: Revision History
Message types ('normal', 'chat', 'headline', etc.) provide an existing framework for determining how an entity should deliver or handle a message. For example XMPP IM [1] 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 Advanced Message Processing (XEP-0079) [2] for applications that need it.
This specification aims to solve the following common problems, and allow a sender to hint to the recipient:
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 Message Carbons (XEP-0280) [3] 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:
<message from='romeo@montague.lit/laptop' to='juliet@capulet.lit/laptop'> <body>V unir avtug'f pybnx gb uvqr zr sebz gurve fvtug</body> <no-copy xmlns="urn:xmpp:hints"/> <no-store xmlns="urn:xmpp:hints"/> </message>
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 Message Archiving (XEP-0136) [4] and Message Archive Management (XEP-0313) [5]) 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 Message Carbons (XEP-0280) [6].
This hint MUST only be included on messages addressed to full JIDs and explicitly does not override the behaviour defined in XMPP IM [7] for handling messages to bare JIDs, which may involve copying to multiple resources, or multiple occupants in a Multi-User Chat (XEP-0045) [8] 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 the Internet Assigned Numbers Authority (IANA) [9].
This document requires no interaction with XMPP Registrar [10].
<?xml version='1.0' encoding='UTF-8'?> <xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema' targetNamespace='urn:xmpp:hints' xmlns='urn:xmpp:hints' elementFormDefault='qualified'> <xs:element name='no-permanent-store' type='empty'/> <xs:element name='no-store' type='empty'/> <xs:element name='no-copy' type='empty'/> <xs:simpleType name='empty'> <xs:restriction base='xs:string'> <xs:enumeration value=''/> </xs:restriction> </xs:simpleType> </xs:schema>
Series: XEP
Number: 0334
Publisher: XMPP Standards Foundation
Status:
Experimental
Type:
Standards Track
Version: 0.1
Last Updated: 2013-07-11
Approving Body: XMPP Council
Dependencies: XMPP Core
Supersedes: None
Superseded By: None
Short Name: NOT_YET_ASSIGNED
Source Control:
HTML
This document in other formats:
XML
PDF
Email:
mwild1@gmail.com
JabberID:
me@matthewwild.co.uk
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.
The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.
Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.
Errata can be sent to <editor@xmpp.org>.
The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".
1. RFC 6121: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://tools.ietf.org/html/rfc6121>.
2. XEP-0079: Advanced Message Processing <http://xmpp.org/extensions/xep-0079.html>.
3. XEP-0280: Message Carbons <http://xmpp.org/extensions/xep-0280.html>.
4. XEP-0136: Message Archiving <http://xmpp.org/extensions/xep-0136.html>.
5. XEP-0313: Message Archive Management <http://xmpp.org/extensions/xep-0313.html>.
6. XEP-0280: Message Carbons <http://xmpp.org/extensions/xep-0280.html>.
7. RFC 6121: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://tools.ietf.org/html/rfc6121>.
8. XEP-0045: Multi-User Chat <http://xmpp.org/extensions/xep-0045.html>.
9. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.
10. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <http://xmpp.org/registrar/>.
Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/
Initial published version approved by the XMPP Council.
(psa)First draft.
(mw)END