Re: [Ace] Embedded Content Types

Jim Schaad <ietf@augustcellars.com> Thu, 21 February 2019 22:31 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A36DE130F0F; Thu, 21 Feb 2019 14:31:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 7sXkQUdPF-H6; Thu, 21 Feb 2019 14:31:12 -0800 (PST)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E2A6130E8E; Thu, 21 Feb 2019 14:31:11 -0800 (PST)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 21 Feb 2019 14:31:05 -0800
From: Jim Schaad <ietf@augustcellars.com>
To: "'Panos Kampanakis (pkampana)'" <pkampana@cisco.com>, 'Carsten Bormann' <cabo@tzi.org>
CC: <ace@ietf.org>, 'Klaus Hartke' <hartke@projectcool.de>, <draft-ietf-ace-coap-est@ietf.org>
References: <02a201d4c945$eb10a510$c131ef30$@augustcellars.com> <17e617f1090e451c8b17f6550c2e213a@XCH-ALN-010.cisco.com> <CCD28BCC-16AA-492B-8E14-DAE9F2CF2E3C@tzi.org> <38fa1ec646974a329c286279b3fa9ff0@XCH-ALN-010.cisco.com> <032f01d4ca2f$ff19c6a0$fd4d53e0$@augustcellars.com> <b4bb6e5f3c7c47ffa040389f000f027f@XCH-ALN-010.cisco.com>
In-Reply-To: <b4bb6e5f3c7c47ffa040389f000f027f@XCH-ALN-010.cisco.com>
Date: Thu, 21 Feb 2019 14:31:05 -0800
Message-ID: <033201d4ca35$23f58f40$6be0adc0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJrZGJxf0tFnICB97QT3wBXQb1jnQH8O2UCAceAOO4BnmC3sAE5b/I6AkVh342kdpmHkA==
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/qFhEQ2bYKoWnEf1bnwFoqCR9M7I>
Subject: Re: [Ace] Embedded Content Types
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Feb 2019 22:31:14 -0000

I am thinking of two different URLs, that is not do the difference by a query parameter but by changing the URI.  This makes it easier because the client should be able to be deterministic about going to the same URI so it should do the second POST to the same location and there is no need for any existing code to be changed.  These would be two different URIs and there would be one additional URI returned in the query to well-known/core.

Jim


> -----Original Message-----
> From: Panos Kampanakis (pkampana) <pkampana@cisco.com>;
> Sent: Thursday, February 21, 2019 2:11 PM
> To: Jim Schaad <ietf@augustcellars.com>;; 'Carsten Bormann' <cabo@tzi.org>;
> Cc: ace@ietf.org; 'Klaus Hartke' <hartke@projectcool.de>;; draft-ietf-ace-
> coap-est@ietf.org
> Subject: RE: [Ace] Embedded Content Types
> 
> > This is why I would prefer doing something like "/est/skg" and
> "/est/skg/yyy".
> 
> Not sure I am following. Are these two request URIs? Or in the discovery
> response?
> 
> 
> -----Original Message-----
> From: Jim Schaad <ietf@augustcellars.com>;
> Sent: Thursday, February 21, 2019 4:54 PM
> To: Panos Kampanakis (pkampana) <pkampana@cisco.com>;; 'Carsten
> Bormann' <cabo@tzi.org>;
> Cc: ace@ietf.org; 'Klaus Hartke' <hartke@projectcool.de>;; draft-ietf-ace-
> coap-est@ietf.org
> Subject: RE: [Ace] Embedded Content Types
> 
> 
> 
> > -----Original Message-----
> > From: Panos Kampanakis (pkampana) <pkampana@cisco.com>;
> > Sent: Thursday, February 21, 2019 1:32 PM
> > To: Carsten Bormann <cabo@tzi.org>;
> > Cc: Jim Schaad <ietf@augustcellars.com>;; ace@ietf.org; Klaus Hartke
> > <hartke@projectcool.de>;; draft-ietf-ace-coap-est@ietf.org
> > Subject: RE: [Ace] Embedded Content Types
> >
> > Thanks Carsten.
> >
> > Let's say we use a query /skg?sk=xxx&spk=yyy. /skg/xxx,yyy is a
> > different URI imo, so it changes the EST spec and that introduces
> > changes that affect CAs that already implemented it. So let's say we do
> /skg?sk=xxx&spk=yyy.
> > When I am doing resource discovery and the server is returning the
> > content formats for skg, is he going to signal his supported formats
> > with
> > </est/skg>;rt="ace.est.skg";ct="62 xxx yyy"
> 
> This is why I would prefer doing something like "/est/skg" and
> "/est/skg/yyy".  This does not change any existing servers other than getting
> the ct values corrected in discovery.
> 
> 
> >
> > RFC5272 says
> > > The Content-Format code "ct" attribute provides a hint about the
> > > Content-Formats this resource returns.  Note that this is only a
> > > hint, and it does not override the Content-Format Option of a CoAP
> > > response obtained by actually requesting the representation of the
> resource.
> > > [...] The Content-Format code attribute MAY include a
> > > space-separated sequence of Content-Format codes, indicating that
> > > multiple content-formats are available.
> >
> > So it looks tome that ct="62 280 284 281 TBD287" could hint to the
> > client that all the following formats are supported for the multipart.
> >
> > I had a chat with Klaus where he mentioned that he assumed the ct="63
> > xxx yyy" returned attribute values are the accepted values by the
> > server in the "Accept" option.
> 
> I would agree with Klaus that this is a correct answer.
> 
> Jim
> 
> >
> >
> > -----Original Message-----
> > From: Carsten Bormann <cabo@tzi.org>;
> > Sent: Wednesday, February 20, 2019 8:11 PM
> > To: Panos Kampanakis (pkampana) <pkampana@cisco.com>;
> > Cc: Jim Schaad <ietf@augustcellars.com>;; ace@ietf.org; Klaus Hartke
> > <hartke@projectcool.de>;; draft-ietf-ace-coap-est@ietf.org
> > Subject: Re: [Ace] Embedded Content Types
> >
> > On Feb 20, 2019, at 22:33, Panos Kampanakis (pkampana)
> > <pkampana@cisco.com>; wrote:
> > >
> > > If we broke the requests to different URIs, it means that a client
> > > needs to
> > keep track of his transactions and on top of it he needs to correlate
> > the key and the cert he receives at a later time.
> >
> > I think this is just a misunderstanding — the idea wasn’t to supply
> > the parts under different URIs, but to make up different URIs for
> > retrieving the different combinations coming in one multipart-core, in one
> transaction.
> >
> > As in
> >
> > /skg?sk=284&spk=281
> >
> > (Where sk is short for “secret key” and spk for “signed public key” —
> > substitute your own names.)
> >
> > or, say
> >
> > /skg/284,281
> >
> > This provides full format agility while preserving the interaction model.
> >
> > Grüße, Carsten
>