Re: [core] Fwd: New Version Notification for draft-hartke-core-pending-02.txt

Klaus Hartke <hartke@projectcool.de> Mon, 26 February 2018 11:16 UTC

Return-Path: <hartke@projectcool.de>
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 6D3F7126CB6 for <core@ietfa.amsl.com>; Mon, 26 Feb 2018 03:16:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NO_DNS_FOR_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_TEMPERROR=0.01] autolearn=no 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 zHrzUMPWk9qw for <core@ietfa.amsl.com>; Mon, 26 Feb 2018 03:16:46 -0800 (PST)
Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEF5D126D74 for <core@ietf.org>; Mon, 26 Feb 2018 03:16:44 -0800 (PST)
Received: from mail-qk0-f181.google.com ([209.85.220.181]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1eqGlu-0006n0-B1; Mon, 26 Feb 2018 12:16:42 +0100
Received: by mail-qk0-f181.google.com with SMTP id z197so18543570qkb.6 for <core@ietf.org>; Mon, 26 Feb 2018 03:16:42 -0800 (PST)
X-Gm-Message-State: APf1xPDS7htTersqpkMRwX1Rd4yV/EoGAMbZAndEAJz1sMpmXbJG3ukj OqKCG3s88uBtFe8FSm4sXkloi+UEDdG0UTf95dI=
X-Google-Smtp-Source: AG47ELv74t3tc5fPF2qgpEmnt99YSKhJYGm5XFWgRthmwXHfrxJYcNXROtcXerr4V2INIX5mKVoEaA4OM0IfcDnwQvM=
X-Received: by 10.55.15.7 with SMTP id z7mr16307033qkg.312.1519643801351; Mon, 26 Feb 2018 03:16:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.134.195 with HTTP; Mon, 26 Feb 2018 03:16:01 -0800 (PST)
In-Reply-To: <92499CF0-46E3-4FF9-82F7-797D29369558@tzi.org>
References: <151963922478.31478.9450242369979488900.idtracker@ietfa.amsl.com> <7dbaebcd27310388dd4fd0e2e3968609@xs4all.nl> <92499CF0-46E3-4FF9-82F7-797D29369558@tzi.org>
From: Klaus Hartke <hartke@projectcool.de>
Date: Mon, 26 Feb 2018 12:16:01 +0100
X-Gmail-Original-Message-ID: <CAAzbHvY1yrQRxaKTLRYnPZebDwAYiSajZbtSrSYrATKb1dTwJA@mail.gmail.com>
Message-ID: <CAAzbHvY1yrQRxaKTLRYnPZebDwAYiSajZbtSrSYrATKb1dTwJA@mail.gmail.com>
To: Core <core@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1519643805; a3067daa;
X-HE-SMSGID: 1eqGlu-0006n0-B1
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/ch_n2iLUWhHBoF44tOnbfePqHMo>
Subject: Re: [core] Fwd: New Version Notification for draft-hartke-core-pending-02.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 26 Feb 2018 11:16:47 -0000

Carsten Bormann wrote:
>> The current version does not try to extend one already dedicated response code or create a new one.
>
> No, but the draft seems to bend the semantics of existing response codes?

Not really. Or, at least, it shouldn't, although it appears a bit like
it due to the renamed response codes.

The idea is just that the content-format encourages the client to
poll/observe until it gets another content-format.

This should work with unaware intermediaries; only the two ends need
to understand it.

> I think that is mainly a problem with 2.02, which means the resource is gone, but in this case it isn’t really gone just yet?

Good point. Maybe we should restrict it to GET, PUT, and POST?

> I’d rather provide that information in the body (the actual media type behind the content-format needs to be defined, anyway).

The content-format is defined to be absent or a human-readable
diagnostic message (second to last paragraph in Section 2). It might
be worth being able to include application-specific status
information, but I don't have a good idea yet how to indicate the
content-format of that.

Klaus