Re: [Standards] NEW: XEP-0224 (Attention)

Thu, 09 Aug 2007 13:50:05 -0700 

Le mercredi 8 août 2007, XMPP Extensions Editor a écrit :
> Version 0.1 of XEP-0224 (Attention) has been released.
>
> Abstract: This document defines an XMPP protocol extension for getting the
> attention of another user.
>
> Changelog: Initial published version. (psa)
>
> Diff: N/A
>
> URL: http://www.xmpp.org/extensions/xep-0224.html

One year ago, i also wrote a JEP about that (but never published it)

The concept is quite the same.  (but i also defined a lower important message 
level)

I did not publish it because I was thinking it could be included in the SHIM 
(XEP-0131)

Anyway, I've attached it.   
I think the lower important level is related and should be include to this 
XEP.

-- 
Olivier
Title: JEP-xxxx: notification levels

JEP-xxxx: notification levels

This JEP provides documentation for the notification level.

WARNING: This document has not yet been accepted for consideration or approved in any official manner by the Jabber Software Foundation, and this document must not be referred to as a Jabber Enhancement Proposal (JEP). If this document is accepted as a JEP by the Jabber Council, it will be published at <http://www.jabber.org/jeps/> and announced on the <[EMAIL PROTECTED]> mailing list.

JEP Information

Status: ProtoJEP
Type: Standards Track
Number: xxxx
Version: 0.0.1
Last Updated: 2006-06-11
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: XMPP Core
Supersedes: None
Superseded By: None
Short Name: notification levels

Author Information

Olivier Goffart

Email: [EMAIL PROTECTED]
JID: [EMAIL PROTECTED]

Legal Notice

This Jabber Enhancement Proposal is copyright 1999 - 2006 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy <http://www.jabber.org/jsf/ipr-policy.shtml>. This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License (<http://creativecommons.org/licenses/by/2.5/>).

Discussion Venue

The preferred venue for discussion of this document is the Standards-JIG discussion list: <http://mail.jabber.org/mailman/listinfo/standards-jig>.

Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the Jabber Software 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 JEP 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.

Conformance Terms

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Table of Contents

1. Introduction
2. Notification level
3. Use Cases
3.1. Lower message
3.2. Urgent message
4. Discovery
5. Business Rules
6. Implementation Notes
7. Security Considerations
8. IANA Considerations
9. DTD
Notes
Revision History

1. Introduction

This JEP let change the notification level of a message. A different notification may be executed on the user's client depending the level.

It allow to send message without disturbing a busy person, or at the opposite notify a busy person that the message is really urgent.

It also describe how to do the equivalent of a wizz or a nudge in others messaging systems

2. Notification level

We define the several notification level

Table 1: Different notification level

Level Meaning
normal This is the default level of all message without additional notification indication
lower This mark a message which is not important and doesn't require immediate reply.
urgent This is a message that require an immediate reply or action in return.

3. Use Cases

3.1 Lower message

Romeo know that Juliet is busy, and don't want to distrub her, but would like to let her a message she could read when she is has time.

Example 1. Send a lower priority message

<message to='[EMAIL PROTECTED]'>
      <body>I love you, Juliet</body>
      <notify xmlns='http://kopete.kde.org/protocol/notify' level='lower' />
</message>

3.2 Urgent message

Juliet know that Romeo is busy, and is probably not paying attention to his massages, but has a very urgent message to communicate.

Example 2. Send a urgent message

<message to='[EMAIL PROTECTED]'>
      <body>The reservation deadline for my father's ball ends in five minutes. Do you want to go there with me ?</body>
      <notify xmlns='http://kopete.kde.org/protocol/notify' level='urgent' />
</message>

4. Discovery

It may be usefull to know if the client support that feature in order to let know the user that setting notification level will not have any effect

Example 3. Client Service Discovery request

<iq type='get' to='[EMAIL PROTECTED]/balcony'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

Example 4. Client send discovery response

<iq type='result'
	from='[EMAIL PROTECTED]/balcony'
    to='[EMAIL PROTECTED]/orchard'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
    ...
    <feature var='http://kopete.kde.org/protocol/notify'/>
    ...
  </query>
</iq>

5. Business Rules

  1. A message without body, with a notification level of urgent is equivalent to a nudge or a wizz in others messaging systems. Clients MUST execute the appropriate notification if such empty message arrive.
  2. An implementations SHOULD NOT make too easy to send each message with an urgent level.
  3. Implementations MAY execute a different notification regarding the level.
  4. A level of urgent SHOULD trigger a notification even if the user disabled normal notification
  5. The notification of a lower level MAY be suppressed

6. Implementation Notes

The notification level could be set with a combo box, that automatically return to normal on each message.

7. Security Considerations

There are no security features or concerns related to this proposal.

8. IANA Considerations

This JEP requires no interaction with the Internet Assigned Numbers Authority (IANA) [1].

9. DTD

TODO

TODO

Notes

1. 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/>.

Revision History

Version 0.0.1 (2006-06-11)

Initial version. (ogoffart)

END

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to