Re: [Cbor] draft-ietf-cbor-network-addresses: tag validity; deterministic encoding

Carsten Bormann <cabo@tzi.org> Fri, 08 October 2021 22:57 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D59633A0C67 for <cbor@ietfa.amsl.com>; Fri, 8 Oct 2021 15:57:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 01Pj5s_udnu7 for <cbor@ietfa.amsl.com>; Fri, 8 Oct 2021 15:57:50 -0700 (PDT)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C04803A0C77 for <cbor@ietf.org>; Fri, 8 Oct 2021 15:57:49 -0700 (PDT)
Received: from smtpclient.apple (p5089a8ac.dip0.t-ipconnect.de [80.137.168.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4HR3Vx6lsVz2xkh; Sat, 9 Oct 2021 00:57:45 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <dab25fe3-43c4-865e-2c7a-54b24340c295@gmail.com>
Date: Sat, 9 Oct 2021 00:57:45 +0200
Cc: cbor@ietf.org, Michael Richardson <mcr+ietf@sandelman.ca>
Content-Transfer-Encoding: quoted-printable
Message-Id: <19BCDB95-AB61-4F92-A38D-F6FD5CA8BBB1@tzi.org>
References: <891995AA-2854-431E-9242-98FFCDA5E161@tzi.org> <dab25fe3-43c4-865e-2c7a-54b24340c295@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/RpryR9KB3i33DjPJABVbZNBjApM>
Subject: Re: [Cbor] draft-ietf-cbor-network-addresses: tag validity; deterministic encoding
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Oct 2021 22:57:55 -0000

Hi Brian,

The weird thing about the current definition of the prefix is that trailing zero bytes are not sent, even if they are part of the prefix.

   As an example, ::/128 is encoded as	
 		
   54([128, h’’])

(::/128 is 16 zero bytes).

So don’t forget to zero-expand the prefix you get (which is another way to do the “recommendation”).

I’m not fluent in Python after midnight, so here’s Ruby:

   fail if prefix[-1] == “\0” # may need to check for prefix != ‘’ in your language
   l = prefix.bytesize
   fail if l > 16
   prefix << “\0”.b * (16 - l)
   [now do the trailing bit check in the document[

Grüße, Carsten


> On 9. Oct 2021, at 00:40, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 
> On 09-Oct-21 00:52, Carsten Bormann wrote:
>> There are various admonitions scattered in draft-ietf-cbor-network-addresses about doing the right thing when encoding and decoding the tags.
>> We do have a concept in CBOR to handle this properly:
>> Tag validity (Section 5.3.2 of RFC8949).
>> 
>> In response to various observations about those admonitions during IESG 
> processing, I went ahead and consolidated the actual content to a proper section about Tag Validity.
>> 
>> https://github.com/cbor-wg/cbor-network-address/pull/15
>> 
>> I also wrote:
>> 
>>> The tag validity rules, combined with the rules in {{Section 4.2.1 of
>>> -cbor}}, lead to deterministic encoding for tags 54 and 52 and require
>>> no further Additional Deterministic Encoding Considerations as per
>>> {{Section 4.2.2 of -cbor}}.
>> 
>> … which might come in handy when deterministic encoding is actually needed.
>> 
>> Comments welcome before we merge.
> 
> I glanced at my Python code while checking the PR and noticed this:
> 
>>> A recommendation for prefix decoder implementations is to first create
>>> an array of 16 (or 4) zero bytes.
> 
> That's exactly what I don't do in my code, although I'm sure it's exactly
> what I would do in C. I think 'recommendation' is a bit strong.
> 
>>> check that any unused
>>> bits in the byte string are zero:
> 
> I came up with this:
> 
>    if prefix[length//8] & bytemasks[length%8][0] != prefix[length//8]:
>        #extra bits in prefix, signal an error
> 
> I also came up with a corner use case - suppose all I want to convey is
> a prefix length but no prefix? At the moment, I simply send an all-zeroes
> prefix, but those are wasted bits. Probably, this isn't worth fixing.
> 
>   Brian
> 
> 
>> 
>> Grüße, Carsten
>> 
>> _______________________________________________
>> CBOR mailing list
>> CBOR@ietf.org
>> https://www.ietf.org/mailman/listinfo/cbor