<section3option='Publisher-Specific Subscriptions and Unsubscriptions'>
<section3topic='Publisher-Specific Subscriptions and Unsubscriptions'>
<p>
Subscriptions can be specific to a publisher, in which case a to attribute
@ -324,7 +325,7 @@ being pushed information from that publisher if he's specified a
@@ -324,7 +325,7 @@ being pushed information from that publisher if he's specified a
</section3>
<section3option='Non-Publisher-Specific Subscriptions and Unsubscriptions'>
<section3topic='Non-Publisher-Specific Subscriptions and Unsubscriptions'>
<p>
As well as being able to subscribe to specific publishers, it is also
@ -445,7 +446,7 @@ from everywhere.
@@ -445,7 +446,7 @@ from everywhere.
</section3>
<section3option='Further Notes'>
<section3topic='Further Notes'>
<p>
All the examples so far have shown actions on the subscriber's part, and
<abstract>NOTE WELL: this document was retracted on 2003-11-05 since the topic is addressed definitively in XMPP Core. Please refer to XMPP Core for further information.</abstract>
&LEGALNOTICE;
<abstract>NOTE WELL: this document was retracted on 2003-11-05 since the topic is addressed definitively in XMPP Core. Please refer to XMPP Core for further information.</abstract>
<title>Definition of Jabber Identifiers (JIDs)</title>
<abstract>This document defines the exact nature of a Jabber Identifier (JID). <em>Note well: this document was superseded by RFC 3920, which in turn has been superseded by RFC 6122.</em></abstract>
<abstract>Note well: this document was superseded by RFC 3920, which in turn has been superseded by RFC 6122. This document defines the exact nature of a Jabber Identifier (JID).</abstract>
<title>A Framework For Securing Jabber Conversations</title>
<abstract>
Although the value and utility of contemporary instant messaging
systems, like Jabber, are now indisputable, current security
@ -20,38 +17,28 @@ environments like large, commercial enterprises and government
@@ -20,38 +17,28 @@ environments like large, commercial enterprises and government
agencies. These current features suffer from issues of
scalability, usability, and supported features. Furthermore, there is a
lack of standardization.
We present a protocol to allow communities of Jabber users to
apply cryptographic protection to selected conversation data.
</abstract>
&LEGALNOTICE;
<number>0031</number>
<status>Deferred</status>
<type>Standards Track</type>
<sig>Standards</sig>
<dependencies/>
<supersedes/>
<supersededby/>
<shortname>N/A</shortname>
<author>
<firstname>
Paul
</firstname>
<surname>
Lloyd
</surname>
<email>
paul_lloyd@hp.com
</email>
<jid>
paul_lloyd@jabber.hp.com (private)
</jid>
<firstname>Paul</firstname>
<surname>Lloyd</surname>
<email>paul_lloyd@hp.com</email>
<jid>paul_lloyd@jabber.hp.com (private)</jid>
</author>
<revision>
<version>0.2</version>
<date>2002-07-09</date>
<initials>
PCL
</initials>
<initials>PCL</initials>
<remark>
updated to reflect group consensus to incorporate XML Encryption, as well