145
edits
Difference between revisions of "XMPP 2.0"
Jump to navigation
Jump to search
→Migration path in a hypothetical XMPP 2.0 Session
m (→Proposed change: IQs) |
|||
| Line 41: | Line 41: | ||
Rules for stanzas entering the XMPP 2.0 realm (from an XMPP 1.0 node): | Rules for stanzas entering the XMPP 2.0 realm (from an XMPP 1.0 node): | ||
* | * A stanza with a <code><xmpp-2/></code> tag MUST be processed as if it came from an XMPP 2.0 node. Any XMPP 1.0 Routing Modifiers MUST be stripped. | ||
* | * A message to a ''bare JID'' must be delivered to all online clients (this is allowed by RFC 6120 already). | ||
* A message to a ''full JID'' with <code><private/></code> or <code><no-copy/></code> is delivered to the targeted full JID (this matches current Carbons behavior). | |||
* For a message to a ''full JID'' with no XMPP 1.0 Routing Modifier, a set of rules similar to Carbon copying needs to be applied, to determine if the message must be rerouted to the bare JID: | |||
** type=normal - needs to detect body presence / special use cases | |||
** type=chat - reroute to bare JID, deliver to all clients (alternatively: deliver Carbons); store in archive | |||
** type=groupchat - treat as ''transient'', deliver to single resource | |||
** type=headline - treat as ''transient'', deliver to single resource | |||
* The stanza MUST be marked with a to-be-defined <code><xmpp-1/></code> tag so that XMPP 2.0 nodes further downstream can recognize that the XMPP 1.0 routing semantics shall apply. | * The stanza MUST be marked with a to-be-defined <code><xmpp-1/></code> tag so that XMPP 2.0 nodes further downstream can recognize that the XMPP 1.0 routing semantics shall apply. | ||