[Standards] MAM IDs

2014-02-17 Thread Kevin Smith
In MAM, stanzas stored get stamped with a MAM ID by the entity that stored them, and entities receiving them then receive this. So a general question - are these useful? Are clients going to ignore them and just request all history since they last requested it anyway? /K

Re: [Standards] MAM IDs

2014-02-17 Thread Spencer MacDonald
If you mean the archived element: archived by='jul...@capulet.lit’ id=‘28482-98726-73623' / I personally have not found any need for it. Regards Spencer On 17 Feb 2014, at 10:26, Kevin Smith ke...@kismith.co.uk wrote: In MAM, stanzas stored get stamped with a MAM ID by the entity that

Re: [Standards] MAM IDs

2014-02-17 Thread Kevin Smith
On Mon, Feb 17, 2014 at 10:42 AM, Spencer MacDonald spencer.macdonald.ot...@gmail.com wrote: If you mean the archived element: archived by='jul...@capulet.lit' id='28482-98726-73623' / I personally have not found any need for it. Thanks. /K

Re: [Standards] MAM IDs

2014-02-17 Thread Kevin Smith
On Mon, Feb 17, 2014 at 10:26 AM, Kevin Smith ke...@kismith.co.uk wrote: In MAM, stanzas stored get stamped with a MAM ID by the entity that stored them, and entities receiving them then receive this. So a general question - are these useful? Are clients going to ignore them and just request

Re: [Standards] MAM IDs

2014-02-17 Thread Thijs Alkemade
On 17 feb. 2014, at 11:26, Kevin Smith ke...@kismith.co.uk wrote: In MAM, stanzas stored get stamped with a MAM ID by the entity that stored them, and entities receiving them then receive this. So a general question - are these useful? Are clients going to ignore them and just request all

Re: [Standards] MAM IDs

2014-02-17 Thread Spencer MacDonald
I just used XEP-0202 to get around the wrong time issue. I have only been to dealing with storing messages that people type and send, so the chance of multiple messages in (very) quick succession wasn’t an issue for me. Regards Spencer On 17 Feb 2014, at 10:55, Thijs Alkemade

Re: [Standards] MAM IDs

2014-02-17 Thread Kevin Smith
On Mon, Feb 17, 2014 at 10:55 AM, Thijs Alkemade th...@xnyhps.nl wrote: On 17 feb. 2014, at 11:26, Kevin Smith ke...@kismith.co.uk wrote: In MAM, stanzas stored get stamped with a MAM ID by the entity that stored them, and entities receiving them then receive this. So a general question -

Re: [Standards] BOSH patches, hopefully the last before final

2014-02-17 Thread Winfried Tilanus
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

Re: [Standards] MAM IDs

2014-02-17 Thread Kevin Smith
On Mon, Feb 17, 2014 at 11:42 AM, Thijs Alkemade th...@xnyhps.nl wrote: On 17 feb. 2014, at 12:02, Kevin Smith ke...@kismith.co.uk wrote: On Mon, Feb 17, 2014 at 10:55 AM, Thijs Alkemade th...@xnyhps.nl wrote: On 17 feb. 2014, at 11:26, Kevin Smith ke...@kismith.co.uk wrote: In MAM,

Re: [Standards] compression attacks

2014-02-17 Thread Winfried Tilanus
-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 stpe...@stpeter.im 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

Re: [Standards] compression attacks

2014-02-17 Thread Winfried Tilanus
-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

Re: [Standards] compression attacks

2014-02-17 Thread Thijs Alkemade
On 17 feb. 2014, at 14:29, Winfried Tilanus winfr...@tilanus.com wrote: Signed PGP part On 13-02-14 13:19, Thijs Alkemade wrote: On 13 feb. 2014, at 01:04, Peter Saint-Andre stpe...@stpeter.im wrote: While working on draft-sheffer-uta-tls-attacks with Yaron Sheffer this week, he

[Standards] SMS/Email Forwarding of Messages

2014-02-17 Thread Spencer MacDonald
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

2014-02-17 Thread Steffen Larsen
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

Re: [Standards] SMS/Email Forwarding of Messages

2014-02-17 Thread Daniele Ricci
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

Re: [Standards] SMS/Email Forwarding of Messages

2014-02-17 Thread Spencer MacDonald
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

Re: [Standards] BOSH patches, hopefully the last before final

2014-02-17 Thread Christian Schudt
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

Re: [Standards] BOSH patches, hopefully the last before final

2014-02-17 Thread Winfried Tilanus
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,

Re: [Standards] BOSH patches, hopefully the last before final

2014-02-17 Thread Christian Schudt
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':

Re: [Standards] BOSH patches, hopefully the last before final

2014-02-17 Thread Winfried Tilanus
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

Re: [Standards] SMS/Email Forwarding of Messages

2014-02-17 Thread Steffen Larsen
Yes exactly. Support of data forms etc. would be nice for setup and query. /Steffen On 17 Feb 2014, at 19:10, Simon Tennant si...@buddycloud.com wrote: IMHO this is really something that should be in the push spec. configure with numbers/email addresses push events to pusher component

[Standards] IoT device Discovery XEP

2014-02-17 Thread Peter Waher
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

Re: [Standards] [IOT] Comments on XEP0323

2014-02-17 Thread Peter Waher
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