Re: [Cbor] Request for IANA registry addition for cbor tag

Laurence Lundblade <lgl@island-resort.com> Wed, 22 January 2020 02:25 UTC

Return-Path: <lgl@island-resort.com>
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 7249C1200C3 for <cbor@ietfa.amsl.com>; Tue, 21 Jan 2020 18:25:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 dlJsgaH80bkb for <cbor@ietfa.amsl.com>; Tue, 21 Jan 2020 18:25:32 -0800 (PST)
Received: from p3plsmtpa11-07.prod.phx3.secureserver.net (p3plsmtpa11-07.prod.phx3.secureserver.net [68.178.252.108]) (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 2F1B0120013 for <cbor@ietf.org>; Tue, 21 Jan 2020 18:25:32 -0800 (PST)
Received: from [192.168.1.76] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id u5hyirqXU9TSnu5hziW03Y; Tue, 21 Jan 2020 19:25:31 -0700
From: Laurence Lundblade <lgl@island-resort.com>
Message-Id: <0A10ACB1-A2A2-450E-9394-D92B575F5AC0@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_40442990-8A6E-451C-A1CB-EC19D64E86C8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 21 Jan 2020 18:25:30 -0800
In-Reply-To: <000001d5d0c0$100a0cd0$301e2670$@augustcellars.com>
Cc: Carsten Bormann <cabo@tzi.org>, cbor@ietf.org, Kio Smallwood <kio@mothers-arms.co.uk>
To: Jim Schaad <ietf@augustcellars.com>
References: <8eefb11ba6e49f7f19fd645d11d47a7f@mothers-arms.co.uk> <75E3B32F-CEF8-4338-917D-2264006287FF@tzi.org> <644EE647-CC60-4F4C-AE4A-94B511E9597F@island-resort.com> <8EB0DDFD-5AF1-4010-84AF-55F6E21688B2@tzi.org> <000001d5d0c0$100a0cd0$301e2670$@augustcellars.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-CMAE-Envelope: MS4wfAuiRFkwzq08EeaYyAkMrtqSEgNw8RYXS24mIJl3OnIoaCe/2HbtObhSz1O7hcbwWfk+EuE9Ufv3yIJQQbiQauOv2iOW+Tqy7UQKe7rV/awmXZPmzYf8 jxPX1XbLEZE1oNvWy8TjfxGLEUXJcrIcXKw0ulqPY1yZX6cgsZw2bbOOy+WMb/I1RHVTQZhi7QN25MiPYmzoDFq1D+v7HufGSob9yr5shdTV0ULpkVoveCWQ EfZPedYNUAjrMgQ110l3Lw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/VJsIasyp4hEKzJq1cunw9ooQ0dI>
Subject: Re: [Cbor] Request for IANA registry addition for cbor tag
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: Wed, 22 Jan 2020 02:25:34 -0000

My bad. I read the proposal wrong.  Let me try again.

1) Decoder recognizes and supports the tag. A nice ordered map will be returned to the caller.

2) Decoder knows nothing of the tag. A tag plus an array (not a map) will be returned to the caller in order.

3) The programing environment can’t support returning an ordered map and the implementor considers doing something about the tag

3a) The mellow implementor opts for 2).

3b) The knows-what-is-best implementor considers the input invalid and returns an error.

3c) The lets-all-get-along implementor offers an option to behave as 2) or 3b).

This tag is really aimed at type 1) so it is sort of the same, if you use this tag, be sure the decoder supports it. Same with just about any tag. Seems OK.


Separately...

So it appears to me that no where does it say “arrays are ordered” in 7049 or CBORbis. This seems like an omission that should be fixed. They are ordered aren’t they? COSE would break if they weren’t.

Also, I noticed recently that JWT requires either duplicate detection or take-last. CWT is silent on this including inheriting this behavior from JWT.

LL



> On Jan 21, 2020, at 5:05 PM, Jim Schaad <ietf@augustcellars.com> wrote:
> 
> 
> 
> -----Original Message-----
> From: CBOR <cbor-bounces@ietf.org> On Behalf Of Carsten Bormann
> Sent: Tuesday, January 21, 2020 12:03 PM
> To: Laurence Lundblade <lgl@island-resort.com>
> Cc: cbor@ietf.org; Kio Smallwood <kio@mothers-arms.co.uk>
> Subject: Re: [Cbor] Request for IANA registry addition for cbor tag
> 
> Hi Laurence,
> 
> I’m not sure I follow.  Decoders either implement a tag or they don’t.
> 
>> On 2020-01-21, at 18:58, Laurence Lundblade <lgl@island-resort.com> wrote:
>> 
>> Here’s some decoders types in relation to this tag:
>> 
>> 1) It recognizes the tag, supports it and does the right thing.
> 
> That would be a decoder that implements the tag.
> 
>> 2) It recognizes the tag, knows it can’t do what is required and errors out. For this decoder this type is invalid.
> 
> That would be a decoder that fundamentally doesn’t accept this tag.
> Not particularly useful.
> What does “can’t do what is required” mean?
> 
>> 3) It doesn’t recognizes the tag and happens to do the wrong thing. That is perfectly OK.
> 
> How would that be OK?  But maybe I don’t understand that “do the wrong thing” means.
> 
>> 4) It doesn’t recognize the tag and happens to do the right thing.
> 
> Which would be to present the tag number and the tag content to the application.
> 
>> So anyone using this tag really needs to be sure they are using a decoder of type 1. Decoder types 3 and 4 are really the same in that there is no way to know which one you’ve got.
>> 
>> I don’t think we want some sort of implication that decoder type 3 is defective creating a situation where all decoders are forced to support this.
> 
> Now I’m completely lost about your type 3.  “Do the wrong thing” and “OK” don’t mix that well for me…
> 
>> I think this should be spelled out in the description of this tag.
> 
> I think 7049bis might need some more text about handling unimplemented tags in decoders.
> 
> Right now, it says:
>  Implementations receiving an unknown tag number can choose to simply ignore
>  it or to process it as an unknown tag number wrapping the enclosed data
>  item. The IANA registry in {{ianatags}} is the appropriate way to
> 
> [JLS]
> Carsten,
> 
> I would argue that the decode that I use obeys the text above and would fall into the category of decode that is going to do one of "bad" things Laurence discussed above.  It will return a tree with the following 
> <TAG  new tag number>
>   <MAP>
>       [<key> <value>]+
> 
> However, depending on what the final language that the group comes up with for the duplicate tag language, it will either take the first, the last or throw and exception when a duplicate tag is found.  That says that it can not do the first option (hey dup tags are not done will for hash based maps) and thus will either do 3  or totally fail.
> 
> I would not really be a huge fan of this tag.  If this is really what you want to do then an array seems to me to be a better answer.
> 
> Jim
> 
> 
> But it also says:
> Generic encoders provide an application interface that allows the application to specify any well-formed value, including simple values and tags unknown to the encoder.
> 
> So a generic encoder would not have problems with unimplemented tags; but other (e.g., task-specific) implementations might.
> 
> Grüße, Carsten
> 
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor
> 
>