<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>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 ===================================================== -->
<section2topic='How It Works'anchor='intro-howitworks'>
@ -135,7 +135,7 @@ END:VCALENDAR
]]></example>
<p>This specification is structured as follows: <linkurl='#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 <linkurl='#create'>Creating Calendars</link>. The section on <linkurl='#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 <linkurl='#retrieve'>Retrieving Calendar Entries</link> and <linkurl='#freebusy'>Retrieving Free/Busy Time</link> define how to retrieve items from a calendar node, and how to search for busy time information. <linkurl='#alarm'>Alarm Notifications</link> provide a mechanism for setting up and subscribing to alarm notifications.</p>
<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 ================================================ -->
<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 ================================================= -->
<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>
<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 <create/> request (see section <linkurl='#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'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>
<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>
<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>
<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>
<examplecaption='Entity queries calendar service regarding supported features'><![CDATA[
@ -327,9 +327,9 @@ END:VCALENDAR
</iq>
]]></example>
</section2>
<!-- == Node Information ================================================= -->
<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>
<examplecaption='Entity queries a node for information'><![CDATA[
@ -437,7 +437,7 @@ END:VCALENDAR
</iq>
]]></example>
</section2>
<!-- == Success Case ===================================================== -->
<pclass='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>
<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 <invalid-payload/>.</p>
<examplecaption='Entity attempts to publish item with invalid payload'><![CDATA[
<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 <linkurl='#config'>Calendar Node Configuration</link>), the service MUST respond with a &badrequest; error, which SHOULD also include a pubsub-specific error condition of <item-forbidden/>.</p>
<p>If the calendar component submitted in the request does not obey all restrictions specified in section <linkurl='#datamodel-items'>Calendar Items</link> (e.g., calendar items MUST NOT contain more than one type of calendar component), in section <linkurl='#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 <invalid-payload/>.</p>
</section3>
<section3topic='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 <linkurl='#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 ===================================================== -->
<p>If the <filter/> 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 <filter/> cannot nest a <comp name='VEVENT'/> element in a <comp name='VTODO'/> element, and a <filter/> cannot nest a <time-range start='...' end='...'/> element in a <prop name='SUMMARY'/> element.</p>
<p>If any <comp-filter/>, <prop-filter/>, or <param-filter/> element used in the <filter/> 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 <filter/> element attempts to reference an unsupported component, property, or parameter), the service MUST respond with a &badrequest; error.</p>
</section3>
<section3topic='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 <linkurl='#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>
<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 ===================================================== -->
<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>
<section3topic='Notification With Payload'anchor='alarm-notify-withpayload'>
<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>
<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>
<section2topic='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>
<section2topic='sync'anchor='Re-Syncing after Connectivity Loss'>
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>
<section2topic='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'>
<rosterxmlns='urn:xmpp:dmuc:0'>
<itemaffiliation='owner'
<itemaffiliation='owner'
jid='scott@fairfax.tridsys.com' name='Scott'/>
<itemaffiliation='admin'
<itemaffiliation='admin'
jid='kevin@fairfax.tridsys.com' name='Kevin'/>
<itemaffiliation='none'
<itemaffiliation='none'
jid='wayne@raleigh.tridsys.com' name='Wayne'/>
<itemaffiliation='none'
<itemaffiliation='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
<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 @@
<section1topic='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 @@
<section1topic='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>
<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>
<examplecaption='Domain name assertion in stream features'><![CDATA[<stream:features>
<examplecaption='Domain name assertion in stream features'><![CDATA[<stream:features>
<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>
<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>
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>
<section2topic='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 @@
<savedxmlns='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>
<section2topic='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.
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 @@
<section1topic='Use Cases'anchor='usecases'>
<p>
Subscribing to events is performed much the same way as requesting sensor data from a device, as defined in <linkurl='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 @@
<section2topic='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>
<examplecaption='Subscription request of momentary values from a device'>
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>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>
<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>
@ -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>
<section2topic="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>
<examplecaption="Service List Request"><![CDATA[
@ -140,7 +140,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring
<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>
<section2topic="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>
<examplecaption="Service List Request"><![CDATA[
@ -162,7 +162,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring
</iq> ]]></example>
<p>In this example 'juliet@capulet.lit/balcony' returned a Relay Service entry that is restricted to its roster. This Service is usable as the requester has 'juliet@capulet.lit/balcony' on its roster. Although, services with policy 'roster' MUST NOT be listed in Tracker Responses expects in Tracker Responses that comes from the Service Entity itself, in this case 'juliet@capulet.lit/balcony'.</p>
<em>In the presented example 'romeo@montague.lit/orchard' knows that 'juliet@capulet.lit/balcony' provides Relay Service, but if another entity requests 'romeo@montague.lit/orchard' its known services, it MUST NOT include 'juliet@capulet.lit/balcony' as it is a roster restricted entry.</em>
</section2>
</section2>
<section2topic="Jingle Client Consuming the Relay Service"anchor="clientconsumingrelay">
<p>A Jingle Client with direct access to a public IP can potentially provide the Relay Service becaming itself a Jingle Relay Node. The service can intend to provide a public service, or a restricted services based on user preferences, like buddylist, whitelist, blacklist, domain, etc...</p>
<p>
@ -236,35 +236,35 @@ All signalling, request, response and publishing is done via XMPP, not requiring
<td>id</td>
<td>A random candidate identifier generated by the Relay Service, which effectively maps to the created Channel; this SHOULD match the XML Nmtoken production <note>See <<linkurl='http://www.w3.org/TR/2000/WD-xml-2e-20000814#NT-Nmtoken'>http://www.w3.org/TR/2000/WD-xml-2e-20000814#NT-Nmtoken</link>></note> so that XML character escaping is not needed for characters such as '&'. In some situations the Jingle session identifier might have security implications. See &rfc4086; regarding requirements for randomness.</td>
<td>REQUIRED on response, NOT RECOMMENDED on requests</td>
</tr>
</tr>
<tr>
<td>host</td>
<td>The IP address or Host address of the Relay Channel.</td>
<td>The IP address or Host address of the Relay Channel.</td>
Emmanuel Gil Peyrot
6 years ago
committed by