Remove trailing whitespace from all XML files.

hacx
Emmanuel Gil Peyrot 2017-08-02 20:49:11 +01:00 committed by Sam Whited
parent 901ccc83de
commit e8d49ee6ed
45 changed files with 1128 additions and 1128 deletions

View File

@ -81,13 +81,13 @@ C: <bidi xmlns='urn:xmpp:bidi'/>
<section1 topic='Examples' anchor='examples'>
<p>This section shows two complete examples of bidirectional streams, the first example uses SASL EXTERNAL, the second uses Server Dialback. </p>
<example caption='Bidirectional Streams with SASL Authentication'><![CDATA[
C: <stream:stream xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server' xmlns:db='jabber:server:dialback'
to='montague.lit' from='capulet.lit'
C: <stream:stream xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server' xmlns:db='jabber:server:dialback'
to='montague.lit' from='capulet.lit'
xml:lang='en' version='1.0'>
S: <stream:stream xmlns='jabber:server' xmlns:db='jabber:server:dialback'
xmlns:stream='http://etherx.jabber.org/streams' xml:lang='en'
id='65b30434afd7646699d077f7affcb2c120c48e18'
S: <stream:stream xmlns='jabber:server' xmlns:db='jabber:server:dialback'
xmlns:stream='http://etherx.jabber.org/streams' xml:lang='en'
id='65b30434afd7646699d077f7affcb2c120c48e18'
from='montague.lit' to='capulet.lit' version='1.0'>
S: <stream:features>
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
@ -95,13 +95,13 @@ S: <stream:features>
</stream:features>
C: <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
S: <proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
C: <stream:stream xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server' xmlns:db='jabber:server:dialback'
to='montague.lit' from='capulet.lit'
C: <stream:stream xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server' xmlns:db='jabber:server:dialback'
to='montague.lit' from='capulet.lit'
xml:lang='en' version='1.0'>
S: <stream:stream xmlns='jabber:server' xmlns:db='jabber:server:dialback'
xmlns:stream='http://etherx.jabber.org/streams' xml:lang='en'
id='b5cd769b1dc292c6f6557fe76cabc4d112333f9a'
S: <stream:stream xmlns='jabber:server' xmlns:db='jabber:server:dialback'
xmlns:stream='http://etherx.jabber.org/streams' xml:lang='en'
id='b5cd769b1dc292c6f6557fe76cabc4d112333f9a'
from='montague.lit' to='capulet.lit' version='1.0'>
S: <stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
@ -113,31 +113,31 @@ C: <bidi xmlns='urn:xmpp:bidi'/>
<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='EXTERNAL'>
Y2FwdWxldC5saXQ=</auth>
S: <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
C: <stream:stream xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server' xmlns:db='jabber:server:dialback'
to='montague.lit' from='capulet.lit'
C: <stream:stream xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server' xmlns:db='jabber:server:dialback'
to='montague.lit' from='capulet.lit'
xml:lang='en' version='1.0'>
S: <stream:stream xmlns='jabber:server' xmlns:db='jabber:server:dialback'
xmlns:stream='http://etherx.jabber.org/streams' xml:lang='en'
id='b5cd769b1dc292c6f6557fe76cabc4d112333f9a'
S: <stream:stream xmlns='jabber:server' xmlns:db='jabber:server:dialback'
xmlns:stream='http://etherx.jabber.org/streams' xml:lang='en'
id='b5cd769b1dc292c6f6557fe76cabc4d112333f9a'
from='montague.lit' to='capulet.lit' version='1.0'>
S: <stream:features/>
<!-- At this point, S is allowed to send C stanzas from capulet.lit
since that is the value of 'to' in the stream open sent by C above.
-->
C: <iq from='juliet@capulet.lit/balcony' to='montague.lit' type='get'
C: <iq from='juliet@capulet.lit/balcony' to='montague.lit' type='get'
id='8dfc70af'><query xmlns='urn:xmpp:ping'/></iq>
S: <iq from='montague.lit' to='juliet@capulet.lit/balcony' type='result'
S: <iq from='montague.lit' to='juliet@capulet.lit/balcony' type='result'
id='8dfc70af'><query xmlns='urn:xmpp:ping'/></iq>
]]></example>
<example caption='Bidirectional Streams with Server Dialback'><![CDATA[
C: <stream:stream xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server' xmlns:db='jabber:server:dialback'
to='montague.lit' from='capulet.lit'
C: <stream:stream xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server' xmlns:db='jabber:server:dialback'
to='montague.lit' from='capulet.lit'
xml:lang='en' version='1.0'>
S: <stream:stream xmlns='jabber:server' xmlns:db='jabber:server:dialback'
xmlns:stream='http://etherx.jabber.org/streams' xml:lang='en'
id='65b30434afd7646699d077f7affcb2c120c48e18'
S: <stream:stream xmlns='jabber:server' xmlns:db='jabber:server:dialback'
xmlns:stream='http://etherx.jabber.org/streams' xml:lang='en'
id='65b30434afd7646699d077f7affcb2c120c48e18'
from='montague.lit' to='capulet.lit' version='1.0'>
S: <stream:features>
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
@ -145,13 +145,13 @@ S: <stream:features>
</stream:features>
C: <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
S: <proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
C: <stream:stream xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server' xmlns:db='jabber:server:dialback'
to='montague.lit' from='capulet.lit'
C: <stream:stream xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server' xmlns:db='jabber:server:dialback'
to='montague.lit' from='capulet.lit'
xml:lang='en' version='1.0'>
S: <stream:stream xmlns='jabber:server' xmlns:db='jabber:server:dialback'
xmlns:stream='http://etherx.jabber.org/streams' xml:lang='en'
id='b5cd769b1dc292c6f6557fe76cabc4d112333f9a'
S: <stream:stream xmlns='jabber:server' xmlns:db='jabber:server:dialback'
xmlns:stream='http://etherx.jabber.org/streams' xml:lang='en'
id='b5cd769b1dc292c6f6557fe76cabc4d112333f9a'
from='montague.lit' to='capulet.lit' version='1.0'>
S: <stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
@ -164,13 +164,13 @@ C: <bidi xmlns='urn:xmpp:bidi'/>
<!-- At this point S may send from capulet.lit.
-->
S: <db:result from='montague.lit' to='capulet.lit' type='valid'/>
C: <iq from='juliet@capulet.lit/balcony' to='montague.lit' type='get'
C: <iq from='juliet@capulet.lit/balcony' to='montague.lit' type='get'
id='8dfc70af'><query xmlns='urn:xmpp:ping'/></iq>
S: <iq from='montague.lit' to='juliet@capulet.lit/balcony' type='result'
S: <iq from='montague.lit' to='juliet@capulet.lit/balcony' type='result'
id='8dfc70af'><query xmlns='urn:xmpp:ping'/></iq>
S: <db:result from='conference.montague.lit' to='capulet.lit'>
1bac3ef56fed987cfe098c9785c654a5476ed765</db:result>
<!-- The above is also legal - S attempts to authenticate as
<!-- The above is also legal - S attempts to authenticate as
a different domain as well, presumably a MUC domain
-->
C: <db:result from='capulet.lit' to='conference.montague.lit' type='valid'/>

View File

@ -128,7 +128,7 @@
</section2>
<section2 topic="Buddycloud Channels" anchor="Buddycloud Channels">
<p>
Buddycloud channels are a bundle of <cite>XEP-0060</cite> publish-subscribe nodes with
Buddycloud channels are a bundle of <cite>XEP-0060</cite> publish-subscribe nodes with
identical subscribers and permissions presented as a JID-like
name (example:
<link url="buddycloud:juliet@capulit.lit">juliet@capulet.lit</link>
@ -232,7 +232,7 @@
]]>
</example>
<p>The entity then iterates through the &lt;item/&gt; elements, sending an
info discovery request to each JID.
info discovery request to each JID.
</p>
<example caption="The Entity sends a disco#info request to each component">
<![CDATA[
@ -280,7 +280,7 @@
</section2>
</section1>
<section1 topic="Register" anchor="register" xml:base="sections/40.register.xml">
<p>Upon connection to the buddycloud server a user should send a register
<p>Upon connection to the buddycloud server a user should send a register
stanza.</p>
<example caption="The Entity sends a register request to the domain">
@ -294,11 +294,11 @@
]]>
</example>
<p>The register request creates the user's personal channels on first use
and has the additional benefit of creating additional new channel nodes
<p>The register request creates the user's personal channels on first use
and has the additional benefit of creating additional new channel nodes
as they become available on the server (e.g. 'status' node, 'geoloc' nodes).
</p>
</section1>
<section1 topic="Channel and Node Configuration" anchor="channel-config" xml:base="sections/50.node-config.xml">
<p>Node metadata is used to describe the channel to users. All nodes in a
@ -767,32 +767,32 @@
<p>Many of the item use cases follow those from <cite>XEP-0060</cite>. This section notes
the departures from the parent XEP and specific requirements.
</p>
<section2 topic="Retrieving items" anchor="items-retrieve">
<section3 topic="Recent Items" anchor="items-recent">
<p>It is possible to retrieve any new items since last retrieval from all subscribed channels ('<em>/posts</em>' nodes specifically) since last retrieval using the <strong>recent items</strong> functionality.
</p>
<example caption="Recent items query">
<![CDATA[
<iq from="juliet@capulet.lit/bc-app" to="buddycloud.capulet.lit" type="get" id="recent-items:1">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<recent-items xmlns="http://buddycloud.org/v1"
since="2014-04-18T10:46.100Z"
<iq from="juliet@capulet.lit/bc-app" to="buddycloud.capulet.lit" type="get" id="recent-items:1">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<recent-items xmlns="http://buddycloud.org/v1"
since="2014-04-18T10:46.100Z"
max="50"
parent-only="true" />
</pubsub>
parent-only="true" />
</pubsub>
</iq>
]]>
</example>
<example caption="Recent items reply">
<![CDATA[
<iq to="juliet@capulet.lit/bc-app" from="buddycloud.capulet.lit" type="result" id="recent-items:1">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<iq to="juliet@capulet.lit/bc-app" from="buddycloud.capulet.lit" type="result" id="recent-items:1">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<items node="/user/romeo@montague.lit/posts">
<item id="tag:channels.capulet.lit,/users/juliet@montague.lit/posts,16584564008760001">
...atom payload...
@ -811,16 +811,16 @@
...atom payload...
</item>
</items>
</pubsub>
</pubsub>
</iq>
]]>
</example>
<p>In this example <em>max</em> represents the maximum number of items the user wishes to retrieve
from any one channel, <em>since</em> is the datetime from which posts should start, and
<em>parent-only</em> allows users to requests posts which only start a discussion
<p>In this example <em>max</em> represents the maximum number of items the user wishes to retrieve
from any one channel, <em>since</em> is the datetime from which posts should start, and
<em>parent-only</em> allows users to requests posts which only start a discussion
(i.e. no reply posts).</p>
<section4 topic="Error Cases" anchor="items-recent-errorcases">
<p>The following extended error cases are used:
</p>
@ -843,19 +843,19 @@
</li>
</ul>
</section4>
</section3>
</section2>
<section2 topic="Deleting items" anchor="items-delete">
<example caption="The client sends">
<![CDATA[
<iq from="juliet@capulet.lit/bc-app" to="buddycloud.capulet.lit" type="set" id="retractitem:32">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<retract node="/user/juliet@capulet.lit/posts" notify="1">
<item id="1291048772456"/>
</retract>
</pubsub>
<iq from="juliet@capulet.lit/bc-app" to="buddycloud.capulet.lit" type="set" id="retractitem:32">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<retract node="/user/juliet@capulet.lit/posts" notify="1">
<item id="1291048772456"/>
</retract>
</pubsub>
</iq>
]]>
</example>
@ -868,10 +868,10 @@
replace the deleted post
<example caption="The Buddycloud server sends retractions out to online clients">
<![CDATA[
<message from="buddycloud.capulet.lit" id="bc:MGV3B" to="benvolio@montague.lit">
<event xmlns="http://jabber.org/protocol/pubsub#event">
<items node="/user/channeluser@example.com/posts">
<retract id="1291048772456"/>
<message from="buddycloud.capulet.lit" id="bc:MGV3B" to="benvolio@montague.lit">
<event xmlns="http://jabber.org/protocol/pubsub#event">
<items node="/user/channeluser@example.com/posts">
<retract id="1291048772456"/>
<item id="1291048772456">
<deleted-entry xmlns="http://purl.org/atompub/tombstones/1.0" ref="xmpp:buddycloud.capulet.lit?pubsub;action=retrieve;node=/user/juliet@capulet.lit/posts;item=1291048772456" when="2012-07-01T15:08:32.950Z">
<updated>2012-07-01T15:08:32.950Z</updated>
@ -884,8 +884,8 @@
<verb xmlns="http://activitystrea.ms/spec/1.0/">post</verb>
</deleted-entry>
</item>
</items>
</event>
</items>
</event>
</message>
]]>
</example>
@ -1209,7 +1209,7 @@
<p>
The Buddycloud server should make sure that the remote server
component is the authoritative Buddycloud server for the domain it
claims to represent. This is done by running the server discovery <!--
claims to represent. This is done by running the server discovery <!--
how do we reference a section in this document? -->
process and confirming the same XMPP component name.
</p>

View File

@ -15,17 +15,17 @@
<!ENTITY ITEM "&lt;item/&gt;">
<!ENTITY ITEMS "&lt;items/&gt;">
<!ENTITY PUBSUB "&lt;pubsub/&gt;">
<!ENTITY VEVENT "&lt;vevent/&gt;">
<!ENTITY VTODO "&lt;vtodo/&gt;">
<!ENTITY VJOURNAL "&lt;vjournal/&gt;">
<!ENTITY VFREEBUSY "&lt;vfreebusy/&gt;">
<!ENTITY VALARM "&lt;valarm/&gt;">
<!ENTITY VTIMEZONE "&lt;vtimezone/&gt;">
<!ENTITY SN "calendar">
<!ENTITY NS "urn:xmpp:tmp:&SN;:0">
<!ENTITY TODO "## TODO. ##">
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
@ -99,7 +99,7 @@
<p>This specification defines calendaring extensions to &xep0060; for the purposes of group calendaring and scheduling between "Calendar Users" (CUs) as defined by <cite>iTIP</cite>. Additionally, it defines extensions for accessing, managing, and sharing calendaring and scheduling information on a calendar server, reusing the syntax and semantics defined by <cite>CalDAV</cite>. Finally, it defines a mechanism for reminding of upcoming events by alarm notifications.</p>
<p>The protocol enables all common transactions such as publish, schedule, reschedule, respond to scheduling requests, negotiation of changes or cancel <cite>iCalendar</cite>-based calendar components, as well as search for busy time information. The protocol is a superset of <cite>Publish-Subscribe</cite> and will gracefully degrade to <cite>Publish-Subscribe</cite> for clients that do not support the calendaring extensions defined.</p>
</section2>
<!-- == How It Works ===================================================== -->
<section2 topic='How It Works' anchor='intro-howitworks'>
@ -135,7 +135,7 @@ END:VCALENDAR
]]></example>
<p>This specification is structured as follows: <link url='#disco'>Discovering Support</link> describes how to discover support for the calendaring extensions defined by this specification. An entity may create new calendar nodes as described in <link url='#create'>Creating Calendars</link>. The section on <link url='#publish'>Scheduling Calendar Entries</link> provides the transport specific information necessary to convey <cite>iTIP</cite> messages over <cite>Publish-Subscribe</cite> which enables transactions such as publish, schedule, reschedule, respond to scheduling requests, negotiation of changes or cancel iCalendar-based calendar components. The sections <link url='#retrieve'>Retrieving Calendar Entries</link> and <link url='#freebusy'>Retrieving Free/Busy Time</link> define how to retrieve items from a calendar node, and how to search for busy time information. <link url='#alarm'>Alarm Notifications</link> provide a mechanism for setting up and subscribing to alarm notifications.</p>
</section2>
<!-- == Formatting Conventions =========================================== -->
<section2 topic='Formatting Conventions' anchor='intro-conventions'>
@ -145,7 +145,7 @@ END:VCALENDAR
<p>Calendar components defined by <cite>RFC 2445</cite> are referred to with capitalized text. All calendar components start with the letter "V". For example, VEVENT refers to the event calendar component, VTODO refers to the to-do calendar component and VJOURNAL refers to the daily journal calendar component.</p>
<p>Properties defined by <cite>RFC 2445</cite> are referred to with capitalized, quoted-strings of text, followed by the word "property". For example, "ATTENDEE" property refers to the iCalendar property used to convey the calendar address of a "Calendar User". Property parameters are referred to with lower case, quoted-strings of text, followed by the word "parameter". For example, "value" parameter refers to the iCalendar property parameter used to override the default data type for a property value. Values are referred to with quoted-strings of text, either alone or followed by the word "value".</p>
</section2>
<!-- == Related Documents ================================================ -->
<section2 topic='Related Documents' anchor='intro-related'>
@ -169,7 +169,7 @@ END:VCALENDAR
<p>This specification follows the same pattern as the Internet calendaring and scheduling standards by developing all features based on a well-described data model.</p>
<p>As a brief overview, a calendar is modeled as a publish-subscribe node with a defined structure; each calendar node contains a number of items representing calendar objects. Each item representing a calendar object (event, to-do, journal entry, or other calendar components) is called a "calendar item".</p>
-->
<!-- == Calendar Service ================================================= -->
<section2 topic='Calendar Service' anchor='datamodel-service'>
@ -178,7 +178,7 @@ END:VCALENDAR
<p>A publish-subscribe service can advertise itself as a calendar service if it supports the functionality defined in this specification at any of its nodes. That might mean that calendar nodes are spread throughout the service and mixed with non-calendar nodes. Calendaring features are only required in the nodes that are calendar nodes.</p>
<p>The calendar service is the canonical location for calendar data and state information. Entities may submit requests to change data or download data. Entities may store calendar objects offline and attempt to synchronize at a later time. However, entities MUST be prepared for calendar data on the service to change between the time of last synchronization and when attempting an update, as calendar nodes may be shared and accessed by multiple entities.</p>
</section2>
<!-- == Calendar Nodes =================================================== -->
<section2 topic='Calendar Nodes' anchor='datamodel-nodes'>
@ -186,7 +186,7 @@ END:VCALENDAR
<p>A calendar node can be created through provisioning (i.e., automatically created when a user's account is provisioned), or it can be created with the publish-subscribe &lt;create/&gt; request (see section <link url='#create'>Creating Calendars</link>). It can be useful for a user to create additional calendars (e.g., soccer schedule) or for users to share a calendar (e.g., team events or conference rooms). However, note that this specification doesn&apos;t define the purpose of calendar nodes. Users may use the 'pubsub#title' and 'pubsub#description' fields in node meta-data to find out what a calendar node is for.</p>
<p>Calendar nodes MUST only contain calendar items. This ensures that entities do not have to deal with non-calendar data in a calendar node.</p>
</section2>
<!-- == Calendar Items =================================================== -->
<section2 topic='Calendar Items' anchor='datamodel-items'>
@ -265,7 +265,7 @@ END:VCALENDAR
-->
<p>&TODO;</p>
</section2>
<!-- == Calendar Entry State ============================================= -->
<section2 topic='Calendar Entry State' anchor='entrystate'>
@ -273,7 +273,7 @@ END:VCALENDAR
<p>The state of an entry is defined by the "STATUS" property and is controlled by the "Organizer." There is no default value for the "STATUS" property. The "Organizer" sets the "STATUS" property to the appropriate value for each calendar entry.</p>
<p>The state of a particular "Attendee" relative to an entry is defined by the "partstat" parameter in the "ATTENDEE" property for each "Attendee". When an "Organizer" issues the initial entry, "Attendee" status is unknown. The "Organizer" specifies this by setting the "partstat" parameter to "needs-action". Each "Attendee" modifies their "ATTENDEE" property "partstat" parameter to an appropriate value.</p>
</section2>
<!-- == Calendar Item Revisions ========================================== -->
<section2 topic='Calendar Item Revisions' anchor='itemrevisions'>
@ -284,9 +284,9 @@ END:VCALENDAR
<li>The "SEQUENCE" property value MUST NOT be incremented when an "Attendee" modifies the "ATTENDEE" property "partstat" parameter, when an "Attendee" submits a counter proposal to negotiate a change in a calendar item, or when an "Attendee" grants another CU (or several CUs) the right to attend on their behalf.</li>
<li>The "SEQUENCE" property value MUST NOT be incremented when retrieving calendar objects from a calendar node or sending pubsub notifications to subscribers.</li>
</ul>
<p>The value of the "SEQUENCE" property contained in a response from an "Attendee" may not always match the current revision of the master calendar entry. Implementations may choose to indicate to the "Attendee" that the response is to an entry that has been revised and allow the CU to decide whether or not to send the response.</p>
<p>The value of the "SEQUENCE" property contained in a response from an "Attendee" may not always match the current revision of the master calendar entry. Implementations may choose to indicate to the "Attendee" that the response is to an entry that has been revised and allow the CU to decide whether or not to send the response.</p>
</section2>
<!-- == Request Sequencing =============================================== -->
<section2 topic='Request Sequencing' anchor='requestsequencing'>
@ -300,9 +300,9 @@ END:VCALENDAR
======================================================================= -->
<section1 topic='Discovering Support' anchor='disco'>
<!-- == Service Features ================================================= -->
<section2 topic='Service Features' anchor='disco-service'>
<p>A calendar service MUST respond to service discovery information requests qualified by the 'http://jabber.org/protocol/disco#info' namespace. The "disco#info" result returned by a calendar service MUST indicate the identity of a pubsub service and indicate which pubsub features are supported. A calendar service supporting the features described in this specification MUST also include "&NS;" as a feature in the "disco#info" result. A feature of "&NS;" &VNOTE; in the result MUST indicate that the service supports all MUST level requirements in this specification.</p>
<example caption='Entity queries calendar service regarding supported features'><![CDATA[
@ -327,9 +327,9 @@ END:VCALENDAR
</iq>
]]></example>
</section2>
<!-- == Node Information ================================================= -->
<section2 topic='Node Information' anchor='disco-node'>
<p>A calendar service MUST also allow entities to query individual nodes for the information associated with that node. A calendar service supporting the features described in this specification MUST include "&NS;" &VNOTE; as a feature in the "disco#info" result for a calendar node. It MUST NOT include the feature in the result for a non-calendar node. The "disco#info" result MAY include detailed meta-data about the node as described in section 5.4 of <cite>XEP-0060</cite>.</p>
<example caption='Entity queries a node for information'><![CDATA[
@ -437,7 +437,7 @@ END:VCALENDAR
</iq>
]]></example>
</section2>
<!-- == Success Case ===================================================== -->
<section2 topic='Success Case' anchor='create-success'>
@ -459,7 +459,7 @@ END:VCALENDAR
<li>The requesting entity does not have sufficient privileges to create calendar nodes.</li>
</ol>
<p>These error cases are described more fully in the following sections.</p>
<section3 topic='Calendar Node Creation Not Supported' anchor='create-error-notallowed'>
<p>If the calendar service does not allow new calendar nodes to be created, it MUST respond with a &notallowed; error.</p>
<example caption='Service does not allow creation of calendar nodes'><![CDATA[
@ -476,7 +476,7 @@ END:VCALENDAR
</iq>
]]></example>
</section3>
<section3 topic='Insufficient Privileges' anchor='create-error-forbidden'>
<p>If the requesting entity has insufficient privileges to create new calendar nodes, the service MUST respond with a &forbidden; error.</p>
<example caption='Requesting entity has insufficient privileges to create calendar nodes'><![CDATA[
@ -628,7 +628,7 @@ END:VCALENDAR
</iq>
]]></example>
</section2>
<!-- == Success Case ===================================================== -->
<section2 topic='Success Case' anchor='publish-success'>
@ -642,7 +642,7 @@ END:VCALENDAR
<p class='box'>Note: If the publisher previously published an item with the same ItemID, successfully processing the request means that the service MUST proceed as described in <cite>RFC 2446</cite> for the calendaring-specific method used. This usually means that the service MUST overwrite the old calendar entry with a modified entry and then proceed as follows.</p>
<p>The calendar service MUST then send one &MESSAGE; stanza containing a pubsub event notification to each entity that meets the criteria for receiving a notification, as described in section 7.1.2 of <cite>XEP-0060</cite>. Event notifications MUST be sent specifying the "PUBLISH" method, even if the event notification results from a publishing request that specified a different method.</p>
</section2>
<!-- == Error Cases ====================================================== -->
<section2 topic='Error Cases' anchor='publish-error'>
@ -654,7 +654,7 @@ END:VCALENDAR
<li>The calendar component submitted in the request does not conform to the configuration.</li>
</ol>
<p>These error cases are described more fully in the following sections.</p>
<section3 topic='Bad Payload' anchor='publish-error-badpayload'>
<p>If the namespace of the root payload element submitted in the request does not match the configured namespace for the node (i.e., the 'urn:ietf:params:xml:ns:xcal' namespace) or the payload does not conform to the syntax of the 'urn:ietf:params:xml:ns:xcal' namespace, the service MUST respond with a &badrequest; error, which SHOULD also include a pubsub-specific error condition of &lt;invalid-payload/&gt;.</p>
<example caption='Entity attempts to publish item with invalid payload'><![CDATA[
@ -676,15 +676,15 @@ END:VCALENDAR
</iq>
]]></example>
</section3>
<section3 topic='Unsupported Calendar Component' anchor='publish-error-unsupported'>
<p>If the calendar component submitted in the request does not contain a type of calendar component that is supported in the calendar node (see section <link url='#config'>Calendar Node Configuration</link>), the service MUST respond with a &badrequest; error, which SHOULD also include a pubsub-specific error condition of &lt;item-forbidden/&gt;.</p>
</section3>
<section3 topic='Invalid Calendar Item' anchor='publish-error-invalid'>
<p>If the calendar component submitted in the request does not obey all restrictions specified in section <link url='#datamodel-items'>Calendar Items</link> (e.g., calendar items MUST NOT contain more than one type of calendar component), in section <link url='#publish-request'>Request</link> (e.g., the request MUST specify an iCalendar "METHOD" property, etc.), and/or those defined for the specified iCalendar method, the service MUST respond with a &badrequest; error, which SHOULD also include a pubsub-specific error condition of &lt;invalid-payload/&gt;.</p>
</section3>
<section3 topic='Request Does Not Match Configuration' anchor='publish-error-forbidden'>
<p>If the calendar component submitted in the request does not conform to the configuration of the calendar node where the component will be stored (see section <link url='#config'>Calendar Node Configuration</link>), the service MUST respond with a &badrequest; error, which SHOULD also include a pubsub-specific error condition. The following rules apply:</p>
<ul>
@ -737,7 +737,7 @@ END:VCALENDAR
</iq>
]]></example>
</section2>
<!-- == Success Case ===================================================== -->
<section2 topic='Success Case' anchor='retrieve-success'>
@ -763,7 +763,7 @@ END:VCALENDAR
</iq>
]]></example>
</section2>
<!-- == Error Cases ====================================================== -->
<section2 topic='Error Cases' anchor='retrieve-error'>
@ -779,11 +779,11 @@ END:VCALENDAR
<section3 topic='Invalid Filter' anchor='retrieve-error-invalid'>
<p>If the &lt;filter/&gt; element does not conform to the syntax of the 'urn:ietf:params:xml:ns:caldav' namespace, the service MUST respond with a &badrequest; error. For instance, a &lt;filter/&gt; cannot nest a &lt;comp name='VEVENT'/&gt; element in a &lt;comp name='VTODO'/&gt; element, and a &lt;filter/&gt; cannot nest a &lt;time-range start='...' end='...'/&gt; element in a &lt;prop name='SUMMARY'/&gt; element.</p>
</section3>
<section3 topic='Unsupported Filter' anchor='retrieve-error-unsupported'>
<p>If any &lt;comp-filter/&gt;, &lt;prop-filter/&gt;, or &lt;param-filter/&gt; element used in the &lt;filter/&gt; element in the report request makes a reference to components, properties, or parameters for which queries are not supported by the server (i.e., if the &lt;filter/&gt; element attempts to reference an unsupported component, property, or parameter), the service MUST respond with a &badrequest; error.</p>
</section3>
<section3 topic='Request Does Not Match Configuration' anchor='retrieve-error-forbidden'>
<p>If the reporting request does not conform to the configuration of the calendar node being queried (see section <link url='#config'>Calendar Node Configuration</link>), the service MUST respond with a &badrequest; error<!--, which SHOULD also include a pubsub-specific error condition-->. The following rules apply:</p>
<ul>
@ -791,7 +791,7 @@ END:VCALENDAR
<li>If any XML element specifying a range of time has its start or end DATE or DATE-TIME values greater than the value of the "&SN;#max_date_time" configuration option, the service MUST respond with a &badrequest; error.</li>
</ul>
</section3>
<section3 topic='Unsupported Collation' anchor='retrieve-error-collation'>
<p>If any XML attribute specifying a collation does not specify a collation supported by the calendar service as described in section 7.5 of <cite>RFC 4791</cite>, the service MUST respond with a &badrequest; error.</p>
</section3>
@ -834,7 +834,7 @@ END:VCALENDAR
</iq>
]]></example>
</section2>
<!-- == Success Case ===================================================== -->
<section2 topic='Success Case' anchor='freebusy-success'>
@ -860,7 +860,7 @@ END:VCALENDAR
</iq>
]]></example>
</section2>
<!-- == Error Cases ====================================================== -->
<section2 topic='Error Cases' anchor='freebusy-error'>
@ -919,7 +919,7 @@ END:VCALENDAR
</iq>
]]></example>
</section2>
<!-- == Subscribing to Alarm Notifications =============================== -->
<section2 topic='Subscribing to Alarm Notifications' anchor='alarm-subscribe'>
@ -946,9 +946,9 @@ END:VCALENDAR
</iq>
]]></example>
</section2>
<!-- == Receiving Alarm Notifications ==================================== -->
<section2 topic='Receiving Alarm Notifications' anchor='alarm-notify'>
<p>When an alarm is triggered, the calendar service MUST send one &MESSAGE; stanza containing a alarm notification to each entity that meets the criteria for receiving a alarm notification (typically to each approved subscriber who configured its subscription to have the "calendar#notify_alarm" configuration option set to "true"). Depending on the node configuration, the alarm notification either will or will not contain the payload, as shown below.</p>
<section3 topic='Notification With Payload' anchor='alarm-notify-withpayload'>
@ -1002,10 +1002,10 @@ END:VCALENDAR
</section1>
<section1 topic='Examples' anchor='examples'>
<section2 topic='Published Event Examples' anchor='examples-event'>
<p>&TODO;</p>
<section3 topic='A Minimal Published Event'></section3>
<section3 topic='Changing A Published Event'></section3>
<section3 topic='Canceling A Published Event'></section3>
@ -1019,7 +1019,7 @@ END:VCALENDAR
<section2 topic='Group Event Examples' anchor='examples-groupevent'>
<p>&TODO;</p>
<section3 topic='A Group Event Request'></section3>
<section3 topic='Reply To A Group Event Request'></section3>
<section3 topic='Update An Event'></section3>
@ -1037,7 +1037,7 @@ END:VCALENDAR
<section2 topic='Busy Time Examples' anchor='examples-freebusy'>
<p>&TODO;</p>
<!-- <section3 topic='Request Busy Time'></section3> -->
<!-- <section3 topic='Reply To A Busy Time Request'></section3> -->
@ -1047,7 +1047,7 @@ END:VCALENDAR
<section2 topic='Recurring Event and Time Zone Examples' anchor='examples-recurringevent'>
<p>&TODO;</p>
<section3 topic='A Recurring Event Spanning Time Zones'></section3>
<section3 topic='Modify A Recurring Instance'></section3>
<section3 topic='Cancel an Instance'></section3>
@ -1084,7 +1084,7 @@ END:VCALENDAR
<section2 topic='Journal Examples' anchor='examples-journal'>
<p>&TODO;</p>
</section2>
<section2 topic='Notification Examples' anchor='examples-notification'>
<p>&TODO;</p>
</section2>

View File

@ -66,7 +66,7 @@
<p>This XEP defines an approach for ensuring that all of my devices
get both sides of all conversations in order to avoid user
confusion. As a pleasant side-effect, information about the current
state of a conversation is shared between all of a user's clients
state of a conversation is shared between all of a user's clients
that implement this protocol.</p>
</section1>
@ -110,7 +110,7 @@
<feature var='urn:xmpp:carbons:0'/>
...
</query>
</iq>]]></example>
</iq>]]></example>
</section2>
<section2 topic='Enabling Carbons' anchor='enabling'>
@ -236,7 +236,7 @@
RECOMMENDED. (Note: another XEP might be written to document
traditional resource locking, if the documentation in &rfc3921bis;
is not sufficient.)</p>
<p>Also note that &xep0085; recommends sending chat state
notifications as chat type messages, which means that they will be
subject to Carbon-copying. This is intentional.</p>
@ -328,7 +328,7 @@
copied client had terminated the conversation. In order to
prevent unwanted termination of conversations on other resources,
clients SHOULD NOT send <em>gone</em> chat states on logout, but
instead SHOULD count on the unavailable presence to convey the change
instead SHOULD count on the unavailable presence to convey the change
in attention.</p>
<p>Upon receiving an outbound notification of any chat state other
than <em>gone</em>, the copied client MAY conclude that the
@ -372,7 +372,7 @@
encryption mechanism is adjusted to have knowledge of Carbons.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='reg'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>

View File

@ -49,10 +49,10 @@
<p>Juliet has an XMPP client on her phone, which is available to receive messages. However most of the time
Juliet has her phone screen turned off and is not interested in the status of her contacts unless they are
communicating with her.</p>
<p>Juliet's client informs the server when Juliet is not interacting with it. The server uses this information to
suppress or reduce stanzas that are unimportant, such as status updates.</p>
<p>When Juliet returns to her IM client, the client again informs the server, this time to report that it is active
again. The server then disables its traffic optimisations and restores the stream to its normal state.</p>
</section2>
@ -90,12 +90,12 @@
<example caption='Client indicates it is inactive'><![CDATA[
<inactive xmlns='urn:xmpp:csi'/>
]]></example>
<p>As might be anticipated, when the client is active again it sends an &lt;active/&gt; element:</p>
<example caption='Client indicates it is active'><![CDATA[
<active xmlns='urn:xmpp:csi'/>
]]></example>
<p>There is no reply from the server to either of these elements (though they may indirectly cause the server to
send stanzas, e.g. to update presence information when the client becomes active after a period of inactivity).</p>
</section2>
@ -103,10 +103,10 @@
<section1 topic='Business Rules' anchor='rules'>
<p>As this protocol is for indication only, clients MUST NOT make assumptions about how the server
will use the active/inactive state information.</p>
<p>The server MUST assume all clients to be in the 'active' state until the client indicates otherwise. Also the
CSI active/inactive state is unrelated to the user's presence, the server MUST treat the two independently.</p>
<p>This protocol is intended primarily for clients with human interaction. Due to the open-ended nature of
the possible optimisations implemented by the server, it may not be suitable for non-IM purposes where the
fully standard behaviour of XMPP is required.</p>

View File

@ -4,9 +4,9 @@
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<!--
<!--
© XMPP Standards Foundation, 2016
Author: Peter Waher
Author: Peter Waher
-->
<xep>
<header>
@ -57,7 +57,7 @@ Author: Peter Waher
</p>
<example caption='Hinting at a content type'>
<![CDATA[
<message
<message
from='person1@example.org/34892374'
to='person2@example.org/938089023'
type='chat'>
@ -76,7 +76,7 @@ Author: Peter Waher
</p>
<example caption='Alternate encoding'>
<![CDATA[
<message
<message
from='person1@example.org/34892374'
to='person2@example.org/938089023'
type='chat'>
@ -96,7 +96,7 @@ Author: Peter Waher
</p>
<example caption='Alternate encodings'>
<![CDATA[
<message
<message
from='person1@example.org/34892374'
to='person2@example.org/938089023'
type='chat'>
@ -156,20 +156,20 @@ Author: Peter Waher
<section1 topic='Implementation Notes' anchor='impl'>
<section2 topic='Content Types' anchor='contentTypes'>
<p>
This document does not specify how content types are to be interpreted, or if content types are valid or well defined.
It does not specify which content types are to be understood, or when. It only provides a means to hint or include different
encodings in the same message.
This document does not specify how content types are to be interpreted, or if content types are valid or well defined.
It does not specify which content types are to be understood, or when. It only provides a means to hint or include different
encodings in the same message.
</p>
</section2>
<section2 topic='Custom Content Types' anchor='customTypes'>
<p>
It is possible to use custom or vendor-specific content types. These types are marked by prefixing the subtype with
It is possible to use custom or vendor-specific content types. These types are marked by prefixing the subtype with
<strong>x.</strong> for custom unregistered types, and with <strong>vnd.</strong> for registered vendor specific types.
</p>
</section2>
<section2 topic='Stanza size' anchor='stanzaSize'>
<p>
Care has to be taken when sending multiple encodings of the same message, as to not reach the smallest allowed
Care has to be taken when sending multiple encodings of the same message, as to not reach the smallest allowed
maximum stanza size used by client and server software.
</p>
</section2>
@ -186,9 +186,9 @@ Author: Peter Waher
<code>
<![CDATA[
<?xml version='1.0' encoding='UTF-8'?>
<!--
<!--
© XMPP Standards Foundation, 2016
Author: Peter Waher
Author: Peter Waher
-->
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'

View File

@ -167,7 +167,7 @@
<section1 topic='Business Rules' anchor='bizrules'>
<p>To limit the extent of the presence leak, the receiving entity SHOULD send only bare presence without the XMPP &PRIORITY;, &SHOW;, or &STATUS; element. Unfortunately, this has two implications:</p>
<ol>
<li><p>The initiating entity cannot know which of the receiving entity's resources is more likely to engage in communication. This might imply that the initiating entity will need to send a session initiation request or other communication to more than one of the receiving entity's resources (and then retract the session initiation requests that are not answered by the receiving entity). Solutions to that problem are out of scope for this specification.</p></li>
<li><p>Set up of a session might be delayed (e.g., because in Jingle it is desirable to start negotiating candidates as soon as possible but a user interface that prompts the receiving entity to explicitly approve of divulging presence will tend to delay call setup). As a result, it may be advantageous to have a way to configure unconditional decloaking in certain deployments, at least within the same trust domain.</p></li>

View File

@ -322,7 +322,7 @@
</x>
</presence>
]]></example>
<p>The source then delivers that presence stanza to its local users. (Note: The shadow needs to send only one presence stanza to the source, thus reducing the number of stanzas sent over the server-to-server link between the peerhost and the firsthost.)</p>
<p>The source then delivers that presence stanza to its local users. (Note: The shadow needs to send only one presence stanza to the source, thus reducing the number of stanzas sent over the server-to-server link between the peerhost and the firsthost.)</p>
</section2>
<section2 topic='Sending a Message' anchor='send'>
<p>When a user sends a message to an instance, the instance sends the message to its local occupants and to other instances.</p>
@ -349,7 +349,7 @@
<body>Message 4.</body>
</message>
]]></example>
<p>The source then delivers that message stanza to its local users. (Note: The shadow needs to send only one message stanza to the source, thus reducing the number of stanzas sent over the server-to-server link between the peerhost and the firsthost.)</p>
<p>The source then delivers that message stanza to its local users. (Note: The shadow needs to send only one message stanza to the source, thus reducing the number of stanzas sent over the server-to-server link between the peerhost and the firsthost.)</p>
</section2>
<section2 topic='sync' anchor='Re-Syncing after Connectivity Loss'>
<p>To follow.</p>
@ -365,11 +365,11 @@
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='reg'>
<p>This document requires no interaction with the &REGISTRAR;.</p>
<p>This document requires no interaction with the &REGISTRAR;.</p>
</section1>
<section1 topic='Acknowledgements' anchor='ack'>

View File

@ -51,7 +51,7 @@
<p>
MUC uses lots of bandwidth. Sometimes the network link that S2S traffic is carried on is heavily constrained. This protocol reduces the amount of traffic going across S2S through local mirrors of remote MUC rooms.
It needs no bandwidth for remote rooms without local occupants.
</p>
</p>
</section2>
<section2 topic='Requirements' anchor='reqs'>
<p>The following is a list of goals for the design of this extension:
@ -153,7 +153,7 @@ To determine if a server or service supports Distributed MUC, the requesting ent
</presence>
]]></example>
<p>chatroom@conference.fairfax.tridsys.com recognises that the mirror service is now mirrorring it,
<p>chatroom@conference.fairfax.tridsys.com recognises that the mirror service is now mirrorring it,
and performs the usual ACL checks as if wayne@tridsys.com/TransVerse had joined directly,
sending presence to all occupants. The master MUC will be able to take advantage of the fact that the
rosters are being maintained by the distributed MUC services and send one presence with no
@ -191,13 +191,13 @@ will contain information like if the room is moderated, how much history, who is
id='roster1'
type='set'>
<roster xmlns='urn:xmpp:dmuc:0'>
<item affiliation='owner'
<item affiliation='owner'
jid='scott@fairfax.tridsys.com' name='Scott'/>
<item affiliation='admin'
<item affiliation='admin'
jid='kevin@fairfax.tridsys.com' name='Kevin'/>
<item affiliation='none'
<item affiliation='none'
jid='wayne@raleigh.tridsys.com' name='Wayne'/>
<item affiliation='none'
<item affiliation='none'
jid='keith@raleigh.tridsys.com' name='Keith'/>
</roster>
</iq>
@ -214,7 +214,7 @@ will contain information like if the room is moderated, how much history, who is
to='chatroom@conference.fairfax.tridsys.com/Wayne'
id='history'
type='get'>
<room xmlns='urn:xmpp:dmuc:0'
<room xmlns='urn:xmpp:dmuc:0'
id='chatroom@conference.fairfax.tridsys.com'>
<history xmlns='http://jabber.org/protocol/muc'/>
</room>
@ -227,20 +227,20 @@ will contain information like if the room is moderated, how much history, who is
id='history1'
type='result'>
<history xmlns='http://jabber.org/protocol/muc'>
<message xmlns='jabber:client'
<message xmlns='jabber:client'
from='chatroom@conference.fairfax.tridsys.com/Wayne' type='groupchat'>
<body>All work and no play makes Jack a dull boy</body>
<delay xmlns='urn:xmpp:delay'
from='wayne@raleigh.tridsys.com/TransVerse'
<delay xmlns='urn:xmpp:delay'
from='wayne@raleigh.tridsys.com/TransVerse'
stamp='2011-01-19T08:02:43Z'/>
</message>
...
</message>
<message xmlns='jabber:client'
<message xmlns='jabber:client'
from='chatroom@conference.fairfax.tridsys.com/Scott' type='groupchat'>
<body>All work and no play makes Jack a dull boy</body>
<delay xmlns='urn:xmpp:delay'
from='scott@fairfax.tridsys.com/TransVerse'
<delay xmlns='urn:xmpp:delay'
from='scott@fairfax.tridsys.com/TransVerse'
stamp='2011-01-19T08:23:10Z'/>
<body>All work and no play makes Jack a dull boy</body>
</message>
@ -293,7 +293,7 @@ will contain information like if the room is moderated, how much history, who is
</section3>
<section3 topic='Failure case' anchor='joinfail'>
<p>If the master doesn't allow the user to join, it sends the standard MUC error to the mirror.
<p>If the master doesn't allow the user to join, it sends the standard MUC error to the mirror.
The mirror SHOULD only send the rejection to the user that failed to join. Other users don't
need to know.
</p>
@ -310,7 +310,7 @@ the \40 to an @ and the \2f to a / to get the target user's JID and then forward
type='error'>
<x xmlns='http://jabber.org/protocol/muc'/>
<error type='auth'>
<registration-required
<registration-required
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</presence>
@ -325,7 +325,7 @@ the \40 to an @ and the \2f to a / to get the target user's JID and then forward
type='error'>
<x xmlns='http://jabber.org/protocol/muc'/>
<error type='auth'>
<registration-required
<registration-required
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</presence>
@ -368,7 +368,7 @@ the \40 to an @ and the \2f to a / to get the target user's JID and then forward
</x>
</presence>
]]></example>
<example caption='Mirror delivers join to its occupants'><![CDATA[
<presence
from='chatroom@conference.fairfax.tridsys.com/Kevin'

View File

@ -56,7 +56,7 @@
<di>
<dt>Self-hosted domain</dt>
<dd>A domain whose owner acts as its hosting provider.</dd>
</di>
</di>
<di>
<dt>Delegation</dt>
<dd>A ceremony that acts as proof of the intent of the owner of a hosted domain to cede control to a hosting provider for a given protocol.</dd>
@ -115,7 +115,7 @@
<section1 topic='Generic Use Cases' anchor='genericusecases'>
<p>The DNA mechanism can be used for multiple different protocols. In particular, client-to-server XMPP and server-to-server XMPP are discussed herein, but the general approach could be used for non-XMPP protocols such as SMTP. As such, the protocol syntax offered here is normative for XMPP, but merely illustrative for other protocols, which will need their own protocol bindings.</p>
<p>The following domain names are used in the examples:</p>
<dl>
<dl>
<di>
<dt>asserted.tld</dt>
<dd>The domain name being asserted.</dd>
@ -180,7 +180,7 @@
<section1 topic='DNA for XMPP Federation' anchor='federation'>
<p>Two XMPP servers, each of which hosts multiple domains that they do not directly control, desire to connect in order to exchange traffic for at least two of those domains, one on either side (we call this a "dimain pair").</p>
<p>The following domain names are used in the examples:</p>
<dl>
<dl>
<di>
<dt>target.tld</dt>
<dd>The domain portion of the JID in the <strong>"to"</strong> address of the stanza that caused this connection to be initiated.</dd>
@ -232,7 +232,7 @@ CN=server.originatingprovider.tld
<p>The <strong>"to"</strong> and <strong>"from"</strong> addresses are REQUIRED on the stream:stream tag. These represent the first domain pair associated with this stream, and are the domain names from the stanza that caused this connection to be established.</p>
<p>To announce its support for DNA, the receiving server asserts its identity in the stream features following TLS negotiation. </p>
<example caption='Domain name assertion in stream features'><![CDATA[<stream:features>
<example caption='Domain name assertion in stream features'><![CDATA[<stream:features>
<assert xmlns='urn:xmpp:dna:0' from='target.tld'/>
</stream:features>
]]></example>
@ -296,7 +296,7 @@ CN=server.originatingprovider.tld
<section2 topic='Announcing Support' anchor='announce'>
<p>To announce its support for DNA, the server asserts its identity in the stream features following TLS negotiation. The server MUST offer the identity of the domain specified in the client's stream header <strong>"to"</strong> attribute.</p>
<example caption='Server assertion'><![CDATA[<stream:features>
<example caption='Server assertion'><![CDATA[<stream:features>
<assert xmlns='urn:xmpp:dna:0' from='target.tld'/>
</stream:features>
]]></example>
@ -315,7 +315,7 @@ CN=server.originatingprovider.tld
<p>The domains offered are International Domain Names, as specified in <strong>rfc3920bis</strong>.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>For the urn:xmpp:dna:proof:attribute-cert proof type, the trust path for an assertion flows from two different trust anchors, one that proves the identity of the hosting provider, and another that proves the identity of the delegating party.</p>
<p>For the urn:xmpp:dna:proof:attribute-cert proof type, the trust path for an assertion flows from two different trust anchors, one that proves the identity of the hosting provider, and another that proves the identity of the delegating party.</p>
<p>All proof types SHALL have a mechanism to limit the period of availability.</p>
<p>All proof types SHALL include a mechanism for revocation.</p>
</section1>

View File

@ -196,7 +196,7 @@
application-specific error condition element of &lt;bad-timestamp/&gt; as shown below:</p>
<example><![CDATA[
<message from='romeo@example.net/orchard'
id='6410ed123'
id='6410ed123'
to='juliet@capulet.net/balcony'
type='error'>
<signed xmlns='urn:xmpp:signed:0'>
@ -213,7 +213,7 @@
error condition element of &lt;bad-signature/&gt; as shown below:</p>
<example><![CDATA[
<message from='romeo@example.net/orchard'
id='6410ed123'
id='6410ed123'
to='juliet@capulet.net/balcony'
type='error'>
<e2e xmlns='urn:xmpp:signed:0'>

View File

@ -169,7 +169,7 @@
</x>
</presence>
]]></example>
<example caption='Proxy delivers join to its occupants'><![CDATA[
<presence
from='jabberchat\40talk.example.com@mirror.remote.example.com/Curtis'
@ -332,7 +332,7 @@
</message>
]]></example>
</section3>
</section2>
<section2 topic='Administration Use Cases' anchor='admin'>

View File

@ -132,7 +132,7 @@
</query>
</iq>]]></example>
</section2>
<section2 topic='Invitation' anchor='1to1-invite'>
<p>
In order to invite someone to a game, the initiator sends a message to her/his opponent containing an &INVITE; element,
@ -166,7 +166,7 @@
<game var='http://jabber.org/protocol/games/checkers'/>
</invite>
</message>]]></example>
<table caption='Invitation types'>
<tr>
<th>Invitation Type</th>
@ -198,7 +198,7 @@
<td>A previous invitation with the same match ID in the &THREAD; element is no longer valid.</td>
</tr>
--> </table>
<p>
An invitation of type "renew" SHOULD contain the same match ID and &GAME; element as the initial "new" invitation.
It MUST only be send when the previous match with the same match ID has been terminated.
@ -260,7 +260,7 @@
<thread>romeo@montague.net-juliet@capulet.com-checkers-1591-02-21T12:56:15Z-1234</thread>
<join xmlns='http://jabber.org/protocol/games'/>
</message>]]></example>
<p>
A successful join MUST be confirmed by sending the same message (with different sender and recipient) back to the opponent.
</p>
@ -281,9 +281,9 @@
</error>
</message>]]></example>
</section2>
<section2 topic='Game Play' anchor='1to1-play'>
<p>
<p>
A turn in a game is sent in a message (of type "chat") to the other player's full JID.
The &MESSAGE; stanza contains a &TURN; element which contains the element, representing the desired action (e.g. &MOVE;) qualified by the namespace of the particular game.
The action itself can be further described by attributes or child elements (see corresponding game protocol).
@ -324,13 +324,13 @@
<saved xmlns='http://jabber.org/protocol/games'/>
</message>]]></example>
<p>After receiving such an notification, an implementation MAY decide to save the game, too.</p>
<p>
When playing games with incomplete knowledge,
it is desirable that both players save the game at the same time in order to save a clean game state.
The game protocol MUST define whether its game has to be saved independently or mutually.
</p>
<p>
If a game needs to be saved mutually by both players,
one of the players requests the game to be saved by sending a message with a &SAVE; child element as follows.
@ -373,7 +373,7 @@
</section2>
<section2 topic='Game Loading' anchor='1to1-load'>
<p>
<p>
An XMPP entity that wishes to resume a saved game has to send an invitation
of "type" 'adjourned' to the same opponent it began playing with.
It MAY also resume the game with another opponent, but then it MUST use the "type" 'constructed' and a new match ID.
@ -475,7 +475,7 @@
A terminating &MESSAGE; with reason 'cheating' SHOULD be send, if an illegal move is received.
If one entity receives a terminating &MESSAGE; although it already send one by it's own, it MUST ignore it.
</p>
<table caption='Termination reasons'>
<tr>
<th>Reason</th>
@ -550,7 +550,7 @@
xmlns='http://jabber.org/protocol/games'
elementFormDefault='qualified'>
<xs:import
<xs:import
namespace='jabber:x:data'
schemaLocation='http://www.xmpp.org/schemas/x-data.xsd'/>

View File

@ -48,10 +48,10 @@
informs the device or application of desired sensor data, when certain conditions have been met, defined by the device or application.
</p>
<p>
The architecture defined in this document, permits the specification of conditions individually, something that would not be possible, or very difficult to achieve, if a centralized
publish/subscribe or multi-cast pattern would have been used. By allowing individual conditions to be specified, devices or applications can be informed of information that best suit them,
and when it suits them, instead of having to figure out, from the Thing perspective, a common denominator, sufficiently good for all intended devices or applications. Furthermore,
by aligning itself with XEP-0323 and the request/response pattern, the Thing can easily integrate with a provisioning server, as defined in XEP-0324: &xep0324;, to allow for delegation
The architecture defined in this document, permits the specification of conditions individually, something that would not be possible, or very difficult to achieve, if a centralized
publish/subscribe or multi-cast pattern would have been used. By allowing individual conditions to be specified, devices or applications can be informed of information that best suit them,
and when it suits them, instead of having to figure out, from the Thing perspective, a common denominator, sufficiently good for all intended devices or applications. Furthermore,
by aligning itself with XEP-0323 and the request/response pattern, the Thing can easily integrate with a provisioning server, as defined in XEP-0324: &xep0324;, to allow for delegation
of trust and allowing detailed provisioning of who is allowed to receive what information. Through the use of attributes defined in XEP-0326: &xep0326; subscriptions can be extended
to underlying nodes controlled by the Thing as well.
</p>
@ -267,7 +267,7 @@
<section1 topic='Use Cases' anchor='usecases'>
<p>
Subscribing to events is performed much the same way as requesting sensor data from a device, as defined in <link url='http://xmpp.org/extensions/xep-0323.html#usecases'>XEP-0323</link>.
Instead of requesting the data using the <strong>req</strong> element of the <strong>urn:xmpp:iot:sensordata</strong> namespace, it is done using the <strong>subscribe</strong> element
Instead of requesting the data using the <strong>req</strong> element of the <strong>urn:xmpp:iot:sensordata</strong> namespace, it is done using the <strong>subscribe</strong> element
of the <strong>urn:xmpp:iot:events</strong> namespace. Much of the syntax of this <strong>subscribe</strong> element coincides with that of the <strong>req</strong> element,
with some differences, as will be described in this document.
</p>
@ -285,7 +285,7 @@
<section2 topic='Request Subscription of momentary values' anchor='subscribemomentary'>
<p>
The client that wishes to receive momentary values regularly from the sensor initiates the request using the <strong>subscribe</strong> element sent to the device.
In the following example, a subscription is made to receive momentary values every five minutes (specified by the <strong>maxInterval</strong> attribute), with no
In the following example, a subscription is made to receive momentary values every five minutes (specified by the <strong>maxInterval</strong> attribute), with no
field-specific conditions attached.
</p>
<example caption='Subscription request of momentary values from a device'>
@ -325,7 +325,7 @@
id='S0002'>
<subscribe xmlns='urn:xmpp:iot:events' seqnr='1' momentary='true' maxInterval='PT5M'/>
</iq>
<iq type='error'
from='device@clayster.com'
to='client@clayster.com/amr'
@ -380,7 +380,7 @@
id='S0003'>
<unsubscribe xmlns='urn:xmpp:iot:events' seqnr='1'/>
</iq>
<iq type='result'
from='device@clayster.com'
to='client@clayster.com/amr'
@ -610,7 +610,7 @@
</section2>
<section2 topic='Overriding subscriptions' anchor='overriding'>
<p>
A subscriber can only have one active subscription per node on a Thing. If a Thing does not support nodes, each subscriber can only have one active subscription
A subscriber can only have one active subscription per node on a Thing. If a Thing does not support nodes, each subscriber can only have one active subscription
per corresponding Thing. This means, that a new event subscription automatically overrides (or unsubscribes) any existing subscription on the corresponding node or Thing.
This in turn makes it easier for subscribers to handle restarts and avoids multiplicity problems due to lack of synchronization between subscriber and Thing.
</p>
@ -652,7 +652,7 @@
elementFormDefault='qualified'>
<xs:import namespace='urn:xmpp:iot:sensordata'/>
<xs:element name='subscribe'>
<xs:complexType>
<xs:choice minOccurs='0' maxOccurs='unbounded'>

View File

@ -26,7 +26,7 @@
<email>goffi@goffi.org</email>
<jid>goffi@jabber.fr</jid>
</author>
<revision>
<version>0.0.1</version>
<date>2016-01-16</date>

View File

@ -114,9 +114,9 @@ Initiator Responder
]]></example>
<p>The initiator then immediately begins sending IBB packets using an IQ-set for each chunk as described in XEP-0047, and the responder acknowledges each IQ-set.</p>
<example caption='An IBB packet'><![CDATA[
<iq from='romeo@montague.net/orchard'
<iq from='romeo@montague.net/orchard'
id='ls72b58f'
to='juliet@capulet.com/balcony'
to='juliet@capulet.com/balcony'
type='set'>
<data xmlns='http://jabber.org/protocol/ibb' seq='0' sid='ch3d9s71'>
qANQR1DBwU4DX7jmYZnncmUQB/9KuKBddzQH+tZ1ZywKK0yHKnq57kWq+RFtQdCJ
@ -128,9 +128,9 @@ Initiator Responder
</iq>
]]></example>
<example caption='An IBB ack'><![CDATA[
<iq from='juliet@capulet.com/balcony'
<iq from='juliet@capulet.com/balcony'
id='ls72b58f'
to='romeo@montague.net/orchard'
to='romeo@montague.net/orchard'
type='result'/>
]]></example>
<p>Once the parties have finished using the bytestream (e.g., because a complete file has been sent), either party can send a Jingle session-terminate action.</p>

View File

@ -121,7 +121,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring
</services>
</iq> ]]></example>
<em>In this example 'montague.lit' XMPP Domain a Relay Service and a Tracker Service. The Relay Service can be contacted in order to retrieve Relay Channels. The Tracker Service can be contacted in order to retrieve its known services.</em>
</section2>
</section2>
<section2 topic="Jingle Client Searches for Services on a Retrieved Tracker Service" anchor="clientcheckownserver">
<p>A Jingle Client MAY NOT be satisfied with only one Relay Service entry found. So it keeps the search on the known Tracker Services.</p>
<example caption="Service List Request"><![CDATA[
@ -140,7 +140,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring
<services xmlns='http://jabber.org/protocol/jinglenodes'/>
</iq> ]]></example>
<em>In this example 'capulet.lit' returned an empty service list, meaning that it does NOT known ANY Relay or Tracker Services.</em>
</section2>
</section2>
<section2 topic="Jingle Client Searches for Services on online Roster Entries" anchor="clientcheckownserver">
<p>A Jingle Client MAY NOT be satisfied with only one Relay Service entry found. So it keeps the search on his Roster Items until find the desired amount of Relay Services, or while it does NOT exceed a search depth or ANY other Client implementation policy. The Client SHOULD keep a list of visited Tracker Services in order to avoid searching twice in same Service Entity.</p>
<example caption="Service List Request"><![CDATA[