[core] Benjamin Kaduk's Discuss on draft-ietf-core-multipart-ct-03: (with DISCUSS and COMMENT)

Benjamin Kaduk via Datatracker <noreply@ietf.org> Thu, 02 May 2019 00:05 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: core@ietf.org
Delivered-To: core@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ABF3B120261; Wed, 1 May 2019 17:05:40 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-core-multipart-ct@ietf.org, Jaime Jimenez <jaime.jimenez@ericsson.com>, core-chairs@ietf.org, jaime.jimenez@ericsson.com, core@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.95.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <155675554069.2851.9351849772053196736.idtracker@ietfa.amsl.com>
Date: Wed, 01 May 2019 17:05:40 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/dXboG6RY9Joi6CRsscIYizdefXg>
Subject: [core] Benjamin Kaduk's Discuss on draft-ietf-core-multipart-ct-03: (with DISCUSS and COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 02 May 2019 00:05:41 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-core-multipart-ct-03: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-multipart-ct/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

It's not clear to me that we're really specifying the semantics of a
single media-type.  The introduction discusses how we may want multiple
representations to appear in a sequence, potentially representing
different content.  Or we may have a set of related representations that
conceptually are the same content (but are they literally the same
resource, or related content?).  And there is yet a third option -- one
that I'm not sure I fully understand -- wherein the representation is
not important, but rather which format is chosen of the several
possibilities, to the extent that extreme compression of the
representation is possible, with the compression just outputting the
format indicator.

I don't see that any of these three cases are mutually compatible with
each other -- are we not defining three different semantical
representations that share a common syntax?  How does a receiver know
which semantics to apply, if they share a common media-type codepoint?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The security considerations seem incomplete, at least given my
understanding of the intended technical semantics for the media-type.
Specifically, there is no discussion of how the recipient chooses which
semantics to apply (and the risks of choosing incorrectly), or
discussion of the latent risk when there are supposed to be multiple
equivalent or related components but that's not validated or the
recipient only acts on part of the data.