From d60e922a8a5f5385ec284aad3f22554f4cd5dbf4 Mon Sep 17 00:00:00 2001
From: Peter Saint-Andre Initial published version approved by the XMPP Council. Defined HTTP lookup methods using well-known URIs as specified in RFC 5785. First draft. Rayo allows for the third-party control of media sessions such as telephone calls. A common requirement in telephony applications is to establish the progress characteristics of the session, such as dtmf, fax or modem tones, or to differentiate between a human and an answering machine. This specification extends the core Rayo specification, and specifically its Input component to describe a protocol for establishing such progress analysis and gathering its results. This section describes the form, function and order of Rayo stanzas sent across the wire, and the circumstances in which they apply and/or may arise. CPA is achieved as a special case of the core input component. All rules regarding component execution and the input component in particular apply from the core specification. When a call's controlling party wishes to begin detection of signals from the suported set, it SHOULD begin an input component with the mode attribute set as 'cpa'. The grammars supplied determine the types of signal detected and parameters applied to their detection. The grammars MUST be referenced by URI in the format described below. If a Rayo server supports this specification, it MUST invoke its supported CPA function using the parameters provided from the grammars; if it does not support this specification or any of the supplied parameters within the grammar, it MUST raise an error according to the rules in the core specification. The server MUST validate that it has appropriate resources/mechanisms to collect the requested signals before acknowledging the component creation. If the meta-attribute named 'terminate' is set to true in the grammar, the component MUST terminate on the first signal match it detects. If it is set to false, signals MUST be reported as events until the component is instructed to stop. The input completion reason MUST be one of the supported reasons from the core specification or a signal, indicating that the CPA engine detected one of the requested signals. Any signals other than those requested by the input grammar should be ignored. The grammar URI declares the signal type of interest and the parameters which apply to their detection. The URI should be composed of a URN from the following list of allowed signal types, and parameters to modify their detection as a query string. The names and allowed values of these parameters are implementation specific. Servers MUST support one reserved parameter named 'terminate', whose value indicates the termination behaviour of the component on signal detection as described above. Describes a detected signal. The attributes of the <grammar/> element are as follows. Signal types may be one of the following: STRONGLY RECOMMENDED. If a Rayo server supports Rayo CPA, it MUST advertise that fact by returning a feature of "urn:xmpp:rayo|cpa:0" &VNOTE; in response to a &xep0030; information request. In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead. A server MUST document any cases where its behaviour differs from that in this specification (such as lack of support for particular options/components/etc) and return an error whenever a command is not understood. A server MUST NOT silently ignore any instructions. None This document requires no interaction with &IANA;. This specification defines the following XML namespaces: The ®ISTRAR; includes the foregoing namespaces in its registry at &NAMESPACES;, as governed by &xep0053;. If the protocol defined in this specification undergoes a major revision that is not fully backward-compatible with an older version, or that contains significant new features, the XMPP Registrar shall increment the protocol version number found at the end of the XML namespaces defined herein, as described in Section 4 of XEP-0053. The authors would like to acknowledge the input of teams at Tropo Inc, Mojo Lingo and Grasshopper in the development of this specification. Specific individuals who have contributed to the specification or to software significant to its completion include: First draft. Rayo allows for the third-party control of media sessions such as telephone calls. A common requirement in telephony applications providing backward compatability with legacy systems is to support sending and receiving faxes. This specification extends the core Rayo specification, to describe a protocol for this use case. This section describes the form, function and order of Rayo stanzas sent across the wire, and the circumstances in which they apply and/or may arise. A Rayo client may utilise Rayo CPA to establish a fax CNG tone before initiating fax receipt using the receivefax component described below. The receivefax component accepts a fax from a caller, stores it, and makes it available to Rayo clients. The component is created using a <receivefax/> command. The server MUST validate that it has apropriate resources/mechanisms to receive the fax before acknowledging the component creation. The receivefax component does not implement any intermediary commands. The receivefax component does not provide any intermediate events. The receivefax completion reason MUST be one of the core Rayo reasons or finish (indicating that the document was fully received). Receivefax component completion provides a fax element only when a document was successfully received. The server MUST present the fax for consumption by the client by way of fax meta-data on the complete reason, including a URI at which the document may be fetched. It MUST provide url, resolution, file size & page count data as specified on the fax element. In cases of partial receipt of a fax, a fax element MAY be returned in addition to the error completion reason. Sending faxes can be achieved by using the Sendfax component. A conformant server MUST support image/tiff documents, and MAY also support others. A conformant server MUST support fetching documents via an HTTP URL and MAY support other URL schemes. Additionally, a sendfax component MAY include in its completion reason one or more <metadata/> elements describing the result of transmitting the document, like so: Instructs the server to begin receiving a fax. The <receivefax/> element MUST be empty. The <receivefax/> element has no attributes. Instructs the server to begin transmitting a fax. The <sendfax/> element MUST be empty. The <sendfax/> element has no attributes. Provides the result of a received fax, as a reference to its location. The <fax/> element MUST be empty. The attributes of the <fax/> element are as follows. Provides data for a document to be sent as a fax. The <document/> element MUST be empty. The attributes of the <document/> element are as follows. Provides implementation-specific key-value pairs of metadata regarding the transmission or receipt of a fax document. The <metadata/> element MUST be empty. The attributes of the <metadata/> element are as follows. Indicates that the component came to an end due to the document being received successfully. The <finish/> element MUST be empty. The <finish/> element has no attributes. If a Rayo server supports Rayo Fax, it MUST advertise that fact by returning a feature of "urn:xmpp:rayo:fax:1" &VNOTE; in response to a &xep0030; information request. In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead. A server MUST document any cases where its behaviour differs from that in this specification (such as lack of support for particular options/components/etc) and return an error whenever a command is not understood. A server MUST NOT silently ignore any instructions. None This document requires no interaction with &IANA;. This specification defines the following XML namespaces: The ®ISTRAR; includes the foregoing namespaces in its registry at &NAMESPACES;, as governed by &xep0053;. If the protocol defined in this specification undergoes a major revision that is not fully backward-compatible with an older version, or that contains significant new features, the XMPP Registrar shall increment the protocol version number found at the end of the XML namespaces defined herein, as described in Section 4 of XEP-0053. The authors would like to acknowledge the input of teams at Mojo Lingo and Grasshopper in the development of this specification. Specific individuals who have contributed to the specification or to software significant to its completion include: Incorporated patches from community review. Furthermore, no aspect of this protocol limits its use to communication between a client and a server. For example, it could be used for communication between a server and a peer server if such communication can occur for the relevant application (e.g., in XMPP). However, this document focuses exclusively on use of the transport by clients that cannot maintain arbitrary persistent TCP connections with a server. We assume that servers and components are under no such restrictions and thus would use the native connection transport for the relevant application. (However, on some unreliable networks, BOSH might enable more stable communication between servers.) Since HTTP is a synchronous request/response protocol, the traditional solution to emulating a bidirectional-stream over HTTP involved the client intermittently polling the connection manager to discover if it has any data queued for delivery to the client. This naive approach wastes a lot of network bandwidth by polling when no data is available. It also reduces the responsiveness of the application since the data spends time queued waiting until the connection manager receives the next poll (HTTP request) from the client. This results in an inevitable trade-off between responsiveness and bandwidth, since increasing the polling frequency will decrease latency but simultaneously increase bandwidth consumption (or vice versa if polling frequency is decreased). The technique employed by BOSH achieves both low latency and low bandwidth consumption by encouraging the connection manager not to respond to a request until it actually has data to send to the client. As soon as the client receives a response from the connection manager it sends another request, thereby ensuring that the connection manager is (almost) always holding a request that it can use to "push" data to the client. If the client needs to send some data to the connection manager then it simply sends a second request containing the data. Unfortunately most constrained clients do not support HTTP Pipelining (concurrent requests over a single connection), so the client typically needs to send the data over a second HTTP connection. The connection manager always responds to the request it has been holding on the first connection as soon as it receives a new request from the client -- even if it has no data to send the client. It does so to make sure the client can send more data immediately if necessary. (The client SHOULD NOT open more than two HTTP connections to the connection manager at the same time, BOSH works reliably even if network conditions force every HTTP request to be made over a different TCP connection. However, if as is usually the case, the client is able to use HTTP/1.1, then (assuming reliable network conditions) all requests during a session will pass over the same two persistent TCP connections. Almost all of the time (see below) the client is able to push data on one of the connections, while the connection manager is able to push data on the other (so latency is as low as a standard TCP connection). It's interesting to note that the roles of the two connections typically switch whenever the client sends data to the connection manager. If there is no traffic in either direction for an agreed amount of time (typically several minutes), then the connection manager responds to the client with no data, and that response immediately triggers a fresh client request. The connection manager does so to ensure that if a network connection is broken then both parties will realise within a reasonable amount of time. This exchange is similar to the "keep-alive" or "ping" that is common practice over most persistent TCP connections. Since the BOSH technique involves no polling, bandwidth consumption is not significantly greater than a standard TCP connection. Most of the time data can be pushed immediately. However, if one of the endpoints has just pushed some data then it will usually have to wait for a network round trip until it is able to push again. If HTTP Pipelining is available to the client then multiple concurrent requests are possible. Thus the client can always push data immediately. It can also ensure the connection manager is always holding enough requests such that even during bursts of activity it will never have to wait before pushing data. Furthermore, if the pool of requests being held by the connection manager is large enough, then the client will not be under pressure to send a new empty request immediately after receiving data from the connection manager. It can instead wait until it needs to send data. Therefore, if over time the traffic to and from the client is balanced, bandwidth consumption will be about the same as if a standard TCP connection were being used. Each block of data pushed by the connection manager is a complete HTTP response. So, unlike the Comet technique, the BOSH technique works through intermediate proxies that buffer partial HTTP responses. It is also fully compliant with HTTP/1.0 -- which does not provide for chunked transfer encoding. The technique employed by BOSH, which is sometimes called "HTTP long polling", reduces latency and bandwidth consumption over other HTTP polling techniques. When the client sends a request, the connection manager does not immediately send a response; instead it holds the request open until it has data to actually send to the client (or an agreed-to length of inactivity has elapsed). The client then immediately sends a new request to the connection manager, continuing the long polling loop. If the connection manager does not have any data to send to the client after some agreed-to length of time Where clients and connection managers support persistent connections (i.e. "Connection: keep-alive" from HTTP/1.0, and which is the default state for HTTP/1.1), these sockets remain open for an extended length of time, awaiting the client's next request. This reduces the overhead of socket establishment, which can be very expensive if HTTP over Secure Sockets Layer (SSL) is used. If the client has data to send while a request is still open, it establishes a second socket connection to the connection manager to send a new request. The connection manager immediately responds to the previously held request (possibly with no data) and holds open this new request. This results in the connections switching roles; the "old" connection is responded to and left awaiting new requests, while the "new" connection is now used for the long polling loop. The following diagram illustrates this technique (possibly after XMPP session establishment) The requirements of RFC 2616 MUST be met for both requests and responses. Additional HTTP headers not specified herein MAY be included, but receivers SHOULD ignore any such headers. Clients and connection managers MAY omit headers that are not mandated by RFC 2616 and would otherwise be ignored (e.g. if the client has constrained bandwidth), but clients are advised that network and proxy policies could block such requests. All information is encoded in the body of standard HTTP POST requests and responses. Each HTTP body contains a single <body/> wrapper which encapsulates the XML elements being transferred (see <body/> Wrapper Element). Clients SHOULD send all HTTP requests over a single persistent HTTP/1.1 connection using HTTP Pipelining. However, a client MAY deliver its POST requests in any way permitted by RFC 1945 or RFC 2616. For example, constrained clients can be expected to open more than one persistent connection instead of using Pipelining, or in some cases to open a new HTTP/1.0 connection to send each request. However, clients and connection managers SHOULD NOT use Chunked Transfer Coding, since intermediaries might buffer each partial HTTP request or response and only forward the full request or response once it is available. Clients MAY include an HTTP Accept-Encoding header in any request. If the connection manager receives a request with an Accept-Encoding header, it MAY include an HTTP Content-Encoding header in the response (indicating one of the encodings specified in the request) and compress the response body accordingly. Requests and responses MAY include HTTP headers not specified herein. The receiver SHOULD ignore any such headers. Each BOSH session MAY share the HTTP connection(s) it uses with other HTTP traffic, including other BOSH sessions and HTTP requests and responses completely unrelated to this protocol (e.g., web page downloads). However, the responses to requests that are not part of the session sent over the same connection using HTTP pipelining (or queued to be sent over the same connection) might be delayed if they were sent while a request that is part of the session is being held (since the connection manager MUST send its responses in the same order that the requests were received, and the connection manager typically delays its responses). The HTTP Content-Type header of all client requests SHOULD be "text/xml; charset=utf-8". However, clients MAY specify another value if they are constrained to do so (e.g., "application/x-www-form-urlencoded" or "text/plain"). The client and connection manager SHOULD ignore all HTTP Content-Type headers they receive. The <body/> element SHOULD also include the following attributes (they SHOULD NOT be included in any other responses): The connection manager MAY include an 'accept' attribute in the session creation response element, to specify a space-separated list of the content encodings it can decompress. After receiving a session creation response with an 'accept' attribute, clients MAY include an HTTP Content-Encoding header in subsequent requests (indicating one of the encodings specified in the 'accept' attribute) and compress the bodies of the requests accordingly. The connection manager MAY include an 'accept' attribute in the session creation response element, to specify a comma-separated list of the content encodings it can decompress. After receiving a session creation response with an 'accept' attribute, clients MAY include an HTTP Content-Encoding header in subsequent requests (indicating one of the encodings specified in the 'accept' attribute) and compress the bodies of the requests accordingly. A connection manager MAY include an 'ack' attribute (set to the value of the 'rid' attribute of the session creation request) to indicate that it will be using acknowledgements throughout the session and that the absence of an 'ack' attribute in any response is meaningful (see Acknowledgements). If the connection manager supports session pausing (see Inactivity) then it SHOULD advertise that to the client by including a 'maxpause' attribute in the session creation response element. The value of the attribute indicates the maximum length of a temporary session pause (in seconds) that a client can request. For both requests and responses, the <body/> element and its content SHOULD be UTF-8 encoded. If the HTTP Content-Type header of a request/response specifies a character encoding other than UTF-8, then the connection manager MAY convert between UTF-8 and the other character encoding. However, even in this case, it is OPTIONAL for the connection manager to convert between encodings. The connection manager MAY inform the client which encodings it can convert by setting the optional 'charsets' attribute in the session creation response element to a space-separated list of encodings. As soon as the connection manager has established a connection to the server and discovered its identity, it MAY forward the identity to the client by including a 'from' attribute in a response, either in its session creation response, or (if it has not received the identity from the server by that time) in any subsequent response to the client. If it established a secure connection to the server (as defined in Initiating a BOSH Session), then in the same response the connection manager SHOULD also include the 'secure' attribute set to "true" or "1". As soon as the connection manager has established a connection to the server and discovered its identity, it MAY forward the identity to the client by including a 'from' attribute in a response, either in its session creation response, or (if it has not received the identity from the server by that time) in any subsequent response to the client. Note: If the connection manager did not specify a 'polling' attribute in the session creation response, then it MUST allow the client to poll as frequently as it chooses. At any time, the client MAY gracefully terminate the session by sending a <body/> element with a 'type' attribute set to "terminate". The termination request MAY include one or more payloads that the connection manager MUST forward to the server to ensure graceful logoff. Unreliable network communications or client constraints can result in broken connections. The connection manager SHOULD remember the 'rid' and the associated HTTP response body of the client's most recent requests which were not session pause requests (see Inactivity) and which did not result in an HTTP or binding error. The number of responses to non-pause requests kept in the buffer SHOULD be either the same as the maximum number of simultaneous requests allowed by the connection manager or, if Acknowledgements are being used, the number of responses that have not yet been acknowledged. If the network connection is broken or closed before the client receives a response to a request from the connection manager, then the client MAY resend an exact copy of the original request. Whenever the connection manager receives a request with a 'rid' that it has already received, it SHOULD return an HTTP 200 (OK) response that includes the buffered copy of the original XML response to the client (i.e., a <body/> wrapper possessing appropriate attributes and optionally containing one or more XML payloads). If the original response is not available (e.g., it is no longer in the buffer), then the connection manager MUST return an 'item-not-found' terminal binding error: If the network connection is broken or closed before the client receives a response to a request from the connection manager, then the client MAY resend an exact copy of the original request. Whenever the connection manager receives a request with a 'rid' that it has already received, it SHOULD return an HTTP 200 (OK) response that includes the buffered copy of the original XML response to the client (i.e., a <body/> wrapper possessing appropriate attributes and optionally containing one or more XML payloads). If the connection manager receives a request for a 'rid' which has already been received but to which it has not yet responded then it SHOULD respond immediately to the existing request with a recoverable binding condition (see Recoverable Binding Conditions) and send any future response to the latest request. There is a possibility that a client might subvert polling frequency limits by deliberately sending requests for the same 'rid' multiple times, and so a connection manager implementation MAY choose to impose a limit to the frequency or number of requests for the same 'rid'. If the client exceeds this limit then the connection manager SHOULD terminate the HTTP session and return a 'policy-violation' terminal binding error to the client (see Terminal Binding Conditions). If the original response is not available (e.g., it is no longer in the buffer), then the connection manager MUST return an 'item-not-found' terminal binding error: Because case is not significant in hexadecimal encoding, key comparisons SHOULD be case insensitive. The client MUST set the 'newkey' attribute of the first request in the session to the value K(n). The connection manager MAY verify the key by calculating the SHA-1 hash of the key and comparing it to the 'newkey' attribute of the previous request (or the 'key' attribute if the 'newkey' attribute was not set). If the values do not match (or if it receives a request without a 'key' attribute and the 'newkey' or 'key' attribute of the previous request was set), then the connection manager MUST NOT process the element, MUST terminate the session, and MUST return an 'item-not-found' terminal binding error. The connection manager MAY verify the key by calculating the SHA-1 hash of the key and performing a case insensitive comparison of it to the 'newkey' attribute of the previous request (or the 'key' attribute if the 'newkey' attribute was not set). If the values do not match (or if it receives a request without a 'key' attribute and the 'newkey' or 'key' attribute of the previous request was set), then the connection manager MUST NOT process the element, MUST terminate the session, and MUST return an 'item-not-found' terminal binding error. If the connection manager included a 'stream' attribute in its session creation response then the client MAY ask it to open another stream at any time by sending it an empty <body/> element with a 'to' attribute. The request MUST include valid 'sid' and 'rid' If the connection manager included a 'stream' attribute in its session creation response then the client MAY ask it to open another stream at any time by sending it an empty <body/> element with a 'to' attribute. The request MUST include valid 'sid' and 'rid' If the connection manager did not indicate its support for multiple streams at the start of the session, then it MUST ignore the extra attributes and treat the request as a normal empty request for payloads (see Sending and Receiving XML Payloads). If the connection manager did not indicate its support for multiple streams at the start of the session, then it MUST ignore the extra attributes and treat the request as a normal empty request for payloads (see Sending and Receiving XML Payloads). Note: If the response did not include either 'from' or 'secure' attributes then they MAY be sent in a subsequent response instead (see Session Creation Response). In that case the 'stream' attribute MUST also be specified. Note: If the response did not include a 'from' attribute then they MAY be sent in a subsequent response instead (see Session Creation Response). In that case the 'stream' attribute MUST also be specified. If more than one stream has been opened within a session, then all non-empty <body/> elements sent by the connection manager MUST include a 'stream' attribute that specifies which stream all the payloads it contains belong to. The client SHOULD include a 'stream' attribute for the same purpose. The client MAY omit the 'stream' attribute if it wants the connection manager to broadcast the payloads over all open streams. Note: A <body/> element MUST NOT contain different payloads for different streams. If a stream name does not correspond to one of the session's open streams, then the receiving connection manager SHOULD return an 'item-not-found' terminal binding error, or the receiving client SHOULD terminate the session. However, if the receiving entity has only just closed the stream (and the sender might not have been aware of that when it sent the payloads), then it MAY instead simply silently ignore any payloads the <body/> element contains. Note: Empty <body/> elements that do not include a 'from' or 'secure' attribute SHOULD NOT include a 'stream' attribute (since nothing is being transmitted for any stream). If such a <body/> element does include a 'stream' attribute then the receiving entity SHOULD ignore the attribute. Note: Empty <body/> elements that do not include a 'from' attribute SHOULD NOT include a 'stream' attribute (since nothing is being transmitted for any stream). If such a <body/> element does include a 'stream' attribute then the receiving entity SHOULD ignore the attribute. If more than one stream is open within a session, the client MAY close one open stream at any time using the procedure described in the section Terminating the HTTP Session above, taking care to specify the stream name with a 'stream' attribute. If the client closes the last stream the connection manager MUST terminate the session. If the client does not specify a stream name then the connection manager MUST close all open streams (sending any payloads the terminate request contains to all streams), and terminate the session. If more than one stream is open within a session, the client MAY close one open stream at any time using the procedure described in the section Terminating the BOSH Session above, taking care to specify the stream name with a 'stream' attribute. If the client closes the last stream the connection manager MUST terminate the session. If the client does not specify a stream name then the connection manager MUST close all open streams (sending any payloads the terminate request contains to all streams), and terminate the session. Even if the client requests HTTP Pipelining and the connection manager supports it, there is no guarantee that pipelining will succeed, because it might not be supported by intermediate proxies. The best the client can do is to request the use of HTTP Pipelining by setting the 'hold' attribute to a value of "1". If HTTP Pipelining does not work (because the server returns HTTP 1.0 or connection:close), then the client SHOULD degrade gracefully by using multiple connections. The client SHOULD set the 'hold' attribute to a value of "1". If HTTP Pipelining does not work (because the server returns HTTP 1.0 or connection:close), then the client SHOULD degrade gracefully by using multiple connections. Thanks to Mike Cumings, Tomas Karasek, Tobias Markmann, Chris Seymour, Safa Sofuoğlu, Stefan Strigler, Matthew Wild, Kevin Winters, and Christopher Zorn for their feedback. Thanks to Dave Cridland, Mike Cumings, Tomas Karasek, Steffen Larsen, Tobias Markmann, Matt Miller, Chris Seymour, Safa Sofuoğlu, Stefan Strigler, Mike Taylor, Winfriend Tilanus, Matthew Wild, Kevin Winters, and Christopher Zorn for their feedback. Incorporated patches from community review. The client SHOULD include a 'version' attribute qualified by the 'urn:xmpp:xbosh' namespace in its session creation request. This attribute corresponds to the 'version' attribute of the XMPP <stream:stream/> element as defined in RFC 3920 and &rfc6120;. The connection manager SHOULD forward the value to the XMPP server accordingly. The client SHOULD include a 'version' attribute qualified by the 'urn:xmpp:xbosh' namespace in its session creation request. This attribute corresponds to the 'version' attribute of the XMPP <stream:stream/> element as defined in &rfc6120;. The connection manager SHOULD forward the value to the XMPP server accordingly. Note: The client SHOULD ignore any Transport Layer Security (TLS) feature since BOSH channel encryption SHOULD be negotiated at the HTTP layer. TLS compression (as defined in RFC 3920) and Stream Compression (as defined in &xep0138;) are NOT RECOMMENDED since compression SHOULD be negotiated at the HTTP layer using the 'accept' attribute of the BOSH session creation response. TLS compression and Stream Compression SHOULD NOT be used at the same time as HTTP content encoding. TLS compression (as defined in &rfc6120;) and Stream Compression (as defined in &xep0138;) are NOT RECOMMENDED since compression SHOULD be negotiated at the HTTP layer using the 'accept' attribute of the BOSH session creation response. TLS compression and Stream Compression SHOULD NOT be used at the same time as HTTP content encoding. Note: The 'version' attribute qualified by the 'urn:xmpp:xbosh' namespace SHOULD also be included on the request and response when adding new streams to a session. A success case for authentication and resource binding using the XMPP protocols is shown below. For detailed specification of these protocols (including error cases), refer to RFC 3920 and draft-ietf-xmpp-3920bis. A success case for authentication and resource binding using the XMPP protocols is shown below. For detailed specification of these protocols (including error cases), refer to &rfc6120; It is possible that a connection manager will receive a stanza for delivery to a client even though the client connection is no longer active (e.g., before the connection manager is able to inform the XMPP server that the connection has died). In this case, the connection manager would return an error to the XMPP server; it is RECOMMENDED that the connection manager proceed as follows, since the situation is similar to that addressed by point #2 of Section 11.1 of RFC 3921: It is possible that a connection manager will receive a stanza for delivery to a client even though the client connection is no longer active (e.g., before the connection manager is able to inform the XMPP server that the connection has died). In this case, the connection manager would return an error to the XMPP server; it is RECOMMENDED that the connection manager proceed as follows, since the situation is similar to that addressed by point #2 of Section 11.1 of &rfc6121; Thanks to Dave Cridland, Steffen Larsen, Matt Miller, Jack Moffitt, Stefan Strigler, Mike Taylor, Winfried Tilanus, Ashley Ward, and Matthew Wild for their feedback. Thanks to Kevin Winters for his assistance with the schema. First draft.
+ This XEP provides a common framework for sending events over an XMPP network. These events can then be logged in event logs or analyzed by network monitors
+ to analyze the status or operation of the network and its participants.
+
+ The basic principle behind interoperable event logging over XMPP is the definition of a common XML element defining the event. This payload is then sent in
+ a normal message stanza (i.e. with type='normal') to the recipient. The recipient in turn, if it understands the payload, can choose to store it in an event log, forward it or
+ analyze it accordingly.
+
+ There are various event log packages available, but none yet defined for XMPP or using a well defined and known XML format. Therefore, this document defines
+ such an XML format. This format is able to store Syslog The following table lists common terms and corresponding descriptions.
+ The following example shows how to send a simple event using a normal message to an event log. There are only two parameters that are required:
+ message and timestamp. This message will be treated as a Minor Informational message by the
+ recipient.
+
+ The following example shows how an event message can be categorized with an event type and level.
+
+ The following example shows how an event message can be further enhanced by providing object and subject information.
+
+ The following example shows how an event message can receive an ID that can be singled out later to be analyzed by administrators, for instance.
+
+ The following example shows how to tag an event using custom information in a way that is easy to interpret and process.
+
+ The following example shows how module information can be provided in events to more easilly be able to single out information
+ relating to the same application running on different machines.
+
+ The following example shows how to send a debug message with a stack trace, module and custom inforation.
+ If an entity supports the reception of events as specified herein, it MUST advertise that fact by returning a feature of "urn:xmpp:eventlog" in response to &xep0030; information requests.
+ In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined
+ in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.
+
+ The following table lists possible event types that can be used. If none is specified for an event, it is assumed that the event is Informational.
+ It is largely based on the severity levels of Syslog.
+
+ Given an Event Type, an event level can provide additional information about the extent or importance of the event (a second dimension).
+
+ Using Event IDs the application can provide a machine understandable classification of the event. Examples could be "Login"-events, "ConnectionProblem"-events, etc.
+ It is easier to group, parse or interpret events and their tags if you know what type of event it is. Event IDs are manufacturer specific, and only provide a means
+ to more easilly extract subsets of events for processing without having to parse message texts (which should be allowed to be localizable).
+
+ Note: To avoid problems when running applications using different locales, event IDs should never be localized.
+
+ An event is often linked to an object, i.e. on which object an action was performed, or which object is reporting a condition. The object field permits
+ the tagging of objects in a common way. It is later easy to extract all events relating to a specific object by using this attribute.
+
+ An event is often also linked to a subject, i.e. who or what performed a given action resulting in the event or condition. The subject field permits
+ the tagging of subjects in a common way. It is later easy to extract all events relating to a specific subbject by using this attribute.
+
+ Facility can be either a facility in the network sense or in the system sense. This document does not restrict its use to the possible choices defined by
+ other protocols such as Syslog, and leaves it open. However, it is left as a special attribute since it is important in monitoring applications.
+
+ A module is part of a larger software package. Using the module attribute makes it easier to attribute events to specific parts of a distributed
+ application and analyze them separately.
+
+ Stack Traces can be important information to developers and correlate events to actual locations in the code that generated the event. This document
+ does not specify any particular format for stack traces.
+
+ Note that stack traces can be divided into multiple lines separated by CRLF. It is important to encode such strings correctly to avoid problems in
+ XML parsers.
+
+ Any event can have a custom set of tags attached to it. A tag is required to have a name and a value. It can also optionally specify a datatype.
+ Data Types are specified using Qualified Names (QNames). If possible, they should adher to the list of
+ Data Forms Validation Datatypes
+ Note: To avoid problems when running applications using different locales, tag names should never be localized.
+
+ If persisting received events in a database, care should be taken if normalized tables are used for storage of tags names and values, event IDs, objects, subjects,
+ facilities and modules. If this is the case, the receiver should look for types of values that can be incompatible with normalized tables (such as floating point values or numbers
+ in general, GUIDs, resource names in JIDs etc.) and replace them with some descriptive text and append the corresponding value in the message text instead. This to avoid problems with indexes in
+ databases because of devices implemented by third parties.
+
+ It is still valid to send such information (like sequence numbers, unique GUIDs, resource names in JIDs etc., measurements, etc.) in tags names and values, but should be avoided in
+ event IDs, objects, subjects, facilities and modules, as they can cause problems further down the line.
+
+ All timestamps and dateTime values use the XML data type xs:dateTime to specify values. These values include a date, an optional time and an optional time zone.
+
+ Note: If time zone is not available, it is supposed to be undefined. The recipient of an event message without time zone information
+ should assume the sender has the same time zone as the received, if not explicitly configured otherwise on the recipient side.
+
+ If devices report time zone, this information should be propagated throughout the system. Otherwise, comparing timestamps from different time zones will be impossible.
+
+ Event messages SHOULD contain an xml:lang attribute on the message stanza to specify the language
+ used in message texts, etc. If language information is not available (for instance, if relaying messages not created by the device itself,
+ the xml:lang attribute can be omitted).
+
+ Even though this document permits zero-configuration of devices to event logs, this might not always be the best option. Event information might be sensitive
+ and should not be sent to anybody just because they support the event log feature as defined in this document.
+
+ Never log information that should be handled securely or encrypted, such as passwords.
+ This document requires no interaction with &IANA;.
+ The protocol schema needs to be added to the list of XMPP protocol schemas.
+ Thanks in alphabetical order to Joachim Lindborg, Markus Kohlhase, Matthew Wild, Mike Taylor, Robert Kosten, Steffen Larsen, and Yusuke DOI for all valuable feedback. Added comparison to XEP-0050, Ad-hoc commands. Added support for server push of asynchronous form changes. Added an implementation note regarding client-side values.
+
+
+
+
+
+ Attribute
+ Definition
+ Possible Values
+ Default
+ Inclusion
+
+
+ type
+ Indicates the type of signal detected.
+ Any URI value from the listed signal types
+ none
+ REQUIRED
+
+
+ duration
+ Indicates the duration of the received signal in milliseconds
+ An integer value in milliseconds.
+ none
+ OPTIONAL
+
+
+ value
+ Indicates the value of the signal received if applicable.
+ For dtmf tones it is the digit detected, for speech may be human|machine|notsure and for beeps may be a frequency in Hz.
+ none
+ OPTIONAL
+
+
+
+
+ URI
+ Description
+
+
+ urn:xmpp:rayo:cpa:beep:1
+ Detect a beep.
+
+
+ urn:xmpp:rayo:cpa:dtmf:1
+ Detect DTMF tones.
+
+
+ urn:xmpp:rayo:cpa:speech:1
+ Detect speech and decide human or machine.
+
+
+ urn:xmpp:rayo:cpa:fax-ced:1
+ Detect a fax CED tone.
+
+
+ urn:xmpp:rayo:cpa:fax-cng:1
+ Detect a fax CNG tone.
+
+
+ urn:xmpp:rayo:cpa:ring:1
+ Detect a ringing tone.
+
+
+ urn:xmpp:rayo:cpa:busy:1
+ Detect a busy tone.
+
+
+ urn:xmpp:rayo:cpa:congestion:1
+ Detect a congestion tone.
+
+
+ urn:xmpp:rayo:cpa:sit:1
+ Detect a Special Information Tone.
+
+
+ urn:xmpp:rayo:cpa:modem:1
+ Detect a modem tone.
+
+
+ urn:xmpp:rayo:cpa:offhook:1
+ Detect an off-hook tone.
+
+
+
+
+
+
+
+
+
+
+ Attribute
+ Definition
+ Possible Values
+ Inclusion
+
+
+ url
+ Indicates the URL at which the fax is made available.
+ A valid URI.
+ REQUIRED
+
+
+ resolution
+ Indicates the resolution of the received fax.
+ A string in MxN format, where M and N are integers in pixels.
+ REQUIRED
+
+
+ pages
+ Indicates the number of pages in the received fax.
+ An integer.
+ REQUIRED
+
+
+ size
+ Indicates the filesize of the received fax.
+ A positive integer in bytes.
+ REQUIRED
+
+
+
+
+ Attribute
+ Definition
+ Possible Values
+ Inclusion
+
+
+ url
+ Indicates the URL at which the document to send is available.
+ A valid URI.
+ REQUIRED
+
+
+ identity
+ Indicates the identity from which the fax should appear to be sent.
+ A phone number string in E.164 format.
+ OPTIONAL
+
+
+ header
+ The header line to add to each page of the transmitted fax.
+ A string.
+ OPTIONAL
+
+
+ pages
+ The (set of) range of pages of the document to transmit.
+ A string (or set of strings separated by ',') in the format M[-N], where M and N are integers and the dash and second integer are optional. The set is combinatory and dash-separated integers signify a range of pages. The index is one-based.
+ OPTIONAL
+
+
+
+
+ Attribute
+ Definition
+ Inclusion
+
+
+ name
+ A token giving the name by which the metadata may be known.
+ REQUIRED
+
+
+ value
+ The string value of the named metadata.
+ REQUIRED
+
+
+
+
+
+
+
+
+ ===
+ |-| |
+ | | new message out --> +-+
+ |-| <-- empty body response |X|
+ |*| |-|
+ +-+ | |
+ | | |
+ | | |
+ | | |
+ | empty body response --> |-|
+ | |*|
+ | +-+
+ | |
+ | empty body request --> +-+
+ | |X|
+ | |-|
+ | | |
+ +-+ <-- new message out | |
+ |X| empty body response --> |-|
+ |-| <-- new message in |*|
+ |*| +-+
+ +-+ |
+ | |
+ +-+ <-- empty body request |
+ |X| |
+ |-| |
+ | | |
+ | | new message out --> +-+
+ |-| <-- new message in |X|
+ |*| |-|
+ +-+ | |
+ | | |
+ | | |
+ | | |
+ | empty body response --> |-|
+ | |*|
+ | +-+
+ | |
+ | empty body request --> +-+
+ | |X|
+ | |-|
+ | | |
+ | | |
+ | | |
+ | | |
+ | empty body response --> |-|
+ | |*|
+ | +-+
+ | |
+ ]]>
@@ -280,14 +362,14 @@ Content-Length: 104
-
+
+
+
+
+
+ Type
+ Description
+
+
+ Debug
+ Developers can ask applications to send debug messages during development or testing to more easily see what happens in a system.
+
+
+ Informational
+ An informational message describing a normal event.
+
+
+ Notice
+ Represents a significant condition or change that administrators should be aware of.
+
+
+ Warning
+ A warning condition. If not taken into account, the condition could turn into an error.
+
+
+ Error
+ An error condition. A condition has been detected that is considered to be an error or a fault.
+
+
+ Critical
+ A ciritical condition. An error so great that it could escalate into something graver if not addressed.
+
+
+ Alert
+ An alert condition. Action must be taken immediately.
+
+
+ Emergency
+ System is unusable.
+
+
+
+
+ Level
+ Description
+
+
+ Minor
+ Minor events, concerning normal operating procedures.
+
+
+ Medium
+ Medium events.
+
+
+ Major
+ More substantial events or affecting larger parts of the system.
+
+
+
+
+ Permits spontaneous updates of the form, pushed from the form server to the client showing the form. This might be necessary in + cases where the process of aquiring current values may take some time, but the client is required to show a form right away. +
+Note: This extension is only dependent upon the Data Forms XEP. It works in @@ -126,7 +142,104 @@ in this document may still reference extensions made in other documents, but these are considered to be examples only, used to illustrate a specific point or example.
- ++ &xep0050; defines a mechanism to enhance data forms creating dialog wizards with actions that guide the user through pages, where each page + can depend on the input from previous pages. The following list consists of a comparison of the differences between Ad-hoc commands and + Dynamic Forms, and why this extension is not based on the concepts defined in XEP-0050: +
++ The main point of this extension is to make the current form dynamic. Pages in a wizard, as defined in ad-hoc commands, are still static + requiring page navigation for the dialog to be updated. +
++ There might be a desire to make individual pages inside a wizard dynamic by themselves. In this case, this extension might be used to + extend Ad-hoc commands with dynamic pages inside wizards. +
++ Wizards order their pages linearly, in a one-dimensional array of pages. Navigation is only performed using prev and next actions, and completed with the execute or + complete actions. This might work sufficiently well where page output only is based on input from the previous page. But as soon as the input depends on more pages, + navigation becomes unnecessarily cumbersome. For example a dialog with country, region, city, area, street, building, apartment. To change the country parameter when you + are on the apartment page, requires you to back through many pages, while in the dynamic form you just change the parameter directly, since all are visible + in the same form. +
++ The problem gets worse if this is a normal behavior for a form. Say a dialog with a post carrier field, followed by country, city, office, etc. + When the user comes to office and notices that the selected carrier has no office close to you, you change carrier, but don't want to change country and city, if + possible. +
++ The pages in a wizard do not allow for spontaneous or immediate feedback to the user. Such immediate feedback is of great importance in user-friendly + forms, where complex input is required. Consider the following simple example: +
++ Imagine a dialog used for configuring a TCP port scanner to search for specific devices in a network. It might take five parameters: IP range, port range, number of threads, + connection timeout (ms) and number of tries before failing. However, the operator wants to know how much time the operation will take (which is #IP-addresses * + #port numbers * Connection Timeout * Nr Tries / #Threads). To see this in a separate page and then have to go back to the different pages, forwarding to the + time estimate calculation page, etc., is a very cumbersome process. Presenting all this information on a single page using Dynamic Forms is creates a much + better and richer user experience. Changing the value of any of the five parameters will directly update a text parameter presenting the total expected time of the + operation. +
++ Wizards as defined in Ad-hoc commands are hard-wired to commands as such. Navigation actions are defined outside of the scope of the form itself. This extensions + defines Dynamic Forms as an extension of the Data Form concept. All navigation, post-back fields, etc., are defined within the actual form itself. This makes + it re-usable everywhere data forms are used, including pages inside an Ad-Hoc command wizard. +
++ Ad-hoc command wizards include the feature to return notes including information, warnings or error information to the user. This information however, is associated + with the current page in the wizard itself. Dynamic Forms contains a means to attach error information directly to individual fields, making feedback more precise. + Together with the server post-back feature immediate server-side validation during user input is possible. +
++ Dynamic Forms contains a feature that ad-hoc command wizards do not: Read-only fields. These differs from other text fields in that they are rendered as normal + controls, except input is read-only. Together with the server post-back feature this allows the server to enable and disable parameters depending on user + input on the same page. An example can be a checkbox that enabled another field if checked, as a security measure. +
++ Dynamic Forms defines the concept of an undefined field value. These fields are presented with the available value (if any), but greyed out, signaling to the user that + the value is not well defined for some reason. Perhaps it is only one of many values held my multiple objects in the case when editing multiple objects at once. + Undefined values are not sent back to the server when the form is posted back. When the user edits such a field, the undefined flag is cleared and the field is + presented as a normal control. The main purpose of this flag is to allow for editing multiple objects at once or for editing control forms where current states are + not known at the moment if creating the form. +
++ Dynamic Forms supports asynchronous updates of the form, where the server can push changes to the form not resulting from user input. This is a powerful feature that + allows the server to update a form being edited by the user to reflect changes on the server. Consider the following examples: +
++ Consider a control form containing control fields on a remote device. At the time of displaying the form, the current states of some fields might be unknown. So the fields + are marked perhaps with some default values, but with the undefined flag set for the corresponding fields. At the time of creating the form, a parallel request is made + to the device by the form server, requesting information about current states of the device. When these are received by the server, it issues an update of the form to the + client with the newly received and current field values. The request for values might take some time, so using this mechanism provides a form to the user quickly, clearly + indicating what is missing, and then complements the form when data is available. +
++ Another example might be a dialog showing contents on the form server in a multi-user environment where updates to the contents is made. An example can be a file system. + If changes to the contents is made by another user, the server has the possibility to update any current forms to reflect changes made. This decreases the possibility + of inconsistencies in the system, and at the same time increases the user-friendliness of the end-user experience of the application. +
+The following table lists terms and corresponding descriptions or definitions for use throughout this document.
+ Note 2: Make sure to check the implementation note Merging Client-Side Values for information + on how to merge updates received from the server with current input made by the client. +
@@ -481,7 +598,7 @@ ... - + ]]>
@@ -541,6 +658,75 @@ ]]>
+ The server may send asynchronous updates to open forms on the client. This can be done if the server detects changes that it wants to inform + the client about. Changes are made by sending a message stanza including a formUpdated element which in turn + contains the new updated form. +
++ Examples can include a control form showing control parameters. While the server is trying to retrieve the current values + it presents the control form with undefined values, and later when values are received by the server, it sends an update to the client with + actual values. +
++ Another example can include a dialog containing information on items on the server in a multi-user environment (for instance a file system). + Changes made by users can be displayed in open dialogs to other users as they change. +
++ The client may have more than one form open at any given time. It might also be so that the form has been closed prior to receiving or handling the update message, + and is therefore no longer visible. To be able to identify to which form the update corresponds, the formUpdated + element is required to include a sessionVariable attribute in which it identifies a unique identifying + field in the form. When the client receives the update, it goes through all forms it has open. If a form has a field variable with a corresponding + name, and the field variable has a value equal to the value in the updated form, the form should be updated by the contents of the message. If no form is found, + the update is simply ignored. If multiple forms are found, all should be updated. +
++ Note: Make sure to check the implementation note Merging Client-Side Values for information + on how to merge updates received from the server with current input made by the client. +
+If an entity supports the protocol specified herein, regardless if the entity represents a form server or a form client; it MUST advertise @@ -602,6 +788,73 @@ For normal operations, a dynamic form session timeout of 15 minutes is sufficient.
++ When receiving asynchronous form updates from the server, or when performing a server post-back of a form, it is important + to know how to merge responses from the server with the current form being displayed to the user. As the operation is + asynchronous, and since user input is quick, the user might have input things not known to the server and therefore not + available in form updates. Also, fields not marked for post-back might not have been reported at all to the server, and + therefore, the client is the only one that knows what the user has entered into these fields. +
++ So, when receiving form updates, either asynchronously, or as part of a server post-back response, the client needs to merge + the updated form, with the current form. The following rules must be applied. Here, the updated form represents the + form in the recent message from the server, the current form represents the form currently being edited by the user + and the resulting form represents the result of the merger of the updated form and the current form. +
++ New fields in the updated form not available in the current form, are added as-is to the resulting form. +
++ Fields not available in the updated form but available in the current form, must be removed from the + resulting form regardless if user input is available. Any such user input is lost. +
++ The order of fields in the resulting form must be the same as the order of fields in the updated form. +
++ Fields available in both the updated form and the current form are handled depending on if the user has entered + values in the corresponding field in the current form or not: +
++ If a field in the updated form is flagged as undefined, but the current form has an edited value, + the form in the resulting form must not be marked as undefined. +
++ All other properties for fields must be taken from the updated form and copied to the resulting form. +
++ How the above merger is made is implementation specific. One simple implementation can simply be taking the updated form, adding any client-side values to it + (i.e. values edited in the current form) perhaps removing any undefined value flags, and then use the result as a model for the resulting form. +
+
@@ -679,6 +932,15 @@
+
Thanks to Karin Forsell for all valuable feedback.
+
a=fingerprint:sha-256 02:1A:CC:54:27:AB:EB:9C:53:3F:3E:4B:65:2E:7D:46:3F:54:42:CD:54:F1:7A:03:A2:7D:F9:B0:7F:46:19:B2
- This SDP attribute can be translated into Jingle as a <fingerprint/> element qualified by the 'urn:xmpp:tmp:jingle:apps:dtls:0' namespace, as shown below.
+Additionally, the SDP setup attribute defined in &rfc4145; must be mapped, whose usage for DTLS-SRTP is defined in RFC 5763.
+
+a=setup:role
+
+ These SDP attributes can be translated into Jingle as a <fingerprint/> element qualified by the 'urn:xmpp:jingle:apps:dtls:0' namespace, as shown below.
fingerprint
+
+ fingerprint
+
]]>
An example follows.
+
02:1A:CC:54:27:AB:EB:9C:53:3F:3E:4B:65:2E:7D:46:3F:54:42:CD:54:F1:7A:03:A2:7D:F9:B0:7F:46:19:B2
]]>
- Note: since DTLS can be used to protect non-RTP sessions like SCTP including the fingerprint in the <encryption/> element defined in &xep0167; was deemed inappropriate. Also, the <encryption/> element defined there only applies to the encryption of the RTP data part, whereas DTLS (and DTLS-SRTP) protects the whole message.
-If the Jingle initiator wishes to use DTLS-SRTP, it includes the <fingerprint/> element in its session invitation. If the initiator requires the use of DTLS, the <fingerprint/> element MUST include a 'required' attribute whose logical value is TRUE and whose lexical value is "true" or "1" &BOOLEANNOTE;, where this attribute defaults to a logical value of FALSE (i.e., a lexical value of "false" or "0").
+If the Jingle initiator wishes to use DTLS-SRTP, it includes the <fingerprint/> element in its session invitation.
Thanks to Justin Uberti.
+Thanks to Justin Uberti and Lance Stout.
Corrected namespace to use XSF format.
When replying with a list of files, the offering entity can choose to either reply with verbose information on the file using the file attributes defined by &xep0254; or it may reply only with the 'name' attribute, which is required and MUST be included in every response.
+When replying with a list of files, the offering entity can choose to either reply with verbose information on the file using the file attributes defined by &xep0234; or it may reply only with the 'name' attribute, which is required and MUST be included in every response.
It is RECOMENDED, when the list files to be sent is small, that a verbose response be made (in order to avoid going back and forth requesting information), and that a non-verbose reponse be made otherwise. This recomendation is made to save bandwidth.
One obvious way to overcome the limitations of sending large stanzas in-band, is to transfer that information out of band. &xep0265; could be used for that purpose. It is hereby RECOMMENDED its implementation when the offering entity has a massive amount of files that would not be practical to advertise in-band.
It is further recommended that when using XEP-0265, the entire directory structure, along with all the files in the shared folder and subfolders, be exchanged in one single reply. Also, all the files attributes should be included. This is to avoid wasting bandwidth initiating out of band streams going back and forth.
-This page lists all XMPP Extension Protocols published by the XMPP Standards Foundation, including specifications that have been retracted, rejected, deprecated, and obsoleted.
diff --git a/index.shtml b/index.shtml index 5d6b913a..20cfdfda 100755 --- a/index.shtml +++ b/index.shtml @@ -5,7 +5,7 @@XMPP is the Extensible Messaging and Presence Protocol, a set of open technologies for instant messaging, presence, multi-party chat, voice and video calls, collaboration, lightweight middleware, content syndication, and generalized routing of XML data.
The XMPP Standards Foundation (XSF) develops extensions to XMPP through a standards process centered around XMPP Extension Protocols (XEPs). The process is managed by the XMPP Extensions Editor and involves intensive discussion on the Standards mailing list, formal review and voting by the XMPP Council, and modification based on implementation experience and interoperability testing. All documents in the XEP series are available under a liberal IPR Policy for wide implementation. Submissions are welcome (see also the "inbox"). All XEPs and related files are under source control, old versions are available, and IETF-style XML reference files are provided. A compressed archive of all current XEPs can be downloaded here. You can view and submit XEP-related bugs and feature requests at the issue tracker.
diff --git a/xep-0080.xml b/xep-0080.xml index cdf41315..2a6b0ebb 100644 --- a/xep-0080.xml +++ b/xep-0080.xml @@ -178,7 +178,7 @@Two identities: "client/pc/Psi" and "client/pc/Ψ"
S = 'client/pc/el/Ψ 0.11<client/pc/en/Psi 0.11<'
+S = 'client/pc/el/Ψ 0.11<client/pc/en/Psi 0.11<'
Sort the features: "http://jabber.org/protocol/caps", http://jabber.org/protocol/disco#info", "http://jabber.org/protocol/disco#items", "http://jabber.org/protocol/muc".
- S = 'client/pc/el/Ψ 0.11<client/pc/en/Psi 0.11<http://jabber.org/protocol/caps<http://jabber.org/protocol/disco#info<
+ S = 'client/pc/el/Ψ 0.11<client/pc/en/Psi 0.11<http://jabber.org/protocol/caps<http://jabber.org/protocol/disco#info<
http://jabber.org/protocol/disco#items<http://jabber.org/protocol/muc<'.
Sort the extended service discovery forms by FORM_TYPE (there is only one: "urn:xmpp:dataforms:softwareinfo").
S = 'client/pc/el/Ψ 0.11<client/pc/en/Psi 0.11<http://jabber.org/protocol/caps<http://jabber.org/protocol/disco#info< +
S = 'client/pc/el/Ψ 0.11<client/pc/en/Psi 0.11<http://jabber.org/protocol/caps<http://jabber.org/protocol/disco#info<
http://jabber.org/protocol/disco#items<http://jabber.org/protocol/muc<urn:xmpp:dataforms:softwareinfo<'
Sort the fields by var and append the value(s): "ip_version<ipv4<ipv6", "os<Mac", "os_version<10.5.1", "software<Psi", "software_version<0.11".
S = 'client/pc/el/Ψ 0.11<client/pc/en/Psi 0.11<http://jabber.org/protocol/caps<http://jabber.org/protocol/disco#info< +
S = 'client/pc/el/Ψ 0.11<client/pc/en/Psi 0.11<http://jabber.org/protocol/caps<http://jabber.org/protocol/disco#info<
http://jabber.org/protocol/disco#items<http://jabber.org/protocol/muc<urn:xmpp:dataforms:softwareinfo<
ip_version<ipv4<ipv6<os<Mac<os_version<10.5.1<software<Psi<software_version<0.11<'
Real-time text can be used in conjunction with Chat State Notifications. It is best to handle XEP-0301 and XEP-0085 transmissions in separate <message/> stanzas. Chat states such as <composing/> or <active/> are sent separately from <rtt/> elements.
-Chat states are handled as specified by XEP-0085. The continuous transmission of real-time text corresponds to a <composing/> chat state. Therefore, the timing of the <composing/> chat state coincides with the beginning of continuous <rtt/> transmission.
+Chat states are handled as specified by XEP-0085. The continuous transmission of real-time text corresponds to a <composing/> chat state. Therefore, the timing of the <composing/> chat state coincides with the beginning of continuous <rtt/> transmission.
It is possible to use Last Message Correction with real-time text. If XEP-0308 is implemented in concert with this specification, the following rules apply:
@@ -841,49 +841,49 @@Addressed pre-publication feedback from the XMPP Council.
+
- There are various event log packages available, but none yet defined for XMPP or using a well defined and known XML format. Therefore, this document defines
+ There are various event log packages available, but none yet defined for XMPP or using a well-defined and known XML format. Therefore, this document defines
such an XML format. This format is able to store Syslog
+ This document does not restrict the use of event messages to directed message stanzas alone. It may be envisioned that some would like to publish event information through + &xep0060; or other mechanisms. It is not in the scope of this document to specify such transports however, as it only deals with direct messages, but a brief list is provided + in the Security Considerations section.
- The following example shows how to send a simple event using a normal message to an event log. There are only two parameters that are required: - message and timestamp. This message will be treated as a Minor Informational message by the - recipient. + The following example shows how to send a simple event using a normal message to an event log. Only two parameters are required: + The timestamp of the message goes into the timestamp attribute, and the actual messages goes into a child element + named message. This event will be treated as a Minor Informational event by the recipient.
+ The following example shows how to send a multi-line event. +
+The following example shows how an event message can be categorized with an event type and level.
The following example shows how an event message can be further enhanced by providing object and subject information.
- The following example shows how an event message can receive an ID that can be singled out later to be analyzed by administrators, for instance. + The following example shows how to send an event message with an event ID that can be singled out later to be analyzed by administrators, for instance.
The following example shows how to tag an event using custom information in a way that is easy to interpret and process.
- The following example shows how module information can be provided in events to more easilly be able to single out information + The following example shows how module information can be provided in events to more easily be able to single out information relating to the same application running on different machines.
- The following example shows how to send a debug message with a stack trace, module and custom inforation. + The following example shows how to send a debug message with a stack trace, module and custom information.
+ The following example shows how multiple events can be sent in a single message. The receiver should interpret this as two different events having been received. +
+The following table lists possible event types that can be used. If none is specified for an event, it is assumed that the event is Informational. - It is largely based on the severity levels of Syslog. + It is largely based on the severity levels of Syslog.
Critical | -A ciritical condition. An error so great that it could escalate into something graver if not addressed. | +A critical condition. An error so great that it could escalate into something graver if not addressed. |
Alert | @@ -321,7 +340,7 @@
Given an Event Type, an event level can provide additional information about the extent or importance of the event (a second dimension).
@@ -340,67 +359,64 @@- Using Event IDs the application can provide a machine understandable classification of the event. Examples could be "Login"-events, "ConnectionProblem"-events, etc. + Using Event IDs, the application can provide a machine understandable classification of the event. Examples could be "Login"-events, "ConnectionProblem"-events, etc. It is easier to group, parse or interpret events and their tags if you know what type of event it is. Event IDs are manufacturer specific, and only provide a means - to more easilly extract subsets of events for processing without having to parse message texts (which should be allowed to be localizable). + to more easily extract subsets of events for processing without having to parse message texts (which should be allowed to be localizable).
-- Note: To avoid problems when running applications using different locales, event IDs should never be localized. -
-- An event is often linked to an object, i.e. on which object an action was performed, or which object is reporting a condition. The object field permits + Note: To avoid problems when running applications using different locales, event IDs should never be localized. +
++ An event is often linked to an object, e.g. on which object an action was performed, or which object is reporting a condition. The object field permits the tagging of objects in a common way. It is later easy to extract all events relating to a specific object by using this attribute.
An event is often also linked to a subject, i.e. who or what performed a given action resulting in the event or condition. The subject field permits - the tagging of subjects in a common way. It is later easy to extract all events relating to a specific subbject by using this attribute. + the tagging of subjects in a common way. It is later easy to extract all events relating to a specific subject by using this attribute.
Facility can be either a facility in the network sense or in the system sense. This document does not restrict its use to the possible choices defined by - other protocols such as Syslog, and leaves it open. However, it is left as a special attribute since it is important in monitoring applications. + other protocols such as Syslog, and leaves it open. However, it is left as a special attribute since + it is important in monitoring applications.
A module is part of a larger software package. Using the module attribute makes it easier to attribute events to specific parts of a distributed application and analyze them separately.
Stack Traces can be important information to developers and correlate events to actual locations in the code that generated the event. This document does not specify any particular format for stack traces.
-- Note that stack traces can be divided into multiple lines separated by CRLF. It is important to encode such strings correctly to avoid problems in - XML parsers. -
- Any event can have a custom set of tags attached to it. A tag is required to have a name and a value. It can also optionally specify a datatype.
- Data Types are specified using Qualified Names (QNames). If possible, they should adher to the list of
+ Any event can have a custom set of tags attached to it. A tag is required to have a name and a value. It can also optionally specify a data type.
+ Data types are specified using Qualified Names (QNames). If possible, they should adhere to the list of
Data Forms Validation Datatypes
- Note: To avoid problems when running applications using different locales, tag names should never be localized. -
++ Note: To avoid problems when running applications using different locales, tag names should never be localized. +
If persisting received events in a database, care should be taken if normalized tables are used for storage of tags names and values, event IDs, objects, subjects, facilities and modules. If this is the case, the receiver should look for types of values that can be incompatible with normalized tables (such as floating point values or numbers @@ -408,13 +424,20 @@ databases because of devices implemented by third parties.
- It is still valid to send such information (like sequence numbers, unique GUIDs, resource names in JIDs etc., measurements, etc.) in tags names and values, but should be avoided in - event IDs, objects, subjects, facilities and modules, as they can cause problems further down the line. + It is still valid to send information like sequence numbers, unique GUIDs, measurements, resource names in JIDs etc. in tag names and values, but such information + should be avoided in event IDs, objects, subjects, facilities and modules, as they can cause problems further down the line. +
++ The messag text and stack trace parts of an event message lie as simple type valued child elements (xs:string). This allows for simple encoding of multi-line text + information into these two parameters. However, do not indent new lines when serializing multi-line text to these parameters to make the XML look nicer. The recipient + cannot know what whitespace is indenting and what is part of the actual information.
All timestamps and dateTime values use the XML data type xs:dateTime to specify values. These values include a date, an optional time and an optional time zone.
@@ -426,22 +449,44 @@ If devices report time zone, this information should be propagated throughout the system. Otherwise, comparing timestamps from different time zones will be impossible.Event messages SHOULD contain an xml:lang attribute on the message stanza to specify the language - used in message texts, etc. If language information is not available (for instance, if relaying messages not created by the device itself, - the xml:lang attribute can be omitted). + used in message texts, etc. If language information is not available, e.g. if relaying messages are not created by the device itself, + the xml:lang attribute can be omitted.
- Even though this document permits zero-configuration of devices to event logs, this might not always be the best option. Event information might be sensitive - and should not be sent to anybody just because they support the event log feature as defined in this document. -
-- Never log information that should be handled securely or encrypted, such as passwords. -
++ Even though this document permits zero-configuration of devices to event logs, this might not always be the best option. Event information might be sensitive + and should not be sent to anybody just because they support the event log feature as defined in this document. +
++ Never log information that should be handled securely or encrypted, such as passwords. +
++ The following subsections lists different transport options together with security considerations for each one. +
++ This document explicitly describes how to send event messages in direct messages. If sensitive information is being sent, + end-to-end encryption should be considered. +
++ Event messages could be published using Publish-Subscribe. But, even more care should + be taken to log only information that can be published openly. If there's risk for sensitive information to be logged, the publish/subscribe pattern + should be avoided. +
+This document requires no interaction with &IANA;.
@@ -463,16 +508,17 @@Thanks in alphabetical order to Joachim Lindborg, Markus Kohlhase, Matthew Wild, Mike Taylor, Robert Kosten, Steffen Larsen, and Yusuke DOI for all valuable feedback.
-Thanks in alphabetical order to Dave Cridland, Joachim Lindborg, Karin Forsell, Ludovic Bocquet, Markus Kohlhase, Matthew Wild, Mike Taylor, Philipp Hancke, Robert Kosten, Steffen Larsen, and Yusuke DOI for all valuable feedback.
+Further clarified the intent of the protocol.
Sometimes it is desirable to augment instant messaging (IM) with another real-time communications medium, such as a voice conversation conducted over the traditional public switched telephone network (PSTN) or more recent Voice over Internet Protocol (VoIP) applications. In order to facilitate this functionality, a user needs to advertise the address(es) at which they can be reached. There are several possible ways to do this:
+Sometimes it is desirable to augment instant messaging (IM) with another real-time communications medium, such as a voice conversation conducted over the traditional public switched telephone network (PSTN) or Voice over Internet Protocol (VoIP) applications. In order to facilitate this functionality, a user needs to advertise the address(es) at which they can be reached. There are several possible ways to do this:
Publish the address(es) in the user's vCard (see &xep0054; and &xep0292;); this is convenient, but is not very dynamic (e.g., reachability addresses might change when the user moves to a new conference room in an office building).
Send the address(es) within a &PRESENCE; stanza; this option is described in the Presence Transport section of this document and is consistent with &rfc6121; since reachability is one aspect of a user's availability for communication.
Send address(es) to the appropriate &xep0060; node; this option is described in the PEP Transport section of this document but might not be available at all service providers.
This document defines methods for publishing addresses at which a user can be reached temporarily, as opposed to semi-permanent addresses of the kind that are more appropriately communicated in a user's vCard.
+This document defines methods for publishing addresses at which a user can be reached temporarily, as opposed to semi-permanent addresses of the kind that are more appropriately communicated in a user's vCard. We illustrate this usage through the scenario of a user sending a reachability address upon entering a physical conference room and then sending an updated notification (without a reachability address) upon leaving the conference room. Similar scenarios might apply when an XMPP implementation is used with technologies such as WebRTC and in deployments of the combined use of SIP and XMPP ("CUSAX"; &rfc7081;).
To broadcast reachability addresses in presence information, a user's client includes the <reach/> element in the &PRESENCE; stanza it sends to its server.
-For example, consider someone who walks into a conference room at the office. Via nearfield communication, the user's XMPP client might auto-discovery a 'tel:' URI for the room audio system and a 'sip:' URI for the room video system.
+For example, consider someone who walks into a conference room at the office. Via nearfield communication, the user's XMPP client might auto-discover a 'tel:' URI for the room audio system and a 'sip:' URI for the room video system.
The user's server then broadcasts that presence stanza to all entities who are subscribed to the user's presence:
To preserve network bandwidth, the sender SHOULD NOT include the <desc/> element unless that information is deemed necessary to enable communication.
-A recipient SHOULD attempt communications with reachability addresses in the order that the <addr/> elements appear within the <reach/> element.
+To preserve network bandwidth, the sender ought not include the <desc/> element unless that information is deemed necessary to enable communication.
+A recipient ought to attempt communications with reachability addresses in the order that the <addr/> elements appear within the <reach/> element.
Security considerations for XMPP presence and PEP publication are described in RFC 6120, RFC 6121, XEP-0060, and XEP-0163.
-Clarified scope and intent of the protocol.
The Session Description Protocol (SDP) &rfc4566; is widely used to communicate information about media sessions, typically using the offer/answer model &rfc3264;. For example, when the Session Initiation Protocol (SIP) &rfc3261; is used for establishing media sessions, the payloads of the SIP messages contain SDP payloads. The use of SDP continues to gain force, since SDP has been adopted for use in the WebRTC technologies being defined at the &IETF; and &W3C; for real-time communication among web browsers.
-Some user agents that might want to participate in WebRTC interactions use XMPP as their primary or only communication channel. For example, a browser-based XMPP application might use a JavaScript library that connects to an XMPP server using &xmppoverwebsocket; or using &xep0124; and &xep0206;. Although such an application could use &xep0166; and &xep0167; between the client and the server, converting the Jingle XML format into SDP (and associated SIP headers) might require use of a server-side gateway, and such a gateway might introduce unnecessary complexity into the system (e.g., keeping session state in the gateway). Enabling the user agent to natively send SDP (and a minimal set of SIP headers) can make it easier for XMPP client developers to build real-time communication applications using existing SDP and SIP libraries, especially in the context of WebRTC.
-By specifying a way to send SDP/SIP over XMPP (a.k.a. "SoX"), this document effectively defines another reliable transport method for SIP/SDP messages. However, it is envisioned that this method will be used only by XMPP-only endpoints, not by native SIP or dual-stack SIP/XMPP &cusax; endpoints. It is important to note that SoX is not intended to deprecate Jingle, only to provide a convenient way to reliably transport SIP/SDP traffic for communication with native SIP and dual-stack SIP/XMPP endpoints. Finally, because SoX payloads contain only minimal SIP headers (needed for message delivery in certain scenarios) and SDP content, the method is not designed for sending arbitrary SIP message bodies, only SDP.
+Some user agents that might want to participate in WebRTC interactions use XMPP as their primary or only communication channel. For example, a browser-based XMPP application might use a JavaScript library that connects to an XMPP server using &xmppoverwebsocket; or using &xep0124; and &xep0206;. Although such an application could use &xep0166; and &xep0167; between the client and the server, converting the Jingle XML format into SDP (and associated SIP headers) might require use of a server-side gateway, and such a gateway might introduce unnecessary complexity into the system (e.g., keeping session state in the gateway). Enabling the user agent to natively send SDP (and a minimal set of SIP headers) can make it easier for XMPP client developers to build real-time communication applications using existing SDP and SIP libraries, especially in the context of WebRTC. Even outside of WebRTC, the ability to send SDP/SIP over XMPP can be useful in deployments where XMPP-capable endpoints need to communicate with SIP endpoints such as IP phones.
+By specifying a way to send SDP/SIP over XMPP (a.k.a. "SoX"), this document effectively defines a reliable transport method for SIP/SDP messages. However, it is envisioned that this method will be used only by XMPP-only endpoints, not by native SIP or dual-stack SIP/XMPP &rfc7081; endpoints. It is also important to note that SoX is not intended to replace Jingle as a general-purpose method for negotiating media sessions among XMPP entities; instead, it provides a convenient way to reliably transport SIP/SDP traffic for communication from XMPP-only endpoints to native SIP and dual-stack SIP/XMPP endpoints. Finally, because SoX payloads contain only minimal SIP headers (needed for message delivery in certain scenarios) and SDP content, the method is not designed for sending arbitrary SIP message bodies, only SDP.
Address mapping between SIP and XMPP can be a challenge. See &xmppsipcore; for details.
+Address mapping between SIP and XMPP can be a challenge. See &stoxcore; for details.
The 'to' attribute and 'from' attribute of the XMPP &MESSAGE; stanza need not match the "To" header and "From" header of the SoX payload. For example, the sender might know (based on vCard data or a directory lookup) that the SIP address of the intended recipient is different from the XMPP address of the intended recipient. This is possible in so-called CUSAX scenarios; although the CUSAX specification recommends that all SDP signalling be sent over SIP rather than XMPP, the sender might be an XMPP-only endpoint and the intended recipient might be a CUSAX endpoint.
However, in general it is easier for a user agent to simply set the SIP "To" and "From" headers to the same identifiers (JIDs) used for the XMPP 'to' and 'from' attributes.
Defined HTTP lookup methods using well-known URIs as specified in RFC 5785.
Although &xmppcore; specifies the use of TCP as the method of connecting to an XMPP server, alternative connection methods exist, including the &xep0124; method (for which &xep0206; is the XMPP profile) and &xmppoverwebsocket;. For some of these methods, it is necessary to discover further parameters before connecting, such as the HTTP URL of an alternative connection manager. Without ways to auto-discovering alternative connection methods, the relevant information would need to be provided manually by a human user, which is cumbersome and error-prone.
+Although &xmppcore; specifies the use of TCP as the method of connecting to an XMPP server, alternative connection methods exist, including the &xep0124; method (for which &xep0206; is the XMPP profile) and &xmppoverwebsocket;. For some of these methods, it is necessary to discover further parameters before connecting, such as the HTTP URL of an alternative connection manager. Without ways to auto-discover alternative connection methods, the relevant information would need to be provided manually by a human user (which is cumbersome and error-prone) or hard-coded into XMPP software applications (which is brittle and not interoperable).
This document defines two ways to encapsulate information about alternative connection methods for auto-discovery:
The following examples show two DNS TXT resource records: the first indicates support for the XMPP Over BOSH connection method defined in XEP-0124 and XEP-0206 and the second indicates support for WAP connections (the latter connection method is not yet defined).
+The following examples show two DNS TXT resource records: the first indicates support for the XMPP Over BOSH connection method defined in XEP-0124 and XEP-0206 and the second indicates support for XMPP over WebSocket connections defined in &xmppoverwebsocket;.
The following examples show two host-meta link records: the first indicates support for the XMPP Over BOSH connection method defined in XEP-0124 and XEP-0206 and the second indicates support for the &xmppoverwebsocket; connection method.
+The following examples show two host-meta link records: the first indicates support for the XMPP Over BOSH connection method defined in XEP-0124 and XEP-0206 and the second indicates support for the XMPP Over WebSocket connection method defined in draft-ietf-xmpp-websocket.
It is possible that advertisement of alternative connection methods can introduce security vulnerabilities, since a connecting entity (usually a client) might deliberately seek to connect using the method with the weakest security mechanisms (e.g., no channel encryption or relatively weak authentication). Care needs to be taken in determining which alternative connection methods are appropriate to advertise.
+Entities that use these connection methods need to ensure that they conform to the security considerations of each method (e.g., by preferring to use 'https' or 'wss' URLs that are protected using Transport Layer Security).
The registrant can register more than one attribute at a time, each contained in a separate <method/> element.
-This document registers the following values.
_xmpp-client-httppoll
@@ -239,11 +241,20 @@ _xmppconnect IN TXT "_xmpp-client-wap=http://wap.jabber.org/connector"
XEP-0025
+
+ _xmpp-client-websocket
+ XMPP Over WebSocket connection method
+
+ The ws: or wss: URL at which to contact the WebSocket connection manager or proxy
+
+ draft-ietf-xmpp-websocket
+
+
_xmpp-client-xbosh
XMPP Over Bosh connection method
- The http: or https: URL at which to contact the HTTP Binding connection manager or proxy
+ The http: or https: URL at which to contact the HTTP Binding (BOSH) connection manager or proxy
XEP-0206
From c94da68e83eda0b221bc740b140ee249bf62080e Mon Sep 17 00:00:00 2001
From: Peter Saint-Andre
Date: Tue, 3 Dec 2013 10:17:13 -0700
Subject: [PATCH 26/40] updated WebSocket specs
---
xep.ent | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/xep.ent b/xep.ent
index 3c585d25..6f94eb5f 100644
--- a/xep.ent
+++ b/xep.ent
@@ -374,7 +374,6 @@ THE SOFTWARE.
SDN.801c SDN.801c: Access Control Concept and Mechanism, US National Security Agency, Revision C, 12 May 1999. " >
Unicode The Unicode Standard, Version 3.2.0 (The Unicode Consortium, 2000). " >
Wireless Access Protocol (WAP) Wireless Access Protocol (WAP) <http://www.wapforum.org/>. " >
-The Web Socket Protocol The Web Socket Protocol <http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol>. " >
WV Client-Server Protocol v1.1 Wireless Village Client-Server Protocol v1.1 <http://www.openmobilealliance.org/tech/affiliates/wv/wvindex.html>. " >
XHTML Friends Network (XFN) XHTML Friends Network (XFN) <http://gmpg.org/xfn/index>. " >
XML-RPC XML-RPC <http://www.xmlrpc.com/spec>. " >
@@ -669,7 +668,7 @@ THE SOFTWARE.
draft-ietf-stox-core Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Addresses and Error Conditions <http://tools.ietf.org/html/draft-ietf-stox-core>. " >
Improving TCP's Robustness to Blind In-Window Attacks Improving TCP's Robustness to Blind In-Window Attacks <http://tools.ietf.org/html/draft-ietf-tcpm-tcpsecure>. Work in progress. " >
TURN Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) <http://tools.ietf.org/html/draft-ietf-behave-turn>. Work in progress. " >
-XMPP Over WebSocket An XMPP Sub-protocol for WebSocket <https://datatracker.ietf.org/doc/draft-moffitt-xmpp-over-websocket/>. Work in progress. " >
+XMPP Over WebSocket An XMPP Sub-protocol for WebSocket <https://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/>. Work in progress. " >
From d3e0b40e626d6889d867b786d76c7e399a3c30b8 Mon Sep 17 00:00:00 2001
From: Peter Saint-Andre
Date: Tue, 3 Dec 2013 10:17:24 -0700
Subject: [PATCH 27/40] updated WebSocket citation
---
xep-0124.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xep-0124.xml b/xep-0124.xml
index 25d171f3..551b31a0 100644
--- a/xep-0124.xml
+++ b/xep-0124.xml
@@ -165,7 +165,7 @@
The Transmission Control Protocol (TCP; &rfc0793;) is often used to establish a stream-oriented connection between two entities. Such connections can often be long-lived to enable an interactive "session" between the entities. However, sometimes the nature of the device or network can prevent an application from maintaining a long-lived TCP connection to a server or peer. In this case, it is desirable to use an alternative connection method that emulates the behavior of a long-lived TCP connection using a sequenced series of requests and responses that are exchanged over short-lived connections. The appropriate request-response semantics are widely available via the Hypertext Transfer Protocol (HTTP) as specified in &rfc1945; and &rfc2616;.
- BOSH, the technology defined in this specification, essentially provides a "drop-in" alternative to a long-lived, bidirectional TCP connection. It is a mature, full-featured technology that has been widely implemented and deployed since 2004. To our knowledge it was the first of many similar technologies, which now include the Comet methodology formalized in the &bayeux; as well as &websocket; and &rhttp;.
+ BOSH, the technology defined in this specification, essentially provides a "drop-in" alternative to a long-lived, bidirectional TCP connection. It is a mature, full-featured technology that has been widely implemented and deployed since 2004. To our knowledge it was the first of many similar technologies, which now include the Comet methodology formalized in the &bayeux; as well as WebSocket &rfc6455; and &rhttp;.
BOSH is designed to transport any data efficiently and with minimal latency in both directions. For applications that require both "push" and "pull" semantics, BOSH is significantly more bandwidth-efficient and responsive than most other bidirectional HTTP-based transport protocols and the techniques now commonly known as "Ajax". BOSH achieves this efficiency and low latency by using so-called "long polling" with multiple synchronous HTTP request/response pairs. Furthermore, BOSH can address the needs of constrained clients by employing fully-compliant HTTP 1.0 without the need for "cookies" (see &rfc2965;) Requiring cookies is sub-optimal because several significant computing platforms provide only limited access to underlying HTTP requests/responses; worse, some platforms hide or remove cookie-related headers. or even access to HTTP headers.
BOSH was originally developed in the Jabber/XMPP community as a replacement for an even earlier HTTP-based technology called &xep0025;. Although BOSH assumes that the "payload" of HTTP requests and responses will be XML, the payload formats are not limited to XMPP stanzas (see &xmppcore;) and could contain a mixture of elements qualified by namespaces defined by different protocols (e.g., both XMPP and JSON). This mix is necessary because some connection managers might not support Multiple Streams and constrained clients often have no access to HTTP Pipelining (which limits them to one BOSH session at a time). BOSH connection managers are generally not required to understand anything about the XML content that they transport beyond perhaps ensuring that each XML payload is qualified by the correct namespace.
Note: &xep0206; documents some XMPP-specific extensions of this protocol that were formerly included in this document.
From c651610ff0807947ea01ee478e95a597d211c65a Mon Sep 17 00:00:00 2001
From: Peter Saint-Andre
Date: Tue, 3 Dec 2013 13:41:06 -0700
Subject: [PATCH 28/40] incoming proposals
---
inbox/jingle-grouping.xml | 829 ++++++++++++++++++++++++++++++++++++
inbox/jingle-sources.xml | 870 ++++++++++++++++++++++++++++++++++++++
inbox/peptzo.xml | 134 ++++++
3 files changed, 1833 insertions(+)
create mode 100644 inbox/jingle-grouping.xml
create mode 100644 inbox/jingle-sources.xml
create mode 100644 inbox/peptzo.xml
diff --git a/inbox/jingle-grouping.xml b/inbox/jingle-grouping.xml
new file mode 100644
index 00000000..cfa7ede9
--- /dev/null
+++ b/inbox/jingle-grouping.xml
@@ -0,0 +1,829 @@
+
+
+
+
+
+
+
+
+ customxeps/extensions/jingle-grouping.xml at gh-pages · fippo/customxeps
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/inbox/jingle-sources.xml b/inbox/jingle-sources.xml
new file mode 100644
index 00000000..c612a164
--- /dev/null
+++ b/inbox/jingle-sources.xml
@@ -0,0 +1,870 @@
+
+
+
+
+
+
+
+
+ customxeps/extensions/jingle-sources.xml at gh-pages · fippo/customxeps
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/inbox/peptzo.xml b/inbox/peptzo.xml
new file mode 100644
index 00000000..30450dce
--- /dev/null
+++ b/inbox/peptzo.xml
@@ -0,0 +1,134 @@
+
+
+%ents;
+]>
+
+
+
+ User Time Zone
+ This specification defines a payload format for communicating information about a user's time zone. The payload format is typically transported using the personal eventing protocol, a profile of XMPP publish-subscribe specified in XEP-0163.
+ &LEGALNOTICE;
+ xxxx
+ ProtoXEP
+ Standards Track
+ Standards
+
+ XMPP Core
+ XEP-0082
+ XEP-0163
+
+
+
+ NOT_YET_ASSIGNED
+
+ Lance
+ Stout
+ lance@lance.im
+ lance@lance.im
+
+
+ 0.1
+ 2013-10-28
+ lance
+ Initial version.
+
+
+
+ &xep0060; and &xep0163; can be used to publish a wide variety of "extended presence" information about users. This document specifies an extended presence payload format that communicates information about a user's time zone. For example, this information may be of interest to a user's contacts for displaying notices advising against starting a chat at 4am in the user's local time.
+ Time zone information can also be obtained through &xep0202; by directly querying a full JID for a user. However, given that some clients are chiefly concerned with the time zone offset, and in the interest of reducing floods of IQ requests, we define a way to expose the time zone offset via PEP.
+
+
+
+ The numeric time zone offset from UTC for the user is expressed as the textual content of the <tzo/> element qualified by the 'urn:xmpp:timezone:0' namespace. While &xep0202; defines its own <tzo/> element, the schema allows for neither its reuse as a standalone element nor for the use of the <time/> element without a <utc/> element. The format MUST conform to the Time Zone Definition (TZD) specified in &xep0082;.
+
+
+ When a user wishes to share time zone information, its client may publish that fact to a PEP node whose NodeID is "urn:xmpp:timezone:0" &NSNOTE;. Because time zone information is not pure presence information and can change independently of the user's availability, it SHOULD NOT be provided as an extension to the &PRESENCE; stanza type.
+
+
+
+ -
+
-07:00
+
+
+
+
+ ]]>
+ The time zone offset is then delivered to all subscribers:
+
+
+
+ -
+
-07:00
+
+
+
+
+ ]]>
+ When the user wishes to stop broadcasting its time zone offset, the user's client SHOULD send an empty <tzo/> element with the same ItemID:
+
+
+
+ -
+
+
+
+
+
+ ]]>
+
+
+
+ -
+
+
+
+
+
+ ]]>
+
+
+
+ Revealing an entity's numeric time zone offset may leak limited information about the entity's current location. If the entity's understanding of UTC is far off from actual UTC, revealing that discrepancy may make it possible for an attacker to send XML stanzas that appear to be in the past or future even though they are not; therefore an entity should use the Network Time Protocol (&rfc0958;) or a similar technology to stay synchronized with actual UTC.
+
+
+ This document requires no interaction with &IANA;.
+
+
+
+ The ®ISTRAR; includes 'urn:xmpp:timezone:0' in its registry of protocol namespaces (see &NAMESPACES;).
+
+ - urn:xmpp:timezone:0
+
+
+
+ &NSVER;
+
+
+
+
+
+
+
+
+
+ The protocol documented by this schema is defined in
+ XEP-xxxx: http://www.xmpp.org/extensions/xep-xxxx.html
+
+
+
+
+
+
+ ]]>
+
+
From dea9369cdb6160fbe536824d4b2b39dc2f264abe Mon Sep 17 00:00:00 2001
From: Peter Saint-Andre
Date: Tue, 3 Dec 2013 13:47:25 -0700
Subject: [PATCH 29/40] specs for jingle-grouping and jingle-sources
---
xep.ent | 3 +++
1 file changed, 3 insertions(+)
diff --git a/xep.ent b/xep.ent
index 6f94eb5f..9dd0e125 100644
--- a/xep.ent
+++ b/xep.ent
@@ -603,9 +603,11 @@ THE SOFTWARE.
RFC 5450 RFC 5450: Transmission Time Offsets in RTP Streams <http://tools.ietf.org/html/rfc5450>. " >
RFC 5547 RFC 5547: A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer <http://tools.ietf.org/html/rfc5547>. " >
RFC 5574 RFC 5574: RTP Payload Format for the Speex Codec <http://tools.ietf.org/html/rfc5574>. " >
+RFC 5576 RFC 5576: Source-Specific Media Attributes in the Session Description Protocol (SDP) <http://tools.ietf.org/html/rfc5576>. " >
RFC 5646 RFC 5646: Tags for Identifying Languages <http://tools.ietf.org/html/rfc5646>. " >
RFC 5763 RFC 5763: Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS) <http://tools.ietf.org/html/rfc5763>. " >
RFC 5802 RFC 5802: Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms <http://tools.ietf.org/html/rfc5802>. " >
+RFC 5888 RFC 5888: The Session Description Protocol (SDP) Grouping Framework <http://tools.ietf.org/html/rfc5888>. " >
RFC 5952 RFC 5952: A Recommendation for IPv6 Address Text Representation <http://tools.ietf.org/html/rfc5952>. " >
RFC 5988 RFC 5988: Web Linking <http://tools.ietf.org/html/rfc5988>. " >
RFC 6045 RFC 6045: Real-time Inter-network Defense (RID) <http://tools.ietf.org/html/rfc6045>. " >
@@ -669,6 +671,7 @@ THE SOFTWARE.
Improving TCP's Robustness to Blind In-Window Attacks Improving TCP's Robustness to Blind In-Window Attacks <http://tools.ietf.org/html/draft-ietf-tcpm-tcpsecure>. Work in progress. " >
TURN Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) <http://tools.ietf.org/html/draft-ietf-behave-turn>. Work in progress. " >
XMPP Over WebSocket An XMPP Sub-protocol for WebSocket <https://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/>. Work in progress. " >
+Multiplexing Negotiation Using Session Description Protocol (SDP) Port Numbers Multiplexing Negotiation Using Session Description Protocol (SDP) Port Numbers <http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation/>. Work in progress. " >
From e14c6b837e758ac39583919d5d280683ae105c8a Mon Sep 17 00:00:00 2001
From: Peter Saint-Andre
Date: Tue, 3 Dec 2013 13:47:50 -0700
Subject: [PATCH 30/40] corrected version
---
inbox/jingle-grouping.xml | 961 +++++-----------------------------
inbox/jingle-sources.xml | 1043 +++++++------------------------------
2 files changed, 307 insertions(+), 1697 deletions(-)
diff --git a/inbox/jingle-grouping.xml b/inbox/jingle-grouping.xml
index cfa7ede9..e46e7def 100644
--- a/inbox/jingle-grouping.xml
+++ b/inbox/jingle-grouping.xml
@@ -1,829 +1,134 @@
-
-
-
-
-
-
-
-
- customxeps/extensions/jingle-grouping.xml at gh-pages · fippo/customxeps
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+ The ®ISTRAR; includes the foregoing namespace to the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.
+
TODO
+The ®ISTRAR; includes the foregoing namespace to the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.
+ +TODO
+First draft.
+Added usecases.
++ &xep0298; defines a way for XMPP agents to establish and + participate in tightly coupled conference calls. Such conference + calls would typically involve a number of regular participants + that establish direct one-to-one sessions with a single entity, + often referred to as a focus agent. Focus agents are generally + responsible for making sure that media sent from one call + participant would be distributed to all others so that everyone + would effectively hear or see everyone else. In other words they + often act as media mixers. +
+ ++ Depending on the mixing technology used by media mixers, they may + require significant bandwidth, processing resources or both. It is + hence common for mixers to be hosted on dedicated servers that can + provide such resources. They are then made reachable as + rendez-vous points and conference call participants are required + to call in, in order to join a conference call. This requires a + certain amount of pre-call configuration to be completed by the + service maintainers in order to create conference rooms and grant + proper access to the expected participants. The authorization + credentials are then often relayed to the participants in + preparation of the call by other means, such as IM or mail. +
+ ++ In certain situations, such pre-call preparations are + inconvenient and it is important for users to be able to establish + ad-hoc conference calls. One way to achieve this is for user + agents themselves to act as focus agents and media mixers. + Everyone else just calls the user at the focus agent, who then can + decide whether to accept or reject the calls as they arrive. This + works particularly well for audio only calls as the amount of + bandwidth and processing resources that they require is generally + within reach for end-user devices. +
+ ++ The situation is quite different for video calls. Media decoding + and especially encoding require considerably more resources with + video than they do with audio. Today, encoding a single video flow + with an acceptable quality is often the maximum that can be + expected from an end-user device. The advantages that come with + Moore's law will likely be insufficient to improve this, given the + massive shift toward mobile devices and the ever-increasing user + expectations toward video quality. +
+ ++ Therefore, this specification (COLIBRI) aims to provide a means + for user agents to interact with conference mixers. Such + interaction allows user agents to allocate mixing channels, + indicate what conferences they should be attached to, what + integers the various payload types map to, etc. Using COLIBRI + would hence allow any user agent to organize conference calls and + act as a signalling focus by outsourcing the actual media mixing + to a dedicated mixer. +
+ ++ The extension defined herein is designed to meet the following + requirements: +
++ This section provides a friendly introduction to COLIBRI. +
++ In essence, the goal of COLIBRI is to provide focus agents with a + way of using remote mixers as if as they were available locally. + The most important part of that is the possibility to allocate + ports on the mixer interfaces and then use these ports when + establishing Jingle sessions with the various participants. +
++ Every participant in the conference call is assigned one port for + RTP data and one for RTCP. An RTP/RTCP port couple is called a + channel. Each participant would use one channel per media type. + That is, a client participating with audio only would get one + channel, while another one that joins with both audio and video + would get two: one for audio and one for video. +
++ Channels are used for streams from the bridge to participants and + from participants to the bridge. Typically a channel would contain + one stream from a participant to a bridge, for example their + webcam or desktop, and one or more streams in the opposite + direction (e.g. webcam or desktop streams from other participants + to the one using this channel). This is not a requirement though + and a channel can certainly be used for transportation of multiple + streams in both directions in cases where one bridge is connected + to another. +
++ Typically channels would be created by the entity controlling a + conference call. This could either be a conferencing server or a + smart client capable of handling conferences. We would refer to + both of these as the "focus". In either case, the important part + is that the focus terminates all signalling. It is a signalling + endpoint and it is responsible for all aspects of call signalling + including offer/answer. +
++ In other words, when setting up a conference, a focus would first + allocate the necessary channels, then directly initiate sessions + (invite) other participants into the call. Only, when sending the + invitations to these participants, the focus would use the + transport information (addresses and ports) that it would have + received from the COLIBRI bridge, rather than its own. +
+ ++ The most important thing about setting up a conference is the + creation of channels for every participant. Conference setup is + not the only chance an organiser gets to declare all + participants but typically when a conference call is setup it + is because there are at least some number of known participants + and there would be no point in delaying channel creation for + them. +
++ The following example shows how Romeo creates an audio/video + conference at a bridge, requesting that three participant + channels be created. +
++ Notice how the 'initiator' channel above is set to true. The + setting determines ICE and DTLS/SRTP behaviour for the bridge. + In this specific case, 'initiator' being set to 'true' Romeo is + requesting that the bridge behave as the initiator of the + session which means that it would try to be the controlling ICE + agent and also assume the 'dtls-actpass' role for DTLS/SRTP + negotiation. A value of 'false' would have meant that the bridge + would behave as the controlled ICE agent and assume the + 'dtls-active' role. +
++ When sending its result back, the bridge confirms creation of + the requested channels and it also delivers transport + information that would be necessary for participants to + transport media to the bridge. These would most often include + ICE candidates, ufrag and pwd parameters, and DTLS fingerprints. +
++ Note that ICE is not mandatory for use and COLIBRI bridges can + just as well perform Hosted NAT Traversal using latching and a + RAW-UDP transport. +
++ The above "result" also contains the following elements of + interest for every channel: +
++ - an ID that is necessary for any further modification from that + the focus wants to set on a channel. [FIXME: clients should be + able to specify these id-s so as not to rely on ordering to + identify channels and get complexes thinking they are SDP + parsers] +
++ - an rtp-level-relay-type attribute with possible values of + 'mixer' and 'translator' indicating how the bridge is going to + deliver data on a specific channel [FIXME: this would definitely + need to be specifiable from the client]. +
++ - mixer channels would also include ssrc-s for that channels in + question. This is particularly necessary when SSRC-s need to be + announced to participants (because people never learned how RTP + works and are afraid from anything that wasn't explicitly + announced with an Offer/Answer exchange). Generally such + announcements would be possible by simply propagating SSRCs that + other participants announce. In a mixed flow however the SSRC + would belong to the mixer (or COLIBRI bridge) so it would need + to be known in advance. + attribute +
++ - the initiator value is echoed +
++ - expire describes how many seconds the bridge will keep the + channel open without media activity +
++ Channel updates can happen for various reasons. The following + examples illustrate two of them: +
++ - specifying payload types. While payload types in RTP are + sometimes static (e.g. for older codecs such as G.711), this is + not always the case for more recent types, which need to be + assigned dynamically during session establishment. The tricky + part here is that dynamic means dynamic so every participant in + a conference call may end up expecting different payload types. + As a result, a COLIBRI bridge SHOULD know about everyone's + expectations, which is why channels are updated with payload + types. Note that if a bridge does see unknown payload types it + MUST still relay them to other participants as they might have + used some other mechanism to make sure they know what they + mean. +
++ - DTLS/SRTP fingerprints. +
++ Note that while the result in this case is essentially an + acknowledgement, it still carries a full representation of the + bridge. +
+Essentially that information is the transport description from + the bridge. +
++ ICE candidates are another reason why a focus might want to + update a channel. Earlier examples indicated how conference + setup could be completed without providing any transport + information whatsoever. Whenever that is the case, such + information would need to be provided through channel + modification. +
+If an entity supports COLIBRI, it SHOULD advertise that fact by + returning + a feature of "http://jitsi.org/protocol/colibri" in response to + a &xep0030; + information request. +
+In order for an application to determine whether an entity + supports this + protocol, where possible it SHOULD use the dynamic, presence-based + profile + of service discovery defined in &xep0115;. However, if an + application has + not received entity capabilities information from an entity, it + SHOULD use + explicit service discovery instead. +
+PENDING
+PENDING
+PENDING
+Jitsi's participation in this specification is funded by the + NLnet + Foundation. +
+First draft.
-Added usecases.
First draft.
+
From b505840761f029cb2e8aece548b185bef51f7e28 Mon Sep 17 00:00:00 2001
From: Philipp Hancke This maps to Jingle as a <ssrc-group/> element qualified by the 'urn:xmpp:jingle:apps:rtp:ssma:0' namespace. Like the <source/> element, this is included as child of the Jingle <description/> element. The SDP 'semantics' parameter is mapped to the type attribute (for consistency with FIXME jingle-grouping FIXME) and the list of ssrc-ids is mapped to <source/> elements whole 'ssrc' attribute is set to the ssrc-id. This maps to Jingle as a <ssrc-group/> element qualified by the 'urn:xmpp:jingle:apps:rtp:ssma:0' namespace. Like the <source/> element, this is included as child of the Jingle <description/> element. The SDP 'semantics' parameter is mapped to the semantics attribute (for consistency with FIXME jingle-grouping FIXME) and the list of ssrc-ids is mapped to <source/> elements whole 'ssrc' attribute is set to the ssrc-id. An example follows. Incorporated patches from community review. The Transmission Control Protocol (TCP; &rfc0793;) is often used to establish a stream-oriented connection between two entities. Such connections can often be long-lived to enable an interactive "session" between the entities. However, sometimes the nature of the device or network can prevent an application from maintaining a long-lived TCP connection to a server or peer. In this case, it is desirable to use an alternative connection method that emulates the behavior of a long-lived TCP connection using a sequenced series of requests and responses that are exchanged over short-lived connections. The appropriate request-response semantics are widely available via the Hypertext Transfer Protocol (HTTP) as specified in &rfc1945; and &rfc2616;. BOSH, the technology defined in this specification, essentially provides a "drop-in" alternative to a long-lived, bidirectional TCP connection. It is a mature, full-featured technology that has been widely implemented and deployed since 2004. To our knowledge it was the first of many similar technologies, which now include the Comet methodology formalized in the &bayeux; as well as WebSocket &rfc6455; and &rhttp;. BOSH is designed to transport any data efficiently and with minimal latency in both directions. For applications that require both "push" and "pull" semantics, BOSH is significantly more bandwidth-efficient and responsive than most other bidirectional HTTP-based transport protocols and the techniques now commonly known as "Ajax". BOSH achieves this efficiency and low latency by using so-called "long polling" with multiple synchronous HTTP request/response pairs. Furthermore, BOSH can address the needs of constrained clients by employing fully-compliant HTTP 1.0 without the need for "cookies" (see &rfc2965;) BOSH was originally developed in the Jabber/XMPP community as a replacement for an even earlier HTTP-based technology called &xep0025;. Although BOSH assumes that the "payload" of HTTP requests and responses will be XML, the payload formats are not limited to XMPP stanzas (see &xmppcore;) and could contain a mixture of elements qualified by namespaces defined by different protocols (e.g., both XMPP and JSON). This mix is necessary because some connection managers might not support Multiple Streams and constrained clients often have no access to HTTP Pipelining (which limits them to one BOSH session at a time). BOSH connection managers are generally not required to understand anything about the XML content that they transport beyond perhaps ensuring that each XML payload is qualified by the correct namespace. BOSH was originally developed in the Jabber/XMPP community as a replacement for an even earlier HTTP-based technology called &xep0025;. Although BOSH assumes that the "payload" of HTTP requests and responses will be XML, the payload formats are not limited to XMPP stanzas (see &xmppcore;) and could contain a mixture of elements qualified by namespaces defined by different protocols (e.g., both XMPP and JSON). BOSH connection managers are generally not required to understand anything about the XML content that they transport beyond perhaps ensuring that each XML payload is qualified by the correct namespace. Note: &xep0206; documents some XMPP-specific extensions of this protocol that were formerly included in this document.
a=ssrc-group:<semantics> <ssrc-id> ...
-
+
+
From 9fd3830400730d4049073772f826ef179562513f Mon Sep 17 00:00:00 2001
From: Peter Saint-Andre
The requirements of RFC 2616 MUST be met for both requests and responses. Additional HTTP headers not specified herein MAY be included, but receivers SHOULD ignore any such headers. Clients and connection managers MAY omit headers that are not mandated by RFC 2616 and would otherwise be ignored (e.g. if the client has constrained bandwidth), but clients are advised that network and proxy policies could block such requests.
All information is encoded in the body of standard HTTP POST requests and responses. Each HTTP body contains a single <body/> wrapper which encapsulates the XML elements being transferred (see <body/> Wrapper Element).
-Clients SHOULD send all HTTP requests over a single persistent HTTP/1.1 connection using HTTP Pipelining. However, a client MAY deliver its POST requests in any way permitted by RFC 1945 or RFC 2616. For example, constrained clients can be expected to open more than one persistent connection instead of using Pipelining, or in some cases to open a new HTTP/1.0 connection to send each request. However, clients and connection managers SHOULD NOT use Chunked Transfer Coding, since intermediaries might buffer each partial HTTP request or response and only forward the full request or response once it is available.
+Clients MUST send all HTTP requests as POST requests in any way permitted by RFC 1945 or RFC 2616. For example, clients can be expected to open more than one persistent connection, or in some cases to open a new HTTP/1.0 connection to send each request. However, clients and connection managers SHOULD NOT use Chunked Transfer Coding, since intermediaries might buffer each partial HTTP request or response and only forward the full request or response once it is available.
Clients MAY include an HTTP Accept-Encoding header in any request. If the connection manager receives a request with an Accept-Encoding header, it MAY include an HTTP Content-Encoding header in the response (indicating one of the encodings specified in the request) and compress the response body accordingly.
-Each BOSH session MAY share the HTTP connection(s) it uses with other HTTP traffic, including other BOSH sessions and HTTP requests and responses completely unrelated to this protocol (e.g., web page downloads). However, the responses to requests that are not part of the session sent over the same connection using HTTP pipelining (or queued to be sent over the same connection) might be delayed if they were sent while a request that is part of the session is being held (since the connection manager MUST send its responses in the same order that the requests were received, and the connection manager typically delays its responses).
The HTTP Content-Type header of all client requests SHOULD be "text/xml; charset=utf-8". However, clients MAY specify another value if they are constrained to do so (e.g., "application/x-www-form-urlencoded" or "text/plain"). The client and connection manager SHOULD ignore all HTTP Content-Type headers they receive.
Note: Clients that only support Polling Sessions MAY prevent the connection manager from waiting by setting 'wait' or 'hold' to "0". However, polling is NOT RECOMMENDED since the associated increase in bandwidth consumption and the decrease in responsiveness are both typically one or two orders of magnitude!
A connection manager MAY be configured to enable sessions with more than one server in different domains. When requesting a session with such a "proxy" connection manager, a client SHOULD include a 'route' attribute that specifies the protocol, hostname, and port of the server with which it wants to communicate, formatted as "proto:host:port" (e.g., "xmpp:example.com:9999").
Note: If the connection manager did not specify a 'polling' attribute in the session creation response, then it MUST allow the client to send requests as frequently as it chooses.
It is not always possible for a constrained client to either use HTTP Pipelining or open more than one HTTP connection with the connection manager at a time. In this case the client SHOULD inform the connection manager by setting the values of the 'wait' and/or 'hold' attributes in its session creation request to "0", and then "poll" the connection manager at regular intervals throughout the session for payloads it might have received from the server. Note: Even if the client does not request a polling session, the connection manager MAY require a client to use polling by setting the 'requests' attribute (which specifies the number of simultaneous requests the client can make) of its Session Creation Response to "1", however this is NOT RECOMMENDED.
+It is not always possible for a constrained client to open more than one HTTP connection with the connection manager at a time. In this case the client SHOULD inform the connection manager by setting the values of the 'wait' and/or 'hold' attributes in its session creation request to "0", and then "poll" the connection manager at regular intervals throughout the session for payloads it might have received from the server. Note: Even if the client does not request a polling session, the connection manager MAY require a client to use polling by setting the 'requests' attribute (which specifies the number of simultaneous requests the client can make) of its Session Creation Response to "1", however this is NOT RECOMMENDED.
If a session will use polling, the connection manager SHOULD specify a higher than normal value for the 'inactivity' attribute (see Inactivity) in its session creation response. The increase SHOULD be greater than the value it specifies for the 'polling' attribute.
If the client sends two consecutive empty new requests (i.e. requests with incremented rid attributes, not repeat requests) within a period shorter than the number of seconds specified by the 'polling' attribute (the shortest allowable polling interval) in the session creation response, and if the connection manager's response to the first request contained no payloads, then upon reception of the second request the connection manager SHOULD terminate the HTTP session and return a 'policy-violation' terminal binding error to the client.
The OPTIONAL feature described in this section enables multiple XML streams to be contained within a single HTTP session. This feature is essential in runtime environments that prevent HTTP Pipelining, thereby constraining the number of simultaneous HTTP requests a client can make to each connection manager, since clients running in such environments need multi-stream sessions if they are to connect using more than one account at the same time. This feature also reduces network traffic for any client that needs to establish parallel streams over HTTP.
+The OPTIONAL feature described in this section enables multiple XML streams to be contained within a single HTTP session. This feature allows for clients to connect using more than one account at the same time. This feature also reduces network traffic for any client that needs to establish parallel streams over HTTP.
If a connection manager supports the multi-streams feature, it MUST include a 'stream' attribute in its Session Creation Response. If a client does not receive the 'stream' attribute then it MUST assume that the connection manager does not support the feature.
Even if the client requests HTTP Pipelining and the connection manager supports it, there is no guarantee that pipelining will succeed, because it might not be supported by intermediate proxies.
-The client SHOULD set the 'hold' attribute to a value of "1". If HTTP Pipelining does not work (because the server returns HTTP 1.0 or connection:close), then the client SHOULD degrade gracefully by using multiple connections.
+HTTP pipelining allows a client to send multiple requests over the same HTTP socket connection without waiting for the corresponding responses. However, RFC 2616 notes that only idempotent methods should be allowed to use HTTP pipelining, which does not include the POST method used extensively by BOSH. Furthermore, there is no guarantee that pipelining will succeed because intermediate proxies might not support it. Therefore, clients and connection managers SHOULD NOT use HTTP Pipelining.
Thanks to Emil Ivov and Lance Stout for their feedback.
The XML format for this specification originates from libjingle
The SDP syntax examples are taken from RFC 5888.
This document introduces no additional security considerations above and beyond those defined in the documents on which it depends.
diff --git a/inbox/jingle-sources.xml b/inbox/jingle-sources.xml index 483c41e5..7bfeb944 100644 --- a/inbox/jingle-sources.xml +++ b/inbox/jingle-sources.xml @@ -79,45 +79,39 @@ a=ssrc-group:<semantics> <ssrc-id> ...The following example is taken from RFC 5576.
-m=video 49174 RTP/AVPF 96 98
-a=rtpmap:96 H.264/90000
-a=rtpmap:98 rtx/90000
-a=fmtp:98 apt=96;rtx-time=3000
-a=ssrc-group:FID 11111 22222
-a=ssrc:11111 cname:user3@example.com
-a=ssrc:22222 cname:user3@example.com
-a=ssrc-group:FID 33333 44444
-a=ssrc:33333 cname:user3@example.com
-a=ssrc:44444 cname:user3@example.com
+m=video 1 RTP/SAVPF 100 116 117
+a=rtpmap:100 VP8/90000
+a=ssrc-group:FID 2301230316 386328120
+a=ssrc:2301230316 cname:T5qvrIZj42v//eYQ
+a=ssrc:386328120 cname:uEYgNtStZyTF74sM
+a=ssrc-group:FID 3139499595 2613715171
+a=ssrc:3139499595 cname:re8jhxkly9bxzuxr
+a=ssrc:2613715171 cname:f83avsiw6n1m7vi
This is mapped to Jingle as follows:
-
-
-
-
-
+
-
-
+
+
-
-
+
+
-
@@ -146,9 +140,10 @@ a=ssrc:44444 cname:user3@example.com
]]>
In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.
This document introduces no additional security considerations above and beyond those defined in the documents on which it depends.
a=group:LS voice webcam
- This SDP attribute is translated to Jingle as a <group/> element qualified by the 'urn:xmpp:jingle:apps:grouping:0' namespace, as shown below. The semantics is mapped to a 'semantics' attribute. The identifiation-tags are mapped to content elements whose name attribute is set to the identification-tag.
+This SDP attribute is translated to Jingle as a <group/> element qualified by the 'urn:xmpp:jingle:apps:grouping:0' namespace, as shown below. The semantics is mapped to a 'semantics' attribute. The identification-tags are mapped to content elements whose name attribute is set to the identification-tag.
From b3c190b4bd276c4e59f94a5823abb088411bf81c Mon Sep 17 00:00:00 2001
From: Philipp Hancke
Date: Wed, 18 Dec 2013 18:06:44 +0100
Subject: [PATCH 39/40] example not taken from 5576
---
inbox/jingle-sources.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/inbox/jingle-sources.xml b/inbox/jingle-sources.xml
index 7bfeb944..d0e9cb1d 100644
--- a/inbox/jingle-sources.xml
+++ b/inbox/jingle-sources.xml
@@ -77,7 +77,7 @@ a=ssrc-group:<semantics> <ssrc-id> ...
The following example is taken from RFC 5576.
+A minimal example follows:
m=video 1 RTP/SAVPF 100 116 117
a=rtpmap:100 VP8/90000
From 6a0001367df8e0c5a782545d0236f38a4b5fe5d5 Mon Sep 17 00:00:00 2001
From: Peter Saint-Andre
Date: Fri, 20 Dec 2013 13:49:53 -0700
Subject: [PATCH 40/40] 0.0.4 from Peter Waher
---
inbox/dynamic-forms.xml | 234 ++++++++++++++++++++--------------------
1 file changed, 114 insertions(+), 120 deletions(-)
diff --git a/inbox/dynamic-forms.xml b/inbox/dynamic-forms.xml
index 1d05e456..8bdc716e 100644
--- a/inbox/dynamic-forms.xml
+++ b/inbox/dynamic-forms.xml
@@ -14,15 +14,7 @@
controls with undefined values or error messages, while still being backwards compatible with the existing data form model with available
extensions.
-
- This XMPP Extension Protocol is copyright (c) 1999 - 2013 by the XMPP Standards Foundation (XSF).
- Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.
- ## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. In no event shall the XMPP Standards Foundation or the authors of this Specification be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. ##
- In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising out of the use or inability to use the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.
-
- This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at <http://www.xmpp.org/extensions/ipr-policy.shtml> or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA).
-
-
+ &LEGALNOTICE;
xxxx
ProtoXEP
Standards Track
@@ -34,7 +26,7 @@
- NOT_YET_ASSIGNED
+ dynamic-forms
Peter
Waher
@@ -42,6 +34,24 @@
peter.waher@jabber.org
http://www.linkedin.com/in/peterwaher
+
+ 0.0.4
+ 2013-12-18
+ pw
+
+ The element formPostBack has been renamed to submit.
+ The element formUpdated has been renamed to updated.
+ The elements formPostBackResponse and cancelResponse have been removed. Error handling has been updated to conform to use IQ error stanzas and error codes.
+
+
+
+ 0.0.3
+ 2013-12-04
+ pw
+
+ Namespace changed to urn:xmpp:xdata:dynamic.
+
+
0.0.2
2013-10-29
@@ -284,7 +294,7 @@
The following subsections list use cases for the different enhancements defined by this extension. Elements are defined using the namespace
- http://jabber.org/protocol/xdata-dynamic and namespace prefix xdd.
+ urn:xmpp:xdata:dynamic and namespace prefix xdd.
@@ -298,7 +308,7 @@
Current location
Select your current location to continue.
@@ -333,7 +343,7 @@
- A server post-back is performed by sending an IQ set stanza with a formPostBack child element containing the
+ A server post-back is performed by sending an IQ set stanza with a submit child element containing the
current state of the form. The type of the form must be submit. The client should also provide the current
user language in a xml:lang attribute, if available.
@@ -343,7 +353,7 @@
from='formclient@clayster.com/client'
to='formserver@clayster.com'
id='1'>
-
+
009c7956-001c-43fb-8edb-76bcf74272c9
@@ -352,7 +362,7 @@
CL
-
+
]]>
@@ -360,8 +370,7 @@
submission of the data form.
- As a response to a successful form post-back, the server returns a formPostBackResponse element with a result code of OK
- containing a new data form, as is shown in the following example:
+ As a response to a successful form post-back, the server returns the new data form, as is shown in the following example:
-
-
- Current location
- Select your current location to continue.
-
- 009c7956-001c-43fb-8edb-76bcf74272c9
-
-
- Select your country of residence.
-
-
-
+
+ Current location
+ Select your current location to continue.
+
+ 009c7956-001c-43fb-8edb-76bcf74272c9
+
+
+ Select your country of residence.
+
+
+
+ CL
+
+
-
-
- ...
-
-
- Select your region of residence.
-
-
-
-
-
-
-
-
- ...
-
-
-
+
+
+
+ ...
+
+
+ Select your region of residence.
+
+
+
+
+
+
+
+
+ ...
+
+
]]>
@@ -439,7 +446,7 @@
Object properties
@@ -497,7 +504,7 @@
Communication properties
@@ -546,7 +553,7 @@
Expression
@@ -591,7 +598,7 @@
from='formclient@clayster.com/client'
to='formserver@clayster.com'
id='4'>
-
+
009c7956-001c-43fb-8edb-76bcf74272c9
@@ -602,38 +609,44 @@
]]>
- After receiving the cancel request the form server returns a cancel response having a result code of OK if the form
- was found (and therefore cancelled), or NotFound if the form was not found. The following example shows an OK response:
+ After receiving the cancel request the form server returns an empty response if the form was found (and therefore cancelled), or an
+ IQ error stanza with an item-not-found error if the form was not found. The following example shows a response where
+ the form was found and cancelled:
-
- ]]>
+ id='4'/>]]>
Note: If cancelling a dynamic form using the approach described in this document, there's no need to also submit
a cancel form as defined in the Data Forms XEP. The form server automatically
makes sure the form is cancelled in all instances on the form server.
+
+ Note 2: If the dynamic form is invoked from a specific operation that includes its own cancel procedure, like
+ Ad-hoc command sessions, the dynamic form is automatically and implicitly cancelled if the corresponding operation is cancelled.
+ There is no need to explicitly cancel the dynamic form as explained in this section in such cases.
+
It might happen that the form server does not find the dynamic form posted by the form client during a post back. Reasons for this can be
that the form does not include a post-back field, or that a form session timeout has occurred and the form server has discarded the dynamic
- form to avoid memory leaks. Regardless of the reason, the form server responds using a NotFound result in the response, when
- the client posts a form that is not found back.
+ form to avoid memory leaks. Regardless of the reason, the form server responds using an IQ error stanza with the item-not-found
+ error, when the client posts a form that is not found back.
-
+
+
+
]]>
@@ -643,25 +656,26 @@
- If another error occurs during post-back, the form server can inform the client about this, using the OtherError
- result code, and include an error element to describe the error, as is shown in the following example:
+ If another error occurs during post-back, the form server can inform the client about this by using the relevant error element and
+ provide further information in a text element to describe the error, as is shown in the following example:
-
- An internal error occurred: Stack limit has been reached.
-
+
+
+ An internal error occurred: Stack limit has been reached.
+
]]>
The server may send asynchronous updates to open forms on the client. This can be done if the server detects changes that it wants to inform
- the client about. Changes are made by sending a message stanza including a formUpdated element which in turn
+ the client about. Changes are made by sending a message stanza including a updated element which in turn
contains the new updated form.
@@ -675,7 +689,7 @@
The client may have more than one form open at any given time. It might also be so that the form has been closed prior to receiving or handling the update message,
- and is therefore no longer visible. To be able to identify to which form the update corresponds, the formUpdated
+ and is therefore no longer visible. To be able to identify to which form the update corresponds, the updated
element is required to include a sessionVariable attribute in which it identifies a unique identifying
field in the form. When the client receives the update, it goes through all forms it has open. If a form has a field variable with a corresponding
name, and the field variable has a value equal to the value in the updated form, the form should be updated by the contents of the message. If no form is found,
@@ -684,7 +698,7 @@
Control parameters
@@ -703,9 +717,9 @@
...
-
+
Control parameters
@@ -719,18 +733,22 @@
49152
-
+
]]>
Note: Make sure to check the implementation note Merging Client-Side Values for information
on how to merge updates received from the server with current input made by the client.
+
+ Note 2: The client should also provide the current user language in a xml:lang attribute in the updated
+ element, if available, as is shown in the example above.
+
If an entity supports the protocol specified herein, regardless if the entity represents a form server or a form client; it MUST advertise
- that fact by returning a feature of "http://jabber.org/protocol/xdata-dynamic" in response to &xep0030; information requests.
+ that fact by returning a feature of "urn:xmpp:xdata:dynamic" in response to &xep0030; information requests.
...
-
+
...
]]>
@@ -780,7 +798,7 @@
The form server must be aware that some form clients do not support dynamic forms. This in turn implies that form clients
may not call the correct cancel method to cancel a dynamic form. To protect the form server from memory leaks, it must
include a session timeout, and release any dynamic form session resources if no activity has been made during the
- corresponding time period. If the client would perform a post-back after the timeout period, a NotFound
+ corresponding time period. If the client would perform a post-back after the timeout period, an item-not-found
error message must be returned, to show the corresponding dynamic form session no longer exists, and therefore could
not be found.
@@ -877,8 +895,8 @@
@@ -914,7 +932,7 @@
-
+
@@ -922,17 +940,7 @@
-
-
-
-
-
-
-
-
-
-
-
+
@@ -941,14 +949,6 @@
-
-
-
-
-
-
-
-
@@ -957,16 +957,10 @@
-
-
-
-
-
-
]]>
Thanks to Karin Forsell for all valuable feedback.
+Thanks to Karin Forsell and Lance Stout for all valuable feedback.