Hello Teemu.
Thanks for your input. I'll respond to your comments and suggestions, one at a time:
Hi Peter, here are couple of suggestions:
Does broker in your case can mean two "kind of" different things, a normal XMPP
server and an XMPP pubsub server? In pubsub, subscribers do not necessarily ever contact
to the publisher nor publishers contact subscribers, but only to the broker, so it could
perhaps be clarified a bit more.
I've now clarified this in the text so it's clearer. I refer to the XMPP Server as
the message broker. I did not mean to confuse this with a pubsub server. The only part
where I (intentionally) wanted to refer to the pubsub server in XMPP was in the
introductory section about publish/subscribe. The hybrid approach only includes the XMPP
server and XMPP clients.
"As devices all connect to a message broker,
external entities cannot connect to the devices, unless the message broker authenticates
the device and authorizes its relationship with the original device."
"XMPP also adds a security mechanism whereby clients are authenticated, and the
broker also makes sure each client sending a message to another is authorized to do
so."
So, maybe you could explain shortly security (at least access models) of XMPP's
pubsub, I think that above sentences do not contain enough information about them.
Pubsub is beyond the scope of the hybrid approach described and is not used in HTTP over
XMPP. Sorry to create the confusion in the first place. I mentioned the publish/subscribe
pattern in the introduction, just to describe how the initial problem has been attacked
previously, but then state that the that pattern is not suitable for the needs of the
semantic web.
I would remove words "very" or change them
(as also other fillers words)... "Very" does not tell you much unless you
explain the difference of, e.g., very powerful and powerful.
I've removed several of these.
Otherwise, really interesting case and paper!
BR, Teemu Väisänen
Thanks for taking your time and read the paper.
Sincerely,
Peter Waher