Re: [Cbor] File extension for cbor sequences

Sean Leonard <dev+ietf@seantek.com> Wed, 25 September 2019 14:41 UTC

Return-Path: <dev+ietf@seantek.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 63862120816 for <cbor@ietfa.amsl.com>; Wed, 25 Sep 2019 07:41:55 -0700 (PDT)
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, 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 IUFrv6d0Czvr for <cbor@ietfa.amsl.com>; Wed, 25 Sep 2019 07:41:53 -0700 (PDT)
Received: from smtp-out-4.mxes.net (smtp-out-4.mxes.net [198.205.123.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C22FA120820 for <cbor@ietf.org>; Wed, 25 Sep 2019 07:41:53 -0700 (PDT)
Received: from Customer-MUA (mua.mxes.net [10.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 78F992739B for <cbor@ietf.org>; Wed, 25 Sep 2019 10:41:52 -0400 (EDT)
To: cbor@ietf.org
References: <156753408409.3422.7830964135939662716.idtracker@ietfa.amsl.com> <DFB3F8F3-3851-4B31-922E-75AF7B96AAB6@tzi.org> <99AD19E5-1A5B-41C5-BB10-A7A384458E3C@tzi.org> <BC319FD3-5456-4EB9-9964-1674EDC5CE48@vpnc.org>
From: Sean Leonard <dev+ietf@seantek.com>
Message-ID: <c4b5d161-9844-d853-8d9c-e1c3a7fea19f@seantek.com>
Date: Wed, 25 Sep 2019 07:42:06 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <BC319FD3-5456-4EB9-9964-1674EDC5CE48@vpnc.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Sent-To: <Y2JvckBpZXRmLm9yZw==>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/Fza6Zv0yzr_Gmm-FRmSUtVxowe8>
Subject: Re: [Cbor] File extension for cbor sequences
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, 25 Sep 2019 14:42:00 -0000

On 9/25/2019 6:49 AM, Paul Hoffman wrote:
> On 25 Sep 2019, at 6:15, Carsten Bormann wrote:
>
>> This is now actually the last thing missing before I can declare that 
>> all IESG comments have been addressed.
>>
>> RFC 7049 defines .cbor as the file extension for single encoded CBOR 
>> data items.
>>
>> draft-ietf-cbor-sequence doesn’t define one, because it copied that 
>> RFC 7464 (JSON Text Sequences) doesn’t define one, not because of 
>> some actual thinking about the question.
>>
>> Do we want to go for .cborseq?  Better ideas?  Probably not .csq 
>> (*)?  Since this is bike-shedding, I’d like to timebox this decision 
>> (to today?).
>
> Preference: don't give one, just like JSON sequences.

+1

Not .csq for aforementioned reasons.

While .cborseq is better, my preference is also to omit it entirely.

We don't need a repeat of .DER. (Where DER = Distinguished Encoding 
Rules but the file extension mainly is used for binary X.509 
certificates. A file extension that represents the actual data--rather 
than the generic encoding format--is preferable.)

Sean