This section shows two complete examples of bidirectional streams, the first example uses SASL EXTERNAL, the second uses Server Dialback.
- Buddycloud channels are a bundle of XEP-0060 publish-subscribe nodes with + Buddycloud channels are a bundle of XEP-0060 publish-subscribe nodes with identical subscribers and permissions presented as a JID-like name (example: juliet@capulet.lit @@ -232,7 +232,7 @@ ]]>
The entity then iterates through the <item/> elements, sending an - info discovery request to each JID. + info discovery request to each JID.
Upon connection to the buddycloud server a user should send a register +
Upon connection to the buddycloud server a user should send a register stanza.
The register request creates the user's personal channels on first use - and has the additional benefit of creating additional new channel nodes +
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).
- +Node metadata is used to describe the channel to users. All nodes in a @@ -767,32 +767,32 @@
Many of the item use cases follow those from XEP-0060. This section notes the departures from the parent XEP and specific requirements.
- +It is possible to retrieve any new items since last retrieval from all subscribed channels ('/posts' nodes specifically) since last retrieval using the recent items functionality.
In this example max represents the maximum number of items the user wishes to retrieve - from any one channel, since is the datetime from which posts should start, and - parent-only allows users to requests posts which only start a discussion + +
In this example max represents the maximum number of items the user wishes to retrieve + from any one channel, since is the datetime from which posts should start, and + parent-only allows users to requests posts which only start a discussion (i.e. no reply posts).
- +The following extended error cases are used:
@@ -843,19 +843,19 @@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 process and confirming the same XMPP component name.
diff --git a/inbox/calendaring.xml b/inbox/calendaring.xml index ec41cb0a..185b7d58 100644 --- a/inbox/calendaring.xml +++ b/inbox/calendaring.xml @@ -15,17 +15,17 @@ - + - + - + ]> @@ -99,7 +99,7 @@This specification defines calendaring extensions to &xep0060; for the purposes of group calendaring and scheduling between "Calendar Users" (CUs) as defined by iTIP. Additionally, it defines extensions for accessing, managing, and sharing calendaring and scheduling information on a calendar server, reusing the syntax and semantics defined by CalDAV. Finally, it defines a mechanism for reminding of upcoming events by alarm notifications.
The protocol enables all common transactions such as publish, schedule, reschedule, respond to scheduling requests, negotiation of changes or cancel iCalendar-based calendar components, as well as search for busy time information. The protocol is a superset of Publish-Subscribe and will gracefully degrade to Publish-Subscribe for clients that do not support the calendaring extensions defined.
This specification is structured as follows: Discovering Support describes how to discover support for the calendaring extensions defined by this specification. An entity may create new calendar nodes as described in Creating Calendars. The section on Scheduling Calendar Entries provides the transport specific information necessary to convey iTIP messages over Publish-Subscribe which enables transactions such as publish, schedule, reschedule, respond to scheduling requests, negotiation of changes or cancel iCalendar-based calendar components. The sections Retrieving Calendar Entries and Retrieving Free/Busy Time define how to retrieve items from a calendar node, and how to search for busy time information. Alarm Notifications provide a mechanism for setting up and subscribing to alarm notifications.
Calendar components defined by RFC 2445 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.
Properties defined by RFC 2445 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".
This specification follows the same pattern as the Internet calendaring and scheduling standards by developing all features based on a well-described data model.
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".
--> - +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.
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.
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 Creating Calendars). 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.
Calendar nodes MUST only contain calendar items. This ensures that entities do not have to deal with non-calendar data in a calendar node.
&TODO;
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.
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.
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.
+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.
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.
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 XEP-0060.
These error cases are described more fully in the following sections.
- +If the calendar service does not allow new calendar nodes to be created, it MUST respond with a ¬allowed; error.
If the requesting entity has insufficient privileges to create new calendar nodes, the service MUST respond with a &forbidden; error.
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 RFC 2446 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.
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 XEP-0060. Event notifications MUST be sent specifying the "PUBLISH" method, even if the event notification results from a publishing request that specified a different method.
These error cases are described more fully in the following sections.
- +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/>.
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 Calendar Node Configuration), the service MUST respond with a &badrequest; error, which SHOULD also include a pubsub-specific error condition of <item-forbidden/>.
If the calendar component submitted in the request does not obey all restrictions specified in section Calendar Items (e.g., calendar items MUST NOT contain more than one type of calendar component), in section Request (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/>.
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 Calendar Node Configuration), the service MUST respond with a &badrequest; error, which SHOULD also include a pubsub-specific error condition. The following rules apply:
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.
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.
If the reporting request does not conform to the configuration of the calendar node being queried (see section Calendar Node Configuration), the service MUST respond with a &badrequest; error. The following rules apply:
If any XML attribute specifying a collation does not specify a collation supported by the calendar service as described in section 7.5 of RFC 4791, the service MUST respond with a &badrequest; error.
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.
&TODO;
- +&TODO;
- +&TODO;
- + @@ -1047,7 +1047,7 @@ END:VCALENDAR&TODO;
- +&TODO;
&TODO;
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.
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.
@@ -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 gone 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.Upon receiving an outbound notification of any chat state other than gone, the copied client MAY conclude that the @@ -372,7 +372,7 @@ encryption mechanism is adjusted to have knowledge of Carbons.
This document requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
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.
- +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.
- +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.
As might be anticipated, when the client is active again it sends an <active/> element:
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).
@@ -103,10 +103,10 @@As this protocol is for indication only, clients MUST NOT make assumptions about how the server will use the active/inactive state information.
- +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.
- +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.
diff --git a/inbox/content-types.xml b/inbox/content-types.xml index 4c1aa65d..75c7bd1f 100644 --- a/inbox/content-types.xml +++ b/inbox/content-types.xml @@ -4,9 +4,9 @@ %ents; ]> -- 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.
- 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 x. for custom unregistered types, and with vnd. for registered vendor specific types.
- 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.
-
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:
-
+
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.
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.
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.)
+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.)
When a user sends a message to an instance, the instance sends the message to its local occupants and to other instances.
@@ -349,7 +349,7 @@ Message 4. ]]>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.)
+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.)
To follow.
@@ -365,11 +365,11 @@This document requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
This document requires no interaction with the ®ISTRAR;.
+This document requires no interaction with the ®ISTRAR;.
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. -
+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 ]]> -
chatroom@conference.fairfax.tridsys.com recognises that the mirror service is now mirrorring it, +
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'>
If the master doesn't allow the user to join, it sends the standard MUC error to the mirror.
+ 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.
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. The following domain names are used in the examples: 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"). The following domain names are used in the examples: The "to" and "from" 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. To announce its support for DNA, the receiving server asserts its identity in the stream features following TLS negotiation. 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 "to" attribute. The domains offered are International Domain Names, as specified in rfc3920bis. 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. 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. All proof types SHALL have a mechanism to limit the period of availability. All proof types SHALL include a mechanism for revocation.
+
+
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 @@
| Invitation Type | @@ -198,7 +198,7 @@A previous invitation with the same match ID in the &THREAD; element is no longer valid. |
|---|
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 @@
A successful join MUST be confirmed by sending the same message (with different sender and recipient) back to the opponent.
@@ -281,9 +281,9 @@ ]]>+
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 @@
After receiving such an notification, an implementation MAY decide to save the game, too.
- +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.
- +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 @@
+
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.
- +| Reason | @@ -550,7 +550,7 @@ xmlns='http://jabber.org/protocol/games' elementFormDefault='qualified'> -id | A random candidate identifier generated by the Relay Service, which effectively maps to the created Channel; this SHOULD match the XML Nmtoken production |
REQUIRED on response, NOT RECOMMENDED on requests | -
|---|---|---|---|
| host | -The IP address or Host address of the Relay Channel. | +The IP address or Host address of the Relay Channel. | REQUIRED on response |
| localport | -The port number to be used by the channel requester. | +The port number to be used by the channel requester. | REQUIRED on response |
| remoteport | -The port number to be offered to the remote party. | +The port number to be offered to the remote party. | REQUIRED on response |
| protocol | -The protocol supported by the retrieved channel. | +The protocol supported by the retrieved channel. | REQUIRED on response |
| maxkbps | -The maximum bandwidth supported by the channel. | +The maximum bandwidth supported by the channel. | OPTIONAL on response, NOT RECOMMENDED on requests. |
| expire | -The maximum amount of seconds that the channel can stay without receiving packets, without being deactivated and closed. | +The maximum amount of seconds that the channel can stay without receiving packets, without being deactivated and closed. | REQUIRED |
The value of the 'remoteport' attribute MUST be a valid IP Port number. This port MUST be used as media traffic destination port of the other party. Channel requester MUST use this port value in the candidate offer in combination with the 'host' attribute. Channel requester MUST NOT send any media stream to this port.
For transparent compatibility with major RTP Proxy Deployments, an RCTP Port is allocated and defined by default at Remoteport Attribute Value plus one. (Localport + 1)
-The value of the 'protocol' attribute MUST be a valid protocol value: 'udp' or 'tcp' as also defined in the XML Schema
-The value of the 'maxkbps' attribute MUST be a valid integer value representing the maximum kilobits per seconds the channel supports. This attribute is optional and MAY be used in Relay Channel with bandwidth limitation.
To advertise its support for the Jingle Nodes support, when replying to &xep0030; information requests an entity MUST return URNs for any version of this protocol that the entity supports -- e.g., "http://jabber.org/protocol/jinglenodes" for this version&VNOTE;.
@@ -429,14 +429,14 @@ All signalling, request, response and publishing is done via XMPP, not requiringThe man-in-the-middle can get the password using brute-force. Both public keys and the four salt strings are now known. To keep hidden as man-in-the-middle, the attacker needs to create a respondSalt for both peers that matches its public key, the password, the challengeSalt, and the hash sum it send. The problem for the attacking client is that it had to send out a hash sum at a point where it is not possible to get the shared key (the respondSalt is missing). If the hash sum is secure against creating collisions this is not possible. The man-in-the-middle has to use brute force and create two collisions in a very short time frame.
If an entity supports the zrtp-hash session-info message, it MUST advertise that fact in its responses to &xep0030; information ("disco#info") requests by returning a feature of "urn:xmpp:jingle:apps:rtp:zrtp:0":
{ "tag" : {
- "tag2" : [
+ "tag2" : [
{ "attr" : "attr-value1" },
{ "attr" : "attr-value2" } ]
}
diff --git a/inbox/lop.xml b/inbox/lop.xml
index de70ab3c..b87e499f 100644
--- a/inbox/lop.xml
+++ b/inbox/lop.xml
@@ -104,17 +104,17 @@
- In short, a resource consumer maintains a villein that communicates with a resource provider's farm in order to spawn and compute with a virtual machine that leverages the computing resources of the provider. + In short, a resource consumer maintains a villein that communicates with a resource provider's farm in order to spawn and compute with a virtual machine that leverages the computing resources of the provider.
The farm specification for <presence/> is built on the specification as defined by the Instant Messaging XMPP specification
A <spawn_vm/> element is wrapped by an <iq/> element. The purpose of <spawn_vm/> is to have a farm create a new virtual machine. It is through a virtual machine that a villein is able to access the computing resources of the physical device that hosts the farm (i.e. the resource provider). A virtual machine will maintain a state throughout a villein "session" with that virtual machine. The only way to alter the state of a virtual machine is through submitting jobs and updating its variable bindings
A <submit_job/> element is wrapped by an <iq/> element. The purpose of <submit_job/> is to send code (i.e. expressions, statements, instructions) to a virtual machine for execution (i.e. evaluation, interpretation). The expression SHOULD be respective of the virtual machine's language (i.e. the virtual machine's species). If they are not, then evaluation errors SHOULD occur. The expression submitted through a <submit_job/> stanza can be short (e.g. set a variable value, get a variable value) or long (e.g. define a class/method, execute a long running body of statements). The submitted expression is called a job in Linked Process and is assigned a job_id as specified by the <iq/> id attribute value. That is, the staza id of the <submit_job/> is the job's id.
The virtual machine's state exists over the villein's session with the virtual machine. Thus, note the result of the following <submit_job/>.
-A <ping_job/> element is wrapped by an <iq/> element. The purpose of <ping_job/> is to determine the status (i.e. progress, state) of a previously submitted <submit_job/> stanza (i.e. job) that has yet to complete. @@ -314,7 +314,7 @@
@@ -354,10 +354,10 @@
After the previous <manage_bindings/> stanza has been processed by the virtual machine, it is possible to use the bindings in a statement. For example, in JavaScript
-
+
var fact = name + " knows josh and peter";
-
+
will set fact to the value "marko knows josh and peter" as well as make it an accessible binding.
The http://linkedprocess.org/2009/06/Farm# <feature/> denotes that the XMPP client is in fact a farm.
- For presenting permissions, configurations, and statistics, a farm uses the data forms XEP-0004 XMPP extension in its disco#info response. The following list of <field/> variables (var) are presented below with their requirements specification. What is published by the farm's data form MUST be what is implemented by the farm and its spawned virtual machines. In other words, the data form MUST be consistent with the behavior of the farm and the virtual machines
| Server state | Client state (jabber:iq:roster) | @@ -369,9 +369,9 @@The ad-hoc commands protocol is not supported. |
For the syntax of these errors, see &xep0086;. Naturally, other errors may be returned as well (e.g., &internalserver; if the service cannot be shut down).
+For the syntax of these errors, see &xep0086;. Naturally, other errors may be returned as well (e.g., &internalserver; if the service cannot be shut down).
The privacy list name MUST be equal to "urn:xmpp:muclight:0"
Obviously, this method won't work properly in XMPP Server Federation.
-As opposed to XEP-0016, it is allowed to send "delta" privacy lists.
+As opposed to XEP-0016, it is allowed to send "delta" privacy lists.
Moderated Room -- The owner is allowed to kick users, revoke roles and save the match; antonym: Unmoderated Room.
- +Hidden Room -- a room that cannot be found by any user through normal means such as searching and service discovery; antonym: Public Room.
Public Room -- a room that can be found by any user through normal means such as searching and service discovery; antonym: Hidden Room.
- +Members-Only Room -- a room that a user cannot enter without being on the member list; antonym: Open Room.
Open Room -- a room that anyone may enter without being on the member list; antonym: Members-Only Room.
- +Password-Protected Room -- a room that a user cannot enter without first providing the correct password; antonym: Unsecured Room.
@@ -170,14 +170,14 @@ a room that anyone is allowed to enter without first providing the correct password; antonym: Password-Protected Room. -Fully-Anonymous Room -- - a room in which the full JIDs or bare JIDs of occupants cannot be discovered by anyone, +
Fully-Anonymous Room -- + a room in which the full JIDs or bare JIDs of occupants cannot be discovered by anyone, including the room owner; contrast with Non-Anonymous Room and Semi-Anonymous Room.
-Semi-Anonymous Room -- - a room in which an occupant's full JID can be discovered by the room owner only; +
Semi-Anonymous Room -- + a room in which an occupant's full JID can be discovered by the room owner only; contrast with Fully-Anonymous Room and Non-Anonymous Room.
-Non-Anonymous Room -- - a room in which an occupant's full JID is exposed to all other occupants; +
Non-Anonymous Room -- + a room in which an occupant's full JID is exposed to all other occupants; contrast with Semi-Anonymous Room and Fully-Anonymous Room.
@@ -195,7 +195,7 @@active -- within a match, turns are possible, options cannot be changed
paused -- halted within a match, turns are not possible, options cannot be changed
- +Information about affiliations MUST be sent in all presence stanzas generated or reflected by the match and sent to occupants.
- +- A Jabber entity may wish to discover if a service implements the - Multi-User Game protocol; in order to do so, it sends a service + A Jabber entity may wish to discover if a service implements the + Multi-User Game protocol; in order to do so, it sends a service discovery information ("disco#info") query to the service's JID:
- The service discovery items ("disco#items") protocol enables a user to query a - service for a list of associated items, which in the case of a game service would + The service discovery items ("disco#items") protocol enables a user to query a + service for a list of associated items, which in the case of a game service would consist of the active game rooms hosted by the service.
- If the full list of rooms is large (see &xep0030; for details), - the service MAY return only a partial list of rooms. - If it does so, it SHOULD include a <set/> element (as defined in &xep0059;) + If the full list of rooms is large (see &xep0030; for details), + the service MAY return only a partial list of rooms. + If it does so, it SHOULD include a <set/> element (as defined in &xep0059;) to indicate that the list is not the full result set.
- If the full list of rooms is large, - the service MAY return only a partial list of rooms. - If it does so, it SHOULD include a <set/> element (as defined in &xep0059;) + If the full list of rooms is large, + the service MAY return only a partial list of rooms. + If it does so, it SHOULD include a <set/> element (as defined in &xep0059;) to indicate that the list is not the full result set.
@@ -523,8 +523,8 @@- Using the disco#info protocol, a user may also query a specific room for - more detailed information about the room. A user MAY do so before entering a + Using the disco#info protocol, a user may also query a specific room for + more detailed information about the room. A user MAY do so before entering a room in order to discover the room configuration.
- A room MUST also return more detailed information in its disco#info response - using &xep0128;, identified by inclusion of a hidden FORM_TYPE field whose + A room MUST also return more detailed information in its disco#info response + using &xep0128;, identified by inclusion of a hidden FORM_TYPE field whose value is "http://jabber.org/protocol/mug#matchinfo". It MUST include a 'mug#game' field specifiying the namespace of the game. @@ -606,8 +606,8 @@ ]]>
- An implementation MAY return a list of existing occupants if that - information is publicly available, or return no list at all if this + An implementation MAY return a list of existing occupants if that + information is publicly available, or return no list at all if this information is kept private.
- Note: These <item/> elements are qualified by the disco#items namespace, - not the mug namespace; this means that they cannot possess 'role' attributes, + Note: These <item/> elements are qualified by the disco#items namespace, + not the mug namespace; this means that they cannot possess 'role' attributes, for example.
- If a non-occupant attempts to send a disco request to an address of the form - &ROOMJID;, a MUG service SHOULD return the request to the entity and specify a - &badrequest; error condition. If an occupant sends such a request, the service + If a non-occupant attempts to send a disco request to an address of the form + &ROOMJID;, a MUG service SHOULD return the request to the entity and specify a + &badrequest; error condition. If an occupant sends such a request, the service MAY pass it through the intended recipient.
- A Jabber user may want to discover if one of the user's contacts supports the + A Jabber user may want to discover if one of the user's contacts supports the Multi-User Game protocol. This is done using Service Discovery.
- A user may also query a contact regarding which room the contact is in. - This is done by querying the contact's full JID (<user@host/resource>) - while specifying the Service Discovery node + A user may also query a contact regarding which room the contact is in. + This is done by querying the contact's full JID (<user@host/resource>) + while specifying the Service Discovery node 'http://jabber.org/protocol/mug#matches':
Invitations MAY be based on room JIDs rather than bare JIDs - (so that, for example, an occupant could invite someone from one match to + (so that, for example, an occupant could invite someone from one match to another without knowing that person's bare JID). Thus the service MUST handle both the invites and declines.
@@ -887,7 +887,7 @@ from='island-chess@games.shakespeare.lit/damsel' to='alonso@shakespeare.lit/pda'>- Note: The order of the presence stanzas sent to the new occupant is important. + Note: The order of the presence stanzas sent to the new occupant is important. The service MUST first send the complete list of the existing occupants to the - new occupant and only then send the new occupant's own presence to the new - occupant. This helps the client know when it has received the complete + new occupant and only then send the new occupant's own presence to the new + occupant. This helps the client know when it has received the complete "room roster".
- If the room is non-anonymous, the service MUST send the new occupant's full JID - to all occupants using extended presence information in an &GAME; element qualified - by the 'http://jabber.org/protocol/mug' namespace and containing an &ITEM; child + If the room is non-anonymous, the service MUST send the new occupant's full JID + to all occupants using extended presence information in an &GAME; element qualified + by the 'http://jabber.org/protocol/mug' namespace and containing an &ITEM; child with a 'jid' attribute specifying the occupant's full JID:
- If the room is semi-anonymous, the service MUST send presence from the new occupant - to all occupants as specified above, but MUST include the new occupant's full JID - only in the presence notifications it sends to the room owner and not to any other + If the room is semi-anonymous, the service MUST send presence from the new occupant + to all occupants as specified above, but MUST include the new occupant's full JID + only in the presence notifications it sends to the room owner and not to any other occupant.
- If the room is fully-anonymous, the service MUST send presence from the new occupant - to all occupants as specified above, but MUST NOT include the new occupant's full JID + If the room is fully-anonymous, the service MUST send presence from the new occupant + to all occupants as specified above, but MUST NOT include the new occupant's full JID to any other occupant.
- If the room requires a password and the user did not supply one (or the password - provided is incorrect), the service MUST deny access to the room and inform the - user that they are unauthorized; this is done by returning a presence stanza of + If the room requires a password and the user did not supply one (or the password + provided is incorrect), the service MUST deny access to the room and inform the + user that they are unauthorized; this is done by returning a presence stanza of type "error" specifying a ¬authorized; error:
Passwords SHOULD be supplied with the presence stanza sent when entering the room, - contained within an <game/> element qualified by the - 'http://jabber.org/protocol/mug' namespace and containing a <password/> child. - Passwords are to be sent as cleartext; no other authentication methods are supported - at this time, and any such authentication or authorization methods shall be defined - in a separate specification (see the Security Considerations + contained within an <game/> element qualified by the + 'http://jabber.org/protocol/mug' namespace and containing a <password/> child. + Passwords are to be sent as cleartext; no other authentication methods are supported + at this time, and any such authentication or authorization methods shall be defined + in a separate specification (see the Security Considerations section of this document).
- If the room is members-only but the user is not on the member list, the service MUST - deny access to the room and inform the user that they are not allowed to enter the - room; this is done by returning a presence stanza of type "error" specifying a + If the room is members-only but the user is not on the member list, the service MUST + deny access to the room and inform the user that they are not allowed to enter the + room; this is done by returning a presence stanza of type "error" specifying a ®istration; error condition:
- If the room already contains another user with the nickname desired by the user - seeking to enter the room (or if the nickname is reserved by another user on the - member list), the service MUST deny access to the room and inform the user of the - conflict; this is done by returning a presence stanza of type "error" specifying a + If the room already contains another user with the nickname desired by the user + seeking to enter the room (or if the nickname is reserved by another user on the + member list), the service MUST deny access to the room and inform the user of the + conflict; this is done by returning a presence stanza of type "error" specifying a &conflict; error condition:
- If the room has reached its maximum number of occupants, the service SHOULD - deny access to the room and inform the user of the restriction; this is done - by returning a presence stanza of type "error" specifying a &unavailable; + If the room has reached its maximum number of occupants, the service SHOULD + deny access to the room and inform the user of the restriction; this is done + by returning a presence stanza of type "error" specifying a &unavailable; error condition:
If a user attempts to enter a room while it is "locked" (i.e., before the room creator - provides an initial configuration and therefore before the room officially exists), the + provides an initial configuration and therefore before the room officially exists), the service MUST refuse entry and return an ¬found; error to the user:
If the room does not already exist when the user seeks to enter it, the service SHOULD - create it; however, this is not required, since an implementation or deployment MAY - choose to restrict the privilege of creating rooms. For details, see the + create it; however, this is not required, since an implementation or deployment MAY + choose to restrict the privilege of creating rooms. For details, see the Creating a Room section of this document.
If the role is already taken, the service must return the following error.
If the requested role doesn't exist in the match, the service MUST return a not-acceptable error. @@ -1193,7 +1193,7 @@ ]]>
- In order to see what players are ready to start, the service MUST reflect + In order to see what players are ready to start, the service MUST reflect the start message from each player to all players.
@@ -1232,7 +1232,7 @@ it MUST update the match status from inactive to active by a presence broadcast to all occupants. If the owner changes the configuration or roles change after a player sent his message - and before the service sends presence broadcast indicating the game status active, + and before the service sends presence broadcast indicating the game status active, the player MUST send the message again. @@ -1420,7 +1420,7 @@If a client wants to resign, he sends the following. @@ -1440,7 +1440,7 @@ based on the game specification.
The game protocol respectively the game protocol implementation decides when a match is over.
@@ -1478,9 +1478,9 @@
- Since each occupant has a unique room JID, an occupant MAY send a "private message" to a - selected occupant via the service by sending a message to the occupant's match JID. The message - type SHOULD be "chat", or MAY be left unspecified (i.e., a normal message). This privilege + Since each occupant has a unique room JID, an occupant MAY send a "private message" to a + selected occupant via the service by sending a message to the occupant's match JID. The message + type SHOULD be "chat", or MAY be left unspecified (i.e., a normal message). This privilege SHOULD be allowed to any occupant (even a spectator in a moderated room).
- The service is responsible for changing the 'from' address to the sender's match JID and + The service is responsible for changing the 'from' address to the sender's match JID and delivering the message to the intended recipient's full JID.
- If the sender attempts to send a private message to a room JID that does not exist, + If the sender attempts to send a private message to a room JID that does not exist, the service MUST return an ¬found; error to the sender.
- If the sender is not an occupant of the room in which the intended recipient is visiting, + If the sender is not an occupant of the room in which the intended recipient is visiting, the service MUST return a ¬acceptable; error to the sender.
- If allowed in accordance with room configuration, an occupant MAY be allowed to - retrieve the list of room members. For details, see the + If allowed in accordance with room configuration, an occupant MAY be allowed to + retrieve the list of room members. For details, see the Modifying the Member List section of this document.
- If a game element or the var attribute with the game namespace is - missing then the service MUST deny creating a room and send a + If a game element or the var attribute with the game namespace is + missing then the service MUST deny creating a room and send a presence with a bad request error back to the user.
@@ -1733,7 +1733,7 @@ from='island-chess@games.shakespeare.lit/damsel'> to='miranda@shakespeare.lit/desktop'>Alternatively, the room owner MAY cancel the configuration process:
If the room owner cancels the initial configuration, the service SHOULD destroy the room, making sure to send unavailable presence to the room owner (see the "Destroying a Room" use case for protocol details).
@@ -2095,7 +2095,7 @@ type='result'>
@@ -2326,20 +2326,20 @@
- In the context of a members-only match, the member list is essentially a
+ In the context of a members-only match, the member list is essentially a
"whitelist" of people who are allowed to enter the match. Anyone who is not
a member is effectively banned from entering the match.
- In the context of an open match, the member list is simply a list of users
- (bare JID and reserved nick) who are registered with the match. Such users
- may appear in a match roster, have their match nickname reserved, be
+ In the context of an open match, the member list is simply a list of users
+ (bare JID and reserved nick) who are registered with the match. Such users
+ may appear in a match roster, have their match nickname reserved, be
returned in search results, and the like.
It is RECOMMENDED that only the room owner
- has the privilege to modify the member list in members-only rooms.
- To do so, the owner first requests the member list by querying the room
+ has the privilege to modify the member list in members-only rooms.
+ To do so, the owner first requests the member list by querying the room
for all users with an affiliation of "member":
- Note: A service SHOULD also return the member list to any occupant in a
- members-only room; i.e., it SHOULD NOT generate a &forbidden; error when
- a member in the room requests the member list.
- This functionality may assist clients in showing all the existing members
- even if some of them are not in the room, e.g. to help a member determine
- if another user should be invited.
- A service SHOULD also allow any member to retrieve the member list even
+ Note: A service SHOULD also return the member list to any occupant in a
+ members-only room; i.e., it SHOULD NOT generate a &forbidden; error when
+ a member in the room requests the member list.
+ This functionality may assist clients in showing all the existing members
+ even if some of them are not in the room, e.g. to help a member determine
+ if another user should be invited.
+ A service SHOULD also allow any member to retrieve the member list even
if not yet an occupant.
The service MUST then return the full member list to the owner qualified
- by the 'http://jabber.org/protocol/mug#owner' namespace; each item MUST
+ by the 'http://jabber.org/protocol/mug#owner' namespace; each item MUST
include the 'affiliation' and 'jid' attributes and MAY include the 'nick' and
'role' attributes for each members that is currently an occupant.
- The owner MAY then modify the member list. In order to do so, the owner MUST
- send the changed items (i.e., only the "delta") to the service; each item MUST
- include the 'affiliation' attribute (normally set to a value of "member" or "none")
- and 'jid' attribute but SHOULD NOT include the 'nick' attribute and MUST NOT include
+ The owner MAY then modify the member list. In order to do so, the owner MUST
+ send the changed items (i.e., only the "delta") to the service; each item MUST
+ include the 'affiliation' attribute (normally set to a value of "member" or "none")
+ and 'jid' attribute but SHOULD NOT include the 'nick' attribute and MUST NOT include
the 'role' attribute (which is used to manage game roles in a room):
- The service MUST change the affiliation of any affected user.
- If the user has been removed from the member list, the service MUST change the user's
- affiliation from "member" to "none".
+ The service MUST change the affiliation of any affected user.
+ If the user has been removed from the member list, the service MUST change the user's
+ affiliation from "member" to "none".
If the user has been added to the member list, the service MUST change the user's affiliation to "member".
- If a removed member is currently in a members-only room, the service SHOULD kick
- the occupant by changing the removed member's affiliation to "none" and send appropriate
- presence to the removed member as previously described.
- No matter whether the removed member was in or out of a members-only room, the service MUST
+ If a removed member is currently in a members-only room, the service SHOULD kick
+ the occupant by changing the removed member's affiliation to "none" and send appropriate
+ presence to the removed member as previously described.
+ No matter whether the removed member was in or out of a members-only room, the service MUST
subsequently refuse entry to the user.
- For all room types, the service MUST send updated presence from this individual to all occupants,
- indicating the change in affiliation by including an <game/> element qualified by the
- 'http://jabber.org/protocol/mug' namespace and containing an <item/> child with the
+ For all room types, the service MUST send updated presence from this individual to all occupants,
+ indicating the change in affiliation by including an <game/> element qualified by the
+ 'http://jabber.org/protocol/mug' namespace and containing an <item/> child with the
'affiliation' attribute set to a value of "none".
- In addition, the service SHOULD send an invitation to any user who has been added to the
- member list of a members-only room if the user is not currently affiliated with the
- room, for example as an owner (such a user would by definition not be
- in the match; note also that this example includes a password but not a reason --
+ In addition, the service SHOULD send an invitation to any user who has been added to the
+ member list of a members-only room if the user is not currently affiliated with the
+ room, for example as an owner (such a user would by definition not be
+ in the match; note also that this example includes a password but not a reason --
both child elements are OPTIONAL):
- While only the owner SHOULD be allowed to modify the member list,
- an implementation MAY provide a configuration option that opens invitation privileges
- to any member of a members-only match. In such a situation, any invitation sent SHOULD
- automatically trigger the addition of the invitee to the member list.
- However, if invitation privileges are restricted to the owner and a mere member attempts
- to a send an invitation, the service MUST deny the invitation request and return a
+ While only the owner SHOULD be allowed to modify the member list,
+ an implementation MAY provide a configuration option that opens invitation privileges
+ to any member of a members-only match. In such a situation, any invitation sent SHOULD
+ automatically trigger the addition of the invitee to the member list.
+ However, if invitation privileges are restricted to the owner and a mere member attempts
+ to a send an invitation, the service MUST deny the invitation request and return a
&forbidden; error to the sender:
- Invitations sent through an open room MUST NOT trigger the addition of the invitee
+ Invitations sent through an open room MUST NOT trigger the addition of the invitee
to the member list.
- If a user is added to the member list of an open room and the user is in the room,
- the service MUST send updated presence from this individual to all occupants,
- indicating the change in affiliation by including an <game/> element qualified by
- the 'http://jabber.org/protocol/mug' namespace and containing an <item/>
+ If a user is added to the member list of an open room and the user is in the room,
+ the service MUST send updated presence from this individual to all occupants,
+ indicating the change in affiliation by including an <game/> element qualified by
+ the 'http://jabber.org/protocol/mug' namespace and containing an <item/>
child with the 'affiliation' attribute set to a value of "member".
The room owner may decide to modify the assigned game roles in a room.
- To do so, the owner first requests a list of the occupants
+ To do so, the owner first requests a list of the occupants
and assigned roles by querying the room:
- The service SHOULD then return the full list of all occupants qualified by
+ The service SHOULD then return the full list of all occupants qualified by
the 'http://jabber.org/protocol/mug#owner' namespace; each item MUST include the
- 'role' and 'nick' attributes and MAY include the 'jid' and 'affiliation' attributes for each
- occupant in the room.
+ 'role' and 'nick' attributes and MAY include the 'jid' and 'affiliation' attributes for each
+ occupant in the room.
The owner MAY then modify the roles assigned by occupants.
- In order to do so, the owner MUST send the changed items (i.e., only the "delta") to the service;
- each item MUST include the 'roles' attribute
- and 'nick' attribute but SHOULD NOT include the 'jid' attribute and MUST NOT include
+ In order to do so, the owner MUST send the changed items (i.e., only the "delta") to the service;
+ each item MUST include the 'roles' attribute
+ and 'nick' attribute but SHOULD NOT include the 'jid' attribute and MUST NOT include
the 'affiliation' attribute:
The service MUST change the roles of any affected user and
- MUST send updated presence to all occupants,
- indicating the changed role by including an <game/> element qualified by the
- 'http://jabber.org/protocol/mug' namespace and containing an <item/> child with the
+ MUST send updated presence to all occupants,
+ indicating the changed role by including an <game/> element qualified by the
+ 'http://jabber.org/protocol/mug' namespace and containing an <item/> child with the
'role' attribute.
OPTIONAL.
The following guidelines may assist client and component developers in creating MUG implementations.
The game service MAY offer a managed multi-user chatroom. - This can be done by creating a new chat room and keep membership + This can be done by creating a new chat room and keep membership synchronized with the game room.
- If this protocol will be accepted by the XMPP Standards Foundation, the ®ISTRAR; + If this protocol will be accepted by the XMPP Standards Foundation, the ®ISTRAR; should includes the following information in its registries.
Example: Any control action or counting operation that is not idempotent, such as sending a control action when a button is - pressed, whenever an event has occurred or a transaction. If counting events, transactions, or accumulating consumption, it is + pressed, whenever an event has occurred or a transaction. If counting events, transactions, or accumulating consumption, it is vital that messages are not processed twice, since it will change the end result.
@@ -109,13 +109,13 @@ Author: Peter Waher- To send a message that is received at least once to its destination, an iq stanza of type set is sent containing an - acknowledged element from the "urn:xmpp:qos" namespace. The acknowledged element in turn contains the message to be delivered. - The iq stanza must have an id attribute that is used to identify if the stanza has been received or not. When an acknowledged - message is received, an empty response is returned to acknowledge the receipt. Parsing the message is done after sending the response. - If no response is received by the sending side within a given time frame, an number of retries should be made, using an interval or drop-off + To send a message that is received at least once to its destination, an iq stanza of type set is sent containing an + acknowledged element from the "urn:xmpp:qos" namespace. The acknowledged element in turn contains the message to be delivered. + The iq stanza must have an id attribute that is used to identify if the stanza has been received or not. When an acknowledged + message is received, an empty response is returned to acknowledge the receipt. Parsing the message is done after sending the response. + If no response is received by the sending side within a given time frame, an number of retries should be made, using an interval or drop-off algorithm. These time frames and number of attempts are implementation specific.
It is not guaranteed that the message is delivered only once. Asynchronous conditions may arise where the message is delivered more - than once. If an acknowledgement is not received, at least the sender may become aware that the message was not delivered. + than once. If an acknowledgement is not received, at least the sender may become aware that the message was not delivered. The At least once QoS level requires twice as many messages to be transported in the network as compared to the At most once QoS level.
@@ -144,7 +144,7 @@ Author: Peter Waher- When the sender receives the received response, it sends a new iq set stanza, this time with a deliver payload, + When the sender receives the received response, it sends a new iq set stanza, this time with a deliver payload, to tell the receiving end to parse and deliver the message, if in memory, and remove it from memory. The receiver acknowledges the message by returning an empty iq result stanza. If receiving multiple requests using the same msgId, it will acknowledge each one. But only one message will be parsed and delivered, as it will have been removed from the temporary storage on the receiving end. For both the assured and deliver messages, a retry mechanism similar to the one used for acknowledged service is to be used.
- The Exactly once QoS level requires twice as many messages to be transported in the network as compared to the At least once + The Exactly once QoS level requires twice as many messages to be transported in the network as compared to the At least once QoS level, and four times the number of messages as compared to the At most once QoS level.
@@ -194,7 +194,7 @@ Author: Peter Waher
When sending messages using unacknowledged service, i.e. using the normal message stanza, it can be subject to offline message - storage if the recipient if offline. This might result in delivery of the message at a later time. + storage if the recipient if offline. This might result in delivery of the message at a later time.
- Message routing using unacknowledged service might be handled somewhat differently as compared to acknowledged and assured service, + Message routing using unacknowledged service might be handled somewhat differently as compared to acknowledged and assured service, since the first uses the message stanza and the latter two the iq stanza, which require a fill JID in order to reach its destination. For consistency, full JIDs should be used also for unacknowledged messaging service, if possible.
@@ -320,14 +320,14 @@ Author: Peter Waher or in a database? Such implementation specific concerns are left to the implementor, as this XEP only concerns itself with the communication layer between parties. But the choice of solution might affect to what level a message is ascertained to be delivered: Will delivery be guaranteed, even beyond a system reset at the receiving end? Or a system reset at the sending side? If delivery of the message has to be - ascertained even if a system reset at the sending side is allowed, persistance of the request must also be made on the sending side. + ascertained even if a system reset at the sending side is allowed, persistance of the request must also be made on the sending side. (To some extent, this latter concern even affects acknowledged service.)Outstanding message IDs used in assured delivery, must be unique for the sender (counting the Full JID as the sender). If running - short on Message IDs, such can be reclaimed after the receipt of a successful delivery of a previous message. Message IDs can be + short on Message IDs, such can be reclaimed after the receipt of a successful delivery of a previous message. Message IDs can be sequence numbers, or hash values of the contents of the message.
Set a total limit on the number and size of assured messages that can be simultaneously received from all sources. If anybody - sends a message that will exceed this amount, the resource-constraint error should be returned instead of + sends a message that will exceed this amount, the resource-constraint error should be returned instead of accepting the message.
This document requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
Representational State Transfer (REST) is an architectural style that is a coordinated set of constraints which also apply to the web. It aims at simplifying component implementations, reducing - the complexity of distributed software elements, improving the performance, and increasing the + the complexity of distributed software elements, improving the performance, and increasing the scalability. In relation to the definition of a RESTful application programming interface (API) the uniform interface constraint is of high importance. It simplifies and decouples the architecture and makes REST components independent. The constraints for a uniform interface can be reduced to: - the identification of resources, the self-descriptive representation of resources, and the + the identification of resources, the self-descriptive representation of resources, and the self-descriptive manipulation of resources.
-REST systems typically communicate over the Hypertext Transfer Protocol (HTTP) and are gaining +
REST systems typically communicate over the Hypertext Transfer Protocol (HTTP) and are gaining large acceptance due to its growing support and its simplicity for implementation. RESTful web services - are in this context a simpler alternative to &w3soap; and WSDL-based Web services which are specified + are in this context a simpler alternative to &w3soap; and WSDL-based Web services which are specified for the use with XMPP - in &xep0072; and also a more powerful alternative to &xmlrpc; which are specified as XMPP extension + in &xep0072; and also a more powerful alternative to &xmlrpc; which are specified as XMPP extension in &xep0009;.
The &xep0332; allows for designing REST services in the context of XMPP, but requires an implementation - of both protocols: XMPP and HTTP. Furthermore, HTTP was selected in the past because of its + of both protocols: XMPP and HTTP. Furthermore, HTTP was selected in the past because of its degree of popularity, but has some drawbacks like the lack of discoverability of services. - The REST with XMPP extension is a powerful protocol for cloud services that has + The REST with XMPP extension is a powerful protocol for cloud services that has several advantages in contrast to the traditional HTTP-based REST approach:
In order to explore the capabilities of a resource, the &IQ; stanza type "get" have to be used. The returned +
In order to explore the capabilities of a resource, the &IQ; stanza type "get" have to be used. The returned &IQ; stanza is either of type "error" or "result". If it is of type "result", the returned content has to be - complied with the xwadl schema of this specification. The xwadl schema has been designed for providing a machine + complied with the xwadl schema of this specification. The xwadl schema has been designed for providing a machine process-able description of a resource. It was inspired by the Web Application Description Language (WADL) standard delivered by the World Wide Web Consortium (W3C).
An &IQ; stanza of type "get" is returning an &IQ; stanza of type "result" that describes all actions that the - requesting party can perform. The following example shows an exploration of a cloud provider's REST based + requesting party can perform. The following example shows an exploration of a cloud provider's REST based interface for handling compute services.
In order to explore a resource, only the path to a resource is required. The counter party has to - answer of such a request with a response that exposes all possible actions which can be performed on the + answer of such a request with a response that exposes all possible actions which can be performed on the resource located at the specified path. The following example illustrates a response that exposes all actions for this resource.
This response exposes two methods that can be performed on the +
This response exposes two methods that can be performed on the resource located at "/compute". The first method "create" can be used to create one or more virtual machines (VM). This method has three input parameters in its request and one output parameter in its response. If a client would like to perform this method, at least only a link to - the location of an image is required. The other two parameters are optional. The server will respond to this - method with a list of links to the instantiated VMs. A detailed example of how to access this method is + the location of an image is required. The other two parameters are optional. The server will respond to this + method with a list of links to the instantiated VMs. A detailed example of how to access this method is illustrated in the Resource Access section.
The following subsections describe each component of a xwadl document in detail.
The "resource_type" element forms the root of a xwadl document and MAY comprises the following +
The "resource_type" element forms the root of a xwadl document and MAY comprises the following sub-elements: "doc", "grammars", and "method"
Each xwadl-defined element down to the "param" can have one or more child "doc" elements that - can be used to document that element. The doc element has "title" attributes which is a short plain - text description of the element being documented. The "doc" element can have mixed content +
Each xwadl-defined element down to the "param" can have one or more child "doc" elements that + can be used to document that element. The doc element has "title" attributes which is a short plain + text description of the element being documented. The "doc" element can have mixed content and may contain text and zero or more child elements.
The "grammars" element acts as a container for definitions of the format of data exchanged - during execution of the protocol described by the xwadl document and SHOULD be according to the +
The "grammars" element acts as a container for definitions of the format of data exchanged + during execution of the protocol described by the xwadl document and SHOULD be according to the XML Schema definition.
A method element describes the specific actions that can be performed on a resource targeted +
A method element describes the specific actions that can be performed on a resource targeted by the "path" attribute of the "resource_type" element. A method element is a child of a "resource_type" element and has a "name" attribute that identifies this method.
@@ -212,7 +212,7 @@ which can be empty or be used to expose the optional parameters that this method can execute.The "request" and the "response" element are according to the xwadl schema of type "call". They are +
The "request" and the "response" element are according to the xwadl schema of type "call". They are identical by definition and describe the input and output data for accessing a resource.
A "param" element describes a parameterized component of its parent element (either a request or a - response). It can be identified by its "name" attribute and MUST have a minimum of one "option" element - that defines one of a set of possible - values for the parameter. In order to parameterize a component, the "param" element SHOULD specify +
A "param" element describes a parameterized component of its parent element (either a request or a + response). It can be identified by its "name" attribute and MUST have a minimum of one "option" element + that defines one of a set of possible + values for the parameter. In order to parameterize a component, the "param" element SHOULD specify a combination of the following attributes:
Some combinations of attributes do not make sense, e.g. the specification of "default=?" and "repeating=true", +
Some combinations of attributes do not make sense, e.g. the specification of "default=?" and "repeating=true", and SHOULD be considered application specific.
An "option" element defines one of a set of possible types, representations, link type, or also values +
An "option" element defines one of a set of possible types, representations, link type, or also values for the parameter. An "option" element MUST have one of the following attributes:
The "type" attribute indicates one possible type of the parameter as an XML qualified name, +
The "type" attribute indicates one possible type of the parameter as an XML qualified name, defaults to xs:string. It SHOULD specify the type of a single optional value. Multiple options - with the same type but different values SHOULD specify a set of possible values which are + with the same type but different values SHOULD specify a set of possible values which are acceptable as input for the parent parameter.
The "mediaType" attribute indicates that the parent parameter acts as a media type selector +
The "mediaType" attribute indicates that the parent parameter acts as a media type selector for requests or responses. The value of the attribute is the media type that is expected. If a representation of an OPTIONAL media type is exposed, this representation can act as a template for manipulating a resource.
@@ -266,7 +266,7 @@The "link" attribute is used to identify links to resources. It can have the value local, remote, - or list. A local link links to another resource located at the same server entity. A remote link links to + or list. A local link links to another resource located at the same server entity. A remote link links to a resource located at another server entity anywhere in the XMPP network overlay. A link with a list value indicates a list of remote links that can be used for discovery or linking to a set of resources.
@@ -276,13 +276,13 @@In order to access a resource, the &IQ; stanza type "set" has to be used. The returned +
In order to access a resource, the &IQ; stanza type "set" has to be used. The returned &IQ; stanza is either of type "error" or "result". If it is of type "result", the returned content has to be - complied with the xml-rest schema of this specification. The xml-rest schema has been designed - for providing a xml-rest encoded payload for accessing a resource. + complied with the xml-rest schema of this specification. The xml-rest schema has been designed + for providing a xml-rest encoded payload for accessing a resource. An &IQ; stanza MUST NOT contain more than one method element with one request and one response. - The following example illustrates how the create method of the previous example is requested. - Here, the client requests three VMs which are based on an image that is available as resource + The following example illustrates how the create method of the previous example is requested. + Here, the client requests three VMs which are based on an image that is available as resource on the client's side.
The following subsections describe each component of a xml-rest document in detail.
The "resource" element forms the root of an xml-rest document and MUST comprise only a - single "method" sub-element. In contrast to the xwadl description, no further documentation or grammers - are possible in order to keep the number of bytes as low as possible. + single "method" sub-element. In contrast to the xwadl description, no further documentation or grammers + are possible in order to keep the number of bytes as low as possible. In order to specify the resource to access, the "path" attribute is required.
The "request" and the "response" element are according to the xml-rest schema of type "call". They are +
The "request" and the "response" element are according to the xml-rest schema of type "call". They are identical by definition and including the information for applying the method of a resource. Both elements have no attributes and may contain one or more "param" elements as child elements.
A "link" element or a "resourceList" element have no attributes. While a link targets to a single local - or remote location, a resource list is a set of links which are targeting to any resource in an XMPP - overlay network. A link can be expressed in two forms: as XMPP resource link with a "to" - (e.g. <to>requester@company-b.com/rest-client</to>) and a "path" (e.g. + or remote location, a resource list is a set of links which are targeting to any resource in an XMPP + overlay network. A link can be expressed in two forms: as XMPP resource link with a "to" + (e.g. <to>requester@company-b.com/rest-client</to>) and a "path" (e.g. <path>/images/myLinuxImage</path>) element or as URI (<uri>xmpp://requester@company-b.com/rest-client?/images/myLinuxImage</uri>).
Example to access the sla method.
The REST with XMPP protocol enables a multi-dimensional resource placement. The following examples show +
The REST with XMPP protocol enables a multi-dimensional resource placement. The following examples show how different resources can be placed within a single server entity:
All examples above are accessing different resources. A variation of the path attribute of the resource - element would also combine the presented JIDs and referring to different resources. +
All examples above are accessing different resources. A variation of the path attribute of the resource + element would also combine the presented JIDs and referring to different resources. Further examples are possible to show how different resources can be located at a single server entity.
If an entity supports the REST with XMPP protocol, it SHOULD advertise that fact in response to &xep0030; information ("diso#info") requests by returning an identity of "automation/rest" and a feature of "jabber:iq:rest":
Determining when and how a resource can be accessed or modified based on permissions or - rights are considered outside the scope of this document. Although such mechanisms SHOULD be - considered specifically to the application and/or implementation of this document, +
Determining when and how a resource can be accessed or modified based on permissions or + rights are considered outside the scope of this document. Although such mechanisms SHOULD be + considered specifically to the application and/or implementation of this document, future specifications may address these concerns.
The following terms are used throughout this document to refer to elements, objects, or actions that occur in the context of a transducer using the pubsub service. (Note: Some of these terms are specified in greater detail within the body of this document.)
@@ -556,7 +556,7 @@ The tuple (UUID X, transducer id Y) MUST be unique such that a publish operation
- multimedia input
+ multimedia input
Sensors and controls associated with multimedia input (video camera, microphone, etc)
@@ -614,11 +614,11 @@ The tuple (UUID X, transducer id Y) MUST be unique such that a publish operation
For the sake of interoperability, implementations SHOULD transform native sensor units into the closest relevant SI form. SI units are defined based on +
For the sake of interoperability, implementations SHOULD transform native sensor units into the closest relevant SI form. SI units are defined based on SI conventions as shown in the The Unified Code For Units of Measurement.
-After specifying the units of the transducer device, you can then also specify an SI scalar value as powers of 10. The following example shows how to specify a sensor in centimeters.
+After specifying the units of the transducer device, you can then also specify an SI scalar value as powers of 10. The following example shows how to specify a sensor in centimeters.
-The following example shows how to specify a sensor in kilograms.
+The following example shows how to specify a sensor in kilograms.
@@ -756,7 +756,7 @@ As mentioned earlier, if the XMPP service is capable of handling pub-sub collect
If the XMPP service is not capable of handling pub-sub collections, adapters which want to create nodes for individual transducers SHOULD use a node id of the form X_Y where X is the UUID for the device and Y is the transducer id as listed in the UUID_meta node.
@@ -806,7 +806,7 @@ The information in the meta node is used by consumers to determine which node th
Values for a transducer can also be set by publishing to the data value node.
@@ -847,7 +847,7 @@ If the data value node is configured to include payloads, the subscribers will r
Per the optional note above. If a transducer has the "hasOwnNode" attribute set in the UUID_meta node, then the value set would be done via the UUID_TransducerId node as described above.
@@ -935,7 +935,7 @@ This last step allows an interested agent to subscribe to this node to confirm t
There is the possibility of contention if multiple users attempt to actuate the same device.
This arbitration SHOULD happen at a higher control layer.
Any interested agent can always verify the latest state of the actuator by subscribing to the actuator's node.
-
+
@@ -979,7 +979,7 @@ The sensor used is accurate to the nearest 10 Wh.
-
@@ -1003,7 +1003,7 @@ The new sensor is more accurate and can measure to the nearest 1 Wh.
The adapter provides this additional information in the meta node and data value node.
@@ -1029,7 +1029,7 @@ The adapter provides this additional information in the meta node and data value
-
@@ -1064,7 +1064,7 @@ the adapter implements the OPTIONAL ability that allows a transducer value to ha
@@ -1092,7 +1092,7 @@ the adapter implements the OPTIONAL ability that allows a transducer value to ha
-
@@ -1110,7 +1110,7 @@ the adapter implements the OPTIONAL ability that allows a transducer value to ha
-
@@ -1134,7 +1134,7 @@ the adapter implements the OPTIONAL ability that allows a transducer value to ha
@@ -1166,7 +1166,7 @@ One action could be to turn on the light, in which case the agent would publish:
@@ -1189,7 +1189,7 @@ In response, the camera adapter would turn on the light and publish an acknowled
@@ -1228,7 +1228,7 @@ Thus, the adapter would be required to convert rpm into hertz (i.e. multiply the
@@ -1267,7 +1267,7 @@ Thus, the adapter would be required to convert rpm into hertz (i.e. multiply the
-
@@ -1424,7 +1424,7 @@ The publication of sensor information is not known to introduce any new security
diff --git a/inbox/server-rosters.xml b/inbox/server-rosters.xml
index 2e9f2a30..07aa159f 100644
--- a/inbox/server-rosters.xml
+++ b/inbox/server-rosters.xml
@@ -84,7 +84,7 @@
This document requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
If a server supports the SIFT protocol, it MUST advertise that fact in its responses to &xep0030; information ("disco#info") requests by returning a feature of "urn:xmpp:sift:1":
When a client indicates that it wishes to receive messages, the server SHOULD deliver to the client all messages in the offline message queue and MUST deliver to the client any subsequent messages that would normally be delivered to the client in accordance with the rules defined in &xmppcore; and &xmppim;.
-If the client subsequently indicates that it wants the server to intercept inbound messages (and there are no other connected or available resources that have expressed interest in receiving inbound messages), the server SHOULD treat messages as if there were no connected or available resources (e.g., storing them offline for later delivery); if the client then indicates again that it wishes to receive inbound messages, the server SHOULD send those queued messages to the client so that it can get back in sync regarding messages received from its contacts.
+If the client subsequently indicates that it wants the server to intercept inbound messages (and there are no other connected or available resources that have expressed interest in receiving inbound messages), the server SHOULD treat messages as if there were no connected or available resources (e.g., storing them offline for later delivery); if the client then indicates again that it wishes to receive inbound messages, the server SHOULD send those queued messages to the client so that it can get back in sync regarding messages received from its contacts.
If the client does not request filtering of inbound IQ stanzas, the server MUST pass through to the client all IQ stanzas that are addressed to the full JID of the client (subject to appropriate security controls as defined in the relevant RFCs and XEPs).
@@ -408,7 +408,7 @@This document requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
If an entity supports SoX, it MUST advertise that fact in its responses to &xep0030; information ("disco#info") requests by returning a feature of "urn:xmpp:sox:0":
This document requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
Before connecting to a session, a party MUST determine the &xep0030; identity and supported features of the host. In many situations the party already knows this information (e.g., if the host is the initiator of the Jingle session). In other situations the party will need to send a service discovery information request to the host.
In order to synchronize its local state with the existing state of the edited object, an entity sends a connection request to the host. The identity learned through service discovery determines what kind of message the joining party sends (e.g., type='groupchat' if the host is a MUC room).
To connect to a session, the joiner MUST send an SXE <connect/> element to the host.
The state offer MUST contain the <description/> element or elements that were included in the Jingle session-initiate request.
Once the other entity receives the <accept-state/> element it MUST proceed sending the state as described in the next section.
If a multiple state offers were received, one should be accepted and the others should be refused by sending a <refuse-state/> element.
The state SHOULD include a version of each element that was synchronized, and hence won't be undone, as well as all the later versions. In practice this can often be impossible to know in a session without a specialized MUC component so it may be safest to send version 0 and all the later edits to each element. Version 0 is implied if the version element is missing.
If the session is already in progress, the entity sends the snapshot.
Once a participant has received initial state, he can participate in the editing session.
Here is another edit in the session.
Changes to the records can be divided into two categories: commutative and non-commutative edits.
Commutative edits are commutative with all edits and are never "undone" so keeping a history of them is NOT REQUIRED. Edits that add or remove records are commutative.
-An edit that changes an existing record is called non-commutative because it may not be commutative with edits that change the same record. Hence these changes may need to be undone so keeping a history of the changes caused by such edits is REQUIRED. The breadth of this required history depends on the role of the entity and on whether the session works through a server component:
+An edit that changes an existing record is called non-commutative because it may not be commutative with edits that change the same record. Hence these changes may need to be undone so keeping a history of the changes caused by such edits is REQUIRED. The breadth of this required history depends on the role of the entity and on whether the session works through a server component:
| @@ -782,7 +782,7 @@ PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" - + |
To process a <new/> element the client MUST create a new record with the values of the attributes stored in the corresponding fields.
A client can remove any node in the document by removing the corresponding record with the <remove/> element.
- +| Attribute | @@ -876,11 +876,11 @@ PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"REQUIRED and MUST be the record id of the node to be removed. |
|---|
A client MUST NOT send a <remove/> element that removes a node that has child nodes without explicitly removing the records of those nodes first.
The <set/> element is used to modify an existing record.
- +| Attribute | @@ -948,12 +948,12 @@ PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"replacen | replace n characters. OPTIONAL but only allowed if 'chdata' and 'replacefrom' attributes are also included. MUST be a non-negative integer. |
|---|
The following attributes are defined for the <thumbnail/> element.
- This document offers mechanisms to solve the following problem: - There are two XMPP client entities (Verifier and Prover). The - Verifier can be presenting e.g., a physical device, an application - or a service and and the Prover is presenting an XMPP account of + This document offers mechanisms to solve the following problem: + There are two XMPP client entities (Verifier and Prover). The + Verifier can be presenting e.g., a physical device, an application + or a service and and the Prover is presenting an XMPP account of user entity (e.g., a human) that wants to login. - - Before the Verifier can execute or ask executing any access - control mechanism, e.g., to check if the Prover's XMPP accout is - authorized use certain resource(s), the Prover must be authenticated. + + Before the Verifier can execute or ask executing any access + control mechanism, e.g., to check if the Prover's XMPP accout is + authorized use certain resource(s), the Prover must be authenticated. We present usage of two-factor authentication in which the following authentication factors are used:
- In addition to these, described mechanism offers possibility to + In addition to these, described mechanism offers possibility to approve authentication inside only a certain time-slot.
- Prover and Verifier entities mean same as in &rfc6238; but are + Prover and Verifier entities mean same as in &rfc6238; but are implemented as two XMPP clients. When using terms of &xep0146;, Prover is Local Client and Verifier is Remote Client.
- Several mechanisms for client-to-client authentication, such as - &xep0250; exist and can be used with the protocol defined in - this document. This document describes a new simple and - extendable protocol for two-factor one-way client authentication - by specifying a profile on &xep0050;. One-way here means that - the actual user (e.g, a human) of Prover's XMPP Client is not + Several mechanisms for client-to-client authentication, such as + &xep0250; exist and can be used with the protocol defined in + this document. This document describes a new simple and + extendable protocol for two-factor one-way client authentication + by specifying a profile on &xep0050;. One-way here means that + the actual user (e.g, a human) of Prover's XMPP Client is not required to know anything about the Verifier.
This document addresses the following requirements:
- A client MAY advertise any authentication commands it + A client MAY advertise any authentication commands it supports via &xep0030; (as described in XEP-0050).
- If these commands are advertised, &xep0115; can be used to + If these commands are advertised, &xep0115; can be used to query capability of authentication commands in a client. - If the Prover and the Verifier are working on a same physical - device, they both MAY know the exact format and existence of supported + If the Prover and the Verifier are working on a same physical + device, they both MAY know the exact format and existence of supported commands.
- This document defines a profile of XEP-0050 that - enables a client to perform the following tasks on a entity + This document defines a profile of XEP-0050 that + enables a client to perform the following tasks on a entity that or which resources it wants to use:
- Although this document aims to define common use cases for - authentication, an implementation or deployment MAY support any + Although this document aims to define common use cases for + authentication, an implementation or deployment MAY support any subset and MAY support additional commands not defined herein.
- Note: The text that follows assumes that implementors have
- read and understood XEP-0050, password
+ Note: The text that follows assumes that implementors have
+ read and understood XEP-0050, password
generation algorithms described in &rfc4226; and RFC 6238,
and randomness requirements described in &rfc4086;,
and know about one-time pads and perfect secrecy.
@@ -172,11 +172,11 @@
- Time-Based One-Time Password (TOTP) algorithm described in
- RFC 6238 is an extension of the HMAC-based
- One-Time Password (HOTP) algorithm defined in RFC 4226,
- to support the time-based moving factor. In TOTP, time
- reference and a time step replaces the counter in the HOTP
+ Time-Based One-Time Password (TOTP) algorithm described in
+ RFC 6238 is an extension of the HMAC-based
+ One-Time Password (HOTP) algorithm defined in RFC 4226,
+ to support the time-based moving factor. In TOTP, time
+ reference and a time step replaces the counter in the HOTP
computation.
Unless an error occurs (see the
- Error Handling section below), the service
+ Unless an error occurs (see the
+ Error Handling section below), the service
SHOULD return the appropriate form. After receiving a correct secret, the Verifier informs Prover of completion.
- As described in &rfc4949; one-time pad is an encryption
- algorithm in which the key is a random sequence of symbols
+ As described in &rfc4949; one-time pad is an encryption
+ algorithm in which the key is a random sequence of symbols
and each symbol is used for encryption only one time,
- i.e., used to encrypt only one plaintext symbol and thus
- produce only one ciphertext symbol and thus produce only one
- ciphertext symbol. A copy of the key is used similarly
+ i.e., used to encrypt only one plaintext symbol and thus
+ produce only one ciphertext symbol and thus produce only one
+ ciphertext symbol. A copy of the key is used similarly
for decryption.
Unless an error occurs (see the
- Error Handling section below), the service
+ Unless an error occurs (see the
+ Error Handling section below), the service
SHOULD return the appropriate form. After receiving a one-time pad, the Verifier informs Prover of completion.
- Several error conditions are possible when a Prover sends a - command request to the Verifier, as defined in the following - table. If one of these errors occurs, the Verifier entity MUST + Several error conditions are possible when a Prover sends a + command request to the Verifier, as defined in the following + table. If one of these errors occurs, the Verifier entity MUST return an error stanza to the requesting Prover.
@@ -356,12 +356,12 @@ -->For the syntax of these errors, see &xep0086;. Naturally, other + +
For the syntax of these errors, see &xep0086;. Naturally, other errors may be returned as well.
- Implementations of this protocol MAY introduce extra forms for - commands and MAY use other secret key generation mechanisms than - currently presented TOTP and one-time pad. + Implementations of this protocol MAY introduce extra forms for + commands and MAY use other secret key generation mechanisms than + currently presented TOTP and one-time pad.
- There are several secure ways to transmit one-time pads or the - shared secret that is used in TOTP from Verifier to the Prover. - If both Verifier and Prover entities are running in one - application inside one device, the shared secret can be - generated and transmitted inside running implementation and + There are several secure ways to transmit one-time pads or the + shared secret that is used in TOTP from Verifier to the Prover. + If both Verifier and Prover entities are running in one + application inside one device, the shared secret can be + generated and transmitted inside running implementation and be removed right after the usage.
Presented authentication mechanism offers possibilities to +
Presented authentication mechanism offers possibilities to execute at least the following access policies and different - combinations of them, but their detailed descriptions and how - policies are transmitted to the Verifier are out of scope of + combinations of them, but their detailed descriptions and how + policies are transmitted to the Verifier are out of scope of this document:
- Mechanisms for determining when a command can be executed based - on permissions or rights are considered specific to the + Mechanisms for determining when a command can be executed based + on permissions or rights are considered specific to the application and/or implementation of XEP-0050, as defined in XEP-0050. - - In this application a command SHOULD be executed if and only - if it comes from full user's JID that is already known to - the Verifier. This decreases possibility to execute, e.g, + + In this application a command SHOULD be executed if and only + if it comes from full user's JID that is already known to + the Verifier. This decreases possibility to execute, e.g, relay attacks. - + Determining other permissions or rights are considered specific - to access policies of systems, as presented in + to access policies of systems, as presented in Business Rules section.
- Possibility of executing Denial-of-service (DoS) attacks against - the Verifier can be reduced by ending processing of received + Possibility of executing Denial-of-service (DoS) attacks against + the Verifier can be reduced by ending processing of received messages coming from not authorized JIDs or containing incorrect secret as early as possible.
- Randomness requirements for security described in + Randomness requirements for security described in RFC 4086 apply.
- When using TOTP, security considerations of + When using TOTP, security considerations of RFC 6238 apply.
- When using TOTP, HMAC-SHA-256 or HMAC-SHA-512 functions SHOULD - be used instead of the HMAC-SHA-1 that has been specified for + When using TOTP, HMAC-SHA-256 or HMAC-SHA-512 functions SHOULD + be used instead of the HMAC-SHA-1 that has been specified for the HOTP computation in RFC 4226.
- When using TOTP, when an OTP is generated at the end of a - time-step window, the receiving time most likely falls into the - next time-step window. A validation system MUST set a policy - for an acceptable OTP transmission delay window for validation. - A larger acceptable delay window would expose a larger window - for attacks, so as in RFC 6238, we RECOMMEND that + When using TOTP, when an OTP is generated at the end of a + time-step window, the receiving time most likely falls into the + next time-step window. A validation system MUST set a policy + for an acceptable OTP transmission delay window for validation. + A larger acceptable delay window would expose a larger window + for attacks, so as in RFC 6238, we RECOMMEND that at most one time step is allowed as the network delay.
- As described in Introduction, the - user of the Prover XMPP client does not necessarily know - anything about the Verifier. In addition to this, the user - does not necessarily know what the device or the application - will do after a succesful authentication. Notice that this - problem relates to every closed source XMPP client - implementations, thus implementations' code SHOULD be open + As described in Introduction, the + user of the Prover XMPP client does not necessarily know + anything about the Verifier. In addition to this, the user + does not necessarily know what the device or the application + will do after a succesful authentication. Notice that this + problem relates to every closed source XMPP client + implementations, thus implementations' code SHOULD be open source.
- When using one-time pads, to ensure one-time use, the copy of - the key used for encryption MUST be destroyed after use, as + When using one-time pads, to ensure one-time use, the copy of + the key used for encryption MUST be destroyed after use, as is the copy used for decryption.
- When using one-time pads, commands containing pads that have - incorrect pad length, SHOULD not be executed. + When using one-time pads, commands containing pads that have + incorrect pad length, SHOULD not be executed.
The XMPP Registrar includes 'http://jabber.org/protocol/auth' +
The XMPP Registrar includes 'http://jabber.org/protocol/auth' in its registry of protocol namespaces (see &NAMESPACES;).
&xep0068; defines a process for standardizing the fields used - within Data Forms scoped by a particular namespace - (see also &FORMTYPES;). The reserved fields for the - 'http://jabber.org/protocol/auth' namespace are specified +
&xep0068; defines a process for standardizing the fields used + within Data Forms scoped by a particular namespace + (see also &FORMTYPES;). The reserved fields for the + 'http://jabber.org/protocol/auth' namespace are specified below.
@@ -546,7 +546,7 @@
- Because the protocol defined here is a profile of + Because the protocol defined here is a profile of XEP-0050, no schema definition is needed.
After the TLS handshake has been completed, the parties exchange encrypted data over the tunnel. Because the routing information is already present in the IQ stanzas used by XTLS, it is OPTIONAL for the stanzas encapsulated in the XTLS stream to include routing information (i.e., the 'from' and 'to' attributes). In that case, the entity receiving the data MUST supply the 'from' and 'to' addresses of the IQ stanza that contains the encrypted data.
Either party can close the XTLS tunnel; this is done by sending an IQ-set containing an empty <close/> element qualified by the 'urn:xmpp:tmp:xtls' namespace &NSNOTE;. However, if the entities have a mutual presence subscription then it is RECOMMENDED for the entities to maintain the tunnel until one entity becomes unavailable. Keeping the XTLS tunnel open does not require significant resources and prevents the need for a new TLS handshake.
The other party then acknowledges that the tunnel is closed by sending an IQ-result containing an empty <closed/> element qualified by the 'urn:xmpp:tmp:xtls' namespace &NSNOTE;.
If the tunnel is unknown to the receiving party, it MUST return an ¬found; error.
This entire document addresses security. Particular security-related issues are discussed in the following sections.
An implementation MUST at a minimum support the TLS_RSA_WITH_3DES_EDE_CBC_SHA and TLS_DH_RSA_WITH_AES_256_CBC_SHA ciphers. An implementation MAY support other ciphers as well.
+An implementation MUST at a minimum support the TLS_RSA_WITH_3DES_EDE_CBC_SHA and TLS_DH_RSA_WITH_AES_256_CBC_SHA ciphers. An implementation MAY support other ciphers as well.
As noted, XTLS can be used between XMPP clients, between an XMPP client and a remote XMPP service (i.e., a service with which a client does not have a direct XML stream), or between remote XMPP services. Therefore, a party to an XTLS tunnel will present either a client certificate or a server certificate as appropriate. Such certificates MUST be generated and validated in accordance with the certificate guidelines guidelines provided in &rfc3920bis;.
@@ -344,7 +344,7 @@This document requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
An archive contains a collection of messages relevant to a particular XMPP address, e.g. a user, MUC, pubsub node, server. Note: while a service might have many "archives" as defined here (one per JID capable of being queried) this is a conceptual distinction, +
An archive contains a collection of messages relevant to a particular XMPP address, e.g. a user, MUC, pubsub node, server. Note: while a service might have many "archives" as defined here (one per JID capable of being queried) this is a conceptual distinction, and a server is not bound to any particular implementation or arrangement of data stores.
Exactly which messages a server archives is up to implementation and deployment policy, but it is expected that all messages that hold meaningful content, rather than state changes such as Chat State Notifications, would be archived. Rules are specified later in this document.
@@ -178,7 +178,7 @@ reach a certain age. Any such deleted messages MUST be the oldest in the archive, i.e. it is not permitted to create gaps or "holes" in the archive. The UIDs of deleted messages MUST NOT be reused for new messages. -However a server that wishes to remove messages from the middle of an archive, e.g. to remove accidentally transmitted +
However a server that wishes to remove messages from the middle of an archive, e.g. to remove accidentally transmitted sensitive information may omit the <message> stanza from inside the <forwarded> element or replace the message with an appropriate placeholder when transmitting the result in response to a query. However servers MUST retain the UID, timestamp and JID of the original message internally to ensure that all queries remain consistent. diff --git a/xep-0369.xml b/xep-0369.xml index 2235d795..72cf012f 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -45,7 +45,7 @@ Remove namespace references in Info/Config nodes; Modify Participant and JID Map syntaxes; Clarifications on subscription to participants node and using this to receive Nick changes; - Replace use of "query" as MIX defined operations for setting nick; + Replace use of "query" as MIX defined operations for setting nick;
- The mapping of real bare JID to proxy JID is defined when a participant joins a channel. While a user is a participant in a Channel, the mapping between real JID and proxy JID MUST NOT be changed. This mapping must be maintained after the user leaves the channel. Proxy JID values MUST NOT be re-used. If a JID that left a channel joins the channel again the same proxy JID MAY be used again or a different new proxy JID MAY be assigned. + The mapping of real bare JID to proxy JID is defined when a participant joins a channel. While a user is a participant in a Channel, the mapping between real JID and proxy JID MUST NOT be changed. This mapping must be maintained after the user leaves the channel. Proxy JID values MUST NOT be re-used. If a JID that left a channel joins the channel again the same proxy JID MAY be used again or a different new proxy JID MAY be assigned.
- The example real full JIDs in this specification are aligned the anticipated new format that splits the resource into two parts. The first part is UUID that is a stable and fixed value for the client and is anticipated to be a fixed format which may well be UUID 4. The second part is server assigned and will vary with each session. A realistic JID with resource is: 'hag66@shakespeare.example/d104f6a7-97e9-477f-8947-e4a37691d7ee/7533375f2cd'. This specification uses examples of the style: 'hag66@shakespeare.example/UUID-a1j/7533' which are aligned to real resources, but more compact. CITATION TO BE ADDED. If the final specification differs from this, the examples will be updated. + The example real full JIDs in this specification are aligned the anticipated new format that splits the resource into two parts. The first part is UUID that is a stable and fixed value for the client and is anticipated to be a fixed format which may well be UUID 4. The second part is server assigned and will vary with each session. A realistic JID with resource is: 'hag66@shakespeare.example/d104f6a7-97e9-477f-8947-e4a37691d7ee/7533375f2cd'. This specification uses examples of the style: 'hag66@shakespeare.example/UUID-a1j/7533' which are aligned to real resources, but more compact. CITATION TO BE ADDED. If the final specification differs from this, the examples will be updated.
The full JIDs held in the presence nodes are anonymized using a similar mechanism. First the bare JID is mapped to a bare proxy JID, using the mapping held in the "urn:xmpp:mix:nodes:jidmap" node for the bare JID. Then the resource is replaced with a generated value. For example, 'hag66@shakespeare.example/UUID-a1j/7533' in the channel coven might have a proxy JID of '123456#coven@mix.shakespeare.example/789'. There is no client visible mapping of proxy full JIDs maintained as this is not needed. The MIX channel will need to maintain a mapping, to support directly addressing clients, such as for client to client disco#info queries. While an full proxy JID is held in the presence node, the mapping to real JID MUST NOT be changed. When adding a client to the presence node, the server MAY add the same anonymized JID as used before by that client, or it MAY create a different anonymized JID. @@ -493,7 +493,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa When a user joins a channel, the user's bare JID is added to the participants node by the MIX service. When a user leaves a channel, they are removed from the participants node. The participants node MUST NOT be directly modified using pubsub.
- Users MAY subscribe to and read information this node, when permitted by the channel. Standard PubSub access will allow a full list of participants and associated nicks to be determined. By subscribing to the node, a user will be informed of changes to the Participants Node. + Users MAY subscribe to and read information this node, when permitted by the channel. Standard PubSub access will allow a full list of participants and associated nicks to be determined. By subscribing to the node, a user will be informed of changes to the Participants Node.
The participants node is OPTIONAL. If the Participants Node is not used, information on channel participants is not shared. If there is no participants node, the access control value 'participants' MUST NOT be used. The Participants node is a permanent node with one item per participant.
The JID Maybe Visible Map node is a similar node to the JID Map node that is used in addition to the JID Map Node in JID Maybe Visible channels. All participants may subscribe to and access this node. It uses the same encoding as JID Map node and all participant JIDs MUST be included. Where a participant's preference is to not share the JID, the encoded participant value is the proxy JID. This will enable a user looking up a JID to clearly determine that the user preference is to not share the JID and to clearly distinguish this case from an erroneous proxy JID.
- +The presence node contains the presence value for clients belonging to participants that choose to publish presence to the channel. A MIX channel MAY require that all participants publish presence. Each item in the presence node is identified by the full proxy JID, and contains the current presence value for that JID. The presence is encoded in the same way as data that would be sent in a presence stanza. The full proxy JID is always used in this node. In MIX it is possible to have a 'presence-less channel' by not using this node. Access Control MAY be set to enforce that for each of the full JIDs in this list, the bare JID MUST be in the participants list. @@ -638,7 +638,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
As part of the channel joining process, the user's server MUST add the MIX channel to the user's roster. This is done to share the user's presence status with the channel and channel participants subscribing to presence, when the user wishes this presence to be shared. These roster entries also enables the user's client to quickly determine which channels the user has joined. - This roster entry will lead to the user's server correctly sending user's presence from all the user's MIX clients to the MIX channel. Where the user wishes to share presence, the roster subscription is configured with one way presence, as presence is sent to the MIX channel but no presence information is sent about the MIX channel to the user. + This roster entry will lead to the user's server correctly sending user's presence from all the user's MIX clients to the MIX channel. Where the user wishes to share presence, the roster subscription is configured with one way presence, as presence is sent to the MIX channel but no presence information is sent about the MIX channel to the user.
If the user does not wish to publish presence information to the channel, the user's server will add the roster entry with mode subscription=none. The roster entry will be present to record that the user has joined the channel, but it will not send presence information to the channel. The user's server MUST do this when the user has chosen Presence preference of 'not share' as described below. If the user changes the value of the preference, the server MUST modify subscription mode to reflect this. @@ -1089,7 +1089,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
The user's server MUST remove this roster entry when the user leaves the channel.
- +A channel MAY publish an Avatar following &xep0084;. A client MAY make use of this information to associate an Avatar with the roster entry for a channel.
@@ -1098,7 +1098,7 @@ This approach enables flexible support of multiple clients for a MIX channel paA channel MAY store user preferences and parameters with each user. A user JID visibility preference has the following values:
- +When an Nick is assigned, the MIX server MUST update the Participants Node in the channel to reflect this change. Any users subscribed to this node will be notified of the change of Nick.
- +The following example shows an example of reporting successful Nick assignment.
- Presence information will provide a MIX client with the nicks and proxy JIDs for participants in a channel. Messages sent to a channel and retrieved from MAM archives will show the proxy JID and nick of the sender. It is sometimes useful to determine the real JID associated with proxy JID. This can always be done for JID Visible channels and can sometimes be done for JID Maybe Visible channels. - + Presence information will provide a MIX client with the nicks and proxy JIDs for participants in a channel. Messages sent to a channel and retrieved from MAM archives will show the proxy JID and nick of the sender. It is sometimes useful to determine the real JID associated with proxy JID. This can always be done for JID Visible channels and can sometimes be done for JID Maybe Visible channels. +
For current users JID visible rooms, the real JID is found by a PubSub lookup on the JID Map node. This is shown in the following example:
- +For JID Maybe Visible rooms the lookup is performed on the JID Maybe Visible Map node. Note that where a user prefers to not share real JID, the result of this lookup of proxy JID will be the (same) proxy JID.
- +When an older message is considered, it is possible that the proxy JID of the sender is not current. Such a JID can be looked up in the MAM Archive of the JID Map Node. This is shown in the following example:
@@ -1561,7 +1561,7 @@ This approach enables flexible support of multiple clients for a MIX channel paThe MIX channel then puts a copy of the message into the MAM archive for the channel and sends a copy of the message to each participant in standard groupchat format. These messages sent by the channel are addressed to the bare JID of each participant and this will be handled by the participant's local server. The message from value is the JID of the channel. To enable sender identification, the Nick and bare proxy JID of the sender are included in the message as MIX parameters. The id of the message is the ID from the MAM archive and NOT the id used by the sender. The message placed in the MAM archive is the reflected message without a 'to' element.
- - + +