Subject: [RAI] Device control and tools, or maybe nails

From: Dean Willis <[email-masked]>
Date: Fri, 15 Jul 2011 10:05:36 -0500

The device control debate, which I just found the time to catch up on, reminds me of a classic parable from my university, whose denizens are known as Aggies and historically received much teasing for the school's genesis as a facility for teaching engineering to farmboys, many of whom had "never been off the farm before" and thus lacked courtly manners and practical, worldly experience (much like IETFers).

Two Aggies are working on a construction project that involves nailing boards to a wall. They run out of nails halfway through the box, because half of the nails have their points on the wrong end. So they take the box of "defective" nails back to the store, where the shopkeeper (who attended a rival university) charges them a small fee for rotating the box 180 degrees. The Aggies then go back to work and complete the project, happy that they didn't have to buy another box of nails.

Our solicited pub/sub mechanism (SUBSCRIBE/NOTIFY) is a nail. It has a flat end for hammering (SUBSCRIBE) and a pointy end for poking into things (NOTIFY). But if we're clever like the shopkeeper, we can turn the nail around ourselves, and use one for controller to controllee (to send commands) and another from controllee to controller (to report state changes like command success/failure/supporting data).

Something like this is required to make something like an RPC mechanism work over SIP, because SIP's UDP legacy means we're very limited in what we can send in a response.

And the "command and control" paradigm we've been talking about is really just a specialized RPC API.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Jul 2011 11:27:33 -0400

> And the "command and control" paradigm we've been talking about is really just a specialized RPC API.

I still say the issue isn't the mechanism. Rather its the model of what 
we are controlling.

An RPC is just a mechanism. It also requires a model of what is 
manipulated with RPCs.

If we say we just want to ask a UA to do "stuff" we will not get much of 
anywhere, because then its really hard to determine a correct 
implementation of any operation from an incorrect one.

Rifaat took a stab at this. And CSTA also provides such a definition.
The trick is deciding on something that is sufficient but manageable.

I don't know that the RAI list is the best place to have that 
discussion. But lets pick a place and nail it down.

	Thanks,
	Paul

---

From: Ben Campbell <[email-masked]>
Date: Fri, 15 Jul 2011 13:25:17 -0500

> Our solicited pub/sub mechanism (SUBSCRIBE/NOTIFY) is a nail. It has a flat end for hammering (SUBSCRIBE) and a pointy end for poking into things (NOTIFY). But if we're clever like the shopkeeper,…

Maybe PUBLISH has the flat part on the right end? 

( Don't take this comment as an endorsement--I share the concerns about the overall model as mentioned by Paul and others. Mechanism seems like the easy part.)

> _______________________________________________
> RAI mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rai