Subject: [Anima-signaling] CBOR implementation model?

From: Brian E Carpenter <[email-masked]>
Date: Tue, 8 Sep 2015 14:58:03 +1200

Let's assume that we want to proceed with CBOR. Then
I'd like to understand the implementation model.

We'll have an Autonomic Service Agent, which is the application
layer. It could be written in C, C++ or Python just to take
three examples.

We'll have a GRASP Protocol Engine which uses the ACP to
send and receive packets. The payloads will be CBOR encoded.
I'm guessing the protocol engine will be written in C and
can use the existing CBOR encoder and decoder.

There'll be an API between the ASA and GRASP, that can pass
GRASP message-objects and also handle asynchronous events.

Would those be CBOR objects too? And would the ASA programmer
be able to "think" at the CDDL level of abstraction, or what?

All ideas are welcome. I may be thinking about this all wrong.

    Brian

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 7 Sep 2015 22:25:29 -0700

You're describing the direction i was thinking of except that
i also wouldn't know how to fill in the details. If
the programming language was JS and the encoding JSON, this
all would come for free ;-))

Worst case one has to go trail & error with the available CBOR
SDKs and come up ourselves with similar APIs that allow CBOR
object arguments between ASA/GRASP.

Cheers
    Toerless

On Tue, Sep 08, 2015 at 02:58:03PM +1200, Brian E Carpenter wrote:
> _______________________________________________
> Anima-signaling mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima-signaling

-- 
---
Toerless Eckert, [email-masked]

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 8 Sep 2015 06:54:43 +0000

> -----Original Message-----
> From: Anima-signaling [mailto:[email-masked]] On Behalf
> Of Brian E Carpenter
> Sent: Tuesday, September 08, 2015 10:58 AM

> There'll be an API between the ASA and GRASP, that can pass GRASP
> message-objects and also handle asynchronous events.
> 
> Would those be CBOR objects too? And would the ASA programmer be able
> to "think" at the CDDL level of abstraction, or what?

[Bing] My rough thinking: maybe the ASAs just directly handle the objects such as Locator, Session ID etc. which are already parsed by the GRASP engine. I can't see reasons why the ASAs need to directly handle those objects in a CBOR/CDDL form?

Best regards,
Bing

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 08 Sep 2015 10:13:46 +0200

(CDDL is to CBOR what ABNF is to text, so I'll talk about CBOR here.)

During the design of ANIMA, you may want to limit yourselves to carrying
around simple data objects in the signaling protocol.
In this case, you might want to ship just those data objects to the
application.

Alternatively, you might find that your data objects naturally have some
structure to them (e.g., they are table-like, or they have some options
inside).  In that case, you would probably still decode the CBOR
encoding upon reception, but hand those more structured data objects to
the application in a form that resembles the JSON/CBOR data model.
(As a sub-alternative to that case, your application might prefer to
directly work with CBOR or JSON, so you might hand them the data objects
undecoded/re-encoded.)

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Tue, 08 Sep 2015 10:37:04 -0400

> to "think" at the CDDL level of abstraction, or what?

They could be CBOR, but it seems to me that this is an internal issue.
ASA could be implemented in a variety of different ways... There might not
always need to be an API interface between GRASP and ASA; they might run as
threads in the same address space.

That would make sense if I were implementing in Java, ObjectiveC, Haskall,
Erlang, Ruby...  In C, it could even be loadable shared objects.

All of this assumes no significant security seperation, and that may make
sense for many environments, and less for others.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 8 Sep 2015 08:43:05 -0700

I would like GRASP to have a format where the payload has
a known "payload-type" in the GRASP headers, and it is passed
transparently from GRASP to the ASA. Then the preferred payload
type is CBOR and the ASA-SDK provides both GRASP APIs as well
as CBOR APIs, and the ASA does it's own de/encoding of it's
payload. That way we're flexible, but reuse CBOR as much
as beneficial (comes by default with the ASA SDK), and could
have different authentication/encryption/delayed de/encoding
at ASA vs. GRASP layer.

Cheers
    Toerless

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 9 Sep 2015 08:35:46 +1200

On 09/09/2015 03:43, Toerless Eckert wrote:
> transparently from GRASP to the ASA. 

One qualification on that is that some parts of a GRASP
session can be handled completely by the GRASP engine
itself, without waking up the ASA thread. Two jobs that
I can think of immediately: waiting for the discovery response
and caching the locator(s) returned by discovery; managing
the negotiation loop and its loop count and timeout.

In that context some of the CBOR objects would never actually
need to be delivered to the ASA. But apart from that I agree.

    Brian

> Then the preferred payload

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 9 Sep 2015 08:42:51 +1200

On 09/09/2015 02:37, Michael Richardson wrote:
> ASA could be implemented in a variety of different ways... 

Sure, but if we provide an API and SDK for at least one language,
it will greatly help the creation of an ASA "industry". I think Toerless
and I are thinking along those lines.

> There might not

Well, yes, but that would be for a special-purpose device with a single ASA,
I think. A general-purpose platform that might carry a variety of ASAs would be
better with an API and SDK.

> sense for many environments, and less for others.

Yes. But that's a bit outside the WG's concern, I suppose. Mainly I want us
to avoid rushing off in this direction without some evidence that it's
implementable ;-).

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 9 Sep 2015 08:47:22 +1200

> directly work with CBOR or JSON, so you might hand them the data objects

OK. So does that mean that the application (ASA) code would
be using the dumps and loads functions in cbor.py, for example?

(Bing: that is how a Python app can convert between CBOR binary
and its own variables that contain Locators, Session IDs, etc., if I
have understood correctly.)

   Brian

> .