This specification was pending acceptance by the council. I have taken
the decision to block its publication for now, until some further
discussion has taken place.

Any technical points made below are based on my current understanding,
someone correct me if I am misunderstanding anything.

Although the title and text reference sensors heavily, the document is
primarily about a way to delegate trust to a third-party (which the
document calls the 'provisioning server', but I shall simply call the
authority).

For any given action that an entity is requested to perform by an
actor, the entity may present the authority with the actor's
credentials and the action they wish to perform. The authority can
either allow or deny this action. The actor's credentials can be
anything from a JID or IP address to a physical location (for example
if the actor is a physical user).

As far as I can tell, this one protocol flow covers most of the cases
described in the spec (even though it currently uses a slightly
different protocol for each separate case).

I believe the spec would benefit from being more general. We don't
currently have a protocol for this in XMPP. Sensors need it, other
people need it, and it would receive more widespread usage and review
if it were not sensor-specific.

This same thought applies to many of the other "sensor" XEPs that are
really not about sensors. EXI for example - no mention of it belongs
here. I suggest that the ideal solution would be a single
informational XEP that describes how sensor networks can employ XMPP -
which XEPs they should use, and how. The glossary and table of XEPs
from each of these sensor documents would then live there, and there
only.

In general the XSF is good at protocols, few of us know anything of
the world of sensors or any other niche that XMPP finds its way into.
I think it would be best to keep working on good reusable protocol
building-blocks, and not get distracted too much by working on
single-use protocols and specifications.

I'm happy to help with transformation of this spec, or creation of a
new one to meet these criteria.

Regards,
Matthew

Reply via email to