diff --git a/inbox/Makefile b/inbox/Makefile
new file mode 100644
index 00000000..2e27a1f6
--- /dev/null
+++ b/inbox/Makefile
@@ -0,0 +1,8 @@
+OUTDIR?=../build/
+
+xeps=$(wildcard *.xml)
+
+.PHONY: all
+all: html
+
+html: $(patsubst %.xml, $(OUTDIR)/%.html, $(xeps))
diff --git a/inbox/account-management.xml b/inbox/account-management.xml
index 6e71fb0b..b2a8e75a 100644
--- a/inbox/account-management.xml
+++ b/inbox/account-management.xml
@@ -23,7 +23,7 @@
the server MUST NOT decide whether or not to propose the <registration/> feature based on the existence of the JID filled in 'from'. Doing so would leak away information about the existence of a JID which could therefore be sent undesirable messages. Being consistent on showing the feature forces to try to register which can already eliminates part of the risk if the challenge provides some bot protection (for instance CAPTCHAs). A perfectly valid alternative would be to always provide the <registration/> feature when no "from" is filled but never provide it when a "from is filled" (no matter it is an existing JID or not). This consistent logics does not leak information. Do not modify the SASL authentication's mechanisms listed in the <mechanisms/> feature depending on the 'from'. Even though a given JID might not be able to connect with some mechanisms because the credentials storage is incompatible, this would leak information on the kind of storage mechanism used for this user. This information would allow attackers to determine, then target, users whose storage would be weaker. Of course this particular point might cause issues for users regularly changing their clients or log in from various computer. For instance the SCRAM-SHA-1 and SCRAM-SHA-256 storage are incompatible. If you first registered by specifying the SCRAM-SHA-256 storage, then on another client which does not support SCRAM-SHA-256 or even who supports it, but for some reason always try and gives priority to SCRAM-SHA-1, the user could be found in a situation where he never manages to authenticate while providing the right password. For this reason, it could be wiser for server deployments to choose compatible mechanisms, when possible. On client side, if they are provided a raw password, instead of pre-computed data for a specific mechanism, then they should intelligently try the various mechanisms, starting from the one they consider the stronger. Hence try SCRAM-SHA-256, then SCRAM-SHA-1 if the first failed, then only if both failed, tell the user that authentication failed (note that the client should not try PLAIN as a last fallback, because we remind that any SCRAM-* storage is compatible with the SASL PLAIN mechanism. Trying PLAIN would therefore be a security risk. First draft. The Buddycloud project is a set of independently deployable services, that
inter-operate to create a rich collaboration service.
@@ -188,7 +134,7 @@
Each XMPP domain can have one Buddycloud server that serves user's channels.
Buddycloud clients and servers need to be able to discover the authoratative
Buddycloud server. find the
@@ -196,7 +142,7 @@
To find the correct remote Buddycloud service for a domain, the Buddycloud
- server should:
+ server should: The Buddycloud service first sends an items discovery request to the domain
@@ -274,12 +219,12 @@
This example delegates all the Buddycloud service to an XMPP component
running the Buddycloud named
- buddycloud-component.verona.lit
+ buddycloud-component.verona.lit
.
Upon connection to the buddycloud server a user should send a register
stanza.
-
+
A perfectly valid alternative would be to always provide the <registration/> feature when no "from" is filled but never provide it when a "from is filled" (no matter it is an existing JID or not). This consistent logics does not leak information.
Of course this particular point might cause issues for users regularly changing their clients or log in from various computer. For instance the SCRAM-SHA-1 and SCRAM-SHA-256 storage are incompatible. If you first registered by specifying the SCRAM-SHA-256 storage, then on another client which does not support SCRAM-SHA-256 or even who supports it, but for some reason always try and gives priority to SCRAM-SHA-1, the user could be found in a situation where he never manages to authenticate while providing the right password. For this reason, it could be wiser for server deployments to choose compatible mechanisms, when possible. On client side, if they are provided a raw password, instead of pre-computed data for a specific mechanism, then they should intelligently try the various mechanisms, starting from the one they consider the stronger. Hence try SCRAM-SHA-256, then SCRAM-SHA-1 if the first failed, then only if both failed, tell the user that authentication failed (note that the client should not try PLAIN as a last fallback, because we remind that any SCRAM-* storage is compatible with the SASL PLAIN mechanism. Trying PLAIN would therefore be a security risk.
-
Node metadata is used to describe the channel to users. All nodes in a channel have the same metadata and permission.
-- using disco-info + with the node specified - using &xep0060; 5.4 Discover Node Metadata
set Not sure what + goes here?
minimum setting/optional recommended fallbacks @@ -401,7 +347,6 @@
Channel owners and moderators can also set the default affiliation for the channel
-
Channel Type | @@ -429,8 +374,6 @@
---|
Access Model | @@ -455,7 +398,6 @@
---|
Buddycloud is designed to be extended with new node and content types. To @@ -523,16 +465,14 @@
Buddycloud adapts XEP-0060's machine-to-machine design goals with logic and presets that work better in a social person-to-person and person-to-group environment. For example, to discourage "glorifying the wicked", the list of banned users is only presented to the channel's moderators.
-
Property | Access model | @@ -544,8 +484,6 @@Anonymous (e.g. web) | Banned users |
---|---|---|---|
channel name | all | @@ -665,12 +603,8 @@no | no |
Property | Producer | @@ -680,8 +614,6 @@Anonymous (e.g. web) | Banned users |
---|---|---|---|
change channel name | only at creation time | @@ -745,9 +677,7 @@no | no |
A Buddycloud server MUST maintain similar affiliations and permissions for a subscribed @@ -762,7 +692,7 @@
Many of the item use cases follow those from XEP-0060. This section notes
the departures from the parent XEP and specific requirements.
@@ -864,8 +794,8 @@
A retraction message is sent to all online clients, with an Atom tombstone to + replace the deleted post
The minimal payload for a publish request must be formatted as follows:
Posts in Buddycloud can be formed into threads consisting of a parent post - and comments to a maximum thread depth of 1. Posts follow the - ATOM threading specification + and comments to a maximum thread depth of 1. Posts follow the &rfc4685; and utilise the & thread ; namespace with the 'ref' attribute referring to the full global ID of the @@ -992,7 +922,7 @@ ]]>
Within a single thread comments can reference other comments or the parent item. This is for the purpose of making a comment to a post further back in the thread. @@ -1052,6 +984,7 @@ +
By making use of the & @@ -1119,13 +1052,13 @@
Buddycloud clients follow XEP-0060 subscription mechanisms for following and unfollowing a channel.
- Buddycloud channels build on XEP-0060's node affiliations. + Buddycloud channels build on XEP-0060's node affiliations.
XEP-0060 Affiliation | @@ -1183,10 +1116,9 @@RECOMMENDED |
---|
The Buddycloud server should make sure that the remote server
diff --git a/inbox/carbons.xml b/inbox/carbons.xml
index 997b229f..d77b9424 100644
--- a/inbox/carbons.xml
+++ b/inbox/carbons.xml
@@ -1,6 +1,7 @@
+ rfc3921bis An entity advertises support for this protocol by including the 'urn:xmpp:cmr:0' feature in its service discovery information features as specified in Service Discovery (XEP-0030) or section 6.3 of Entity Capabilities (XEP-0015). If allowed and supported by the server, clients are able to annotate message stanza with a routing hint, that SHOULD affect the used message routing algorithm for the annotated stanza.
Algorithm Namespace: 'urn:xmpp:cmr:all'
Deliver to all non-negative resources with share the same maximum priority. And if message type is 'chat', only to those that have opted in to receive chat messages.
Algorithm Namespace: 'urn:xmpp:cmr:mostactive'
Deliver the message to the "most available" resource or resources, depending on the server's implementation.
Algorithm Namespace: 'urn:xmpp:cmr:roundrobin'
Deliver the message to the next resource selected by a round-robin algorithm.
Algorithm Namespace: 'urn:xmpp:cmr:weighted'
Deliver the message to a resource selected by a weighted round-robin algorithm. The weight of a resource is determined by its priority. To signal the type of communication that is desired, the entity that first decloaks MAY include a 'reason' attribute on the <decloak/> element. The following values for the 'reason' attribute are defined: Inclusion of the 'reason' attribute can be interpreted by the receiving client as a signal that communication is about to start; for instance, a call accept/reject dialog could double as a UI for accepting or rejecting a decloaking request. If a MUC service supports distributed rooms, it MUST return a feature of "urn:xmpp:dmuc:0" &NSVER; in response to &xep0030; information requests. If a MUC service supports distributed rooms, it MUST return a feature of "urn:xmpp:dmuc:0" in response to &xep0030; information requests.
-
The following is a list of goals for the design of this extension: +
The following is a list of goals for the design of this extension:
The following JIDs are used in this document.
To determine if a server or service supports Distributed MUC, the requesting entity SHOULD send a disco#info request to it.
First draft.
diff --git a/inbox/iot-events.xml b/inbox/iot-events.xml
index 97905ebf..2de007fd 100644
--- a/inbox/iot-events.xml
+++ b/inbox/iot-events.xml
@@ -367,7 +367,7 @@
-
To unsubscribe a subscription, send the unsubscribe element in a request to the Thing with the seqnr sequence number corresponding to the
subscription. The Thing responds with an empty response to acknowledge the un-subscription, regardless if the subscription existed or not.
@@ -726,4 +726,4 @@
The basic flow is as follows.
- Jingle Nodes
+ Jingle Nodes
Thiago
Camargo
thiago@xmppjingle.com
@@ -120,7 +120,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring
]]>
-In this example 'montague.lit' XMPP Domain a Relay Service and a Tracker Service. The Relay Service can be contacted in order to retrieve Relay Channels. The Tracker Service can be contacted in order to retrieve its known services.
+In this example 'montague.lit' XMPP Domain a Relay Service and a Tracker Service. The Relay Service can be contacted in order to retrieve Relay Channels. The Tracker Service can be contacted in order to retrieve its known services.
A Jingle Client MAY NOT be satisfied with only one Relay Service entry found. So it keeps the search on the known Tracker Services.
@@ -139,7 +139,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring
type='result'>
]]>
-In this example 'capulet.lit' returned an empty service list, meaning that it does NOT known ANY Relay or Tracker Services.
+In this example 'capulet.lit' returned an empty service list, meaning that it does NOT known ANY Relay or Tracker Services.
A Jingle Client MAY NOT be satisfied with only one Relay Service entry found. So it keeps the search on his Roster Items until find the desired amount of Relay Services, or while it does NOT exceed a search depth or ANY other Client implementation policy. The Client SHOULD keep a list of visited Tracker Services in order to avoid searching twice in same Service Entity.
@@ -161,7 +161,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring
]]>
In this example 'juliet@capulet.lit/balcony' returned a Relay Service entry that is restricted to its roster. This Service is usable as the requester has 'juliet@capulet.lit/balcony' on its roster. Although, services with policy 'roster' MUST NOT be listed in Tracker Responses expects in Tracker Responses that comes from the Service Entity itself, in this case 'juliet@capulet.lit/balcony'.
-In the presented example 'romeo@montague.lit/orchard' knows that 'juliet@capulet.lit/balcony' provides Relay Service, but if another entity requests 'romeo@montague.lit/orchard' its known services, it MUST NOT include 'juliet@capulet.lit/balcony' as it is a roster restricted entry.
+In the presented example 'romeo@montague.lit/orchard' knows that 'juliet@capulet.lit/balcony' provides Relay Service, but if another entity requests 'romeo@montague.lit/orchard' its known services, it MUST NOT include 'juliet@capulet.lit/balcony' as it is a roster restricted entry.
A Jingle Client with direct access to a public IP can potentially provide the Relay Service becaming itself a Jingle Relay Node. The service can intend to provide a public service, or a restricted services based on user preferences, like buddylist, whitelist, blacklist, domain, etc...
@@ -372,15 +372,9 @@ All signalling, request, response and publishing is done via XMPP, not requiring
Relay Channels auto expires MUST expire on traffic inactivity. The inactivity timeout recommended is 60 seconds.
It is heavily recommended that the Super Node implements throttle:
-
- Based on JID, allowing the control of how many concurrent channels an specific JID can have.
-
-
- Based on JID, allowing the control of how many channel requests an specific JID can request in a time period.
-
-
-
- Based on Bandwidth, allowing the control of how much bandwidth a channel can use. The maximum bandwidth SHOULD be included on the candidate element provided by a Super Node on the attribute maxkbps. If no attribute is present, it means that it has no bandwidth control.
-
+ - Based on Bandwidth, allowing the control of how much bandwidth a channel can use. The maximum bandwidth SHOULD be included on the candidate element provided by a Super Node on the attribute maxkbps. If no attribute is present, it means that it has no bandwidth control.
- ]]>
+ ]]>
The basic flow is as follows.
+ rfc3920bis RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/draft-ietf-saintandre-rfc3920bis>. " >
%ents;
]>
diff --git a/inbox/jingle-zrtp.xml b/inbox/jingle-zrtp.xml
index 8088e0b8..85058b08 100644
--- a/inbox/jingle-zrtp.xml
+++ b/inbox/jingle-zrtp.xml
@@ -40,7 +40,7 @@
- &xep0167; recommends the use of the Secure Real-time Transport Protocol (SRTP) for end-to-end encryption of RTP sessions negotiated using &xep0166;. An alternative approach to end-to-end encryption of RTP traffic is provided by &zrtp;. Although negotiation of ZRTP mainly occurs in the media channel rather than the signalling channel, the ZRTP specification defines one SDP attribute called "zrtp-hash" (this communicates the ZRTP version supported as well as a hash of the Hello message).
+ &xep0167; recommends the use of the Secure Real-time Transport Protocol (SRTP) for end-to-end encryption of RTP sessions negotiated using &xep0166;. An alternative approach to end-to-end encryption of RTP traffic is provided by &rfc6189;. Although negotiation of ZRTP mainly occurs in the media channel rather than the signalling channel, the ZRTP specification defines one SDP attribute called "zrtp-hash" (this communicates the ZRTP version supported as well as a hash of the Hello message).
The SDP format is shown below.
a=zrtp-hash:zrtp-version zrtp-hash-value
diff --git a/inbox/json.xml b/inbox/json.xml
index 4c754345..f05c4271 100644
--- a/inbox/json.xml
+++ b/inbox/json.xml
@@ -48,13 +48,11 @@
The following design requirements reflect the need to offer performance as close as possible to standard XMPP-based stanza handling.
-
- JSON default character set must be UTF-8
- JSON stanza must contain (or retain) all XMPP stanza content and hierarchy
- Server must support both XML and JSON content-types.
-
Intent for following use-cases is to support JavaScript-based clients which typically start XMPP-session from HTTP-dialog, and then depending on network environment and run-time support end using BOSH or C2S through Web Sockets.
@@ -69,23 +67,23 @@
Client (and server) implementation needs to take care of using such JSON object format which retains all structure of all XMPP XML stanzas.
- Following http-header is used to communicate with server using JSON playload:
-
+ Following http-header is used to communicate with server using JSON playload:
+
POST /http-bind HTTP/1.1
Host: httpcm.jabber.org
Accept-Encoding: gzip, deflate
Content-Type: application/jsonrequest
Content-Length: 230
-
-
+
+
HTTP/1.1 200 OK
Content-Type: application/jsonrequest
Content-Length: 513
-
In following example server name is modified so content length is not accurate. Also JSON payload is modified for better clarity of its structure.
- In following example server name is modified so content length is not accurate. Also JSON payload is modified for better clarity of its structure. JSON data is typically converted to JS-object in browser client. Practically this means that tag string name / value string pairs are converted to tag name / value string pairs. Example: JSON data is typically converted to JS-object in browser client. Practically this means that tag string name / value string pairs are converted to tag name / value string pairs. Example:
+
POST /http-bind HTTP/1.1
Host: httpcm.jabber.org
Accept-Encoding: gzip, deflate
@@ -106,8 +104,8 @@ Content-Length: 230
"@xmpp" : "urn:xmpp:xbosh" }
}
}
-
+
HTTP/1.1 200 OK
Content-Type: application/jsonrequest
Content-Length: 513
@@ -141,140 +139,139 @@ Content-Length: 513
}
}
}
-
-
+
<tag>txt-value</tag>
-
- JSON:
+ JSON:
+
{ "tag" : "txt-value" }
-
-
+
<tag>
<tag2>txt-value</tag2>
</tag>
-
- JSON:
+ JSON:
+
{ "tag" : {
"$" : {
"tag2" : "txt-value" }
}
}
-
-
+
<tag>
<tag2>txt-value1</tag2>
<tag2>txt-value2</tag2>
</tag>
-
- JSON:
+ JSON:
+
{ "tag" : {
"$" : {
"tag2" : [ "txt-value1", "txt-value2" ] }
}
}
-
-
+
<tag attr="attr-value" />
-
- JSON:
+ JSON:
+
{ "tag" : { "attr" : "attr-value" } }
-
-
+
<tag attr="attr-value1" attr="attr-value2" />
-
- JSON:
+ JSON:
+
{ "tag" : {
"attr" : [ "attr-value1", "attr-value2" ] }
}
-
-
+
<tag>
<tag2 attr="attr-value1" />
<tag2 attr="attr-value2" />
</tag>
-
- JSON:
+ JSON:
+
{ "tag" : {
"tag2" : [
{ "attr" : "attr-value1" },
{ "attr" : "attr-value2" } ]
}
}
-
-
+
<tag xmlns:ns="ns-value" />
-
- JSON:
+ JSON:
+
{ "tag" : {
"xmlns" : {
"@ns" : "attr-value" }
}
}
-
-
+
<tag xmlns="root-value" xmlns:ns="ns-value" />
-
- JSON:
+ JSON:
+
{ "tag" : {
"xmlns" : {
"$" : "root-value",
"@ns" : "attr-value" }
}
}
-
-
+
<ns:tag attr="attr-value" />
-
- JSON:
+ JSON:
+
{ "tag" : {
"$$" : "ns",
"attr" : "attr-value" }
}
-
-
+
<tag attr="attr-value">txt-value</tag>
-
- JSON:
+ JSON:
+
{ "tag" : {
"attr" : "attr-value",
"$" : "txt-value" }
}
-
-
+
<ns:tag attr="attr-value">txt-value</tag>
-
- JSON:
+ JSON:
+
{ "tag" : {
"$$" : "ns",
"attr" : "attr-value",
"$" : "txt-value" }
}
-
+
+
var s = '{ "key" : "value" }';
var sObj = JSON.parse(s); // sObj = { key : "value" };
var sStr = JSON.stringify(sObj); // sStr = '{"key":"value"}';
-
Javascript variable naming doesn't support full colon characters ':'. Intented conversion between JSON and JS-objects is based on native JavaScript class JSON, more spesifically methods JSON.stringify() for converting object to JSON, and JSON.parse() from JSON to object.
- Because of this namespace definitions are constructed hiearchically and their scope is within tag it is defined. Currently only reserved namespace name is 'xml'.
Linked Process is a protocol for Internet-scale, general-purpose distributed computing. With an implementation of this protocol, any computing device with an Internet connection can contribute computing resources to a user-generated compute cloud. +
Within the category of computing devices, Linked Process makes a distinction between resource consumers (devices making use of non-local computing resources) and a resource providers (devices offering computing resources)
- 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 + 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.
+ will set fact to the value "marko knows josh and peter" as well as make it an accessible binding.
- A useful aspect of <manage_bindings/> is that it can be used to track the state of a variable during the execution of a job. For example, suppose the following job is submitted to a JavaScript virtual machine.var x = 1.0;
+ A useful aspect of <manage_bindings/> is that it can be used to track the state of a variable during the execution of a job. For example, suppose the following job is submitted to a JavaScript virtual machine.
var x = 1.0;
while(true) {
x = x + 0.0001;
}
- This job will continue indefinitely (or until it is timed out by the virtual machine). However, during its execution, it is possible to determine the current state of x using <manage_bindings/>. Each get-based <manage_bindings/> call should return a larger x value.
+ This job will continue indefinitely (or until it is timed out by the virtual machine). However, during its execution, it is possible to determine the current state of x using <manage_bindings/>. Each get-based <manage_bindings/> call should return a larger x value.
The following namespaces are defined by Linked Process:
As with anything, there are no hard and fast rules. If there were, they might look like these. First, for devices:
And for servers, similar rules apply:
Finally, protocol designers should aim to minimize any responses required from the handset, and ensure keepalive traffic, if any, fits inside FACH wherever possible.
Because of the ability to spoof the &MOVED; element, the client SHOULD - NOT automatically subscribe to the &MOVED; element target
. + NOT automatically subscribe to the &MOVED; element target.The client MAY include initial configuration and occupant list (the list MUST NOT include the creator). The server MAY allow sending incomplete configuration form. In such case the server MUST use default values for missing fields. The server MAY enforce a minimal occupant list length.
The service MAY either give the creator the 'owner' or 'member' status. In the latter case all users are equal.
Upon room creation success, the service MUST reply with an empty IQ result.
-The following rules (similar to the ones relevant to the affiliation change request) apply to the occupant list: -
The following rules (similar to the ones relevant to the affiliation change request) apply to the occupant list:
+After the room is created (but before receiving IQ result), new occupants (including creator) receive &MESSAGE; from the room with their affiliations (stanza MUST include only recipient's affiliation) and initial room version. <prev-version /> element MUST NOT be included.
On success the server will reply with result IQ with all changed items. BEFORE returning the IQ result, the service MUST route a message with affiliation change to all relevant users.
+On success the server will reply with result IQ with all changed items. BEFORE returning the IQ result, the service MUST route a message with affiliation change to all relevant users.
Newcomers, i.e. users that were not occupants before the change, SHOULD receive only their own affiliation and SHOULD NOT receive <prev-version /> element.
The notifications must include both the new and old room version (<version /> and <prev-version /> respectively) string (except for the ones directed to users that have been removed from the room).
The notifications contain a list of items. The item list may be different from the list in IQ set, because some of the changes may require additional operations, e.g. choosing new owner when the old one leaves. Users, that are still in the room after change, will receive full change list. Users, that have been removed from the room with the request, will get only one item: themselves with affiliation 'none'.
@@ -1007,13 +1006,12 @@If the request sender does not have sufficient privileges (but is a room occupant), the service MUST reply with a 'not-allowed' error.
-It occurs in the following cases: -
It occurs in the following cases:
+MUC Light service may be abused by malicious users, e.g. due to replicating single message for every room occupant. The list below contains suggested configurable limits that SHOULD be implemented.
The service features that might vary depending on specific application are included as well.
--
Jingle XEP-0166 is used to negotiate peer to peer media sessions. Muji is a way to coordinate Jingle sessions between a group of people. -Muji conferences are held in XEP-0045 rooms. +Muji conferences are held in XEP-0045 rooms.
A Muji conference has a number of contents, each of which has unique name. content type, and an encoding. Each participant may provide a stream for each content, and communicates which contents they are willing to provide streams for, along with encoding information, in their MUC presence. This serves two purposes. Firstly, so that each participant knows which contents every other participant provides. Secondly, so that there is a global payload type (PT) mapping for the various contents, so that clients only need to encode and -payload each content that they provide once. +payload each content that they provide once.
-Participants are not required to participate all the contents that are +Participants are not required to participate all the contents that are available. For example, a Muji client might choose to only request audio -streams. +streams.
]]>
- The client MUST then wait until the MUC rebroadcasts its presence message,
+ The client MUST then wait until the MUC rebroadcasts its presence message, after which it MUST wait for all other participants that had a preparing element in their presence to finish preparation. Afterwards it should finish it's own preparation by updating its presence with the contents it wants to - take part in. + take part in.
]]>
-
- - - When a client adds a payload ID to a content description, it MUST have the +
When a client adds a payload ID to a content description, it MUST have the same codec name and receiving parameters as the corresponding entries in other participants' payload maps for that content. For instance, if Alice defines a payload type with ID 98, codec Speex and a a clock rate of 8000 @@ -170,7 +167,7 @@ streams.
Adding a stream follows a process similar to the joining a conference. As a first step an updated presence stanza MUST be send which contains a preparing - element as part of the Muji section. + element as part of the Muji section.
]]>
- The client MUST then wait until the MUC rebroadcasts its presence message,
+ The client MUST then wait until the MUC rebroadcasts its presence message, after which it MUST wait for all other participants that had a preparing - element in their presence to finish their changes. + element in their presence to finish their changes.
- Afterwards the client should add the new content to the muji section of its +Afterwards the client should add the new content to the muji section of its presence and add the content to all the jingle sessions it had with - participants it shared the content with. + participants it shared the content with.
]]>
-
First draft.
@@ -197,8 +197,8 @@
Most of the examples in this document use the scenario of Miranda and Ferdinand playing chess in Act V, Scene I of Shakespeare's The Tempest,
+ represented here as the "island-chess@games.shakespeare.lit" room. The characters are as follows: The following affiliations are defined: Owners are allowed to do what they like (saving/loading, change match options, etc.)
except in unmoderated matches. This match type restricts the use of owner privileges to specific room statuses.
Users with no affiliation SHALL NOT enter members-only matches.
- Besides that, these users have the same privileges as members.
+ Besides that, these users have the same privileges as members. The ways in which a user's affiliation changes are well-defined.
Sometimes the change results from the user's own action (e.g., registering as a member of the match),
whereas sometimes the change results from an action taken by an owner.
If a user's affiliation changes, a MUG service implementation MUST change the user's affiliation to reflect the change
- and communicate that to all occupants.
+ and communicate that to all occupants. It can be useful to invite other users to a room in which one is an occupant.
To do this, a MUG client sends XML of the following form to the &ROOM; itself
adding an &INVITE; element for every invitee.
- (the reason is OPTIONAL and the message MUST be explicitly or implicitly of type "normal"):
+ (the reason is OPTIONAL and the message MUST be explicitly or implicitly of type "normal"): A given deployment MAY wish to redirect users to another medium (e.g., a website) for further stages of registration, rather than allowing in-band registration. The recommended approach is to include only the A given deployment MAY wish to redirect users to another medium (e.g., a website) for further stages of registration, rather than allowing in-band registration. The recommended approach is to include only the <instructions/> element rather than the required fields or a data form in the IQ result, as well as a URL encoded using &xep0066; While SASL provides an excellent framework that has served us well over the past 18 years, a number of shortcomings in the profile - the syntax binding to XMPP - that is in use. This specification addresses a number of shortfalls: The new SASL profile documented herein is primarily a syntactic change to allow extensibility, combined with removal of the (largely) redundant stream restart, and additional results beyond total success or abject failure. Although initiating entities, in general, use SASL, and receiving entities offer it, the SASL specification and common parlance both use "Client " and "Server"; this specification uses Client and Server and assumes C2S links. This is not intended to preclude use of this SASL profile on S2S links. The term "SASL2" is used to mean the new SASL profile specified in this document; however the same RFC 4422 definition of SASL (and SASL profiles) applies. Examples often use hypothetical SASL mechanisms and sub-extensions; this specification does not intend to make a position on any particular SASL mechanism, and the Mandatory To Implement mechanisms are unaffected. Servers capable of SASL2 offer a stream feature of <mechanisms/>, qualified by the "urn:xmpp:sasl:0" namespace. This in turn contains one or more <mechanism/> elements in the same namespace, and potentially other elements (for example, the <hostname/> element defined within XEP-0233). Note that SASL2 is impossible for clients to initiate without at least one mechanism being available, and therefore MUST NOT be offered. The feature so advertised, and its child content, SHOULD be stable for the given stream to and from attributes and encryption state, and therefore MAY be cached by clients for later connections. The Service Name used by XMPP is unchanged from RFC 6120. In all cases, both Clients and Servers encode SASL exchanges using Base 64 encoding. This SHOULD NOT include any line wrapping or other whitespace. As the form <element/> is equivalent to <element></element>, these both indicate an empty string, which is used to indicate no data (ie, the absence of the data). In order to explicitly transmit a zero-length SASL challenge or response, the sending party sends a single equals sign character ("="). Clients, upon observing this stream feature, initiate the authentication by the use of the <authenticate/> top-level element, within the same namespace. The nature of this element is to inform the server about properties of the final stream state, as well as initiate authentication itself. To achieve the latter, it has a single mandatory attribute of "mechanism", with a string value of a mechanism name offered by the Server in the stream feature, and an optional child element of <initial-response/>, containing a base64-encoded SASL Initial Response. On subsequent connections, if a Client has previously cache the stream feature, the Client MAY choose to send it before seeing the stream features - sending it "pipelined" with the Stream Open tag for example. In order to provide support for other desired stream states beyond authentication, additional child elements are used. For example, a hypothetical XEP-0198 session resumption element might be included, and/or Resource Binding requests. Server Challenges MAY then be sent. Each Challenge MUST be responded to by a Client in a Client Response. These are not extensible, and contain the corresponding base64 encoded SASL data: At any time while authentication is in progress, neither Client nor Server sends any element (including stanzas) or other data except the top-level elements defined herein. Clients MUST NOT send whitespace, and MUST send only <response/> elements as appropriate or an <abort/> element to immediately cause an error. Servers MUST disconnect Clients immediately if any other traffic is received. Servers are similarly REQUIRED to send no whitespace, and only the <response/> and completion elements from the section below. Authentication may complete in one of three ways. It may complete successfully, in which case the client is authenticated. It may also fail, in which case the client is not authenticated and the stream and session state remain entirely unchanged. Finally, it may have completed successfully, but further interaction is required - for example, a password change or second-factor authentication. If the Client is now authenticated, the Server sends a <success/> element, which contains an OPTIONAL <additional-data/> element containing SASL additional data. It also contains a <authorization-identity/> element containing the negotiated identity - this is a bare JID, unless resource binding has occurred, in which case it is a full JID. Other extension elements MAY also be contained by the <success/> element. Any security layer negotiated SHALL take effect after the ">" octet of the closing tag (ie, immediately after "</success>"). A <failure/> element is used by the server to terminate the authentication attempt. It MAY contain application-specific error codes, and MAY contain a textual error. It MUST contain one of the SASL error codes from RFC 6120 Section 6.5. A <continue/> element is used to indicate that while the SASL exchange was successful, it is insufficient to allow authentication at this time. This can be used to indicate that the Client needs to perform a Second Factor Authentication ("2FA"), or is required to change password. These are conducted as additional SASL mechanisms. Such SASL mechanisms MUST NOT change the authorization identifier, or introduce any security layer. The authorization identifer transmitted during the subsequent <success/>, and any security layer which comes into effect after the eventual <success/>, therefore MUST be that of the first mechanism. The element contains a <mechanisms/> element, as defined above as a stream feature, containing suitable mechanisms. It MAY contain an <additional-data/> element, as the <success/> element does. Finally, it MAY contain a <text/> element, which can contain human-readable data explaining the nature of the step required. Clients respond with a <next-authenticate/> element, which has a single mandatory attribute of "mechanism", containing the selected mechanism name, and contains an OPTIONAL base64 encoded initial response. This provides pointers and/or clarifications to the in the order and manner defined in RFC 4422, section 4. The service name SHALL be "xmpp", as defined by RFC 6120. Servers list mechanisms during stream features (See ) and within the <continue/> element (See ). TODO: Neither this specification nor RFC 6120 allow clients access to the mechanism list after SASL negotiation...? Clients initiate using the <authenticate/> top level element (See , and after any <continue/> with the <next-authenticate/> message (See ). See . See . If a Client specifies an authorization string which is non-empty, the identifier is normalized by treating it as a JID, and performing normalization as described in RFC 7622. Clients MAY abort unilaterally by sending <abort/> as specified in . Servers MAY abort unliterally by sending <failure/> with the <aborted/> error code as defined in . See . Option (a) is used - any SASL Security Layer is applied first to data being sent, and TLS applied last. Although the <continue/> concept does use multiple SASL sequences, only the first SASL mechanism used is considered an authentication, and only the first can negotiate a security layer. In particular, once <success/> has been sent by the server, any further <authenticate/> element MUST result in a stream error. Relative to the SASL profile documented in RFC 6120, this introduces more data unprotected by any security layer negotiated by SASL itself. This XEP requires no interaction with &IANA;. None. The author wishes to share any credit with many members of the community, including Lance Stout, Ralph Meijer, and Florian Schmaus. Adapter publishes device meta data: To make it easier for agents to sort through available devices and seonsors, it is desirable for implementations to use a common set of types. The following device types are defined:
-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 kilowatt-second with a resolution to the nearest 0.1 kWh. If no unitScaler value is specified, then a unitScaler of 0 (aka 10**0 = 1) is assumed.
Values for a transducer are published via the data value node: OPTIONAL: Instead of putting all of the transducer values into a single data value node, an adapter MAY want to break up the transducer values into multiple nodes.
For example, an adapter may want to do this for reasons of security (allow some entities to subscribe/publish to transducer Y1 and a different set of entities to subscribe/publish to transducer Y2).
@@ -804,7 +796,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. Actuation takes place as a split-phase operation with an action signal (publish) followed by a completion callback (subscribed message).
@@ -1153,12 +1143,11 @@ Event Node ID: 4d4335b5-4134-11e0-9207-0800200c9a66_data
]]>
- Two things to note:
+ Two things to note:
To continue this example further, let's assume an agent is subscribed to the data value node and can also publish to the tid2 node which controls the light.
In this case, an agent will receive notification that movement was sensed and can take action.
@@ -1302,7 +1291,7 @@ If an adapter chooses to publish a subset of transducer data (for example, only
the changed values), it is possible for consumers who are off line or recently
activated to miss older values.
There are a variety of ways to handle this depending on the needs of the
-implementor including (but not limited to):
+implementor including (but not limited to): If an implementaion chooses to put some transducers values into their own nodes
(instead of putting them all into the data value node), remember that a transducer value MUST appear in either the data value node or its own node, but not both.
The meta node indicates to consumers which node they should subscribe to in order to be notified when new data is available for their chosen transducer.
There are various spim protection methods exist in XMPP: &xep0016;, &xep0158;, &xep0191;, &xep0268; and &xep0275;. But they may not be sufficient enough:
+ There are various spim protection methods exist in XMPP: &xep0016;, &xep0158;, &xep0191;, &xep0268; and &xep0275;. But they may not be sufficient enough: Service administrators might want to deploy server-based spim recognition software to fill in the gaps. However, every automated spim recognition suffers from false positives - situations where a stanza incorrectly qualified as spim. To avoid them, a spim filter doesn't block suspicious stanza, but marks it and sends to a client in a regular manner. A client software doesn't need to interrupt a user when processing such marked stanzas: for example, it may put them silently in "SPAM" folder, so a user can look through them at any time later. Furthermore, a spim filter may take user's experience into account. When a user receives an unsolicited stanza, he or she can mark it as spim. In this case a client software sends an automatic complaint to a server-based spim filter. This specification deals with both cases. Thus, in contrast to &xep0159;, it doesn't introduce any spim blocking techniques. Also, the various spim recognition procedures that may be employed by the server are beyond the scope of this document.
A filtering entity SHOULD only add <mark/> or <report/> elements and a receiving entity SHOULD only process those elements if the corresponding stanza envolves an interaction with a human user: subscription requests, messages, conference invites, voice calls, etc. For example, it doesn't make a lot of sense to mark &xep0232; stanzas. To avoid obvious false positives and user confusions, a filtering entity SHOULD NOT add <mark/> or <report/> elements to a stanza and a receiving entity SHOULD ignore <mark/> and <report/> elements of a stanza if:
+ To avoid obvious false positives and user confusions, a filtering entity SHOULD NOT add <mark/> or <report/> elements to a stanza and a receiving entity SHOULD ignore <mark/> and <report/> elements of a stanza if: If an entity supports the spim markers, it MUST report that by including a service discovery feature of "urn:xmpp:spim-marker:0" in response to a &xep0030; information request. If an entity supports the spim reports, it MUST report that by including a service discovery feature of "urn:xmpp:spim-report:0" in response to a &xep0030; information request:
During the game, players change in turn, each of them MUST send only one move at a time.
It MUST possess these attributes:
-
@@ -164,8 +164,8 @@
Note: The text that follows assumes that implementors have
- read and understood XEP-0050, password
- generation algorithms described in &rfc4226; and RFC 6238,
+ read and understood &xep0050;, password
+ generation algorithms described in &rfc4226; and &rfc6238;,
and randomness requirements described in &rfc4086;,
and know about one-time pads and perfect secrecy.
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,
+ &rfc6238; is an extension of the HMAC-based
+ One-Time Password (HOTP) algorithm defined in &rfc4226;,
to support the time-based moving factor. In TOTP, time
reference and a time step replaces the counter in the HOTP
computation.
@@ -431,14 +431,14 @@
- In each case, the Verifier MAY check Prover's JID right after
+ In each case, the Verifier MAY check Prover's JID right after
receiving the first Ad-Hoc command or after a succesful verification
- process.
+ process. If Prover's JID is not approved, the Verifier SHOULD
+ reply with &forbidden; error message. After the a succesful verification the Verifier can, e.g., A user may obtain their own rating by sending an IQ-get with no to address and an element qualified by the ‘rating’ namespace. The server should return an IQ result stanza with <rating/> element: In installations that run as chat servers, moderation of spam users can be delivered to online users and administrators. Users receiving spam from a bare JID can send an IQ stanza to the server that increases the user rating.
JIDs that are critical to server functionality or admins should have a
- permanent OPTIONAL.
Room Nickname Full JID Affiliation Game Role
@@ -216,7 +216,7 @@
Room Type
@@ -275,11 +275,11 @@
+
+
+
+
]]>
-
-
Attribute
@@ -373,11 +372,9 @@ If the meta node is configured to include payloads, the subscribers will receive
A serial number or other unique identifier for the physical device
-
-
Attribute
@@ -507,13 +504,11 @@ The tuple (UUID X, transducer id Y) MUST be unique such that a publish operation
The accuracy of the values reported by this transducer
-
-
Type
@@ -610,7 +605,6 @@ The tuple (UUID X, transducer id Y) MUST be unique such that a publish operation
Other type that isn't listed above
-The following example shows how to specify a sensor in kilograms.
+
-The following example shows how to specify a sensor in kilowatt-second with a resolution to the nearest 0.1 kWh.
+
-If no unitScaler value is specified, then a unitScaler of 0 (aka 10**0 = 1) is assumed.
+
]]>
-
-
Attribute
@@ -744,7 +737,6 @@ The tuple (UUID X, transducer id Y) MUST be unique such that a publish operation
The raw value as seen by the transducer. The rawValue can be used to record a non-unit converted value for record keeping (e.g. a raw ADC value before calibration).
]]>
-
-
Attribute
@@ -922,7 +913,6 @@ The tuple (UUID X, transducer id Y) MUST be unique such that a publish operation
If the adapter can verify that the raw value is an allowable value for the transducer, it SHOULD allow the raw value to take precedence over the typedValue if provided.
-
-If an implementaion chooses to put some transducers values into their own nodes
+
@@ -175,14 +175,14 @@
@@ -193,10 +193,10 @@
diff --git a/inbox/spim.xml b/inbox/spim.xml
index 39d1e232..a3279181 100644
--- a/inbox/spim.xml
+++ b/inbox/spim.xml
@@ -43,14 +43,14 @@
- Service administrators might want to deploy server-based spim recognition software to fill in the gaps. However, every automated spim recognition suffers from false positives - situations where a stanza incorrectly qualified as spim. To avoid them, a spim filter doesn't block suspicious stanza, but marks it and sends to a client in a regular manner. A client software doesn't need to interrupt a user when processing such marked stanzas: for example, it may put them silently in "SPAM" folder, so a user can look through them at any time later. Furthermore, a spim filter may take user's experience into account. When a user receives an unsolicited stanza, he or she can mark it as spim. In this case a client software sends an automatic complaint to a server-based spim filter. This specification deals with both cases. Thus, in contrast to &xep0159;, it doesn't introduce any spim blocking techniques. Also, the various spim recognition procedures that may be employed by the server are beyond the scope of this document.
+
-
-
+
-
- Name
- Type
- Description
-
-
- 'id'
- REQUIRED
- The number of the move. First move is 1.
-
-
- 'row'
- REQUIRED
- The horizontal position of the mark.
-
-
- 'col'
- REQUIRED
- The vertical position of the mark.
-
+
+
+ Name
+ Type
+ Description
+
+
+ 'id'
+ REQUIRED
+ The number of the move. First move is 1.
+
+
+ 'row'
+ REQUIRED
+ The horizontal position of the mark.
+
+
+ 'col'
+ REQUIRED
+ The vertical position of the mark.
+
-
+
-
- Name
- Type
- Description
-
-
- 'id'
- REQUIRED
- The number of the move. First move is 1.
-
-
- 'row'
- REQUIRED
- The horizontal position of the mark.
-
-
- 'col'
- REQUIRED
- The vertical position of the mark.
-
+
+
+ Name
+ Type
+ Description
+
+
+ 'id'
+ REQUIRED
+ The number of the move. First move is 1.
+
+
+ 'row'
+ REQUIRED
+ The horizontal position of the mark.
+
+
+ 'col'
+ REQUIRED
+ The vertical position of the mark.
+