IETF Logo Mail Archive

[core] Incoming AD review of draft-ietf-core-block-19

Alexey Melnikov <alexey.melnikov@isode.com> Fri, 08 April 2016 16:06 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 8650812D573 for <core@ietfa.amsl.com>; Fri, 8 Apr 2016 09:06:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 G-SG_140sTVZ for <core@ietfa.amsl.com>; Fri, 8 Apr 2016 09:06:11 -0700 (PDT)
Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 0FFD812D1CB for <core@ietf.org>; Fri, 8 Apr 2016 09:06:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1460131568; d=isode.com; s=selector; i=@isode.com; bh=RGxUPBS5AVBZqr4xMgr+y3y7KTJ7C4JP5M/QHw4uLg8=; 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=bzVyVhakfRewgvBakCZPD0sqsZtsni9UFyeckJDnAnf8oPPL2TQTfl6l3ix8POjBwIC3Sd TfBnnQkIhhZgdbqQqVjUTMAgsaFFCVOFDwAMC9/b9y7Y7fDCYvssjpMf8xTa2yiwrOEgZj f/NWRi3YpeBPZE7o0y6mgJ6kTB8Xdc4=;
Received: from [31.133.176.254] (dhcp-b0fe.meeting.ietf.org [31.133.176.254]) by statler.isode.com (submission channel) via TCP with ESMTPSA id <VwfW7gB-m1U1@statler.isode.com>; Fri, 8 Apr 2016 17:06:07 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
To: core@ietf.org
Message-ID: <5707D6F8.40000@isode.com>
Date: Fri, 08 Apr 2016 17:06:16 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------020702090707060701080902"
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/utzalc2PiVLxX2YK4VWJi_m8twU>
Subject: [core] Incoming AD review of draft-ietf-core-block-19
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: Fri, 08 Apr 2016 16:06:13 -0000

Hi,
I am mostly happy with this document, but I have a few comments/questions:

On page 11:

Clients that want to retrieve all blocks of a resource SHOULD strive to
do so without undue delay.

This is not an interoperability issue and it would be impossible to
verify compliance with it, unless you have a number that specifies what
is "undue delay". So I think you shouldn't use RFC 2119 SHOULD here.
Just use lowercased "should" instead.

Similarly, in 2.5:

Clients SHOULD strive to send all blocks of a request without undue delay.

(Similar text in 2.6)


In 2.9.2:

Should probably also mention that this response code is also used for
 mismatching content-format options

In 2.10:

A response with a Block1 Option in control usage with the M bit set
invalidates cached responses for the target URI.

Can you explain the reason for this?

In 3.2:

A stateless server that simply builds/updates the resource in place
(statelessly) may indicate this by not setting the more bit in the
response (Figure 8); in this case, the response codes are valid
separately for each block being updated.

What is the behaviour of both the client and the server if PUT on a
particular block fails? Is this clear enough in the document?

Other questions I have after reviewing the document. If I missed where
they are answered, please point me out to existing text in the document
or another RFC:

Is there a special error for block size mismatch between multiple requests?

As block2 is a critical option, how can a server know if a particular
client supports this option?

Thank you,
Alexey

v2.23.0 | Report a Bug | By Email