IETF Logo Mail Archive

[APPS-REVIEW] review of draft-dusseault-http-patch-15

Eliot Lear <lear@cisco.com> Wed, 28 October 2009 18:00 UTC

Return-Path: <lear@cisco.com>
X-Original-To: apps-review@core3.amsl.com
Delivered-To: apps-review@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED85828C1B6 for <apps-review@core3.amsl.com>; Wed, 28 Oct 2009 11:00:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.035
X-Spam-Level:
X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[AWL=0.563, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCvxEHqYCBJm for <apps-review@core3.amsl.com>; Wed, 28 Oct 2009 11:00:27 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 3EED128C179 for <apps-review@ietf.org>; Wed, 28 Oct 2009 11:00:27 -0700 (PDT)
Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmcAAPYj6EqQ/uCWe2dsb2JhbACCITGCIJZMAQEWJAamIocSkRyDbFME
X-IronPort-AV: E=Sophos; i="4.44,641,1249257600"; d="scan'208,217"; a="53027953"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 28 Oct 2009 18:00:39 +0000
Received: from dhcp-10-55-94-136.cisco.com (dhcp-10-55-94-136.cisco.com [10.55.94.136]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9SI0cXi003023; Wed, 28 Oct 2009 18:00:38 GMT
Message-ID: <4AE886C6.20102@cisco.com>
Date: Wed, 28 Oct 2009 19:00:38 +0100
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.5pre) Gecko/20091024 Shredder/3.0pre
MIME-Version: 1.0
To: Lisa Dusseault <lisa.dusseault@gmail.com>, jasnell@gmail.com, "apps-review@ietf.org" <apps-review@ietf.org>
Content-Type: multipart/alternative; boundary="------------060602010901010806090507"
Subject: [APPS-REVIEW] review of draft-dusseault-http-patch-15
X-BeenThere: apps-review@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Applications Review List <apps-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-review>, <mailto:apps-review-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-review>
List-Post: <mailto:apps-review@ietf.org>
List-Help: <mailto:apps-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-review>, <mailto:apps-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Oct 2009 18:00:29 -0000

I have been selected as the Applications Area Review Team reviewer for 
this draft (for background on apps-review, please see 
http://www.apps.ietf.org/content/applications-area-review-team).

Please resolve these comments along with any other Last Call comments 
you may receive. Please wait for direction from your document shepherd 
or AD before posting a new version of the draft.

Document: draft-dusseault-http-patch-15
Reviewer: Eliot Lear
Review Date: October 28, 2009

Review Summary:

This draft is almost ready for publication as a Proposed Standard, but 
should address the one major design issue below before proceeding.

Document Summary:

This document specifies an additional HTTP method, PATCH, which operates 
on a URI in a manner specific to document type.

Major Issues:

There is precisely one key design decision in this document that seems 
to me at all controversial:
Is media-type the appropriate key to determine the appropriate PATCH 
method?  Is that level of indirection correct?  This immediately limits 
the number of PATCH methods per media-type to one, and seems to me to 
provide a difficult route to change the PATCH method.  For example, 
suppose patch(1) became the standard for text/plain, and a new more 
expressive diff/patch came along.  How would that be communicated 
between client and server?  Let's assume for the moment that using a new 
media-type is not the best solution.

Minor issues:

No matter how the authors answer the above question, I would suggest 
that an additional IANA registry for PATCH methods be created.  The 
structure of that registry, however, will depend on the answer to the above.

Nits:

Section 2, 3rd para, last sentence:

> i.e., new resources may be
>     created, or existing ones modified, by the application of a PATCH

or removed?

v2.23.0 | Report a Bug | By Email