Re: [Cbor] Invalid Tag Values

Kio Smallwood <kio@mothers-arms.co.uk> Thu, 24 June 2021 20:12 UTC

Return-Path: <kio@mothers-arms.co.uk>
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 76DB63A29AE for <cbor@ietfa.amsl.com>; Thu, 24 Jun 2021 13:12:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 t-L5l1ZrOYLg for <cbor@ietfa.amsl.com>; Thu, 24 Jun 2021 13:12:06 -0700 (PDT)
Received: from b-painless.mh.aa.net.uk (b-painless.mh.aa.net.uk [IPv6:2001:8b0:0:30::52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 179AD3A29AC for <cbor@ietf.org>; Thu, 24 Jun 2021 13:12:05 -0700 (PDT)
Received: from a-webmail.thn.aa.net.uk ([2001:8b0:0:62::22] helo=webmail.aa.net.uk) by painless-b.tch.aa.net.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <kio@mothers-arms.co.uk>) id 1lwVhk-0003Vo-IA; Thu, 24 Jun 2021 21:12:04 +0100
Received: from cpc105076-sgyl40-2-0-cust233.18-2.cable.virginm.net ([82.4.24.234]) by webmail.aa.net.uk with HTTP (HTTP/1.1 POST); Thu, 24 Jun 2021 21:11:54 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_b14b02477e861ed56f7f0fbedf2a2de9"
Date: Thu, 24 Jun 2021 21:11:54 +0100
From: Kio Smallwood <kio@mothers-arms.co.uk>
To: Carsten Bormann <cabo@tzi.org>
Cc: cbor@ietf.org
In-Reply-To: <C4A51BCF-D1C1-41D4-BF1B-47CB75EEFAFA@tzi.org>
References: <f5650d87a36b10f6b75d2a1123f84bb5@mothers-arms.co.uk> <C4A51BCF-D1C1-41D4-BF1B-47CB75EEFAFA@tzi.org>
Message-ID: <9bec699fcdc78de53f13e591ec139ff8@mothers-arms.co.uk>
X-Sender: kio@mothers-arms.co.uk
User-Agent: Roundcube Webmail/1.3.16
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/RAqXKGXjwYHLYSmAEvuKxuI3ux4>
Subject: Re: [Cbor] Invalid Tag Values
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: Thu, 24 Jun 2021 20:12:12 -0000

Hi Carsten, 

So if I follow the logic correctly, if my decoder encounters
0("1900-01-00T00:00;00") instead of raising an exception it could return

65535({
    "value": "1900-01-00T00:00;00", 
    "_error":"invalid datetime string: '1900-01-00T00:00;00'",
    "original_tag": 0
})

to the application? We could then have a tag handler or schema verifier
raise the error or just log it, but in this case the full CBOR stream
would be decoded. 

Thanks, 

Kio 

On 2021-06-24 20:21, Carsten Bormann wrote:

> Hi Kio,
> 
>> I'm having trouble understanding the rationale of intentionally invalid tags as documented here[1]
>> 
>> Under what circumstances would an encoder produce these tags
> 
> Never.  They are explicitly reserved so that an implementation has a selection of tag numbers that it can use internally, such as in order to mark the absence of a tag.
> 
>> and what should a decoder do when encountering them?
> 
> Mark the data item as invalid.
> I don't think a more rigorous response (rejecting the data item the same way that a non-well-formed input would be) would be out of line, as the tag numbers are explicitly marked as "not to occur in interchange".
> (RFC 8949 just doesn't have a category between non-well-formed and invalid that we could use here.)
> 
>> Since I'm working on that part of the decoder[2] anyway I thought I'd better check.
> 
> Thank you a lot for doing this!
> 
> If you have suggestions how the text in -notable-tags could be made even more explicit about this, please tell us.
> 
> Grüße, Carsten
> 
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor