IETF Logo Mail Archive

Re: [core] Spencer Dawkins' Discuss on draft-ietf-core-etch-03: (with DISCUSS and COMMENT)

Alexey Melnikov <alexey.melnikov@isode.com> Thu, 13 October 2016 11:19 UTC

Return-Path: <alexey.melnikov@isode.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 346A5129732; Thu, 13 Oct 2016 04:19:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.997
X-Spam-Level:
X-Spam-Status: No, score=-4.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 6euYPs197sng; Thu, 13 Oct 2016 04:19:14 -0700 (PDT)
Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id C3BC012972F; Thu, 13 Oct 2016 04:19:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1476357554; d=isode.com; s=june2016; i=@isode.com; bh=PU+DI0VzeW1BgfMOannjXSzndRGj3qsIJLY5OUvD79s=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=vqHI0ZR89SFZXEdop0J62spottyB8/DdBKfjE0FQ3FtCUFyfjfep2ZkrLodUPfT6kx2QLj LZK82j28vlrkMObvCI7SAyw005s3L2usi57BjzHk1TpQ+N8khhshaBwmE96kEZK2PhQH3/ ZeJgS+Y++UuwCNGtoGYugAwUgEc1IYc=;
Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id <V=9tsQBM5W-n@waldorf.isode.com>; Thu, 13 Oct 2016 12:19:13 +0100
To: Carsten Bormann <cabo@tzi.org>, Alexey Melnikov <aamelnikov@fastmail.fm>
References: <147628802464.6377.2774521252462284021.idtracker@ietfa.amsl.com> <3ad76e63e6f6b955b5373a5521bcca98@xs4all.nl> <1476356714.1601674.754646289.1E106782@webmail.messagingengine.com> <57FF6CF3.7090703@tzi.org>
From: Alexey Melnikov <alexey.melnikov@isode.com>
Message-ID: <a154b556-b15e-e548-de09-93a3944b3e78@isode.com>
Date: Thu, 13 Oct 2016 12:18:51 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
In-Reply-To: <57FF6CF3.7090703@tzi.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/Ih2hy7yTWYHbKu0_DSndhJpTRwY>
Cc: draft-ietf-core-etch@ietf.org, core-chairs@ietf.org, Spencer Dawkins <spencerdawkins.ietf@gmail.com>, core@ietf.org, The IESG <iesg@ietf.org>
Subject: Re: [core] Spencer Dawkins' Discuss on draft-ietf-core-etch-03: (with DISCUSS and COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 13 Oct 2016 11:19:16 -0000

Hi Carsten,


On 13/10/2016 12:16, Carsten Bormann wrote:
> Alexey Melnikov wrote:
>> Does this mean that a client that wants doesn't care about idempotency
>> of its request might need to try PATCH, then discover that it is not
>> supported and then retry iPATCH?
> How does it know that the server supports one of these methods (PATCH,
> iPATCH) in the first place, and what media types to use with one of
> these?  This is usually found out using discovery (for an example, see
> the form relations concept introduced in draft-hartke-core-apps).  This
> discovery would also tell the client which specific method to use, so
> there is no need for trial and error.
This would be a useful text to add.
> What we could add is a recommendation for servers to always support both
> methods (that is not hard to do, because what follows), and emphasize
> that there is no particular onus *on the server* to check the client's
> intention that the request be idempotent.
Sound good to me!

v2.23.0 | Report a Bug | By Email