Re: [Standards] XEP-323 vs XEP-325

[Joakim Eriksson]

Hi Peter,

Yes, there might be reasons to be more specific when doing control, but
for making implementations as easy as possible it would be very good if
the types where the same and as few as possible.

I would go for something like:

int
double (or float)
boolean
datetime
string

both for querying (323) and for control (325).

Then of course when having a desired room temperature in C that is a
double the code that checks that the values are correct will need to
check that this room temperature is between +5.0 and +30.0 or so. Is
there also ways to express these "limits" too? Or is there a need for
the controlling entity to know what it is doing by knowing that this is
in fact a room temperature and not a oven temperature.

Best regards
-- Joakim Eriksson, SICS


Peter Waher skrev 2014-01-14 15:38:

Hello Joakim

Thank you for your mail. I'll try to respond to your question:

Hi,

I am working on testing out the new XEP's for Internet of Things and
Sensor networks by mapping a Heat pump connected over serial into these
XEP's in a embedded PC. I have already made some registers readable over

XEP-323 so that seems good, but why is there such a difference between
reading out values and setting values?

Assuming that there is a desired room temperature would be read it would
be something like:

...

   

...

and to set would be (XEP-325):

...

 ...

I can understand omitting unit and momentary but why not keeping the
same tag-names (e.g.  or  in both)?

The reason here is because the control extension (XEP-0325) is more
detailed when it comes to format and validation. For instance, it
contains 3 numeric types: int, long and double. Handling integers is
easier in control applications, but not suitable for all control
parameters, as is the case in your example. The integer types are meant
to be used for say simple analog outputs and the like. The sensor data
extension (XEP-0323) is less interested in formats and validation, and
uses only one element to convey all numeric field values. It also
transmits meta data about the value not applicable in the control case.

I’ve been unable to update the site with the most recent versions of the
extensions you mention. I’ve attached them instead. There are some minor
changes documented in the revision histories of each one.

Best regards,

Peter Waher

Re: [Standards] Fwd: Minutes 2013-11-20

[Ben Langfeld]

Thanks Peter! :)


On 14 January 2014 15:53, Peter Saint-Andre  wrote:

> That's my fault. I hope the yet-to-be-formed editorial team will not
> miss such things.
>
> I'll take care of that now.
>
> On 1/14/14 7:29 AM, Ben Langfeld wrote:
> > There has been an update to the CPA spec in the meantime. The latest
> > version is available
> > at https://github.com/rayo/xmpp/blob/rayo/extensions/inbox/rayo-cpa.xml
> >
> >
> > On 13 January 2014 13:43, Ben Langfeld  > > wrote:
> >
> > It's now been rather a long time and these specs have not been
> > published, though others proposed in the meantime have. As far as I
> > understand, there's nothing blocking their publication (though
> > please correct me if I've missed something), so could they please be
> > published?
> >
> >
> > On 11 December 2013 13:17, Kevin Smith  > > wrote:
> >
> > On Wed, Dec 11, 2013 at 3:07 PM, Ben Langfeld  > > wrote:
> > > It's now three weeks since this meeting. I havn't seen a vote
> > from Tobias on
> > > rayo-fax, or either of rayo-fax and rayo-cpa being published.
> > >
> > > Is there anything blocking these that I can help resolve?
> >
> > Tobias okayed these on 27th November.
> >
> > /K
> >
>

[Standards] NEW: XEP-0341 (Rayo CPA)

[XMPP Extensions Editor]

Version 0.1 of XEP-0341 (Rayo CPA) has been released.

Abstract: This specification defines an extension to the Rayo protocol 
(XEP-0327) to provide provision for performing Call Progress Analysis on a call 
under the control of a Rayo client.

Changelog: Initial published version approved by the XMPP Council. (psa)

Diff: N/A

URL: http://xmpp.org/extensions/xep-0341.html

[Standards] NEW: XEP-0342 (Rayo Fax)

[XMPP Extensions Editor]

Version 0.1 of XEP-0342 (Rayo Fax) has been released.

Abstract: This specification defines an extension to the Rayo protocol 
(XEP-0327) to provide provision for sending and receiving faxcimilies via a 
call under the control of a Rayo client.

Changelog: Initial published version approved by the XMPP Council. (psa)

Diff: N/A

URL: http://xmpp.org/extensions/xep-0342.html

Re: [Standards] Fwd: Minutes 2013-11-20

[Peter Saint-Andre]

That's my fault. I hope the yet-to-be-formed editorial team will not
miss such things.

I'll take care of that now.

On 1/14/14 7:29 AM, Ben Langfeld wrote:
> There has been an update to the CPA spec in the meantime. The latest
> version is available
> at https://github.com/rayo/xmpp/blob/rayo/extensions/inbox/rayo-cpa.xml
> 
> 
> On 13 January 2014 13:43, Ben Langfeld  > wrote:
> 
> It's now been rather a long time and these specs have not been
> published, though others proposed in the meantime have. As far as I
> understand, there's nothing blocking their publication (though
> please correct me if I've missed something), so could they please be
> published?
> 
> 
> On 11 December 2013 13:17, Kevin Smith  > wrote:
> 
> On Wed, Dec 11, 2013 at 3:07 PM, Ben Langfeld  > wrote:
> > It's now three weeks since this meeting. I havn't seen a vote
> from Tobias on
> > rayo-fax, or either of rayo-fax and rayo-cpa being published.
> >
> > Is there anything blocking these that I can help resolve?
> 
> Tobias okayed these on 27th November.
> 
> /K
> 

Re: [Standards] PS: XEP-323 vs XEP-325

[Joachim Lindborg]

Jag kollar på Git skall nog lösa det
Den 14 jan 2014 17:16 skrev "Peter Waher" :

>  PS:
>
>
>
> While I figure out how to update the extensions on the xmpp.org site, the
> latest revisions can be found here:
>
>
> http://htmlpreview.github.com/?https://github.com/joachimlindborg/XMPP-IoT/blob/master/sensor-data.html
>
>
> http://htmlpreview.github.com/?https://github.com/joachimlindborg/XMPP-IoT/blob/master/sensor-network-Control.html
>
>
>
> Links to all can also be found at the bottom of this page:
>
> https://github.com/joachimlindborg/XMPP-IoT
>
>
>
> Best regards,
>
> Peter Waher
>
>
>
>
>
> *From:* Peter Waher
> *Sent:* den 14 januari 2014 11:38
> *To:* standards@xmpp.org
> *Subject:* RE: [Standards] XEP-323 vs XEP-325
>
>
>
> Hello Joakim
>
>
>
> Thank you for your mail. I'll try to respond to your question:
>
>
>
> Hi,
>
>
>
> I am working on testing out the new XEP's for Internet of Things and
> Sensor networks by mapping a Heat pump connected over serial into these
> XEP's in a embedded PC. I have already made some registers readable over
>
> XEP-323 so that seems good, but why is there such a difference between
> reading out values and setting values?
>
>
>
> Assuming that there is a desired room temperature would be read it would
> be something like:
>
> ...
>
>   
> unit='°C'/>
>
> ...
>
>
>
> and to set would be (XEP-325):
>
>
>
> ...
>
>  ...
>
>
>
>
>
> I can understand omitting unit and momentary but why not keeping the same
> tag-names (e.g.  or  in both)?
>
>
>
> The reason here is because the control extension (XEP-0325) is more
> detailed when it comes to format and validation. For instance, it contains
> 3 numeric types: int, long and double. Handling integers is easier in
> control applications, but not suitable for all control parameters, as is
> the case in your example. The integer types are meant to be used for say
> simple analog outputs and the like. The sensor data extension (XEP-0323) is
> less interested in formats and validation, and uses only one element to
> convey all numeric field values. It also transmits meta data about the
> value not applicable in the control case.
>
>
>
> I’ve been unable to update the site with the most recent versions of the
> extensions you mention. I’ve attached them instead. There are some minor
> changes documented in the revision histories of each one.
>
>
>
> Best regards,
>
> Peter Waher
>

[Standards] PS: XEP-323 vs XEP-325

[Peter Waher]

PS:

While I figure out how to update the extensions on the xmpp.org site, the 
latest revisions can be found here:

http://htmlpreview.github.com/?https://github.com/joachimlindborg/XMPP-IoT/blob/master/sensor-data.html
http://htmlpreview.github.com/?https://github.com/joachimlindborg/XMPP-IoT/blob/master/sensor-network-Control.html

Links to all can also be found at the bottom of this page:
https://github.com/joachimlindborg/XMPP-IoT

Best regards,
Peter Waher


From: Peter Waher
Sent: den 14 januari 2014 11:38
To: standards@xmpp.org
Subject: RE: [Standards] XEP-323 vs XEP-325


Hello Joakim



Thank you for your mail. I'll try to respond to your question:



Hi,



I am working on testing out the new XEP's for Internet of Things and Sensor 
networks by mapping a Heat pump connected over serial into these XEP's in a 
embedded PC. I have already made some registers readable over

XEP-323 so that seems good, but why is there such a difference between reading 
out values and setting values?



Assuming that there is a desired room temperature would be read it would be 
something like:

...

  

...



and to set would be (XEP-325):



...

 ...





I can understand omitting unit and momentary but why not keeping the same 
tag-names (e.g.  or  in both)?



The reason here is because the control extension (XEP-0325) is more detailed 
when it comes to format and validation. For instance, it contains 3 numeric 
types: int, long and double. Handling integers is easier in control 
applications, but not suitable for all control parameters, as is the case in 
your example. The integer types are meant to be used for say simple analog 
outputs and the like. The sensor data extension (XEP-0323) is less interested 
in formats and validation, and uses only one element to convey all numeric 
field values. It also transmits meta data about the value not applicable in the 
control case.



I've been unable to update the site with the most recent versions of the 
extensions you mention. I've attached them instead. There are some minor 
changes documented in the revision histories of each one.



Best regards,

Peter Waher

Re: [Standards] Fwd: Minutes 2013-11-20

[Ben Langfeld]

There has been an update to the CPA spec in the meantime. The latest
version is available at
https://github.com/rayo/xmpp/blob/rayo/extensions/inbox/rayo-cpa.xml


On 13 January 2014 13:43, Ben Langfeld  wrote:

> It's now been rather a long time and these specs have not been published,
> though others proposed in the meantime have. As far as I understand,
> there's nothing blocking their publication (though please correct me if
> I've missed something), so could they please be published?
>
>
> On 11 December 2013 13:17, Kevin Smith  wrote:
>
>> On Wed, Dec 11, 2013 at 3:07 PM, Ben Langfeld  wrote:
>> > It's now three weeks since this meeting. I havn't seen a vote from
>> Tobias on
>> > rayo-fax, or either of rayo-fax and rayo-cpa being published.
>> >
>> > Is there anything blocking these that I can help resolve?
>>
>> Tobias okayed these on 27th November.
>>
>> /K
>>
>
>

[Standards] XEP-323 vs XEP-325

[Joakim Eriksson]

Hi,

I am working on testing out the new XEP's for Internet of Things and
Sensor networks by mapping a Heat pump connected over serial into these
XEP's in a embedded PC. I have already made some registers readable over 
XEP-323 so that seems good, but why is there such a difference

between reading out values and setting values?

Assuming that there is a desired room temperature would be read it would
be something like:
...
 unit='°C'/>

...

and to set would be (XEP-325):

...

...


I can understand omitting unit and momentary but why not keeping the 
same tag-names (e.g.  or  in both)?



Best regards,
-- Joakim Eriksson, SICS

Re: [Standards] OneM2M writes about the XMPP IoT extensions

[Steffen Larsen]

Interesting stuff..

/Steffen

On 13 Jan 2014, at 23:41, Peter Waher  wrote:

> Hello
>  
> Look at what OneM2M (& Cisco) writes about the XMPP IoT solution.
> ftp://ftp.onem2m.org/Work%20Programme/WI0008/oneM2M-TR-0009-Protocol_Analysis-V0_4_0.DOC
>  
> Best regards,
> Peter Waher



smime.p7s
Description: S/MIME cryptographic signature

[Standards] Proposed XMPP Extension: Two-factor user authentication with a shared secret

[XMPP Extensions Editor]

The XMPP Extensions Editor has received a proposal for a new XEP.

Title: Two-factor user authentication with a shared secret

Abstract: This document specifies a two-factor authentication mechanism to 
check if a XMPP account exists and if it is trying to use or access services or 
resources of certain device, application or service. Authentication mechanism 
is based on transmitting a password using Ad-Hoc Commands. Password is 
calculated from shared secret. 

URL: http://xmpp.org/extensions/inbox/user-auth.html

The XMPP Council will decide in the next two weeks whether to accept this 
proposal as an official XEP.