[Standards] UPDATED: XEP-0323 (Internet of Things - Sensor Data)

2015-03-02 Thread XMPP Extensions Editor
Version 0.4 of XEP-0323 (Internet of Things - Sensor Data) has been released.

Abstract: This specification provides the common framework for sensor data 
interchange over XMPP networks.

Changelog: [See revision history] (pw)

Diff: http://xmpp.org/extensions/diff/api/xep/0323/diff/0.3/vs/0.4

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



Re: [Standards] Proposed XMPP Extension: Push

2015-03-02 Thread Daniele Ricci
I was just waiting for this :-)
Thanks to Lance and everyone that contributed to the push XEP. I'll
start experimenting with it in a few days and eventually comment the
XEP itself if I bump into practical problems.


On Mon, Mar 2, 2015 at 10:46 PM, XMPP Extensions Editor edi...@xmpp.org wrote:
 The XMPP Extensions Editor has received a proposal for a new XEP.

 Title: Push

 Abstract: This specification defines a way for an XMPP servers to broadcast 
 information for use in push notifications to mobile and other devices.

 URL: http://xmpp.org/extensions/inbox/push.html

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




-- 
Daniele


[Standards] help! reviews needed in XMPP WG

2015-03-02 Thread Peter Saint-Andre - yet
The IETF's XMPP Working Group is finishing up several documents, and 
reviews from folks here would be very helpful in these late stages!


The documents in question are:

1. XMPP Address Format - the fundamental definition of JIDs, now updated 
to be forward-compatible with newer versions of Unicode (Working Group 
Last Call ends March 12)


http://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/

2. Domain Name Associations (DNA) - a more extensible framework 
defining prooftypes for verifying server identity (Working Group Last 
Call ends March 6)


http://datatracker.ietf.org/doc/draft-ietf-xmpp-dna/

3. PKIX over Secure HTTP - a DNA prooftype in which verification 
material is obtained over HTTPS (Working Group Last Call has ended but 
IETF Last Call has not yet started)


http://datatracker.ietf.org/doc/draft-ietf-xmpp-posh/

There are several other related documents in the DANE and PRECIS working 
groups, but those are a good start.


Thanks for your time!

Peter

--
Peter Saint-Andre
https://andyet.com/


[Standards] Proposed XMPP Extension: Push

2015-03-02 Thread XMPP Extensions Editor
The XMPP Extensions Editor has received a proposal for a new XEP.

Title: Push

Abstract: This specification defines a way for an XMPP servers to broadcast 
information for use in push notifications to mobile and other devices.

URL: http://xmpp.org/extensions/inbox/push.html

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



Re: [Standards] Proposed XMPP Extension: Push

2015-03-02 Thread Christian Ulrich
On Mo, 2015-03-02 at 22:53 +0100, Daniele Ricci wrote:
 I was just waiting for this :-)
 Thanks to Lance and everyone that contributed to the push XEP. I'll
 start experimenting with it in a few days and eventually comment the
 XEP itself if I bump into practical problems.
 
 
 On Mon, Mar 2, 2015 at 10:46 PM, XMPP Extensions Editor edi...@xmpp.org 
 wrote:
  The XMPP Extensions Editor has received a proposal for a new XEP.
 
  Title: Push
 
  Abstract: This specification defines a way for an XMPP servers to broadcast 
  information for use in push notifications to mobile and other devices.
 
  URL: http://xmpp.org/extensions/inbox/push.html
 
  The XMPP Council will decide in the next two weeks whether to accept this 
  proposal as an official XEP.
 
 
 
 

I started implementing an older version of the XEP [1] as an ejabberd
module. It's on github [2]. Currently I'm updating it to the new
version. 

My implementation includes the app server (currently only for Ubuntu
push), so the app server and the XMPP server are one instance. In order
to explain why I chose to do this I have to expand the scope a little.
In case of Apple's, Google's and Microsoft's push services the app
server needs secret authorization data (certificate or secret key) to
send push notifications. So all client app instances need to register
with a central app server. In Ubuntu's push service [3] it's different.
The app server only needs the client's token and app_id for
authorization with ubuntu's server. I'd like to keep decentrality alive
where possible and in case of Ubuntu Push it is (at least in the
non-proprietary part). So I'd like to enable an arbitrary XMPP server
to send notifications to Ubuntu's push service.

It's not obligatory to merge app server and XMPP server to achieve this
but it lowers the administration effort (especially for ejabberd
clusters) and increases efficiency, if the app chooses its home server
as app server.

Regarding my requirements there are two little problems with the
current draft:

- apps that need to register with one central app server will know its
  app server's hostname, but for an app supporting arbitrary app
  servers there's no way of dicovering a hostname. So it should be able
  to ask its xmpp server for a hostname serving a specific push service
  type. Maybe something like this (up means ubuntu push):

  iq type='get'
  from='ro...@montague.net/orchard'
  to='montague.net'
  id='items3'
query xmlns='http://jabber.org/protocol/disco#items'
   node='urn:xmpp:push:0#up'/
  /iq

  iq type='result'
  from='montague.net'
  to='ro...@montague.net/orchard'
  id='items3'
query xmlns='http://jabber.org/protocol/disco#items'
   node='urn:xmpp:push:0#up'
  item jid='push-up.montague.net'/
/query
  /iq

- arbitrary app servers require a unified registration process. The 
  draft suggests to use XEP-0077, that's ok I think, but then we need to
  define what data the client has to provide. My suggestion for XEP-0077
  registration fields:

  * token (mandatory)
  * app-id (optional, relevant for Ubuntu push)
  * silent-push (optional, relevant for iOS and Android (I think))

  I think an example for registration should be in the XEP.

Moreover I'm missing an example for configuring the XMPP server part
regarding privacy. In [1] options like 'include-senders' and
'include-bodies' were mentioned. How about defining some
publish-options (XEP-0060 ยง7.1.5) which can be included in the enable
iq-stanza. The XMPP server will consider these when publishing an item
and doesn't need to include them into the pubsub stanza. Like this:

iq type='set' id='x43'
  enable xmlns='urn:xmpp:push:0' jid='push-up.montague.net'
  node='yxs32uqsflafdk3iuqo'
x xmlns='jabber:x:data'
  field var='FORM_TYPE'
valuehttp://jabber.org/protocol/pubsub#publish-options/value
  /field
  field var='include-bodies'value0value/field
  field var='include-senders'value0value/field
  field var='include-message-count'value1value/field
/x
  /enable
/iq

Christian

P.S. thank you Lance and the others involved in writing the draft.

[1]
https://github.com/legastero/customxeps/blob/gh-pages/extensions/push.md
[2]
https://github.com/royneary/ejabberd/blob/master/src/mod_push.erl
[3]
https://developer.ubuntu.com/en/apps/platform/guides/push-notifications-client-guide/