Re: [Standards] [IOT] Comments on XEP0323
Hello Emmanuel Thanks for your mail and all your comments. Sorry for the delay in the response. I've been away of a longer vacation. I'll try to address each one of your concerns one at a time: -Original Message- From: Emmanuel Frécon [mailto:emman...@sics.se] Sent: den 28 januari 2014 05:16 To: i...@xmpp.org Subject: [IOT] Comments on XEP0323 Dear Folks! I have just gone through a thorough reading of XEP-0323 with the view of understanding its details before an implementation. I have a number of comments and suggestions, but also questions that I would like to share and raise. Note that I haven't spent so much time on "cross-XEP" reading. But first of all, I would like to congratulate Peter on putting together a strong (set of) XEP(s) that aim at solving some of the issues faced by IoT applications! Well done. And now... comes the list in no particular order, you will notice that there is a mix of tiny problems and sometimes larger questions. * I have a general question about security and request/responses. I don't see any protection against too many requests sent within a too short time frame. This could harm the receivers since we are usually talking about tiny devices with few resources. The proposal mentions that these requests might not be served, but having to process too many of them, even if taking the decision of not serving them might put a small sensor to its knees. I understand that requesting and requested must be friends, but such an issue might occur because of bad coding or corner cases being reached. I have no real solution, but I thought that I would mention it. Ok. The device can reject a readout request (§3.3) and provide the reason why the readout was rejected. If the device is unable to serve the request it can queue it, reject it or provide a failure, depending on why it was unable to process it. It has been left as implementation specific. * Every example in the text uses a sequence number that matches the "id" field of the . A non-initiated might be misled that they should be the same. Ok. Updated the id attribute values in all examples, to highlight they are different from the sequence numbers. * I am bit puzzled by having values listed as a sub-element of a . This is especially true since, for example, errors place the timestamp as an attribute of the tag. What are the design decisions that led to this ordering? In some cases, there's only one field value per timestamp, so this might look strange. But in the general case, there are multiple field values for each timestamp in a meter. Examples: Water meters report (at least) Accumulated Volume & Momentary Flow for each timestamp. Electricity meters report (at least) Accumulated Energy and Power for each timestamp. Heat meters usually report (at least) Accumulated Energy, Accumulated Volume, Momentary Flow, Momentary Power, Supply Temperature, Return Temperature and Temperature Difference, for each timestamp. The main reason is to have a simple way to group together fields belonging together (by time). Otherwise, a long list of values would be provided, and the receiver would need to compare timestamps to know which field values belong together. Compressed, timestamps also require much memory compared to start/end element signals, and by placing the timestamp in a separate element, redundancy is avoided. * As a side-note, I think that some of the example should highlight the fact that the dateTime type can also specify fractions of seconds, these might be important for some applications. Correct. However, most devices I've seen only report seconds, even though fractions of seconds are possible. * Since units are only under recommendation (and I think that this is very wise), we might consider having not having them as a "required" attribute for numerical values at all. Obviously, this is not very interoperable but it is as good as introducing unknown units that are only recognised within the namespace of an application. Note sure I follow you here. Could you rephrase this? * In the read-out from multiple devices, I would have preferred that the s are placed as sub-element of the . Ok. This would create redundancy in the timestamp part, as explained above. * Wouldn't it be more future-proof to have field types represented by a field called with an attribute describing the period of the history? XEP-0326 contains an alternative way of reporting historical values stored in databases. The values shown here correspond to a momentary readout of a device, where the values have been flagged as historical. The period is described by the timestamp, and here you see the grouping feature of the timestamp element. * I wonder what the real difference is between "peak" and "computed" in the field types. The problem that I have with peak is that it shuts off other mathematical constructs such as mean, median, aver
[Standards] IoT device Discovery XEP
Hello We're planning to start writing a new XEP proposal for IoT device discovery. I've received interest from a couple of people who wants to work on this. If anybody is interested in participating in this work, please let me know. The first proposal for the proto-XEP will be published in normal order on the standards list for anybody to comment on. Best regards, Peter Waher
Re: [Standards] SMS/Email Forwarding of Messages
Yes exactly. Support of data forms etc. would be nice for setup and query. /Steffen On 17 Feb 2014, at 19:10, Simon Tennant wrote: > IMHO this is really something that should be in the push spec. > configure with numbers/email addresses > push events to "pusher component" > Services like "knowing if delivery has gone through could be reflected in the > to . > > This is how we solved it on the Buddycloud "pusher" > https://github.com/buddycloud/buddycloud-pusher#add-or-configure-push-records > > @Lance - do you need any help writing the XEP once you are finished with > Websockets and London? > ᐧ > > > On 17 February 2014 15:02, Spencer MacDonald > wrote: > Hi Steffen, > > I was at the summit and also thought that it could be added to the push > notification XEP, but for SMS/Email you might want to: > > - Know what telephone number or email address the message was forwarded on to. > - Know if the message has been sent/received/opened > - Opt in/Out of paying for forwarding (in the case of SMS). > > So although it can be just another end point, I think you still need > additional logic when compared to push notifications. > > Regards > > Spencer > > On 17 Feb 2014, at 13:51, Steffen Larsen wrote: > > > I think you might look at the stuff we were discussing at the XMPP summit, > > namely push notifications. > > Lance stout have begun doing a XEP for this: > > http://legastero.github.io/customxeps/extensions/push.html > > > > It can prob. be used for SMS and email as well. Just another endpoint. :-) > > > > /Steffen > > > > > > On 17 Feb 2014, at 14:47, Spencer MacDonald > > wrote: > > > >> Is there any XEP that covers a message getting forwarded using another > >> transport e.g. SMS, Email? > >> > >> If not would there be any interest in making a standard one? > >> > >> My personal use case is if the recipient is offline, the message can be > >> forward to their phone as an SMS. > >> > >> Regards > >> > >> Spencer > > > > > > > -- > Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/tQgxP smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] SMS/Email Forwarding of Messages
IMHO this is really something that should be in the push spec. - configure with numbers/email addresses - push events to "pusher component" Services like "knowing if delivery has gone through could be reflected in the to . This is how we solved it on the Buddycloud "pusher" https://github.com/buddycloud/buddycloud-pusher#add-or-configure-push-records @Lance - do you need any help writing the XEP once you are finished with Websockets and London? ᐧ On 17 February 2014 15:02, Spencer MacDonald < spencer.macdonald.ot...@gmail.com> wrote: > Hi Steffen, > > I was at the summit and also thought that it could be added to the push > notification XEP, but for SMS/Email you might want to: > > - Know what telephone number or email address the message was forwarded on > to. > - Know if the message has been sent/received/opened > - Opt in/Out of paying for forwarding (in the case of SMS). > > So although it can be just another end point, I think you still need > additional logic when compared to push notifications. > > Regards > > Spencer > > On 17 Feb 2014, at 13:51, Steffen Larsen wrote: > > > I think you might look at the stuff we were discussing at the XMPP > summit, namely push notifications. > > Lance stout have begun doing a XEP for this: > http://legastero.github.io/customxeps/extensions/push.html > > > > It can prob. be used for SMS and email as well. Just another endpoint. > :-) > > > > /Steffen > > > > > > On 17 Feb 2014, at 14:47, Spencer MacDonald < > spencer.macdonald.ot...@gmail.com> wrote: > > > >> Is there any XEP that covers a message getting forwarded using another > transport e.g. SMS, Email? > >> > >> If not would there be any interest in making a standard one? > >> > >> My personal use case is if the recipient is offline, the message can be > forward to their phone as an SMS. > >> > >> Regards > >> > >> Spencer > > > > -- Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/tQgxP
Re: [Standards] BOSH patches, hopefully the last before final
On 02/17/2014 05:41 PM, Christian Schudt wrote: Hi, to: As SHOULD attribute in the initial session response: "'to' -- This attribute communicates the identity of the backend server to which the client is attempting to connect." from: "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." > 2) Where's exactly the difference between 'to' and 'from' in the > session response? So the 'to' talks about the identity of the backend server, the 'from' talks about the identity that is discovered. The 'to' SHOULD be included in the first response (and not thereafter) the 'from' MAY be included in any response. > 1) I don't see the relation between the 'to' attribute and the > "payload agnostic". If there is an 'identity that is discovered' and what form it has, can vary from payload to payload. So the 'from' MAY contain a full JID when you use XMPP with BOSH. The 'to' SHOULD contain a server identity, whatever payload you use BOSH for. If I use BOSH for example for an home brew communication protocol, then I may do whatever I want with the identity that is in the 'from'. That was one of the use cases for splitting up BOSH to XEP-0124 and XEP-0206. Winfried
Re: [Standards] BOSH patches, hopefully the last before final
Hi Winfried, 1) I don't see the relation between the 'to' attribute and the "payload agnostic". 2) Where's exactly the difference between 'to' and 'from' in the session response? 'to': communicates the identity of the backend server to which the client is attempting to connect. 'from': identity of the backend server the connection manager is connected to. Isn't that the same? Or is the 'to' the identity of the connection manager? Maybe you can make an example, where to and from have different values in the session response? Sorry for my questions, but afaik 124 is supposed to advanced to Final and it should be more clear then, imo. Christian Gesendet: Montag, 17. Februar 2014 um 16:29 Uhr Von: "Winfried Tilanus" An: standards@xmpp.org Betreff: Re: [Standards] BOSH patches, hopefully the last before final On 17-02-14 15:33, Christian Schudt wrote: Hoi Christian, > 'from' and 'to' is really confusing then and I don't quite understand the > slight difference. > > In my opinion, they should just be analog to: > > http://xmpp.org/rfcs/rfc6120.html#streams-attr-to That would by far the most logical, except: 1) XEP-0124 is meant to be payload agnostic. Whatever you want to serve over it, it should be possible. 2) A BOSH connection manager, even when used for XMPP, is not necessarily integrated with a XMPP server, it can be stand-alone too. To cover these cases, the 'to' and 'from' in XEP-0124 got different meanings then the 'to' and 'from' in RFC6120. Like it or not, but that is where XEP-0124 is right now and where it will stay. And to add a personal note: I am not happy with that either, but it is what it is. Winfried
Re: [Standards] BOSH patches, hopefully the last before final
On 17-02-14 15:33, Christian Schudt wrote: Hoi Christian, > 'from' and 'to' is really confusing then and I don't quite understand the > slight difference. > > In my opinion, they should just be analog to: > > http://xmpp.org/rfcs/rfc6120.html#streams-attr-to That would by far the most logical, except: 1) XEP-0124 is meant to be payload agnostic. Whatever you want to serve over it, it should be possible. 2) A BOSH connection manager, even when used for XMPP, is not necessarily integrated with a XMPP server, it can be stand-alone too. To cover these cases, the 'to' and 'from' in XEP-0124 got different meanings then the 'to' and 'from' in RFC6120. Like it or not, but that is where XEP-0124 is right now and where it will stay. And to add a personal note: I am not happy with that either, but it is what it is. Winfried
Re: [Standards] BOSH patches, hopefully the last before final
Hi Winfried, 'from' and 'to' is really confusing then and I don't quite understand the slight difference. In my opinion, they should just be analog to: http://xmpp.org/rfcs/rfc6120.html#streams-attr-to "For response stream headers in client-to-server communication, if the client included a 'from' attribute in the initial stream header then the server MUST include a 'to' attribute in the response stream header and MUST set its value to the bare JID specified in the 'from' attribute of the initial stream header." I.e. if the client receives a BOSH Session Creation Response, the 'to' attribute should be the client's JID and the 'from' attribute is the server's identity. (And on the client's session creation request, they should just be vice-versa). Can't it be analog to that? As it stands, the client receives the response and the 'to' attribute contains "the identity of the backend server to which the client is attempting to connect"? That's weird. Christian Gesendet: Montag, 17. Februar 2014 um 12:36 Uhr Von: "Winfried Tilanus" An: standards@xmpp.org Betreff: Re: [Standards] BOSH patches, hopefully the last before final On 11-02-14 13:54, Christian Schudt wrote: Hi Christian, Thanks for reviewing the patches and sorry for the delay in my response. > 1. Session Creation Response: > My suggestions concerning the 'from' attribute obv hasn't made it :-(.. Well, > so be it. > But I found this sentence: > 'to' -- This attribute communicates the identity of the backend server to > which the client is attempting to connect. > > Isn't it the same than the from attribute then? > Shouldn't the 'to' attribute be the client's JID in the server's response? Good question. Once again you are pointing to an issue where the history of the BOSH XEPs resulted in something that is a bit strange when you don't know the history. Remember that with the 'to' attribute the connection manager tells the identity of the backend server it is connecting to. The 'from' attribute 'MAY' be included once the connection manager established a session with the backend server and tells what identity the client has at the backend server. So they have a slightly different meaning. Also note that that backend server does not have to be a XMPP server. This has historically to do with the split of BOSH into two XEPs: generic BOSH (XEP-0124) and XMPP over BOSH (XEP-0206). Looking backward that was quite useless and even a bit confusing. But we are right now at the point where merging them again would only do more harm. > 2. Terminating the BOSH Session > Why did you remove the "" from this sentence: > > "... terminate the session by sending a element with a 'type' > attribute..." > ? Good catch, it is in the XML source, but I forgot escaping the brackets. Winfried
Re: [Standards] SMS/Email Forwarding of Messages
Hi Steffen, I was at the summit and also thought that it could be added to the push notification XEP, but for SMS/Email you might want to: - Know what telephone number or email address the message was forwarded on to. - Know if the message has been sent/received/opened - Opt in/Out of paying for forwarding (in the case of SMS). So although it can be just another end point, I think you still need additional logic when compared to push notifications. Regards Spencer On 17 Feb 2014, at 13:51, Steffen Larsen wrote: > I think you might look at the stuff we were discussing at the XMPP summit, > namely push notifications. > Lance stout have begun doing a XEP for this: > http://legastero.github.io/customxeps/extensions/push.html > > It can prob. be used for SMS and email as well. Just another endpoint. :-) > > /Steffen > > > On 17 Feb 2014, at 14:47, Spencer MacDonald > wrote: > >> Is there any XEP that covers a message getting forwarded using another >> transport e.g. SMS, Email? >> >> If not would there be any interest in making a standard one? >> >> My personal use case is if the recipient is offline, the message can be >> forward to their phone as an SMS. >> >> Regards >> >> Spencer >
Re: [Standards] SMS/Email Forwarding of Messages
Hello Spencer, what about "extending" [1] XEP-0297 [2] to include something to enable/disable automatic forwarding? [1] by "extending" I mean either improving that one or writing another one which uses XEP-0297 [2] http://xmpp.org/extensions/xep-0297.html On Mon, Feb 17, 2014 at 2:47 PM, Spencer MacDonald wrote: > Is there any XEP that covers a message getting forwarded using another > transport e.g. SMS, Email? > > If not would there be any interest in making a standard one? > > My personal use case is if the recipient is offline, the message can be > forward to their phone as an SMS. > > Regards > > Spencer -- Daniele
Re: [Standards] SMS/Email Forwarding of Messages
I think you might look at the stuff we were discussing at the XMPP summit, namely push notifications. Lance stout have begun doing a XEP for this: http://legastero.github.io/customxeps/extensions/push.html It can prob. be used for SMS and email as well. Just another endpoint. :-) /Steffen On 17 Feb 2014, at 14:47, Spencer MacDonald wrote: > Is there any XEP that covers a message getting forwarded using another > transport e.g. SMS, Email? > > If not would there be any interest in making a standard one? > > My personal use case is if the recipient is offline, the message can be > forward to their phone as an SMS. > > Regards > > Spencer smime.p7s Description: S/MIME cryptographic signature
[Standards] SMS/Email Forwarding of Messages
Is there any XEP that covers a message getting forwarded using another transport e.g. SMS, Email? If not would there be any interest in making a standard one? My personal use case is if the recipient is offline, the message can be forward to their phone as an SMS. Regards Spencer
Re: [Standards] compression attacks
On 17 feb. 2014, at 14:29, Winfried Tilanus wrote: > Signed PGP part > On 13-02-14 13:19, Thijs Alkemade wrote: > > On 13 feb. 2014, at 01:04, Peter Saint-Andre > > wrote: > > >> While working on draft-sheffer-uta-tls-attacks with Yaron > >> Sheffer this week, he pointed out to me that the TIME and BREACH > >> attacks might apply to application-layer compression technologies > >> such as XEP-0138 for XMPP. I haven't looked into that in detail > >> yet, but I figured I'd raise the issue here for discussion. > > XEP-0138's context is to provide compression when TLS is not > available. So it should not be used together with TLS, but the > security considerations cover the case where both are used. Maybe > better adjust these. Prosody recommends disabling TLS compression and enabling XMPP compression instead, citing high memory usage by OpenSSL for the latter. The intended goal might have been to allow for compression without TLS, but that's not how it's used in practice. TLS compression is also more vulnerable to compression attacks as it covers the SASL exchange too. > > Depends on what data you consider secret. > > > > Passwords shouldn't be in the compressed stream, per XEP-0170. > > Other highly sensitive data can be your contact list and the > > contents of your messages. Both of these an attacker should not be > > able to trigger retransmissions of, which complicates attacking > > them. > > > > But it's likely the attacker will be able to extract information > > like "is jul...@example.lit on your roster?", "did you receive a > > message from jul...@example.lit in the past 32 kB?" (the zlib > > window size) or "did you receive a message that included the phrase > > 'thermonuclear war' in the last 32 kB?". > > Thijs, can you explain this a bit more? As far as I understand these > attacks, they work when both a secret and data supplied by the > attacker are in the same compression context. That has to be the same > 32 kB compression window (in the case of zlib). I don't see how the > attacker can inject data into that, we don't have CSRF issues in XMPP. > Or it has to be for contexts like the IOT, where sensors can be > manipulated so you can test if the sensor has been sending the same > value just before. I'm making the following assumptions: 1) The attacker is able to route XMPP packets to the target (by a presence subscription or by knowing their full JID). 2) The attacker is able to observe the length of the packets between the server and the target's client. Sure, if you're only considering scenarios where TLS isn't used then these assumptions make no sense, because any MitM will have full read/write access to the stream. Thijs signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Standards] compression attacks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 17-02-14 14:29, Winfried Tilanus wrote: Hi, > Thijs, can you explain this a bit more? As far as I understand > these attacks, they work when both a secret and data supplied by > the attacker are in the same compression context. Brain-fart, of course this can be done by sending messages to the victim from an other JID. So yes, this can be a problem. Winfried -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJTAhFNAAoJEHZ7UH0X6Ldc+dgP/R7st7bQCZ1/GsE8d+Ay5t00 NJww1gWnhGWZnepZN6baM3QvZ2QI3Hiw7hGoexscD52YLtY3aWZQT5X3W5/9NlD1 d81BY/3cr2uHCKwJ2bnvlqxeoTBHbFHUK4xtbAiqs1ftJEFzKP01mCizPNzUDdXm x2s0mKBg3K8UDx7nuqPQdzFlVrMGvI7KteRx73ct+N1IIsGeyrjOBCerxmMaIpkl GsbVpL6GghLDwxEVH7RqSi0glgfzH0B9AptkJ/tPfwQw29GNKYiUEJIvGG6utPF3 Rz4qJ3tsZYm3p3jdpTu6x8nQIQgsufZP+dI7vfSHJbbrrP6TmmL2Ruh+9thzjKgv +AkZqr9rrxHXqFQMJ2nQKz8oB+6GZ/iam1ngXkgplxF2toWRWYSYwq/Ebo4lZ4P9 wS8APhpvcTcG9TlirCTBCF9ftvO1qZmn6X/677CdfxoFdTu6X1oJ1JEsCm+MqM42 CEByWiErQWnVYqAY1ZHnVufPsYG+znFCNby6XUW0isaE6Hx0g1ma21DP+VeF17Gy P1GJsm52eSbY8crGVAaDG7cpdel4E/vl77fUhUrM2jsLETWyXNagXPW61qDLSsPx R6pswGQ7I1BBaoxkjqm+//o/KTw/sA+A+dSxvJ2n3TTZN9qE6wYl6Rq8njJMfn1/ 1lPO52kZhWBQN2HnLZu9 =T4up -END PGP SIGNATURE-
Re: [Standards] compression attacks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 13-02-14 13:19, Thijs Alkemade wrote: > On 13 feb. 2014, at 01:04, Peter Saint-Andre > wrote: >> While working on draft-sheffer-uta-tls-attacks with Yaron >> Sheffer this week, he pointed out to me that the TIME and BREACH >> attacks might apply to application-layer compression technologies >> such as XEP-0138 for XMPP. I haven't looked into that in detail >> yet, but I figured I'd raise the issue here for discussion. XEP-0138's context is to provide compression when TLS is not available. So it should not be used together with TLS, but the security considerations cover the case where both are used. Maybe better adjust these. > Depends on what data you consider secret. > > Passwords shouldn't be in the compressed stream, per XEP-0170. > Other highly sensitive data can be your contact list and the > contents of your messages. Both of these an attacker should not be > able to trigger retransmissions of, which complicates attacking > them. > > But it's likely the attacker will be able to extract information > like "is jul...@example.lit on your roster?", "did you receive a > message from jul...@example.lit in the past 32 kB?" (the zlib > window size) or "did you receive a message that included the phrase > 'thermonuclear war' in the last 32 kB?". Thijs, can you explain this a bit more? As far as I understand these attacks, they work when both a secret and data supplied by the attacker are in the same compression context. That has to be the same 32 kB compression window (in the case of zlib). I don't see how the attacker can inject data into that, we don't have CSRF issues in XMPP. Or it has to be for contexts like the IOT, where sensors can be manipulated so you can test if the sensor has been sending the same value just before. Winfried -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJTAg6TAAoJEHZ7UH0X6LdcwrAP/1YB1H91bw6RzIrwMXKLCDOl 0SdZE9dfA5WBpoWmd/prclOiTKTIaIQZxVnZZBJhMtySuKePMIrQ11Md+wkcQtYe IMRsOqmSpBkN07BPJdZmEPMGgpiqMHGzhGgxskyakZXETHvv01bx6QFFuZtpnevR bg26eiiSHNuTXpPDZyZSK/OhmeP2eitRawi8edqlH5hjpsn9D0gWrQQb8H1mrzlJ FaM2diFFalAg5vJPOIEDHQnCtcMO5Xb2czB04jhsm/XlC1xQzgQDe1PYooYnq4AQ y5JzpTOreI9pDv3RLZb3mLSp7WaGIw/dCjp9Qtb4KZlUuD4WXaJVdsG9kxH0txgr VDQVBAVe+t9ByWTDqx7HqkltI6v+s0WLTVEy8S7FpswMSSj8vWmUiTbC4kpO04iS IA0UJU6cjkSrCbib19M40OB13xdZKMXybObFttRLKt/OARbcFNowWB6S66rEGECA eb2yOOKV0ir+VGw5aePCJ5LxbLJ2NgsrJShqOTjgXvi9wOLcEZm9jD+jJivLfd5Q czEuVuJTqLmqSQSIRI33tv72KMY8TcNLcXIsN79hncLbysgo6IfpyicXCgZBXLPl AtEAdDMJL2PDwxBZUG/dI3oJ2TnzJujrOq4ZdGOcojQtP1+sCnC88+5eHVz/HDf1 xeleqqxxbBZfQnL6PQr/ =DUFi -END PGP SIGNATURE-
[Standards] [PATCH] XEP-0124: fixing escaping
element. The connection manager SHOULD acknowledge the session termination on the oldest connection with a HTTP 200 OK containing aFixing escapig in XML source of XEP-0124, all elements should be visible now. Thanks to Christian Schudt for reporting. --- extensions/xep-0124.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/extensions/xep-0124.xml b/extensions/xep-0124.xml index 9d3556f..3c6fd3f 100644 --- a/extensions/xep-0124.xml +++ b/extensions/xep-0124.xml @@ -585,7 +585,7 @@ Content-Length: 68 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 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. The payload in the termination request SHOULD NOT need any response from the server. +At any time, the client MAY gracefully terminate the session by sending aelement 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. The payload in the termination request SHOULD NOT need any response from the server. -The connection manager SHOULD respond to this request with an HTTP 200 OK containing an empty element. The connection manager SHOULD acknowledge the session termination on the oldest connection with a HTTP 200 OK containing a element of the type 'terminate'. On all other open connections, the connection manager SHOULD respond with an HTTP 200 OK containing an empty element. +The connection manager SHOULD respond to this request with an HTTP 200 OK containing an empty
