From sm@elandsys.com Sat Apr 6 00:19:51 2024 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28052C14F69F; Sat, 6 Apr 2024 00:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.696 X-Spam-Level: X-Spam-Status: No, score=-1.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAM3aggMj8O5; Sat, 6 Apr 2024 00:19:47 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A96CC14F69D; Sat, 6 Apr 2024 00:19:47 -0700 (PDT) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.117.113.41]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 4367J9nm029853 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Apr 2024 00:19:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=elandsys.com; s=mail; t=1712387983; x=1712474383; i=@elandsys.com; bh=2i5F7278j9Vh+tF9u4gvT81REcwhqppBOeCHejq5FHc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=G1P2ZXxLgc63zVqh0TX61YQ7PQ3Mj/y7uFsFMFKZOyNgdTj9f/cuxokXi9lJw7A7g 8OSDstPakmHZeyxBtMNoheECZrEHmgouV2l66oX607VBhRvnGCmgFsWGXT8EepQfWR qQ7+l3q+w0WsVqjZzUzA1e88TwN2jSVwdFGiTOwE= Message-Id: <6.2.5.6.2.20240405234932.09b2d540@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 06 Apr 2024 00:18:00 -0700 To: Michael Richardson , media-types@ietf.org From: S Moonesamy Cc: anima@ietf.org In-Reply-To: <1810.1712262101@obiwan.sandelman.ca> References: <2E20FEDE-C766-43EE-A6E2-1FB63E79CF0B@mnot.net> <1810.1712262101@obiwan.sandelman.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [Anima] [media-types] Fwd: Thoughts on suffixes, single and multiple X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2024 07:19:51 -0000 Hi Michael, At 01:21 PM 04-04-2024, Michael Richardson wrote: >We in ANIMA have been struggling because we have an artifact, a voucher >(YANG defined in RFC8366, being revised/extended in 8366bis), which can be in >two major formats: JSON and CBOR (in theory, XML too), but can be signed by >three formats (CMS, JWS, COSE). > >That gives us three major variations today: >1) application/voucher-cms+json aka voucher+json+cms? >2) application/voucher+cose or? voucher+cbor+cose? >3) application/voucher-jwt+json aka voucher+json+jwt? > >(because CMS signing CBOR seems dumb, as does mixing {JSON,CBOR} X {JWS,COSE}) > >We didn't know if we should resort to multiple suffixes or not, and the lack >of apparent progress on this has been a pain. So, thank you for the decision >as it takes the options off the table, I guess, even if I'm bit surprised by >it. My quick reaction is that using those variations is a bad idea. The good news is that I cannot prevent the working group from moving forward with the registration. The policy perspective is that someone will have to go through the registry, submit a policy change and figure out how to move it forward. Regards, S. Moonesamy