Review of draft-murchison-webdav-prefer-11

Stewart Bryant <> Wed, 21 December 2016 19:31 UTC

Return-Path: <>
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 2EB3F129532; Wed, 21 Dec 2016 11:31:57 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Stewart Bryant <>
To: <>
Subject: Review of draft-murchison-webdav-prefer-11
X-Test-IDTracker: no
X-IETF-IDTracker: 6.40.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <>
Date: Wed, 21 Dec 2016 11:31:57 -0800
Archived-At: <>
X-Mailman-Version: 2.1.17
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 21 Dec 2016 19:31:57 -0000

Reviewer: Stewart Bryant
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at


Document: draft-murchison-webdav-prefer-11
Reviewer: Stewart Bryant
Review Date: 21 Dec 2016
IETF LC End Date: 16 January 2017
IESG Telechat date: Unknown

Summary: Ready with issues

This is a well written document with some minor editorial issues that
to be looked at before it is sent to the RFC Editor.


>From ID-nits:

  -- The draft header indicates that this document updates RFC7240,
but the
     abstract doesn't seem to mention this, which it should.


SB> The following suggests an open issue, which needs to be
SB> closed, or if closed already, the issue warning needs to be

Open Issues

   o  Should we add any text regarding caching responses in Section


3.1.  Successful State-Changing Requests

   representating the current state resource in the resulting 201
SB> representating - do you mean representing?


3.2.  Unsuccessful Conditional State-Changing Requests

   Frequently, clients using a state-changing method such as those
   listed above will make them conditional by including either an If-
   Match or If-None-Match [RFC7232] header field in the request. 
   is done to prevent the client from accidentially overwriting a
SB> s/accidentially/accidentally./


9.3.  URIs

SB> I think that this section needs a "remove on publishing
SB> since I think you have given instructions to remove all the
SB> text that calls its entries.