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 2
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 norm
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 "knowi
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
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 connectio
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': identi
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
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 'f
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
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
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
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
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 TIM
-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 c
-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 appl
Fixing 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 100
On Mon, Feb 17, 2014 at 11:42 AM, Thijs Alkemade wrote:
>
> On 17 feb. 2014, at 12:02, Kevin Smith wrote:
>
>> On Mon, Feb 17, 2014 at 10:55 AM, Thijs Alkemade wrote:
>>>
>>> On 17 feb. 2014, at 11:26, Kevin Smith wrote:
>>>
In MAM, stanzas stored get stamped with a MAM ID by the entity th
On 17 feb. 2014, at 12:02, Kevin Smith wrote:
> On Mon, Feb 17, 2014 at 10:55 AM, Thijs Alkemade wrote:
>>
>> On 17 feb. 2014, at 11:26, Kevin Smith wrote:
>>
>>> In MAM, stanzas stored get stamped with a MAM ID by the entity that
>>> stored them, and entities receiving them then receive thi
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' -- Th
On Mon, Feb 17, 2014 at 10:55 AM, Thijs Alkemade wrote:
>
> On 17 feb. 2014, at 11:26, Kevin Smith 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 cli
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 wrote:
>
>
On 17 feb. 2014, at 11:26, Kevin Smith 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 history since t
On Mon, Feb 17, 2014 at 10:42 AM, Spencer MacDonald
wrote:
> If you mean the archived element:
>
>
>
> I personally have not found any need for it.
Thanks.
/K
On Mon, Feb 17, 2014 at 10:26 AM, Kevin Smith 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 history sin
If you mean the archived element:
I personally have not found any need for it.
Regards
Spencer
On 17 Feb 2014, at 10:26, Kevin Smith 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
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
26 matches
Mail list logo
