IETF Logo Mail Archive

Re: [core] draft-ietf-core-multipart-ct

Carsten Bormann <cabo@tzi.org> Wed, 20 February 2019 07:03 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F876127287; Tue, 19 Feb 2019 23:03:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 VVrRELWSRw_d; Tue, 19 Feb 2019 23:03:46 -0800 (PST)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 2A7A212426A; Tue, 19 Feb 2019 23:03:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id x1K73XoK016092; Wed, 20 Feb 2019 08:03:39 +0100 (CET)
Received: from [192.168.217.106] (p54A6C2FE.dip0.t-ipconnect.de [84.166.194.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4447qT4HzQz1Br7; Wed, 20 Feb 2019 08:03:33 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <026901d4c8df$e2251410$a66f3c30$@augustcellars.com>
Date: Wed, 20 Feb 2019 08:03:32 +0100
Cc: Thomas Fossati <tho.ietf@gmail.com>, draft-ietf-core-multipart-ct@ietf.org, core@ietf.org, Klaus Hartke <hartke@projectcool.de>
X-Mao-Original-Outgoing-Id: 572339010.995652-ad565c5c8c55f37fa13d7bda363a1b56
Content-Transfer-Encoding: quoted-printable
Message-Id: <A953A288-7A10-454B-A7EF-A15098331ADC@tzi.org>
References: <000901d4c2f8$4b69a640$e23cf2c0$@augustcellars.com> <CAAzbHvYMp7w=mHB8tAifEwEpY26C96SZRjZX8Q9M5w+J_C3+qA@mail.gmail.com> <00f901d4c624$f313cb30$d93b6190$@augustcellars.com> <CAObGJnMRbT__h0YbjaQMkgvRLLA7CFEVSor_Kiu9JF8F6xX+8Q@mail.gmail.com> <026901d4c8df$e2251410$a66f3c30$@augustcellars.com>
To: Jim Schaad <ietf@augustcellars.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/GHhMywFNOMLU_l77MhxmqhtJnwo>
Subject: Re: [core] draft-ietf-core-multipart-ct
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Feb 2019 07:03:49 -0000

On Feb 20, 2019, at 06:48, Jim Schaad <ietf@augustcellars.com> wrote:
> 
> For case (A), unless it is going to have options while doing a rigidly structured response, there is no need to have a value different than Accept 62.  In fact if there is really only one structured response, then there is not a need to have any accept option in the request at all.

Case (A) is somewhat hypothetical now, so let me give an example to find out whether that would be (A) or maybe even a new (C):

We do a FETCH with an array of selectors, which was defined as a content type of its own.  The return might be a specially defined content type for providing an array of responses, or it might simply be a multipart-core, laying out the selector results in the same sequence they were requested in the FETCH payload.  The specific semantics of the (sequence of objects in the) response body here come from the request body and its media-type!

(And the client might still use an Accept if there is another way to represent the array of results as well but the client specifically wants multipart-core.)

Grüße, Carsten

v2.23.0 | Report a Bug | By Email