[standards-jig] Re: Server-Based Privacy Rules (JEP-0016)

Jean-Louis Seguineau /EXC/TEC jean-louis.seguineau at antepo.com
Fri Jul 19 02:45:01 UTC 2002


Hi,

We have come up with a slightly modified version of the JEP-0016 that is able to handle both black and whitelist. We refer to them as control list. A control list belongs to a given JID.
The base principle is that one specify a default behaviour of a control list, and we we could also agree on a defaut behaviour is nothing is specified, such as the control list is a black list, with deny all.
Once the default behaviour is specified, it cannot be changed without clearing the list and starting afresh with a new behaviour.

Whenever a JID is submited to the list it will bear a type that will specify what to do with regard to the existing behaviour. This is why hte type attribute of the item has three values, namely allow, deny, remove that provide a very granular way of modifying the behaviour for a given JID. For example, assuming default behaviour is deny all, then

<iq type="set" id="3"> 
    <query xmlns="jabber:iq:privacy"> 
        <item jid="jack at dalton.com" type="deny"/> 
    </query> 
</iq> 

will add a JID to the list taht will be denied to send everything. Now if we send later

<iq type="set" id="4"> 
    <query xmlns="jabber:iq:privacy"> 
        <item jid="jack at dalton.com" type="allow"> 
            <presence/> 
        </item> 
    </query> 
</iq> 

we can now allow this JID to send us presence.

Specifying the list default behaviour is handled by a tag <list> that work along the same lines as the <item> tag, with a type that either specify the behaviour of the list (allow/deny) or remove the list alltogether (remove).

Wa have already added the support for specific namespaces in the <iq/> element.
In the future, it may become necessary or desirable to add a further level of granularity to the packet being filtered. This could be easily achieved by using the type attribute that both the <message> and the <presence> tag use. For example, to filter out headline messages you could say somthing like:

<iq type="set" id="4"> 
    <query xmlns="jabber:iq:privacy"> 
        <item jid="jack at dalton.com" type="deny"> 
            <message type="headline"/> 
        </item> 
    </query> 
</iq>

or to see only a deconnection

<iq type="set" id="4"> 
    <query xmlns="jabber:iq:privacy"> 
        <item jid="jack at dalton.com" type="allow"> 
            <presence type="unavailable"/> 
        </item> 
    </query> 
</iq>

Please find bellow a modified version of the JEP-0016 thant take these proposals into consideration

____________________________
Jean-Louis Seguineau
Chief Technology Officer
Antepo, Inc.

ACCEPT, by Antepo
Advanced Converging Communication and Enhanced Presence for the Telecom


1 - Introduction

Almost all types of Instant Messaging (IM) applications have found it necessary to develop some method for a user to block the receipt of messages and packets from other users, the rationale for such blockage depending only on the needs of the individual user. The method for implementing this functionality in the current Jabber system is for each client application to keep its own "blacklist" of the Jabber IDs from which the user does not wish to receive messages. This current implementation has the following drawbacks:

  a.. The XML packets are blocked at the client network endpoint. The unwanted packets need to traverse the entire Jabber network before they are blocked from being delivered. However, these packets could be blocked at the server and never delivered "across the wire" to the client, which becomes especially important for clients that have bandwidth restrictions or in situations where bandwidth is expensive. 
  b.. Currently there exists no Jabber standard enabling clients to share their individual blacklists. Thus blacklist entries are not portable across clients and if a user accesses their account with a different client, the user must re-enter the blacklist entries. 
  c.. Most implementations have no way of blocking specific types of packets -- they typically block only message packets. 
A solution to these shortfalls is to have a common control list which is stored on the Jabber server along with the other information which clients receive from the server (such as the roster).

  a.. This control list can be given a default behaviour that will apply in turn to any contact that would not have an explicit behaviour.
  b.. Each entry in the control list can be edited to deny or allow certain packet types at any moment.
  c.. Each entry in the control list can be removed individually at any moment.
  2 - jabber:iq:privacy Namespace Protocol Details

This document describes a new namespace to handle the storage and retrieval of the server-side control list information. The 'jabber:iq:privacy' namespace is consistent with the existing jabber:* namespaces and use the <query/> element as a direct child under the main <iq/> element. 

A client application would use <iq type="get"> to retrieve the list behaviour or the items in the control list from the server, and use <iq type="set"> to specify the list behaviour or add or edit items in the current list.

Each <query/> element would have one or more <item/> elements which would contain the information for a single entry in the control list. If the <item/> element contains no child elements, then the control list default behaviour will be applied to the contact. If no explicit default behaviour has been specified, then all messages, presence and iq packets will be blocked. 

When a message or other XML packet is blocked according to the entries in the control list, the server must bounce the packet back to the original sender. The bounced packet must be of type="error" and contain a child <error/> element with a 'code' attribute of 405 and CDATA of 'Not Allowed'.

2.1 Elements within the query

Each <query/> element would have one or no <list/> elements which would in turn contain the information for the control list default behaviour.

Each <query/> element would have one or more <item/> elements which would in turn contain the information for a single entry in the control list. 

2.2 Attributes

      Attribute
     Meaning
     
      jid
     The jid attribute hold the Jabber ID, i.e. use at host, of the contact which is to be controled
     
      type
     The type attribute describes the action to be performed on the element when present
     



2.3 Elements

Elements describe the packets that are to be controled for the given contact.

      Element
     Meaning
     
      list
     The <list> tag is used to control the list default behaviour.
     
      item
     The <item> tag is used to specify the required behaviour of a given contact.
     
      message
     The <message> tag is used to control the message packets.
     
      presence
     The <presence> tag is used to control the presence packets.
     
      iq
     The <iq> tag is used to to control the info query packets.
     
      ns
     The <ns> tag is used to specify a particular namespace inside the <iq> tag.
     



2.4 Attributes values

      Element
     Attribute
     Value
     Meaning
     
      item list
     type
     Deny
     The packets specified in the tag will be blocked.
     
          Allow
     The packets specified in the tag will be allowed.
     
          Remove
     The contact will be removed from the control list
     



3 - Specifying the control list default behaviour

The following protocol segments illustrate the exchange of packets between the client application and the server in order to specify the defualt behaviour of the control list:

    3.1 Client sets the control list default

        <iq type="set" id="0"> 
            <query xmlns="jabber:iq:privacy"> 
                <list type="deny"/> 
                    <message/> 
                    <presence/>
                    <iq/>
                </list> 
            </query> 
        </iq>
Note: In this case the default behaviour is to deny all messages, presence and iq packets.

3.2 Server Replies to the control list default

                            <iq type="result" id="0"/> 

4 - Retrieving the control list default behaviour

The following protocol segments illustrate the exchange of packets between the client application and the server in order to retrieve the blacklist:

4.1 Client Requests the control list



    <iq type="get" id="1"> 
        <query xmlns="jabber:iq:privacy"> 
            <list/> 
        </query> 
    </iq> 
4.2 Server Replies to the control list Request

    <iq type="result" id="1"> 
        <query xmlns="jabber:iq:privacy"> 
            <list type="deny"/> 
                <message/> 
                <presence/>
                <iq/>
            </list> 
        </query> 
    </iq>
5 - Retrieving the control list content

The following protocol segments illustrate the exchange of packets between the client application and the server in order to retrieve the blacklist:

5.1 Client Requests the control list

    <iq type="get" id="2"> 
        <query xmlns="jabber:iq:privacy"/> 
    </iq> 
5.2 Server Replies to the control list Request

    <iq type="result" id="2"> 
        <query xmlns="jabber:iq:privacy"> 
            <item jid="joe at dalton.com" type="deny"/> 
            <item jid="jack at dalton.com" type="deny"> 
                <message/> 
            </item> 
        </query> 
    </iq>
6 - Adding Entries to the control list

The following protocol segments illustrate the exchange of packets used to add one or more contacts to the control list.

6.1 Client Requests Addition of Control list Entries

    <iq type="set" id="3"> 
        <query xmlns="jabber:iq:privacy"> 
            <item jid="jack at dalton.com" type="deny"/> 
            <item jid="bill at dalton.com" type="deny"> 
                <message/> 
                <iq/> 
            </item> 
            <item jid="joe at dalton.com" type="deny"> 
                <iq> 
                    <ns>jabber:iq:oob</ns> 
                </iq> 
            </item> 
            <item jid="avarel at dalton.com" type="allow"> 
                <presence/> 
            </item> 
        </query> 
    </iq> 
6.2 Server Replies to Add Entry Request

<iq type="result" id="3"/>


Note: this is different from the 'jabber:iq:roster' protocol, in that the client will not receive "push" packets from the server when the blacklist is changed. For example, a client application must query the server for the control list when displaying it in a GUI environment.

7 - Removing Entries from the Control list

The following protocol segments illustrate how a client application would remove entries from the control list. Note that multiple item elements may be placed inside the query element to allow "batch processing".

7.1 Client Requests Removal of Control list Entries

    <iq type="set" id="4"> 
        <query xmlns="jabber:iq:privacy"> 
            <item jid="bill at dalton.com" type="remove"/> 
        </query> 
    </iq> 
7.2 Server Replies to Remove Entry Request

<iq type="result" id="4"/> 

8 - Blocked User Sending a Message

The following protocol segments illustrate the exchange of message packets when the sender is in the recipient's control list.

8.1 Blocked User Sends a Message

    <message to="bill at dalton.com" id="msg_1"> 
        <body>Hey, I just wanted to chat!</body> 
    </message> 
8.2 Recipient's Server Bounces Message Back to Blocked Sender

    <message id="msg_1" type="error"> 
        <body>Hey, I just wanted to chat!</body> 
        <error code="405">Not Allowed</error> 
    </message>

9 - Namespace DTD

    <?xml version="1.0" encoding="UTF-8"?>
    <!ELEMENT iq (query? | ns?)>
    <!ATTLIST iq
    type (get | result | set) #IMPLIED
    id CDATA #IMPLIED
    >
    <!ELEMENT item (message?, presence?, iq?)>
    <!ATTLIST item
    type (allow | deny | remove) #REQUIRED
    jid CDATA #REQUIRED
    >
    <!ELEMENT list (message?, presence?, iq?)>
    <!ATTLIST list
    type (allow | deny | remove) #REQUIRED
    >
    <!ELEMENT message EMPTY>
    <!ELEMENT ns (#PCDATA)>
    <!ELEMENT presence EMPTY>
    <!ELEMENT query (item* | list?)>
    <!ATTLIST query
    xmlns CDATA #REQUIRED
    >


----- Original Message -----

> Subject: Re: [standards-jig] Server-Based Privacy Rules (JEP-0016)
> From: Julian Missig <julian at jabber.org>
> To: standards-jig at jabber.org
> Date: 01 May 2002 18:28:12 -0400
> Reply-To: standards-jig at jabber.org
>
> On Wed, 2002-05-01 at 14:50, Peter Saint-Andre wrote:
> > It's been a while since there has been any discussion of Peter Millard's
> > JEP on server-based privacy rules:
> >
> > http://www.jabber.org/jeps/jep-0016.html
> >
> > This seems like a worthy protocol enhancement. Any thoughts from the
> > Standards community on this one, or suggestions for improvement before I
> > poke the Council about it?
> >
>
> Well, I still have the same opinion: we shouldn't pretend that it's a
> be-all-end-all for security/privacy, but other than that it's fine. As
> with before, I'd like to see a "whitelist" capability too.
>
> Julian
> --
> email: julian at jabber.org
> jabber:julian at jabber.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20020718/6eb4c979/attachment.html>


More information about the Standards mailing list