# HG changeset patch # User Goffi # Date 1452962634 -3600 # Node ID 8807a553e5bf7bc204b782bb1aa9d17f531e75b2 # Parent d8d98e13aae92a04e77959fb25e0031f953e3045 xep (jid mention): fixed mention author diff -r d8d98e13aae9 -r 8807a553e5bf xmpp/xep-jid-mention.xml --- a/xmpp/xep-jid-mention.xml Sat Jan 16 17:28:23 2016 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,274 +0,0 @@ - - -%ents; -]> - - -
- JID Mention - This specification provides a way for an entity to mention a jid - &LEGALNOTICE; - xxxx - ProtoXEP - Standards Track - Standards - Council - - XMPP Core - - - - NOT_YET_ASSIGNED - - Jérôme - Poisson - goffi@goffi.org - goffi@jabber.fr - - - - 0.1 - 2016-01-16 - jp -

First draft.

 - - -
- -

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

- - -

JID mention must

-
    -
  • work online and offline
    • -
  • work if the entity is not aware of the context
    • -
  • work outside of XMPP context (e.g. in a website)
    • -
  • not be tied to a particular syntax
    • -
  • (desirable) be easy to implement
    • -
- - -
    -
  • Mentioning entity — the entity which want to mention somebody.
    • -
  • Mentioned entity — the entity actually mentioned.
    • -
  • Mentioned URI — URI where the entity is mentioned.
    • -
  • PubSub — &xep0060;.
    • -
  • MUC — &xep0045;.
    • -
  • MIX — &xep0369;.
    • -
- - - - -

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.

- - - - You have been mentioned on xmpp:balcony@chat.shakespeare.lit?join - - -]]> - - -

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.

- - - - - - - - You have been mentioned on xmpp:pubsub.montague.lit?;node=urn%3Axmpp%3Amicroblog%3A0%3Acomments%2Fdd88c9bc58886fce0049ed050df0c5f2 - - -]]> - - -

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.

- - - - O Romeo, Romeo! wherefore art thou Romeo? - Deny thy father and refuse thy name! - Or, if thou wilt not, be but sworn my love, - And I'll no longer be a Capulet. - - - - You have been mentioned on xmpp:balcony@chat.shakespeare.lit?join - - -]]> - - -

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 <by> element. If present, it MUST contain one or more of the following elements:

-
    -
  • JID — the user jid, in a <jid> element
    • -
  • email — the user email address, in a <email> element
    • -
  • Full Name — the user full name, in a <name> element
    • -
  • Nickname — the user nickname, in a <nick> element
    • -
- - - - Lord Capulet - capulet@capulet.lit - - - - You have been mentioned on xmpp:balcony@chat.shakespeare.lit?join - - - ]]> - - -

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.

-

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.

- - - - O Romeo, Romeo! wherefore art thou Romeo? - Deny thy father and refuse thy name! - Or, if thou wilt not, be but sworn my love, - And I'll no longer be a Capulet. - - - - - - - You have been mentioned on xmpp:balcony@chat.shakespeare.lit?join - - -]]> - - - - -

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

- - - - - -

If a entity supports the JID mention protocol, it MUST report that fact by including a service discovery feature of "urn:xmpp:mention:0" in response to a &xep0030; information request:

- - - - ]]> - - - ... - - ... - - - ]]> - - -

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

- - - - -
    -
  1. In the case of group chat like MUC or MIX, most of clients already monitor conversations and notify the user if he is mentioned. To avoid to deal with double notifications, the mentioning entity SHOULD NOT mention an other entity using this XEP if the mentioned entity is online and following the conversation (i.e. it joined the MUC room or it subscribed to the MIX conversation).
    2. -
  2. On the other hand, if the mentioned entity is not following the conversation (i.e. it didn't joined the MUC room, or it didn't subscribed to the MIX conversation), the mentioning entity SHOULD use this XEP for the mention.
    3. -
- - -
    -
  1. 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.
    2. -
  2. 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.
    3. -
  3. 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.
    4. -
- - -

This document requires no interaction with &IANA;.

- - - -

The ®ISTRAR; includes 'urn:xmpp:mention:0' in its registry of protocol namespaces (see &NAMESPACES;).

-
    -
  • urn:xmpp:mention:0
    • -
- - - &NSVER; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ]]> - - diff -r d8d98e13aae9 -r 8807a553e5bf xmpp/xep-proto-jid-mention.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/xmpp/xep-proto-jid-mention.xml Sat Jan 16 17:43:54 2016 +0100 @@ -0,0 +1,274 @@ + + +%ents; +]> + + +
+ JID Mention + This specification provides a way for an entity to mention a jid + &LEGALNOTICE; + xxxx + ProtoXEP + Standards Track + Standards + Council + + XMPP Core + + + + NOT_YET_ASSIGNED + + Jérôme + Poisson + goffi@goffi.org + goffi@jabber.fr + + + + 0.1 + 2016-01-16 + jp +

First draft.

 + + +
+ +

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

+ + +

JID mention must

+
    +
  • work online and offline
    • +
  • work if the entity is not aware of the context
    • +
  • work outside of XMPP context (e.g. in a website)
    • +
  • not be tied to a particular syntax
    • +
  • (desirable) be easy to implement
    • +
+ + +
    +
  • Mentioning entity — the entity which want to mention somebody.
    • +
  • Mentioned entity — the entity actually mentioned.
    • +
  • Mentioned URI — URI where the entity is mentioned.
    • +
  • PubSub — &xep0060;.
    • +
  • MUC — &xep0045;.
    • +
  • MIX — &xep0369;.
    • +
+ + + + +

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.

+ + + + You have been mentioned on xmpp:balcony@chat.shakespeare.lit?join + + +]]> + + +

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.

+ + + + + + + + You have been mentioned on xmpp:pubsub.montague.lit?;node=urn%3Axmpp%3Amicroblog%3A0%3Acomments%2Fdd88c9bc58886fce0049ed050df0c5f2 + + +]]> + + +

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.

+ + + + O Romeo, Romeo! wherefore art thou Romeo? + Deny thy father and refuse thy name! + Or, if thou wilt not, be but sworn my love, + And I'll no longer be a Capulet. + + + + You have been mentioned on xmpp:balcony@chat.shakespeare.lit?join + + +]]> + + +

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
    • +
  • email — the user email address, in a <email/> element
    • +
  • Full Name — the user full name, in a <name/> element
    • +
  • Nickname — the user nickname, in a <nick/> element
    • +
+ + + + Lord Capulet + capulet@capulet.lit + + + + You have been mentioned on xmpp:balcony@chat.shakespeare.lit?join + + + ]]> + + +

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.

+

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.

+ + + + O Romeo, Romeo! wherefore art thou Romeo? + Deny thy father and refuse thy name! + Or, if thou wilt not, be but sworn my love, + And I'll no longer be a Capulet. + + + + + + + You have been mentioned on xmpp:balcony@chat.shakespeare.lit?join + + +]]> + + + + +

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

+ + + + + +

If a entity supports the JID mention protocol, it MUST report that fact by including a service discovery feature of "urn:xmpp:mention:0" in response to a &xep0030; information request:

+ + + + ]]> + + + ... + + ... + + + ]]> + + +

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

+ + + + +
    +
  1. In the case of group chat like MUC or MIX, most of clients already monitor conversations and notify the user if he is mentioned. To avoid to deal with double notifications, the mentioning entity SHOULD NOT mention an other entity using this XEP if the mentioned entity is online and following the conversation (i.e. it joined the MUC room or it subscribed to the MIX conversation).
    2. +
  2. On the other hand, if the mentioned entity is not following the conversation (i.e. it didn't joined the MUC room, or it didn't subscribed to the MIX conversation), the mentioning entity SHOULD use this XEP for the mention.
    3. +
+ + +
    +
  1. 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.
    2. +
  2. 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.
    3. +
  3. 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.
    4. +
+ + +

This document requires no interaction with &IANA;.

+ + + +

The ®ISTRAR; includes 'urn:xmpp:mention:0' in its registry of protocol namespaces (see &NAMESPACES;).

+
    +
  • urn:xmpp:mention:0
    • +
+ + + &NSVER; + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ]]> + +