Hi Peter,
On 03 Apr 2014, at 14:03, Peter Waher peter.wa...@clayster.com wrote:
Hello Edwin Co.
You seem to confuse Historical with Deprecated. Although the XEP is
historical, the status is active. Furthermore, all servers I have used so
far support XEP-0114: this is a core feature of
On 7 April 2014 08:27, Steffen Larsen zoo...@gmail.com wrote:
I completely agree about making XEP-0114 (external components) more
suitable and secure like any other S2S scenario. Lifting it to a XMPP
version 1.0 stage would be great, but would also break a lot of
implementations.
I'm not
The alternative is we just say Components are privately-authenticated S2S
connections, and invoke BiDi and SASL auth and make it happen. This is
functionally equivalent, but differs in that components are no longer
special in any way (aside from near-mandatory support for XEP-0288), aren't
On 7 April 2014 10:04, Philipp Hancke fi...@goodadvice.pages.de wrote:
The alternative is we just say Components are privately-authenticated S2S
connections, and invoke BiDi and SASL auth and make it happen. This is
functionally equivalent, but differs in that components are no longer
special
Hello Edwin Co.
You seem to confuse Historical with Deprecated. Although the XEP is
historical, the status is active. Furthermore, all servers I have used so far
support XEP-0114: this is a core feature of most implementations.
Actually, I do not. I am aware of the difference. What
Example: Consider 100'000 devices connecting to an XMPP server they've found
somehow, and then need to find a Thing Registry to register themselves. One
might be preconfigured, but I want to include the case when one is not.
100'000 devices cannot start looping through all possible JIDs and
Hello Philipp
Thanks for your insightful input. My response to the main item:
section 3.4:
I don't think IBR should be recommended anymore.
IoT requires automatic account creation. However, I agree it must also be
secure, from the point of view of the server administrator, especially if
Hello Lance
Thanks for taking the time to read the proposal and your input. My responses to
your concerns below:
Example: Consider 100'000 devices connecting to an XMPP server they've found
somehow, and then need to find a Thing Registry to register themselves. One
might be preconfigured,
Hi Peter et. al.
Just a quick one about XE-0114 (external components): Most xmpp developers are
putting their business logic there and its dead simple and every server out
there supports it. + since its a protocol and can be run as client or server it
makes it very portable and robust. :-)
On 02/04/14 16:14, Peter Waher wrote:
Hello Philipp
Thanks for your insightful input. My response to the main item:
section 3.4:
I don't think IBR should be recommended anymore.
IoT requires automatic account creation. However, I agree it must also be
secure, from the point of view of the
Hi Peter,
section 3.3.1 describes how to find an xmpp servers. The methods described
there aren't limited to iot (at least the dhcp one), so it might be a good idea
to split them off. Not sure how useful that is however.
Ok. Can we break this out at a later stage? I agree it makes sense to
On Thu, Mar 27, 2014 at 2:31 PM, Philipp Hancke
fi...@goodadvice.pages.de wrote:
Am 13.03.2014 17:26, schrieb XMPP Extensions Editor:
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Internet of Things - Discovery
Abstract: This specification describes an
Hello Philipp
Thanks a lot for the input, and taking the time to read the proposal. I'll try
to address your concerns one at a time:
section 3.3.1 describes how to find an xmpp servers. The methods described
there aren't limited to iot (at least the dhcp one), so it might be a good
idea to
From: Ivan Vučica [mailto:i...@vucica.net]
Sent: den 27 mars 2014 19:38
To: XMPP Standards
Subject: Re: [Standards] Proposed XMPP Extension: Internet of Things - Discovery
Re: section 3.3.x
Doesn't more choices for discovery mean servers and clients need to implement
all choices? I'd go
Hello Kevin
Thanks for taking the time to read the proposal, and come with input. I'll
address your concerns one at a time:
section 3.3.1 describes how to find an xmpp servers. The methods
described there aren't limited to iot (at least the dhcp one), so it
might be a good idea to split
Am 13.03.2014 17:26, schrieb XMPP Extensions Editor:
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Internet of Things - Discovery
Abstract: This specification describes an architecture based on the XMPP
protocol whereby Things can be installed and safely discovered
Re: section 3.3.x
Doesn't more choices for discovery mean servers and clients need to
implement all choices? I'd go with the mDNS/DNSSD method only as it is
already widely used for other discovery uses. DHCP may not be easily
configurable by the XMPP server administrator.
sent from phone
On Mar
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Internet of Things - Discovery
Abstract: This specification describes an architecture based on the XMPP
protocol whereby Things can be installed and safely discovered by their owners
and connected into networks of Things.
18 matches
Mail list logo
