Re: [Ace] ace-coap-est-08: using /skg with Accept Option set to TBD287

Peter van der Stok <stokcons@bbhmail.nl> Wed, 13 February 2019 08:00 UTC

Return-Path: <stokcons@bbhmail.nl>
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 041FB12D4E6 for <ace@ietfa.amsl.com>; Wed, 13 Feb 2019 00:00:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bbhmail.nl
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 NN3iOSSaHTmw for <ace@ietfa.amsl.com>; Wed, 13 Feb 2019 00:00:44 -0800 (PST)
Received: from smtprelay.hostedemail.com (smtprelay0213.hostedemail.com [216.40.44.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FC96128CB7 for <ace@ietf.org>; Wed, 13 Feb 2019 00:00:44 -0800 (PST)
Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay03.hostedemail.com (Postfix) with ESMTP id 9932083777E3; Wed, 13 Feb 2019 08:00:42 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbhmail.nl; h= mime-version:content-type:date:from:to:cc:subject:reply-to :in-reply-to:references:message-id; s=key; bh=Tqc1hJAEkRf7QC7EK7 3LALHNJ6Q80fcZDUHtf1NqfbY=; b=Bfd3S4o5pMsJ30slEeWhBnfUlAUEQmDDKQ 0Bf/1f5k7z92TK18fihNj4ZG7ngvvgSZh/aPrrugx3QRL0woFIqyZjpC5XToYwoF xnsh63i3SdAwFx8AEo9HCYlLzh42uOQBCpRVwyElC5vsm2Jd5B+cFaNsDIZW62gg v4oboUfpc=
X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C
X-Spam-Summary: 2, -10, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::::, RULES_HIT:41:72:152:355:379:582:599:800:962:967:968:973:983:988:989:1152:1189:1208:1212:1221:1260:1313:1314:1345:1359:1431:1436:1437:1516:1517:1518:1535:1544:1575:1588:1589:1592:1594:1711:1730:1777:1792:2068:2069:2198:2199:2525:2527:2528:2559:2564:2682:2685:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3355:3622:3865:3866:3867:3868:3870:3871:3872:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4120:4250:4321:4470:4860:5007:6117:6119:6120:6261:6657:6659:6678:7875:7903:8603:8985:9010:9025:9177:10004:10848:11232:11658:11914:12043:12050:12291:12379:12438:12663:12683:12740:12895:13139:13141:13161:13229:13230:13439:13846:13891:13972:14095:14096:14180:14181:14721:21060:21063:21080:21433:21451:21611:21627:21790:30054:30060:30080:30083:30089, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bu
X-HE-Tag: aunt02_7a8ccb86fd236
X-Filterd-Recvd-Size: 9552
Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf16.hostedemail.com (Postfix) with ESMTPA; Wed, 13 Feb 2019 08:00:42 +0000 (UTC)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_0023970c30eb010022c8748a69f258c4"
Date: Wed, 13 Feb 2019 09:00:41 +0100
From: Peter van der Stok <stokcons@bbhmail.nl>
To: Klaus Hartke <hartke@projectcool.de>
Cc: "Panos Kampanakis (pkampana)" <pkampana@cisco.com>, Esko Dijk <esko.dijk@iotconsultancy.nl>, ace@ietf.org
Organization: vanderstok consultancy
Reply-To: consultancy@vanderstok.org
Mail-Reply-To: consultancy@vanderstok.org
In-Reply-To: <CAAzbHvbD0B0A6L4-YCXVRhmKMRCUmTWaOJrtSZOQkbRfhsQBuQ@mail.gmail.com>
References: <DB6P190MB0054313C1BA6E125FA07813BFD650@DB6P190MB0054.EURP190.PROD.OUTLOOK.COM> <CAAzbHvaMTXgzKtMbpVpbXfT1EKjJu4L3zM5hesrNPgG+BqfoJw@mail.gmail.com> <9594d00cd7bc43e496c2c5073481e637@XCH-ALN-010.cisco.com> <CAAzbHvbD0B0A6L4-YCXVRhmKMRCUmTWaOJrtSZOQkbRfhsQBuQ@mail.gmail.com>
Message-ID: <cdc4b359dc58bb7753a5e497b6b9420a@bbhmail.nl>
X-Sender: stokcons@bbhmail.nl
User-Agent: Roundcube Webmail/1.2.7
X-Originating-IP: [86.203.169.153]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/eSuq4u0lDJJtBUWgNgOk4hjAaxs>
Subject: Re: [Ace] ace-coap-est-08: using /skg with Accept Option set to TBD287
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: Wed, 13 Feb 2019 08:00:47 -0000

HI all,

I have seen at least two viable solutions to the content-format
associated with draft-ietf-core-multipart-ct.
Probably, there are more possibiities.
Of course est-coaps can take over any of those solutions, but it then
remains a local est-coaps solution.
IMO the problem is more general.

I suggest that a solution is standardized in either
draft-ietf-core-multipart-ct or in a new to create draft.
The current text can then be removed from est-coaps and replaced with a
refrence to the text to be created.

Reactions?

Peter
Klaus Hartke schreef op 2019-02-12 22:35:

> Panos Kampanakis wrote: 
> 
>> Well, RFC7252 refers to a singular content format. In our case we are talking about a dual content format (286 or 281 and 280 or 284) returned in a 62 multipart-content. Would it be a violation of RFC7252, since RFC7252's text had single content format responses in mind only?
> 
>> From the point of view of CoAP, there is just a representation with
> content-format 62. A client can indicate that it accepts a
> representation with content-format 62; the server then is required to
> return either a representation with content-format 62 or an error.
> CoAP is not aware that the representation happens to contain embedded
> representations and therefore the content negotiation mechanism cannot
> be used directly to negotiate the formats of those.
> 
> Maybe thedraft-ietf-core-multipart-ct  should extend the semantics of "Accept" to cover this case?

A content format is not a protocol extension and cannot override the
protocol definition.

> I think that is good idea. The simplest way to do that would be encode the 3 content formats (for example 62, 286 and 280) into a single CF included in the Accept option which tells the server what combination of content formats to send back. Would that violate RFC7252 because the Content-Formats needs to be actual CFs defined in the IANA registry and not a combination of them?

The value of the Accept option in the request needs to be registered
in the IANA registry and the value of the Content-Format option in the
response must be the same as Accept value.

Of course, one possible solution is to drop the use of content format
ID 62 entirely and just register one ID for each possible combination.
(But then the client can still only include at most one Accept option
in its request.)

> From a previous thread with Jim S., I was under the impression that In the virtual CoAP WG meeting a month back we went through in some explicit detail that both Content-Format and Max-Age have no meaning when appearing on a request and therefore should not be there.

Max-Age doesn't have a meaning in requests and therefore must not be
there. I'm not sure where that about the Content-Format option comes
from. If a POST request has a payload, then the format of that payload
is described by a Content-Format option. (A GET request doesn't have a
payload and therefore must not include a Content-Format option.)

Klaus

_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace