Re: [core] MULTIPART-CT: A few editorial comments

Christer Holmberg <christer.holmberg@ericsson.com> Fri, 23 August 2019 10:04 UTC

Return-Path: <christer.holmberg@ericsson.com>
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 4FD08120801 for <core@ietfa.amsl.com>; Fri, 23 Aug 2019 03:04:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 rXFM5wP4CncU for <core@ietfa.amsl.com>; Fri, 23 Aug 2019 03:04:18 -0700 (PDT)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10077.outbound.protection.outlook.com [40.107.1.77]) (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 D251F120251 for <core@ietf.org>; Fri, 23 Aug 2019 03:04:17 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LV+pfmvvPFsoPPCa7ikz0gJXaTxBcIz3gOedKjQG/eEUqI67oK2WI34uw+hB2LUECohPum0slY8uSP4BNEuNeFaoigr8rtN6zdPqdxjqBOBogbQbJ+S7EAn+wuazBUOi+IlGw171Qkq6tZS60IF8IMYhJDOsyFlJYUbxAIzxfQyCwkcCyMIOwvLCqK9RE+46akHWN2O5x7vMOG4Dwj21zaBDN0y0jUiVPENf8DFVolH7Tl78IV8AAti29vnKgFZASJ5nooJrykRXNXZ8NHMpRagHDgM2u6pwDukOF7umutU9Dx6Weu0aUz/EemeRuIFFwzFrLpdhyHKfWDbeDRaQXw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KnrgrJV7XZqmE4F/gEKNPxTesdidYaAtAAD6VtTJnf8=; b=VE5ORmVYU1wnLOSx1x6D9PiuModR4/O/0SiOo8p2ixAaopCS83nEz0XEgRVgvqIokKzhheMX9YXaeMQ9BJUbdNYBFn/VRPkLFEqB9WmKjMU2o9D8i6FuSRTCSQiKI1+7UfXel4UebcdiSmb8hotFDMk+d6bxZTocC9e41zUGxMCNCxvjEAY6GC9M2QLZE9Zb9yWTuggUVgMxCL4gU+JThmXhgdYEYxR22816CIsv5lOE81Kz7CF+tmtIcTlp+7VV7YIKEIqOC66KFh11s1n5XnuW1xAX/lGvh2RxrD6/g4rT3ES05iyFN0SuZX7PNKVH2FY7bFBtZYDGLzLFqN/QmQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KnrgrJV7XZqmE4F/gEKNPxTesdidYaAtAAD6VtTJnf8=; b=j9knHTjQBSbMt1DEXQUORs9TF4D5a9hSFGvOR9F+pQA2GGCTlrV+WiU9VRGxD4kAUbzgJ1gGO8S4yRqBoTLUsVdzyKimbYB00hPmUXx5ctXLlmYqX9DaRw8eJp37lYCY1of2NLFjB4yPGrVPNNu/dh0YHGxKrga3JEhoFOVbZTE=
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4299.eurprd07.prod.outlook.com (20.176.166.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.12; Fri, 23 Aug 2019 10:04:15 +0000
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::f0a1:2199:7816:ff8d]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::f0a1:2199:7816:ff8d%6]) with mapi id 15.20.2220.009; Fri, 23 Aug 2019 10:04:15 +0000
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Carsten Bormann <cabo@tzi.org>, core <core@ietf.org>
Thread-Topic: [core] MULTIPART-CT: A few editorial comments
Thread-Index: AQHVQWZgcXFsFiMu/0yz/ihjx4/NdacGPfhAgADfDgCAAcazAA==
Date: Fri, 23 Aug 2019 10:04:15 +0000
Message-ID: <A5B0CDBB-6A2A-40C0-B9AC-01784FA02250@ericsson.com>
References: <189192D6-F32E-450F-998F-20FA87761487@ericsson.com> <HE1PR07MB316145ACB50BED8616460D3993AA0@HE1PR07MB3161.eurprd07.prod.outlook.com> <20745914-A504-4181-B39D-742C62688C46@tzi.org>
In-Reply-To: <20745914-A504-4181-B39D-742C62688C46@tzi.org>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1b.0.190715
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com;
x-originating-ip: [89.166.49.243]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 56cf5c40-4857-42d5-704f-08d727b1412c
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB4299;
x-ms-traffictypediagnostic: HE1PR07MB4299:
x-microsoft-antispam-prvs: <HE1PR07MB4299B265618104E5CD70B22193A40@HE1PR07MB4299.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0138CD935C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(346002)(376002)(136003)(366004)(189003)(199004)(76116006)(66946007)(71200400001)(71190400001)(66476007)(66556008)(64756008)(66446008)(478600001)(6436002)(26005)(229853002)(53936002)(486006)(66066001)(5660300002)(44832011)(36756003)(25786009)(186003)(14444005)(256004)(33656002)(3846002)(14454004)(476003)(11346002)(446003)(2616005)(110136005)(81156014)(81166006)(6512007)(99286004)(7736002)(305945005)(8936002)(6246003)(76176011)(2906002)(58126008)(8676002)(6116002)(6486002)(6506007)(86362001)(102836004)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4299; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: mlocvnUcDGO10Z7EQiGpYflu/I432srzTK5DkOgCioNXp6kIcoELmH4JTU6N+zZYbI7sH+Gb6276RjbcNkVTx1YoR2Lqk1d8K79TtadTeMFeuldHGk+vjaM1QJafEY7vzayTh6HKV5n4JetUFvd6K0UpOlBSbFa/0p+LqeGLqpwZ8HbzSsVetXwWuRJrbfDyVEY5AH9CwW6LY71g/dFHdjYIP47xZj/v0If7bNZ0RHv7Pf4tDF6+9yY4b6o0erm9cdaU37cu9M4IezziTJS9BAL0aa2e5DQVQD/FfwpQlmJpWN6/m+X60TME5nGnarYTCMxX3y9WPloKsh+RG5Yv0OZudmDPeM+cJsyWsPnMMk+DNPpTnJ9RRm8ilUewX14pvDYB8+c0U/QxU16ydNjD7CKu2K3nE3hnGdGrmwVOypo=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <05215241671781419860F4233B2CAAFC@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 56cf5c40-4857-42d5-704f-08d727b1412c
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Aug 2019 10:04:15.1541 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: J3T9wYE0NZec6rK7p/5PatMA5bzbiF5+RzkSpUtjeCD1lbK3uTN2T8xZ1gWnaGKomIAYPKmkG1kvdrp5sFxsfMUJakcWgSuA7WWzRuKTaTQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4299
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/tZSDwNmdZ0XzprVNlpNpEmwme7c>
Subject: Re: [core] MULTIPART-CT: A few editorial comments
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: Fri, 23 Aug 2019 10:04:20 -0000

Hi,

Q1:
     
>> The Introduction says talks about “request or response body’.
>> 
>> However, when looking in RFC 7252, I don’t find ‘body’ anywhere.
>    
>   Right.  Body is an RFC 7959 term (which was adapted from HTTP’s “Message Body”, obviously).

When we define a CoAP extension, we should adapt the terminology used in 7252. 

"CoAP request or response body" is not MULTIPART-CT specific terminology - it is something that should be defined in 7252.

Also, I have no problem separating between "body" and "body payload" (or just "payload"), but the difference needs to be described.

> I didn’t really want to muddy the picture by explaining again that CoAP block-wise transfers can cut up a 
> single body into multiple payloads (as per RFC 7959).  The current text already might be misunderstood to
> say that this media type is CoAP specific, which it is not at all.
>  
> We didn’t go to the trouble of having a formal terminology import section (apart from the usual BCP14 boilerplate in 1.1).  
> We could add that text, reference 7959 and 7230 as well, and make this abundantly clear.  Or we could leave it as it is.
   
When you refer to different parts/content of a CoAP message, there needs to be a definition of what it is.

>> I assume that ‘body’ refers to what RFC 7252 calls ‘payload’. If so, I suggest aligning the terminology.
>> 
>> (For some reason section 10.2.3 of RFC 7252 does use ‘message-body’, without any explanation or reference, but I guess that is just an error)
>    
>    That is about the message-body on the HTTP side, so it is exactly as it should be.
>    
>    (Actually, 1.2 of 7252 says 
>     »This specification requires readers to be familiar with all the terms
>      and concepts that are discussed in [RFC2616], including "resource",
>      "representation", "cache", and "fresh".  (Having been completed
>      before the updated set of HTTP RFCs, RFC 7230 to RFC 7235, became
>      available, this specification specifically references the predecessor
>      version -- RFC 2616.)  In addition, this specification defines the
>      following terminology: « […]
>
>    So this term is already defined in RFC 7252, albeit implicitly only.)  

HTTP does not define "CoAP request or response body".

And, even if it does, why is "body" not used in 7252? 

---
  
  Q2:
   
  >> Related to Q1, the text says:
  >> 
  >>   “can be used to combine representations of zero or more different media types into a single message”
  >  
  >  Actually, it now says
  >  
  >    This memo defines application/multipart-core, an application-
  >    independent media-type that can be used to combine representations of
  >    zero or more different media types, each along with a CoAP Content-
  >     Format identifier, into a single representation, with minimal framing
  >    overhead.  This combined representation may then be carried in a
  >    single message, such as a CoAP [RFC7252] request or response body.
  >  
  > (Where “message” might be a whole block-wise transfer.)
  >  
  >  Is that better?
    
  The text looks better, eventhough it still uses "request or response body" (see Q1).

  However, my understanding of "message" is a CoAP request or response. If it means something else, you need to define it.

---

Regards,

Christer