# HG changeset patch # User souliane # Date 1452964041 -3600 # Node ID d944c37c36fe5a7374683ae71269b4011d09fbf9 # Parent 8807a553e5bf7bc204b782bb1aa9d17f531e75b2 xmpp (xep-proto-jid-mention): typos fixes diff -r 8807a553e5bf -r d944c37c36fe xmpp/xep-proto-jid-mention.xml --- a/xmpp/xep-proto-jid-mention.xml Sat Jan 16 17:43:54 2016 +0100 +++ b/xmpp/xep-proto-jid-mention.xml Sat Jan 16 18:07:21 2016 +0100 @@ -36,11 +36,11 @@ -

Usually mentioning somebody is done in the context of a multi-user chat: a notification is triggered when somebody's nickname is written, and it often only works when a client is online and monitoring the conversation.

But it is more and more common to mention people in other contexts (e.g. microblogging), and it is desirable that this works even when an entity is offline or not aware of the context. This XEP offer a simple solution to mention people in any context, online or offline and even outside of XMPP

Mentioning somebody is usually done in the context of a multi-user chat: a notification is triggered when somebody's nickname is written, and it often only works when a client is online and monitoring the conversation.

But it is more and more common to mention people in other contexts (e.g. microblogging), and it is desirable that this works even when an entity is offline or not aware of the context. This XEP offers a simple solution to mention people in any context, online or offline and even outside of XMPP.

JID mention must

JID mention must:

work online and offline
work if the entity is not aware of the context

Mentioning entity — the entity which want to mention somebody.
Mentioning entity — the entity which wants to mention somebody.
Mentioned entity — the entity actually mentioned.
Mentioned URI — URI where the entity is mentioned.
PubSub — &xep0060;.

The syntax used by the software willing to mention a jid is up to the implemention. Nickname followed by ":" is commonly used in group chats like MUC or Internet Relay Chat (IRC) while "@" followed by nickname is often used with microblogging. Note that if it is not possible to associate a nickname with a jid without ambiguity, a bare jid SHOULD be used instead of a nickname.

To mention an entity, a &MESSAGE; stanza must be sent to the bare jid of the entity with a <mention/> elements which MUST have the 'urn:xmpp:mention:0' namespace. The <mention/> element MUST have a 'uri' attribute which link to the context where the entity has been mentioned. This URI can be the URI of a MUC room, a PubSub node, a Jingle file (e.g. a photo where mentioned entity appears), a website, or anything which make sense. A <body/> element MUST be present with a human readable text indicating the mentioned URI (e.g. “You have been mentioned on xmpp:xsf@muc.xmpp.org?join”). No other elements or attributes are mandatory.

To mention an entity, a &MESSAGE; stanza must be sent to the bare jid of the entity with a <mention/> elements which MUST have the 'urn:xmpp:mention:0' namespace. The <mention/> element MUST have a 'uri' attribute which links to the context where the entity has been mentioned. This URI can be the URI of a MUC room, a PubSub node, a Jingle file (e.g. a photo where mentioned entity appears), a website, or anything which makes sense. A <body/> element MUST be present with a human readable text indicating the mentioned URI (e.g. “You have been mentioned on xmpp:xsf@muc.xmpp.org?join”). No other elements or attributes are mandatory.

@@ -74,8 +74,8 @@ ]]>

Sometime the 'uri' refers to an element which is a child of other one(s). For instance, a mentioned URI may refers to a website comment with a direct link, which is a part of a more general conversation, or PubSub URI refers to a microblog comment which is a child of an other comment, itself a child of the main item.

In this case, it is desirable for the mentioned entity to know where is the main item, so it can understand the whole context. To deal with this, the mentioning entity MAY add a <parents/> element which MUST contain one or more <parent/> elements. Each <parent/> element MUST contain an 'uri' attribute with the URI of the parent. If more than one parents are specified, they MUST be put in order, from the more distant one to the last child before the one specified in the main <mention/> element.

Sometime the 'uri' refers to an element which is a child of other one(s). For instance, a mentioned URI may refer to a website comment with a direct link, which is a part of a more general conversation, or PubSub URI refers to a microblog comment which is a child of another comment, itself a child of the main item.

In this case, it is desirable for the mentioned entity to know where is the main item, so it can understand the whole context. To deal with this, the mentioning entity MAY add a <parents/> element which MUST contain one or more <parent/> elements. Each <parent/> element MUST contain an 'uri' attribute with the URI of the parent. If more than one parents are specified, they MUST be put in order, from the more distant one to the last child just before the one specified in the main <mention/> element.

@@ -90,7 +90,7 @@ ]]>

To help the mentioned entity understand the context, the mentioning entity MAY add a <context> element which include human readable text. What is inside is at the discretion of the mentioning entity, it MAY be the paragraph where the mentioning entity is mentioned, or anything useful.

@@ -108,7 +108,7 @@ ]]>

If the mention is done outside of XMPP context (e.g.: on a website), the 'from' attribute of the message may be the jid of a server component or a bot. In this case, the mentioning entity can give informations on the real author of the mention.

The author of the mention MAY be specified in <author/> element. If present, it MUST contain one or more of the following elements:

JID — the user jid, in a <jid/> element

In some contexts, an URI may be not sufficient to locate the exact place of the mention. For instance, it may be be useful to know the exact message of a MUC room where the mention did take place. If a mentioning entity want to specify the exact part of the location where the mention happened, it MAY use a <part/> element. This element contains informations dependant of the mentioned URI. For now, only stanza-id is used, but later versions of this specification, or other XEPs can add new elements.

In some contexts, an URI may not be sufficient to locate the exact place of the mention. For instance, it may be useful to know the exact message of a MUC room where the mention did take place. If a mentioning entity wants to specify the exact part of the location where the mention happened, it MAY use a <part/> element. This element contains information dependent on the mentioned URI. For now, only stanza-id is used, but later versions of this specification, or other XEPs can add new elements.

If the mentioned URI refers to an XMPP context (e.g. a MUC room), a stanza id can be specified. To do so, the &xep0359; semantic is used: mentioning entity MAY add a <stanza-id/> element to the <part/> element as specified in XEP-0359.

@@ -157,7 +157,7 @@ -

a server MAY provide a way for clients to configure their notifications (e.g. send by email instead of XMPP, accept mentions only from entities in the roster). To do so, the &xep0050; is used on the well-defined command node 'urn:xmpp:mention:0#configure'.

A server MAY provide a way for clients to configure their notifications (e.g. send by email instead of XMPP, accept mentions only from entities in the roster). To do so, the &xep0050; is used on the well-defined command node 'urn:xmpp:mention:0#configure'.

@@ -186,7 +186,7 @@ ]]>

A server doesn't have to announce JID mention namespace as it is a client feature, but if it offers a configuration node as specified in configuration section, it MUST announce this fact by including a service discovery feature of "urn:xmpp:mention:0#configure".

A server doesn't have to announce JID mention namespace as it is a client feature, but if it offers a configuration node as specified in the configuration section, it MUST announce this fact by including a service discovery feature of "urn:xmpp:mention:0#configure".

To avoid spamming (e.g. a mention of an entity redirecting to an advertisement), a server SHOULD allow a mentioned entity to black list mentioning entities, or to accept mentions only for some entities (e.g. entities in roster). See the configuration section to see how to set it up. A client MAY offer the same kind of feature, but filtering is preferably done on server side to avoid useless traffic.
To avoid spamming (e.g. a mention of an entity redirecting to an advertisement), a server SHOULD allow a mentioned entity to black list mentioning entities, or to accept mentions only from some entities (e.g. entities in roster). See the configuration section to see how to set it up. A client MAY offer the same kind of feature, but filtering is preferably done on server side to avoid useless traffic.
As a mention can link to malicious content, or a user may not want to join a context (and show its presence at the same time), a client SHOULD NOT open automatically the mentioned URI. Instead it SHOULD show a notification to the user, with context hint when available, and propose to join the context or not.
When an author is specified as explained in mention author section, the elements, notably the <jid> element, are not checked. A malicious mentioning entity could use fake author information to fool mentioned entity. To avoid this, the mentioned entity's client SHOULD display a warning, like an icon or a message, to indicate that the author can't be checked.