Re: [Anima-signaling] GRASP API issue 2: Passing the (CBOR) value of an objective

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 19 January 2017 02:49 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: anima-signaling@ietfa.amsl.com
Delivered-To: anima-signaling@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11DB5129469; Wed, 18 Jan 2017 18:49:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKrVW9t0alKg; Wed, 18 Jan 2017 18:49:17 -0800 (PST)
Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11014129453; Wed, 18 Jan 2017 18:49:17 -0800 (PST)
Received: by mail-pf0-x244.google.com with SMTP id e4so2271420pfg.0; Wed, 18 Jan 2017 18:49:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=+V8+2iSu4Om+KJOCe/KdKqrFK46NHCb+eRVl1ZdVOqY=; b=gzMiUABxs9geySDDsKzTlaxm8xWDcL0iYlXKd6dp4bgcEn3UTLE1KQamW1WUZOotiV tYnEh1Qgayb/f97s7FM5OghtVzFn+/83y+sOGrauhc+Mvyu8d0O8hxR8mqh7GK1lJ7yp 86Dj5KNHrAZNVRGSB+oqVTZ/xT2OfZTwlFvrftEKQt8HajAXPi+7kis8KzIsaF3XCXwN stFLeVl4LAvOEAbp0QyMl4zErBE66uMj8UAbOZ0qGLdRprwvpW/82WXnxkJTKoaNzkLm QdQoWSuLLWDGhwSNQQCIG8POsO8a5HnTHqkune2UEkYpMvAuGW01dpHbgIGtfygEV845 Xong==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=+V8+2iSu4Om+KJOCe/KdKqrFK46NHCb+eRVl1ZdVOqY=; b=guof+WQF3mKhkjoxIxsBlTHyUdKo1c4qUE6FxHpWhFJow9TMVO4d9gpDkzfPtwNClu h0DPGh8M0lFJUoC0+VcI3SWaMW6f4SeLnW15uowEIZ3keTxU6iSrAfm0iV4TgIjhq42k uma+YLa3mg0kB4PXhgF+z07ocwBliNgnkXvle9iRYgvGYYld7adTDRGIIrCzpfMF96ue fenvsqXGVoAQRQr2AvEAUiGIunRrrS4rhDvVbqj2ODo1AF6cXr7ZY2Xq27PAlrXYjPhu cvjWVdQezL16Q8FtUwovpqVl13L0MzQjqT++WtBm//PdkYvIla3qpKl6UiRmxqjdq8Lk JNNg==
X-Gm-Message-State: AIkVDXJgGpcs7I/PWaSFbznU5mr3x5PCctNXfUt+OJeeW4qr9P2fBj2zzAtLd+//wnGgaw==
X-Received: by 10.98.88.133 with SMTP id m127mr7468683pfb.155.1484794156381; Wed, 18 Jan 2017 18:49:16 -0800 (PST)
Received: from [192.168.178.21] ([118.148.124.183]) by smtp.gmail.com with ESMTPSA id e11sm3831601pgp.10.2017.01.18.18.49.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Jan 2017 18:49:15 -0800 (PST)
To: Anima signaling DT <anima-signaling@ietf.org>
References: <93f5edf8-c9e2-3319-eeba-aebc513992d2@gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <a4662ee7-8ee3-184a-d88e-741835e6ccb9@gmail.com>
Date: Thu, 19 Jan 2017 15:49:15 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <93f5edf8-c9e2-3319-eeba-aebc513992d2@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima-signaling/iD2yRBJAOn7pQwCxo_a7bm9W1E4>
Cc: draft-liu-anima-grasp-api@ietf.org
Subject: Re: [Anima-signaling] GRASP API issue 2: Passing the (CBOR) value of an objective
X-BeenThere: anima-signaling@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list for the signaling design team of the ANIMA WG <anima-signaling.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima-signaling>, <mailto:anima-signaling-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima-signaling/>
List-Post: <mailto:anima-signaling@ietf.org>
List-Help: <mailto:anima-signaling-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima-signaling>, <mailto:anima-signaling-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Jan 2017 02:49:18 -0000

I have a proposal for the issue mentioned below.

We can say in the abstract description of the API something like the following:

   o  value - a specific data structure expressing the value of the
      objective.  The format is language dependent, with the constraint
      that it can be validly represented in CBOR (default integer = 0).
      In case a required format cannot be supported in a particular
      language, every implementation must provide a mechanism for passing
      the value as an already encoded CBOR bytestring, which will be
      transmitted in all resulting GRASP messages as an embedded Tag 24
      item.

For those of you who don't know every single detail of CBOR :-), Tag 24
is simply the label for CBOR encapsulated in CBOR.

So for simple things a language mapping could be defined, and for
complex things the ASA writer would use a CBOR library.

I've implemented this in Python - if the ASA passes in an objective
whose value field is a 'bytes' object, and if that bytes object is
valid CBOR, it is wrapped in Tag 24 for transmission, and unwrapped
at the far end. It seems to work fine (about 35 new lines of code).

Regards
   Brian Carpenter



On 08/01/2017 14:16, Brian E Carpenter wrote:
> How should the API represent the 'value' part of a GRASP Objective
> in a non-OO language?
> 
> In an OO language there will be a natural way to represent the value
> of an objective: for example, in Python, any valid Python object
> that the CBOR library can handle.
> 
> In a traditional language such as C, it's not so clear. For example, this doesn't
> quite work:
> 
> typedef struct {
>     gstring name;
>     bool neg;
>     bool dry;
>     bool synch;
>     int loop_count;
>     void * value;    // user has to cast this pointer appropriately and do own malloc()
>     } objective;
> 
> This doesn't work because the GRASP implementation won't know how
> to CBORise whatever ends up in the 'value' parameter.
> 
> Is this already a solved problem in CBORland? For example, should we expect
> the ASA to pass an already CBORised byte string?
> 
> Regards
>    Brian
> 
>