moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

added member-affiliation disco feature 

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1228 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-09-24 22:31:27 +00:00
parent 3d10c92ab9
commit d32f197b3d
5 changed files with 89 additions and 68 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
xep-0060.xml
View File

@ -442,7 +442,7 @@ And by opposing end them?
<section2 topic='Affiliations' anchor='affiliations'>
<p>To manage permissions, the protocol defined herein uses a hierarchy of affiliations, similiar to those introduced in &xep0045;.</p>
<p>Support for the "owner" and "none" affiliations is REQUIRED. Support for all other affiliations is RECOMMENDED. Particular kinds of pubsub services MAY enforce additional requirements.</p>
<p>Support for the "owner" and "none" affiliations is REQUIRED. Support for all other affiliations is RECOMMENDED. For each non-required affiliation supported by an implementation, it SHOULD return a service discovery feature of "name-affiliation" where "name" is the name of the affiliation, such as "member", "outcast", or "publisher" (see the <link url='#features'>Feature Summary</link>). Particular kinds of pubsub services MAY enforce additional requirements (e.g., requiring support for a given non-required affiliation or for all affiliations).</p>
<table caption='Affiliations and their Privileges'>
<tr>
<th>Affiliation</th>
@ -5163,6 +5163,12 @@ And by opposing end them?
<td>OPTIONAL</td>
<td><link url='#owner-subscriptions'>Manage Subscribers</link></td>
</tr>
<tr>
<td>member-affiliation</td>
<td>The member affiliation is supported.</td>
<td>RECOMMENDED</td>
<td><link url='#affiliations'>Affiliations</link></td>
</tr>
<tr>
<td>meta-data</td>
<td>Node meta-data is supported.</td>
@ -5226,8 +5232,8 @@ And by opposing end them?
<tr>
<td>publisher-affiliation</td>
<td>The publisher affiliation is supported.</td>
<td>OPTIONAL</td>
<td>&#160;</td>
<td>RECOMMENDED</td>
<td><link url='#affiliations'>Affiliations</link></td>
</tr>
<tr>
<td>purge-nodes</td>
@ -5942,13 +5948,18 @@ O, what a rogue and peasant slave am I!
<doc>XEP-0060</doc>
</var>
<var>
<name>http://jabber.org/protocol/pubsub#meta-data</name>
<desc>Node meta-data is supported.</desc>
<name>http://jabber.org/protocol/pubsub#manage-subscription</name>
<desc>Node owners may manage subscriptions.</desc>
<doc>XEP-0060</doc>
</var>
<var>
<name>http://jabber.org/protocol/pubsub#manage-subscription</name>
<desc>Node owners may manage subscriptions.</desc>
<name>http://jabber.org/protocol/pubsub#member-affiliation</name>
<desc>The member affiliation is supported.</desc>
<doc>XEP-0060</doc>
</var>
<var>
<name>http://jabber.org/protocol/pubsub#meta-data</name>
<desc>Node meta-data is supported.</desc>
<doc>XEP-0060</doc>
</var>
<var>
@ -6524,6 +6535,8 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=unsubscribe;node=princely_musings
<xs:attribute name='affiliation' use='required'>
<xs:simpleType>
<xs:restriction base='xs:NCName'>
<xs:enumeration value='member'/>
<xs:enumeration value='none'/>
<xs:enumeration value='outcast'/>
<xs:enumeration value='owner'/>
<xs:enumeration value='publisher'/>
@ -6727,6 +6740,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=unsubscribe;node=princely_musings
<xs:enumeration value='item-ids'/>
<xs:enumeration value='leased-subscription'/>
<xs:enumeration value='manage-subscriptions'/>
<xs:enumeration value='member-affiliation'/>
<xs:enumeration value='meta-data'/>
<xs:enumeration value='modify-affiliations'/>
<xs:enumeration value='multi-collection'/>
@ -6957,6 +6971,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=unsubscribe;node=princely_musings
<xs:attribute name='affiliation' use='required'>
<xs:simpleType>
<xs:restriction base='xs:NCName'>
<xs:enumeration value='member'/>
<xs:enumeration value='none'/>
<xs:enumeration value='outcast'/>
<xs:enumeration value='owner'/>

2
xep-0071.xml
View File

@ -758,7 +758,7 @@ That seems fine to me.
<section1 topic='Discovering Support for XHTML-IM' anchor='discovery'>
<p>This section describes methods for discovering whether a Jabber client or other XMPP entity supports the protocol defined herein.</p>
<section2 topic='Explicit Discovery' anchor='discovery-explicit'>
<p>The primary means of discovering support for XHTML-IM is &xep0030;.</p>
<p>The primary means of discovering support for XHTML-IM is &xep0030; (or the dynamic profile of service discovery defined in &xep0115;).</p>
<example caption='Seeking to Discover XHTML-IM Support'><![CDATA[
<iq type='get'
from='juliet@shakespeare.lit/balcony'

58
xep-0154.xml
View File

@ -25,7 +25,7 @@
<spec>XEP-0054</spec>
</supersedes>
<supersededby/>
<shortname>profile</shortname>
<shortname>TO BE ASSIGNED</shortname>
&stpeter;
<revision>
<version>0.5</version>
@ -124,7 +124,7 @@
<ol>
<li>
<p><strong>IQ (request-and-response) semantics.</strong></p>
<p>In the simplest case, an entity may store its own profile data and provide only the complete profile and only on request, using the request-response semantics of the XMPP &IQ; stanza type. This model is most appropriate for stable entities that are always online and whose profile data does not change frequently, such as servers and server-side components (entities that are not always online or that frequently modify their profile data, such as IM users, may prefer to publish their information to entities that are always online, such as an IM user's server). While it may seem desirable to embed profile data in the responses an entity provides to service discovery information requests using &xep0128;, it is likely that profile data will be quite extensive; therefore, we define a standalone "wrapper" element for profile data, qualified by the 'http://jabber.org/protocol/profile' namespace.</p>
<p>In the simplest case, an entity may store its own profile data and provide only the complete profile and only on request, using the request-response semantics of the XMPP &IQ; stanza type. This model is most appropriate for stable entities that are always online and whose profile data does not change frequently, such as servers and server-side components (entities that are not always online or that frequently modify their profile data, such as IM users, may prefer to publish their information to entities that are always online, such as an IM user's server). While it may seem desirable to embed profile data in the responses an entity provides to service discovery information requests using &xep0128;, it is likely that profile data will be quite extensive; therefore, we define a standalone "wrapper" element for profile data, qualified by the 'http://www.xmpp.org/extensions/xep-0154.html#ns' namespace &NSNOTE;.</p>
</li>
<li>
<p><strong>Pubsub (publish-and-subscribe) semantics.</strong></p>
@ -148,7 +148,7 @@
<p><strong>A format represented by means of &w3rdf;.</strong></p>
<p>An argument could be made that RDF is a reasonable approach for representing profile data for communication over the XMPP network; however, such an argument will not be made in the current proposal. The author has considered RDF and has concluded that there are several reasons why RDF is undesirable as an XMPP wire protocol:</p>
<ol>
<li>RDF exists in an XML representation but the semantics of RDF impose a more complex conceptual structure (data triples) than does XML, which is sub-optimal since unnecessary complexity is to be avoided (see &xep0134;).</li>
<li>RDF exists in an XML representation but the semantics of RDF impose a more complex conceptual structure (data triples) than does XML; this is sub-optimal since unnecessary complexity is to be avoided (see &xep0134;).</li>
<li>RDF requires a specialized parser rather than the normal XML parser that comes standard with all XMPP implementations.</li>
<li>As long as it is possible to define a consistent mapping of profile data to RDF representations, it should be straightforward to convert the XMPP data formats into those RDF representations if desired (e.g., to output a FOAF file).</li>
</ol>
@ -167,13 +167,13 @@
</ol>
</li>
</ul>
<p>Therefore, this proposal specifies that profile data shall be scoped by a FORM_TYPE of 'http://jabber.org/protocol/profile', in accordance with the field standardization methods defined in <cite>XEP-0068</cite>. For the sake of interoperability, profile data fields that will be in common use SHOULD be registered with the &REGISTRAR; (although they may or may not be defined in a XMPP Extension Protocol specification). Profile data fields that are intended to be used only within the context of a specialized application MAY remain unregistered, but unregistered fields MUST begin with the string "x-" in accordance with Section 3.4 of <cite>XEP-0068</cite>. <note>Alternatively, specialized applications MAY define separate FORM_TYPEs for their particular data elements.</note></p>
<p>Therefore, this proposal specifies that profile data shall be represented in data forms scoped by a FORM_TYPE of 'http://www.xmpp.org/extensions/xep-0154.html#ns' &NSNOTE;, in accordance with the field standardization methods defined in <cite>XEP-0068</cite>. For the sake of interoperability, profile data fields that will be in common use SHOULD be registered with the &REGISTRAR; (although they may or may not be defined in a XMPP Extension Protocol specification). Profile data fields that are intended to be used only within the context of a specialized application MAY remain unregistered, but unregistered fields MUST begin with the string "x-" in accordance with Section 3.4 of <cite>XEP-0068</cite>. <note>Alternatively, specialized applications MAY define separate FORM_TYPEs for their particular data elements.</note></p>
<p>The following is a simple and incomplete example of profile data represented via the Data Forms protocol, containing two registered data fields and one unregistered field:</p>
<example caption='A Basic Example'><![CDATA[
<profile xmlns='http://jabber.org/protocol/profile'>
<profile xmlns='http://www.xmpp.org/extensions/xep-0154.html#ns'>
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/profile</value>
<value>http://www.xmpp.org/extensions/xep-0154.html#ns</value>
</field>
<field var='common_name'>
<value>Peter Saint-Andre</value>
@ -188,7 +188,7 @@
</x>
</profile>
]]></example>
<p>By specifying that all fields are scoped by a FORM_TYPE of 'http://jabber.org/protocol/profile', this proposal does not mean to imply that all profile data will or should be gathered in one data form. In reality, most such data will probably be gathered at the time of registration either at a website or via a "wizard" interface that breaks the process into smaller bundles (such as "Basic Personal Data", "Physical Location", "Internet Addresses", "Hobbies and Interests", and "Favorite Things"). The use of one FORM_TYPE is simply meant to scope the data fields so that each field is unique within the context of profile data. Any form that uses these fields along with a FORM_TYPE of 'http://jabber.org/protocol/profile' is of the "profile type" (i.e., is a specific instance of that type), which does not limit the number of forms that can be of that type.</p>
<p>By specifying that all fields are scoped by a FORM_TYPE of 'http://www.xmpp.org/extensions/xep-0154.html#ns', this proposal does not mean to imply that all profile data will or should be gathered in one data form. In reality, most such data will probably be gathered at the time of registration either at a website or via a "wizard" interface that breaks the process into smaller bundles (such as "Basic Personal Data", "Physical Location", "Internet Addresses", "Hobbies and Interests", and "Favorite Things"). The use of one FORM_TYPE is simply meant to scope the data fields so that each field is unique within the context of profile data. Any form that uses these fields along with a FORM_TYPE of 'http://www.xmpp.org/extensions/xep-0154.html#ns' is of the "profile type" (i.e., is a specific instance of that type), which does not limit the number of forms that can be of that type.</p>
<p>However, scoping all data fields with a single FORM_TYPE implies it is necessary to define separate data fields for similar kinds of information. For example, the vCard specification (<cite>RFC 2426</cite>) defines "types" for certains kinds of data, such as email addresses, telephone numbers, and physical addresses, making it possible to specify that a telephone number corresponds to a fax machine or mobile phone or that a physical address corresponds to one's home or work location. In the Data Forms representation, any desired piece of information (e.g., work phone) must be represented with a separate data field.</p>
<p>In order to address most (if not all) of the pieces of information described in existing profile specifications, this document defines a great number of data fields. Even so, the data fields specified herein are not exhaustive, and it is expected that additional fields will be registered in the future through the mechanisms specified in the <link url='#registrar'>XMPP Registrar Considerations</link> section of this document.</p>
</section2>
@ -198,10 +198,10 @@
<p>In order to publish a full profile, an entity sends an IQ-set to its server with a child element of &lt;profile/&gt; containing the full profile information.</p>
<example caption='Entity publishes full profile'><![CDATA[
<iq type='set' id='setfull'>
<profile xmlns='http://jabber.org/protocol/profile'>
<profile xmlns='http://www.xmpp.org/extensions/xep-0154.html#ns'>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/profile</value>
<value>http://www.xmpp.org/extensions/xep-0154.html#ns</value>
</field>
<field var='nickname'>
<value>Hamlet</value>
@ -226,12 +226,12 @@
<p>Otherwise it MUST return an error. If the server does not support the profile data functionality, the error MUST be &unavailable;.</p>
</section2>
<section2 topic='Updating One or More Profile Fields' anchor='producer-pub'>
<p>In order to update selected fields in a public profile, an entity simply publishes the modified fields (not the entire profile) to a pubsub node of "http://jabber.org/protocol/profile" at its server using the PEP subset of the publish-subscribe extension, as specified in <cite>XEP-0163</cite>.</p>
<p>In order to update selected fields in a public profile, an entity simply publishes the modified fields (not the entire profile) to a pubsub node of "http://www.xmpp.org/extensions/xep-0154.html#ns" at its server using the PEP subset of the publish-subscribe extension, as specified in <cite>XEP-0163</cite>.</p>
<example caption='Account owner publishes profile field(s)'><![CDATA[
<iq type='set' id='pub1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='http://jabber.org/protocol/profile'>
<profile xmlns='http://jabber.org/protocol/profile'>
<publish node='http://www.xmpp.org/extensions/xep-0154.html#ns'>
<profile xmlns='http://www.xmpp.org/extensions/xep-0154.html#ns'>
<x xmlns='jabber:x:data' type='result'>
<field var='weblog'>
<value>http://www.denmark.lit/blogs/princely_musings</value>
@ -246,9 +246,9 @@
<example caption='Server generates notifications'><![CDATA[
<message to='francisco@denmark.lit' from='hamlet@denmark.lit/elsinore' type='headline' id='foo'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='http://jabber.org/protocol/profile'>
<items node='http://www.xmpp.org/extensions/xep-0154.html#ns'>
<item>
<profile xmlns='http://jabber.org/protocol/profile'>
<profile xmlns='http://www.xmpp.org/extensions/xep-0154.html#ns'>
<x xmlns='jabber:x:data' type='result'>
<field var='weblog'>
<value>http://www.denmark.lit/blogs/princely_musings</value>
@ -270,7 +270,7 @@
</section1>
<section1 topic='Consumer Use Cases' anchor='consumer'>
<section2 topic='Discovering Support' anchor='consumer-disco'>
<p>If an entity can provide profile data directly using the standalone 'http://jabber.org/protocol/profile' namespace, it SHOULD advertise that feature in response to &xep0030; information requests:</p>
<p>If an entity can provide profile data directly using the standalone 'http://www.xmpp.org/extensions/xep-0154.html#ns' namespace, it SHOULD advertise that feature in response to &xep0030; information requests:</p>
<example caption='A request for service discovery information'><![CDATA[
<iq type='get'
from='bard@shakespeare.lit/globe'
@ -287,7 +287,7 @@
<query xmlns='http://jabber.org/protocol/disco#info'>
<identity category='account' type='registered'/>
...
<feature var='http://jabber.org/protocol/profile'/>
<feature var='http://www.xmpp.org/extensions/xep-0154.html#ns'/>
...
</query>
</iq>
@ -295,13 +295,13 @@
<p>Note: Because the foregoing request was sent to the bare JID &lt;hamlet@denmark.lit&gt;, the response is provided by the &lt;denmark.lit&gt; server on behalf of the registered account. The answer indicates that the server can also provide profile data on behalf of the registered account.</p>
</section2>
<section2 topic='Requesting Full Profile' anchor='consumer-full'>
<p>In order to request the full profile, the requesting entity sends an IQ-get to the providing entity's JID, where the request contains an empty &lt;profile/&gt; element qualified by the 'http://jabber.org/protocol/profile' namespace. In this example, the request is sent to a server:</p>
<p>In order to request the full profile, the requesting entity sends an IQ-get to the providing entity's JID, where the request contains an empty &lt;profile/&gt; element qualified by the 'http://www.xmpp.org/extensions/xep-0154.html#ns' namespace. In this example, the request is sent to a server:</p>
<example caption='A request for profile data'><![CDATA[
<iq type='get'
from='hamlet@denmark.lit/elsinore'
to='shakespeare.lit'
id='iq1'>
<profile xmlns='http://jabber.org/protocol/profile'/>
<profile xmlns='http://www.xmpp.org/extensions/xep-0154.html#ns'/>
</iq>
]]></example>
<p>The server then replies:</p>
@ -310,10 +310,10 @@
from='shakespeare.lit'
to='hamlet@denmark.lit/elsinore'
id='iq1'>
<profile xmlns='http://jabber.org/protocol/profile'>
<profile xmlns='http://www.xmpp.org/extensions/xep-0154.html#ns'>
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/profile</value>
<value>http://www.xmpp.org/extensions/xep-0154.html#ns</value>
</field>
<field var='common_name'>
<value>shakespeare.lit IM server</value>
@ -364,7 +364,7 @@
from='bard@shakespeare.lit/globe'
to='hamlet@denmark.lit'
id='iq2'>
<profile xmlns='http://jabber.org/protocol/profile'/>
<profile xmlns='http://www.xmpp.org/extensions/xep-0154.html#ns'/>
</iq>
]]></example>
<p>If the requesting entity is not allowed to retrieve hosted profiles (e.g., because it is not on a whitelist of entities permitted to "spider" the server's users), the server SHOULD return a &unavailable; error:</p>
@ -373,7 +373,7 @@
from='hamlet@denmark.lit'
to='bard@shakespeare.lit/globe'
id='iq2'>
<profile xmlns='http://jabber.org/protocol/profile'/>
<profile xmlns='http://www.xmpp.org/extensions/xep-0154.html#ns'/>
<error code='503' type='cancel'>
<service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
@ -386,10 +386,10 @@
from='hamlet@denmark.lit'
to='bard@shakespeare.lit/globe'
id='iq2'>
<profile xmlns='http://jabber.org/protocol/profile'>
<profile xmlns='http://www.xmpp.org/extensions/xep-0154.html#ns'>
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/profile</value>
<value>http://www.xmpp.org/extensions/xep-0154.html#ns</value>
</field>
<field var='nickname'>
<value>Hamlet</value>
@ -412,14 +412,14 @@
]]></example>
</section2>
<section2 topic='Receiving Profile Updates' anchor='consumer-sub'>
<p>In order to receive updated fields for a contact's profile, an entity shall send a pubsub subscription request to the contact's bare JID (&BAREJID;) and specify a node of "http://jabber.org/protocol/profile":</p>
<p>In order to receive updated fields for a contact's profile, an entity shall send a pubsub subscription request to the contact's bare JID (&BAREJID;) and specify a node of "http://www.xmpp.org/extensions/xep-0154.html#ns":</p>
<example caption='Entity subscribes to profile node'><![CDATA[
<iq type='set'
from='francisco@denmark.lit/barracks'
to='hamlet@denmark.lit'
id='sub1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<subscribe node='http://jabber.org/protocol/profile' jid='francisco@denmark.lit'/>
<subscribe node='http://www.xmpp.org/extensions/xep-0154.html#ns' jid='francisco@denmark.lit'/>
</pubsub>
</iq>
]]></example>
@ -434,9 +434,9 @@
<example caption='Entity receives notification'><![CDATA[
<message to='francisco@denmark.lit' from='hamlet@denmark.lit/elsinore' type='headline' id='foo'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='http://jabber.org/protocol/profile'>
<items node='http://www.xmpp.org/extensions/xep-0154.html#ns'>
<item>
<profile xmlns='http://jabber.org/protocol/profile'>
<profile xmlns='http://www.xmpp.org/extensions/xep-0154.html#ns'>
<x xmlns='jabber:x:data' type='result'>
<field var='weblog'>
<value>http://www.denmark.lit/blogs/princely_musings</value>
@ -1928,7 +1928,7 @@ XhK8hFkPvXjudl7xAJ95+2fAHfmHheZJVaO8VaJiL54Tvw==
<!--
<code caption='Registry Submission'><![CDATA[
<form_type>
<name>http://jabber.org/protocol/profile</name>
<name>http://www.xmpp.org/extensions/xep-0154.html#ns</name>
<doc>XEP-0154</doc>
<desc>Forms for entity profile data.</desc>
<field

40
xep-0194.xml
View File

@ -21,8 +21,14 @@
</dependencies>
<supersedes/>
<supersededby/>
<shortname>chatting</shortname>
<shortname>TO BE ASSIGNED</shortname>
&stpeter;
<revision>
<version>0.2</version>
<date>2007-09-14</date>
<initials>psa</initials>
<remark><p>Updated in accordance with XEP-0163.</p></remark>
</revision>
<revision>
<version>0.1</version>
<date>2006-08-30</date>
@ -41,7 +47,7 @@
</section1>
<section1 topic='Protocol' anchor='protocol'>
<section2 topic='Container Element and Child Elements' anchor='protocol-elements'>
<p>Information about chatrooms is provided by the user (or automated integration with Jabber, IRC, or other systems) and is propagated on the network by the user's client. The information container for chatting data is a &lt;room/&gt; element that is qualified by the 'http://jabber.org/protocol/chatting' namespace. The chatting information itself is provided as the XML character data of the following children of the &lt;room/&gt; element:</p>
<p>Information about chatrooms is provided by the user (or automated integration with Jabber, IRC, or other systems) and is propagated on the network by the user's client. The information container for chatting data is a &lt;room/&gt; element that is qualified by the 'http://www.xmpp.org/extensions/xep-0194.html#ns' namespace &NSNOTE;. The chatting information itself is provided as the XML character data of the following children of the &lt;room/&gt; element:</p>
<table caption='Child Elements'>
<tr>
<th>Element</th>
@ -60,13 +66,13 @@
<tr>
<td>topic</td>
<td>The current topic of discussion in the room</td>
<td>Whiteboard protocol meeting</td>
<td>whiteboard brainstorming session</td>
<td>xs:string</td>
<td>OPTIONAL</td>
</tr>
<tr>
<td>uri</td>
<td>A URI for the room (this SHOULD be an XMPP URI in accordance with &rfc4622; but MAY use some other URI scheme, such as the irc: scheme)</td>
<td>A URI for the room (this SHOULD be an XMPP URI or IRI in accordance with &rfc4622; but MAY use some other URI scheme, such as the irc: scheme)</td>
<td>xmpp:jdev@conference.jabber.org</td>
<td>xs:anyURI</td>
<td>REQUIRED</td>
@ -75,13 +81,13 @@
<p>NOTE: The datatypes specified above are defined in &w3xmlschema2;.</p>
</section2>
<section2 topic='Transport Mechanism' anchor='protocol-transport'>
<p>When a user joins a room, its client may publish that fact to a special pubsub or PEP node (if a PEP node, the NodeID is "http://jabber.org/protocol/chatting"). The chatting information SHOULD be communicated and transported by means of the <cite>XEP-0060</cite> protocol, especially the subset specified in <cite>XEP-0163</cite> (as shown in the following examples). Because chatroom information is not pure presence information and can change independently of the user's availability, it SHOULD NOT be provided as an extension to the &PRESENCE; stanza type.</p>
<p>When a user joins a room, its client may publish that fact to a special pubsub or PEP node (if a PEP node, the NodeID is "http://www.xmpp.org/extensions/xep-0194.html#ns" &NSNOTE;). The chatting information SHOULD be communicated and transported by means of the <cite>XEP-0060</cite> protocol, especially the subset specified in <cite>XEP-0163</cite> (as shown in the following examples). Because chatroom information is not pure presence information and can change independently of the user's availability, it SHOULD NOT be provided as an extension to the &PRESENCE; stanza type.</p>
<example caption='User Publishes Chatting Information'><![CDATA[
<iq type='set' from='stpeter@jabber.org/work' id='chatting1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='http://jabber.org/protocol/chatting'>
<publish node='http://www.xmpp.org/extensions/xep-0194.html#ns'>
<item id='1b395148292c0b0ab3a83bb2c22909bf83d2a80b'>
<room xmlns='http://jabber.org/protocol/chatting'>
<room xmlns='http://www.xmpp.org/extensions/xep-0194.html#ns'>
<name>jdev</name>
<uri>xmpp:jdev@conference.jabber.org</uri>
</room>
@ -94,9 +100,9 @@
<example caption='Chatting Information is Delivered to All Subscribers'><![CDATA[
<message from='stpeter@jabber.org' to='maineboy@jabber.org'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='http://jabber.org/protocol/chatting'>
<items node='http://www.xmpp.org/extensions/xep-0194.html#ns'>
<item id='1b395148292c0b0ab3a83bb2c22909bf83d2a80b'>
<room xmlns='http://jabber.org/protocol/chatting'>
<room xmlns='http://www.xmpp.org/extensions/xep-0194.html#ns'>
<name>jdev</name>
<uri>xmpp:jdev@conference.jabber.org</uri>
</room>
@ -112,9 +118,9 @@
<example caption='User Publishes Exit Information'><![CDATA[
<iq type='set' from='stpeter@jabber.org/work' id='chatting2'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='http://jabber.org/protocol/chatting'>
<publish node='http://www.xmpp.org/extensions/xep-0194.html#ns'>
<item id='1b395148292c0b0ab3a83bb2c22909bf83d2a80b'>
<room xmlns='http://jabber.org/protocol/chatting'/>
<room xmlns='http://www.xmpp.org/extensions/xep-0194.html#ns'/>
</item>
</publish>
</pubsub>
@ -123,9 +129,9 @@
<example caption='Empty Room Information is Delivered to All Subscribers'><![CDATA[
<message from='stpeter@jabber.org' to='maineboy@jabber.org'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='http://jabber.org/protocol/chatting'>
<items node='http://www.xmpp.org/extensions/xep-0194.html#ns'>
<item id='1b395148292c0b0ab3a83bb2c22909bf83d2a80b'>
<room xmlns='http://jabber.org/protocol/chatting'/>
<room xmlns='http://www.xmpp.org/extensions/xep-0194.html#ns'/>
</item>
</items>
</event>
@ -143,8 +149,8 @@
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>The &REGISTRAR; shall include 'http://jabber.org/protocol/chatting' in its registry of protocol namespaces.</p>
<section2 topic='Protocol Namespaces' anchor='ns'>
<p>Until this specification advances to a status of Draft, its associated namespace shall be "http://www.xmpp.org/extensions/xep-0194.html#ns"; upon advancement of this specification, the &REGISTRAR; shall issue a permanent namespace in accordance with the process defined in Section 4 of &xep0053;.</p>
</section2>
</section1>
<section1 topic='XML Schema' anchor='schema'>
@ -153,8 +159,8 @@
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='http://jabber.org/protocol/chatting'
xmlns='http://jabber.org/protocol/chatting'
targetNamespace='http://www.xmpp.org/extensions/xep-0194.html#ns'
xmlns='http://www.xmpp.org/extensions/xep-0194.html#ns'
elementFormDefault='qualified'>
<xs:element name='room'>

28
xep-0195.xml
View File

@ -41,7 +41,7 @@
</section1>
<section1 topic='Protocol' anchor='protocol'>
<section2 topic='Container Element and Child Elements' anchor='protocol-elements'>
<p>Information about web pages is provided by the user (or automated integration with browsers or other systems) and is propagated on the network by the user's client. The information container for web page data is a &lt;page/&gt; element that is qualified by the 'http://jabber.org/protocol/browsing' namespace. The web page information itself is provided as the XML character data of the following children of the &lt;page/&gt; element:</p>
<p>Information about web pages is provided by the user (or automated integration with browsers or other systems) and is propagated on the network by the user's client. The information container for web page data is a &lt;page/&gt; element that is qualified by the 'http://www.xmpp.org/extensions/xep-0195.html#ns' namespace &NSNOTE;. The web page information itself is provided as the XML character data of the following children of the &lt;page/&gt; element:</p>
<table caption='Child Elements'>
<tr>
<th>Element</th>
@ -74,7 +74,7 @@
<tr>
<td>uri</td>
<td>The URI of the page (usually but not necessarily an HTTP URL)</td>
<td>http://www.saint-andre.com/blog/</td>
<td>https://stpeter.im/</td>
<td>xs:anyURI</td>
<td>REQUIRED</td>
</tr>
@ -82,13 +82,13 @@
<p>NOTE: The datatypes specified above are defined in &w3xmlschema2;.</p>
</section2>
<section2 topic='Transport Mechanism' anchor='protocol-transport'>
<p>When a user visits a web page, its client may publish that fact to a special pubsub or PEP node (if a PEP node, the NodeID is "http://jabber.org/protocol/browsing"). The web page information SHOULD be communicated and transported by means of the <cite>XEP-0060</cite> protocol, especially the subset specified in <cite>XEP-0163</cite> (as shown in the following examples). Because browsing information is not pure presence information and can change independently of the user's availability, it SHOULD NOT be provided as an extension to the &PRESENCE; stanza type.</p>
<p>When a user visits a web page, its client may publish that fact to a special pubsub or PEP node (if a PEP node, the NodeID is "http://www.xmpp.org/extensions/xep-0195.html#ns" &NSNOTE;). The web page information SHOULD be communicated and transported by means of the <cite>XEP-0060</cite> protocol, especially the subset specified in <cite>XEP-0163</cite> (as shown in the following examples). Because browsing information is not pure presence information and can change independently of the user's availability, it SHOULD NOT be provided as an extension to the &PRESENCE; stanza type.</p>
<example caption='User Publishes Browsing Information'><![CDATA[
<iq type='set' from='stpeter@jabber.org/work' id='browsing1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='http://jabber.org/protocol/browsing'>
<publish node='http://www.xmpp.org/extensions/xep-0195.html#ns'>
<item id='da6abe63d1e5ed45a6de466732abff72e6fccb93'>
<page xmlns='http://jabber.org/protocol/browsing'>
<page xmlns='http://www.xmpp.org/extensions/xep-0195.html#ns'>
<uri>http://www.saint-andre.com/blog/</uri>
</page>
</item>
@ -100,9 +100,9 @@
<example caption='Browsing Information is Delivered to All Subscribers'><![CDATA[
<message from='stpeter@jabber.org' to='maineboy@jabber.org'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='http://jabber.org/protocol/browsing'>
<items node='http://www.xmpp.org/extensions/xep-0195.html#ns'>
<item id='da6abe63d1e5ed45a6de466732abff72e6fccb93'>
<page xmlns='http://jabber.org/protocol/browsing'>
<page xmlns='http://www.xmpp.org/extensions/xep-0195.html#ns'>
<uri>http://www.saint-andre.com/blog/</uri>
</page>
</item>
@ -117,9 +117,9 @@
<example caption='User Publishes Stop Information'><![CDATA[
<iq type='set' from='stpeter@jabber.org/work' id='browsing2'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='http://jabber.org/protocol/browsing'>
<publish node='http://www.xmpp.org/extensions/xep-0195.html#ns'>
<item id='da6abe63d1e5ed45a6de466732abff72e6fccb93'>
<page xmlns='http://jabber.org/protocol/browsing'/>
<page xmlns='http://www.xmpp.org/extensions/xep-0195.html#ns'/>
</item>
</publish>
</pubsub>
@ -128,9 +128,9 @@
<example caption='Stop Information is Delivered to All Subscribers'><![CDATA[
<message from='stpeter@jabber.org' to='maineboy@jabber.org'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='http://jabber.org/protocol/browsing'>
<items node='http://www.xmpp.org/extensions/xep-0195.html#ns'>
<item id='da6abe63d1e5ed45a6de466732abff72e6fccb93'>
<page xmlns='http://jabber.org/protocol/browsing'/>
<page xmlns='http://www.xmpp.org/extensions/xep-0195.html#ns'/>
</item>
</items>
</event>
@ -149,7 +149,7 @@
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>The &REGISTRAR; shall include 'http://jabber.org/protocol/browsing' in its registry of protocol namespaces.</p>
<p>Until this specification advances to a status of Draft, its associated namespace shall be "http://www.xmpp.org/extensions/xep-0195.html#ns"; upon advancement of this specification, the &REGISTRAR; shall issue a permanent namespace in accordance with the process defined in Section 4 of &xep0053;.</p>
</section2>
</section1>
<section1 topic='XML Schema' anchor='schema'>
@ -158,8 +158,8 @@
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='http://jabber.org/protocol/browsing'
xmlns='http://jabber.org/protocol/browsing'
targetNamespace='http://www.xmpp.org/extensions/xep-0195.html#ns'
xmlns='http://www.xmpp.org/extensions/xep-0195.html#ns'
elementFormDefault='qualified'>
<xs:element name='page'>