Re: [Standards] XEP-0322: EXI for constrained processing environments

[Peter Waher]

Hello Dave.

 

> On 30 June 2015 at 18:40, Peter Waher <  
> peter.wa...@clayster.com> wrote:

>Thanks for your input. For small devices, that do not wish to (or cannot)
>perform a dynamic handshake, there's the concept of quick configurations
>(§2.6). With a quick configuration ID, the entire setup is predefined. It
>can be defined, either in-band using a normal handshake, as described
>earlier, perhaps by a more powerful device, or out-of-band, by manual
>configuration of the server.

> 

>There is no §2.6 - did you mean §2.2.6?

 

Correct. Thanks for spotting.

 

> Also this negotiation of quick configuration happens in XML prior to the EXI 
> "switch" doesn't it?

 

The document specifies one way to generate this quick configuration, in-band. 
It does not limit the ways such quick-configurations are handled by the server. 
It is understood that these quick configurations are managed by the server, and 
hence can be administrated on the server (without explicitly stating so). We 
have discussed this internally, that it can be used to preinstall 
configurations on the server. But, since it is out-of-band and server-specific, 
we didn’t include this in the XEP.

 

Note that we included a configurationLocation attribute (§3.11) to be able to 
automate preconfiguration of what schemas to include, where the devices are not 
capable of performing an XML handshake and configuration negotiation. But since 
these preconfiguration files/schemas might depend on EXI library being used, 
we’ve stated that it is server-specific.

 

> Rick's problem is that he wants to have no XML processing.

 

These preconfigurations can be accessed by the alternate binding also. (§2.4, 
step 13, and §3.11).

 

> On that basis, I'm thinking a distinct port is the most sensible, which would 
> mean a different SRV name. It may be possible to combine these ports into a 
> single autodetecting port, but I'd rather leave that experiment outside a 
> spec for now.

 

The document defines a DNS SRV record for the alternative EXI binding in §2.4.1.

 

Best regards,

Peter

Re: [Standards] Request HTTP upload slots over XMPP

[Peter Waher]

Hello Edwin

 

> So, you're suggesting an in-band transfer mechanism for out-of-band data 
> transfers?  That sounds a bit wasteful to me. 

 

XEP-0332 allows the client and server to use different methods based on your 
requirements and capabilites. It supports both chunked transfer, as well as 
file transfer, in-band byte streams and Jingle. If out-of-band transfer is 
necessary for bandwidth requirements, I suggest the Jingle transfer method. 

 

An in-band method, or a properly negotiated P2P method out-of-band, would 
handle the case where the server resides behind a firewall, like the case where 
you have your own personal credit-card sized server (RaspberryPi2, Cubieboard, 
Tonido, etc.) at home, behind the firewall. You can still access content over 
XMPP, and in web clients that understand the proposed httpx URI scheme.

 

Best regards,

Peter Waher

 

 

Från: Edwin Mons [mailto:j...@edwinm.ik.nu] 
Skickat: den 1 juli 2015 03:40
Till: XMPP Standards
Ämne: Re: [Standards] Request HTTP upload slots over XMPP

 

On 30/06/15 19:45, Peter Waher wrote:

Hello Daniel

 

You could use XEP-0332, HTTP over XMPP, to do this. To upload content, simply 
perform a PUT, and you can then retrieve it using a normal GET.

http://xmpp.org/extensions/xep-0332.html#PUT

 

If content is small, you can do the transfer in the same request. Otherwise, 
chunked service can be used, or integration with sipub, ibb and/or jingle as 
well, depending on capabilities.


So, you're suggesting an in-band transfer mechanism for out-of-band data 
transfers?  That sounds a bit wasteful to me.  By the way, how are updates to 
332 progressing?

Edwin

Re: [Standards] XEP-0322: EXI for constrained processing environments

[Rick van Rein]

Hi Daniel,

Thanks for the references; I had indeed missed discussion.  I also noted that 
the Last Call seems to have been closed.

> I think you gave yourself the answer in the latter part of your mail 
> mentioning that with a dedicated port one can start using EXI right-away.
> Is this approach not working for you?

This means that the constrained elements could only communicate through their 
"home server", for which a port was hard-configured, right?  They could not 
perform SRV lookups for another domain and communicate with that.  This might 
be a reasonable assumption, but it is good to be aware of such limitations.

>> As for the EXI cookie, is it an idea to use a processing instruction
>> and/or XML declaration that would be sent to the server?
>
> Please correct me if I am wrong but I think this has nothing to do with 
> processing instructions. The EXI Cookie is an optional part of the EXI 
> stream. In fact it is nothing more than a 4 byte "magic cookie" that serves 
> to identify whether a stream is XML or EXI.

Yes, you are right.  I was not aware that $EXI was part of the EXI 
specification, and assumed it was invented by the XEP.

Cheers,
 -Rick

Re: [Standards] XEP-0322: EXI for constrained processing environments

[Rick van Rein]

Hi Dave,

> It's remarkable how small XML processors can be these days, but in any
> case, have you considered how encryption fits into this, or were you
> assuming a trusted network?

Have not (as is common with XMPP).  I can imagine that there would be
applications of constrained environments, possibly on trusted networks or
using ZigBee processors with hardware support for encryption.  In general,
I put up the desire of not wanting to get to EXI through fullblown XML to
at least not block such applications.

-Rick

Re: [Standards] Push and headline messages

[Mickaël Rémond]

Hello,

On 1 Jul 2015, at 11:42, Dave Cridland wrote:

On 1 July 2015 at 09:20, Mickaël Rémond  
wrote:


I think it implies that they should not be pushed as well. Otherwise, 
you
may receive a push notification for a message you will never be able 
to

receive if you reconnect.

Am I wrong ?
Do you think it could be useful to clarify the push XEP on that point 
?


I don't think you're wrong in your interpretation, but it's not clear 
this
is a desirable outcome. Things that are time-critical information seem 
to
be exactly the things we need to ensure can be received via mobile 
push.


Let me describe further the example that brought me to this conclusion. 
We are dealing with Pubsub based sketching, geoloc, whiteboard 
application that send update on quite a fast rate (headline messages).


Possibly we need another concept here, but I bringing the point that in 
the current state, it does not seem desirable to trigger tens / hundreds 
of push notifications for those headline messages.


That and the fact that when a client receive a push, the default 
behaviour is probably to reconnect to retrieve message. In that case a 
push is received, but no offline message will be delivered.


--
Mickaël Rémond
ProcessOne - Boxcar
Founder and CEO

Re: [Standards] Push and headline messages

[Dave Cridland]

On 1 July 2015 at 09:20, Mickaël Rémond  wrote:

> Hello,
>
> XEP-0160 clarify the best practice for offline message and states for
> offline messages that headline message should not be stored for offline
> delivery:
>
>  headline -- Messages with a 'type' attribute whose value is "headline"
>> SHOULD NOT be stored offline, since such messages are usually
>> time-sensitive.
>>
>
> I think it implies that they should not be pushed as well. Otherwise, you
> may receive a push notification for a message you will never be able to
> receive if you reconnect.
>
> Am I wrong ?
> Do you think it could be useful to clarify the push XEP on that point ?
>

I don't think you're wrong in your interpretation, but it's not clear this
is a desirable outcome. Things that are time-critical information seem to
be exactly the things we need to ensure can be received via mobile push.

Dave.

[Standards] Push and headline messages

[Mickaël Rémond]

Hello,

XEP-0160 clarify the best practice for offline message and states for 
offline messages that headline message should not be stored for offline 
delivery:


headline -- Messages with a 'type' attribute whose value is "headline" 
SHOULD NOT be stored offline, since such messages are usually 
time-sensitive.


I think it implies that they should not be pushed as well. Otherwise, 
you may receive a push notification for a message you will never be able 
to receive if you reconnect.


Am I wrong ?
Do you think it could be useful to clarify the push XEP on that point ?

Thanks !

--
Mickaël Rémond
ProcessOne - Boxcar
Founder and CEO

Re: [Standards] XEP-0322: EXI for constrained processing environments

[Dave Cridland]

On 26 June 2015 at 05:41, Rick van Rein  wrote:

> I am thinking of constrained processing environments, such as clients on
> microcontrollers.  These may want to use EXI to avoid having to deal
> with the full XML notation, and they would most certainly not be
> serviced if they have to go through an initial handshake based on XML.
>

It's remarkable how small XML processors can be these days, but in any
case, have you considered how encryption fits into this, or were you
assuming a trusted network?

Dave.

Re: [Standards] XEP-0322: EXI for constrained processing environments

[Dave Cridland]

On 30 June 2015 at 18:40, Peter Waher  wrote:

> Thanks for your input. For small devices, that do not wish to (or cannot)
> perform a dynamic handshake, there's the concept of quick configurations
> (§2.6). With a quick configuration ID, the entire setup is predefined. It
> can be defined, either in-band using a normal handshake, as described
> earlier, perhaps by a more powerful device, or out-of-band, by manual
> configuration of the server.
>

There is no §2.6 - did you mean §2.2.6?

Also this negotiation of quick configuration happens in XML prior to the
EXI "switch" doesn't it? Rick's problem is that he wants to have no XML
processing.

On that basis, I'm thinking a distinct port is the most sensible, which
would mean a different SRV name. It may be possible to combine these ports
into a single autodetecting port, but I'd rather leave that experiment
outside a spec for now.

Dave.