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] 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] 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.

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

[Peter Waher]

Hello Rick

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.

Best regards,
Peter Waher

-Ursprungligt meddelande-
Från: Rick van Rein [mailto:r...@openfortress.nl] 
Skickat: den 26 juni 2015 01:42
Till: XMPP Standards
Ämne: [Standards] XEP-0322: EXI for constrained processing environments

Hello,

I was happy to run into XEP-0322, explaining a path of integration for the
compact XML representation of EXI.

The fully specified path assumes starting off with fullblown XML and then
switching to EXI; this is a scenario that would work when the viewpoint is
saving bandwidth.  Another usecase, where EXI serves the relative simplicity
of a client, is not really dealt with under the usual clarity.

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. 
Although 2.4 gives some ideas and possibilities, its style sounds
informative ("ex." and "e.g.") rather than normative, which means that there
is non real certainty to be drawn.  I am writing to emphasise that this
should IMHO be cleared up before finalising this XEP.

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?  That would be in line
with common XML syntax without adding the burden of XML parsing onto the
(constrained) client.  A few forms could be used, and in all honesty, may be
better standardised as part of EXI than as part of
XEP-0322 because it would occur everywhere EXI is used:

 (illegal 1.0 syntax)
   (illegal 1.0 syntax)
(illegal 1.0 syntax)
(breaks with 1.0 requirements)
 (after  -- upon recognition, respond
with the same string, would otherwise ignored?)

Ref: http://www.w3.org/TR/REC-xml/#sec-pi and
http://www.w3.org/TR/REC-xml/#sec-prolog-dtd

This approach would save from specifying another port, and it would be easy
to send/process in a constrained environment.  Adding NS negotiation might
be possible along the same lines, but would already be more complex.  Still,
not having to build an XML processor to be able to switch to EXI seems like
a really good usecase to me.

I hope this is useful!

Cheers,
 -Rick

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

[Peintner, Daniel (ext)]

Hi Rick

We also believe that EXI is very useful in restricted environments. That said, 
w.r.t. this use case the XEP-0322 might be further improved. We shared already 
our ideas in the following thread [1][2].

> The fully specified path assumes starting off with fullblown XML and
> then switching to EXI; this is a scenario that would work when the
> viewpoint is saving bandwidth.  Another usecase, where EXI serves the
> relative simplicity of a client, is not really dealt with under the
> usual clarity.

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?

> 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.

Thanks,

-- Daniel

[1] http://mail.jabber.org/pipermail/standards/2014-October/029228.html
[2] http://mail.jabber.org/pipermail/standards/2014-October/029254.html

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

[Rick van Rein]

Hello,

I was happy to run into XEP-0322, explaining a path of integration for
the compact XML representation of EXI.

The fully specified path assumes starting off with fullblown XML and
then switching to EXI; this is a scenario that would work when the
viewpoint is saving bandwidth.  Another usecase, where EXI serves the
relative simplicity of a client, is not really dealt with under the
usual clarity.

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. 
Although 2.4 gives some ideas and possibilities, its style sounds
informative ("ex." and "e.g.") rather than normative, which means that
there is non real certainty to be drawn.  I am writing to emphasise that
this should IMHO be cleared up before finalising this XEP.

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?  That would be
in line with common XML syntax without adding the burden of XML parsing
onto the (constrained) client.  A few forms could be used, and in all
honesty, may be better standardised as part of EXI than as part of
XEP-0322 because it would occur everywhere EXI is used:

 (illegal 1.0 syntax)
   (illegal 1.0 syntax)
(illegal 1.0 syntax)
(breaks with 1.0 requirements)
 (after  -- upon recognition, respond
with the same string, would otherwise ignored?)

Ref: http://www.w3.org/TR/REC-xml/#sec-pi and
http://www.w3.org/TR/REC-xml/#sec-prolog-dtd

This approach would save from specifying another port, and it would be
easy to send/process in a constrained environment.  Adding NS
negotiation might be possible along the same lines, but would already be
more complex.  Still, not having to build an XML processor to be able to
switch to EXI seems like a really good usecase to me.

I hope this is useful!

Cheers,
 -Rick