Subject: Re: [APPS-REVIEW] [Fwd: Review of metalink I-D]
From: Peter Saint-Andre <[email-masked]>
To: SM <[email-masked]>
Cc: [email-masked]
Date: Fri, 30 Oct 2009 15:17:59 -0600
List-Id: Applications Review List <apps-review.ietf.org>

On 10/30/09 3:09 PM, SM wrote:
> At 13:21 30-10-2009, Peter Saint-Andre wrote:
>> Is there a straightforward way to discover the document shepherd? I
>> don't see that information listed in the datatracker, but I might be
>> missing something.
> 
> You can use https://datatracker.ietf.org/idtracker/  I'll use Lisa's I-D
> as an example.
> https://datatracker.ietf.org/idtracker/draft-dusseault-http-patch/
> mentions the responsible I-D and the Document Shepherd.

Aha, I had ended up at
https://datatracker.ietf.org/drafts/draft-dusseault-http-patch/ instead
of https://datatracker.ietf.org/idtracker/draft-dusseault-http-patch/

> An I-D may not have been assigned to an AD or have a Document Shepherd
> yet.  Should the team review such an I-D?  I'll say maybe if it helps
> the Apps Area ADs decide whether to sponsor the I-D.  But you may be
> reviewing the document too early then (see Alexey's message about the
> intent).

In general we will be reviewing documents in IETF Last Call, so they
will have at least an AD and perhaps a shepherd. We will complete early
reviews if requested, but I think that will be exceptional.

> The bottom line is whether to use the process to determine the
> acceptable level of quality for an I-D to be reviewed.

Yes.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

Date: Fri, 30 Oct 2009 14:09:27 -0700
To: Peter Saint-Andre <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [APPS-REVIEW] [Fwd: Review of metalink I-D]

At 13:21 30-10-2009, Peter Saint-Andre wrote:
>Is there a straightforward way to discover the document shepherd? I
>don't see that information listed in the datatracker, but I might be
>missing something.

You can use https://datatracker.ietf.org/idtracker/  I'll use Lisa's 
I-D as an 
example. 
https://datatracker.ietf.org/idtracker/draft-dusseault-http-patch/ 
mentions the responsible I-D and the Document Shepherd.

An I-D may not have been assigned to an AD or have a Document 
Shepherd yet.  Should the team review such an I-D?  I'll say maybe if 
it helps the Apps Area ADs decide whether to sponsor the I-D.  But 
you may be reviewing the document too early then (see Alexey's 
message about the intent).

The bottom line is whether to use the process to determine the 
acceptable level of quality for an I-D to be reviewed.

Regards,
S. Moonesamy 

Date: Fri, 30 Oct 2009 14:21:53 -0600
From: Peter Saint-Andre <[email-masked]>
To: [email-masked]
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [APPS-REVIEW] [Fwd: Review of metalink I-D]

On 10/30/09 2:04 PM, Barry Leiba wrote:
>> http://www.apps.ietf.org/content/applications-area-review-team has been
>> updated accordingly.
> ...
>> Reviewers: Please send all reviews to the apps-discuss list and make
>> sure to cc the author(s) of the specification you are reviewing!
> 
> I think we should also CC the working-group chairs, for documents that
> belong to WGs, and the document shepherd, if the document has a
> shepherd and that shepherd is not one of the chairs.

Is there a straightforward way to discover the document shepherd? I
don't see that information listed in the datatracker, but I might be
missing something.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

Date: Fri, 30 Oct 2009 16:04:03 -0400
From: Barry Leiba <[email-masked]>
To: Peter Saint-Andre <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [APPS-REVIEW] [Fwd: Review of metalink I-D]
Reply-To: [email-masked]

> http://www.apps.ietf.org/content/applications-area-review-team has been
> updated accordingly.
...
> Reviewers: Please send all reviews to the apps-discuss list and make
> sure to cc the author(s) of the specification you are reviewing!

I think we should also CC the working-group chairs, for documents that
belong to WGs, and the document shepherd, if the document has a
shepherd and that shepherd is not one of the chairs.

Barry

Date: Fri, 30 Oct 2009 19:00:08 +0000
From: Alexey Melnikov <[email-masked]>
To: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [APPS-REVIEW] team update

SM wrote:

> Hi Peter,
> At 11:45 16-10-2009, Peter Saint-Andre wrote:
>
>> And of course if you have suggestions for ways to improve the
>> apps-review team (e.g., a template for reviews, a page for tracking
>> review assignments, etc.), please do send them along.
>
> The reviews are described as "semi-formal reviews of Internet-Drafts 
> as a way to improve the quality of IETF specifications".  The current 
> procedure is for the author to request a review.  The target audience 
> is ill-defined.  Authors who are not familiar with the IETF may not be 
> aware of apps-discuss.
>
> I suggest doing the reviews to help the Apps AD.

This is indeed the intend. Just like SecDir or GenArt reviews.

> That narrows down the target audience and makes the review 
> informational instead of "authors must change their proposal as this 
> review says so".  In addition to review requests, it might be good to 
> identify drafts that have an impact on the Apps Area.  That could be 
> done as a second stage if the team has the energy to do the work.
>
> The subject of the email when submitting the review could be 
> "apps-team review of draft-name".  The email could be copied to 
> document authors, the WG chairs (if applicable), the Document Shepherd,

Indeed, don't forget the shepherd.

> the apps-discuss mailing list and the apps-review mailing list.

Either one of these would be fine as far as I am concerned.

Date: Fri, 30 Oct 2009 11:49:10 -0700
To: Peter Saint-Andre <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [APPS-REVIEW] team update

Hi Peter,
At 11:45 16-10-2009, Peter Saint-Andre wrote:
>And of course if you have suggestions for ways to improve the
>apps-review team (e.g., a template for reviews, a page for tracking
>review assignments, etc.), please do send them along.

The reviews are described as "semi-formal reviews of Internet-Drafts 
as a way to improve the quality of IETF specifications".  The current 
procedure is for the author to request a review.  The target audience 
is ill-defined.  Authors who are not familiar with the IETF may not 
be aware of apps-discuss.

I suggest doing the reviews to help the Apps AD.  That narrows down 
the target audience and makes the review informational instead of 
"authors must change their proposal as this review says so".  In 
addition to review requests, it might be good to identify drafts that 
have an impact on the Apps Area.  That could be done as a second 
stage if the team has the energy to do the work.

The subject of the email when submitting the review could be 
"apps-team review of draft-name".  The email could be copied to 
document authors, the WG chairs (if applicable), the Document 
Shepherd, the apps-discuss mailing list and the apps-review mailing list.

It would be good if the review is not a substitute for reviews from 
outside the Apps Area team.  If I have read the different iterations 
of an I-D, I might not notice some mistakes.  I probably won't pick 
an I-D in here if I commented on it previously.

The above is more of a "think about it" and not a review.

Regards,
S. Moonesamy 

Date: Fri, 30 Oct 2009 11:36:15 -0600
From: Peter Saint-Andre <[email-masked]>
To: Mark Baker <[email-masked]>
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [APPS-REVIEW] [Fwd: Review of metalink I-D]

On 10/30/09 11:26 AM, Mark Baker wrote:
> On Fri, Oct 30, 2009 at 1:28 PM, Peter Saint-Andre <[email-masked]> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Thanks, Mark!
>>
>> I notice that you sent this to apps-discuss. Indeed, that might be a
>> better place to send reviews than apps-review, because apps-discuss has
>> broader distribution and anyone can subscribe (although it is always
>> best to cc the authors).
> 
> I sent my review to apps-discuss primarily because I assumed that was
> already the case, but agree it would make for a good policy.
> 
> Agreed about CCing the authors too.

OK, we have rough consensus. ;-)

http://www.apps.ietf.org/content/applications-area-review-team has been
updated accordingly.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

Sender: [email-masked]
Date: Fri, 30 Oct 2009 14:26:41 -0300
From: Mark Baker <[email-masked]>
To: Peter Saint-Andre <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [APPS-REVIEW] [Fwd: Review of metalink I-D]

On Fri, Oct 30, 2009 at 1:28 PM, Peter Saint-Andre <[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Thanks, Mark!
>
> I notice that you sent this to apps-discuss. Indeed, that might be a
> better place to send reviews than apps-review, because apps-discuss has
> broader distribution and anyone can subscribe (although it is always
> best to cc the authors).

I sent my review to apps-discuss primarily because I assumed that was
already the case, but agree it would make for a good policy.

Agreed about CCing the authors too.

Mark.

Date: Fri, 30 Oct 2009 10:54:09 -0600
From: Peter Saint-Andre <[email-masked]>
To: "[email-masked]" <[email-masked]>
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Subject: [APPS-REVIEW] tracker page

FYI, I've created a page where we can track the reviews completed by our
team:

http://www.apps.ietf.org/content/apps-review-tracker

/psa

Date: Fri, 30 Oct 2009 10:28:12 -0600
From: Peter Saint-Andre <[email-masked]>
To: "[email-masked]" <[email-masked]>
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Subject: [APPS-REVIEW] [Fwd: Review of metalink I-D]

Thanks, Mark!

I notice that you sent this to apps-discuss. Indeed, that might be a
better place to send reviews than apps-review, because apps-discuss has
broader distribution and anyone can subscribe (although it is always
best to cc the authors).

Are there any objections to making that team policy? We would retain
apps-review for team discussions (requesting reviews, complaints about
the team leads, etc.).

/psa

- -------- Original Message --------
Subject: Review of metalink I-D
Date: Thu, 29 Oct 2009 21:46:23 -0300
From: Mark Baker <[email-masked]>
To: [email-masked]

This is my review of draft-bryan-metalink-21.

- - sec 3, last paragraph, it is mentioned that some kinds of white
space can produce an "invalid" document, yet no where is it defined
what that means

- - sec 4.1.2.1.  not sure why "name" is a MUST.  I'm sure metalink
agents can pick a reasonable one, or ask the user, but if it was
required then they might not include this logic.

- - sec 4.2.3.  If metalink:dynamic is intended to be a cue to agents to
redownload the file periodically, you probably also want to give them
an indication of how often to do so.  HTTP caching could be used to do
that.

- - sec 4.2.6, the Openoffice example confused me briefly.  You need to
make sure it's seen to be an example, and also that "OpenOffice.org"
isn't the only possible value.  Perhaps change to;

   The "metalink:identity" element is a Text construct that conveys a
   human-readable name for a file.  For example, the identity of
OpenOffice.org
   3.0 might be "OpenOffice.org", "Openoffice", or "OpenOffice 3.0".

- - sec 4.2.10.2.  do we really need to use a special "torrent" type
when "application/x-bittorrent" could be used?  I'd prefer to stick
just to media type syntax and get rid of the reserved syntax.  You
should also call them "media types" instead of (or as well as if you
prefer) MIME types, and include a reference to BCP 13.

- - in sec 6.3, it's not within the authority of a protocol
specification to tell agents that they "MUST NOT stop processing" or
"MUST NOT change their behaviour".  They might have their own
perfectly good reasons for, say, halting if some XHTML with Javascript
were included.  I agree with what you're trying to accomplish, but
that should be specified by saying, for example, that extensions can
be ignored.

Overall, a decent spec.  It's nice to see extensibility given
considerable attention for a change.

Mark.
_______________________________________________
Apps-Discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

- --
Peter Saint-Andre
https://stpeter.im/

Date: Thu, 29 Oct 2009 15:00:46 -0700
From: Lisa Dusseault <[email-masked]>
To: Aaron Stone <[email-masked]>
Cc: Mark Nottingham <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [APPS-REVIEW] review of draft-dusseault-http-patch-15

On Wed, Oct 28, 2009 at 1:52 PM, Aaron Stone <[email-masked]> wrote:

>
> If it's worth adding some example text, here's a suggestion:
>
> =A0 For example, the common 'diff' utility can generate a patch document =
that
> =A0 applies to multiple files in a directory hierarchy. A client could ap=
ply
> =A0 this patch to a server using the PATCH method on a resource that maps=
 to a
> =A0 directory on the server containing the files to be patched. The requi=
rement
> =A0 for atomicity of the request holds for all affected files.

Thanks!  I would be happy to add this to the doc.  I'll file it as
perhaps an RFC Ed. note to save having to do a new version, unless
there are more changes as a result of IETF Last Call and IESG
Evaluation.

Lisa

Date: Wed, 28 Oct 2009 13:52:02 -0700
From: Aaron Stone <[email-masked]>
To: Eliot Lear <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [APPS-REVIEW] review of draft-dusseault-http-patch-15

On Wed, 28 Oct 2009 19:48:27 +0100, Eliot Lear <[email-masked]> wrote:
> Aaron,
>> My open question:
>> What does one do with a patch document that describes actions on
multiple
>> resources? Should we leave it assumed that this just doesn't make sense
>> in
>> the HTTP context? Or does it make sense, if, say, the resource of the
>> PATCH
>> method maps to a directory and the patch document applies to several
>> files
>> within that directory? In that case, does anything need to be said
about
>> the behavior of PATCH for this type of patch?
>>
>>
>>    
> 
> Here I think the draft is pretty specific:
> 
>     The PATCH
>     method affects the resource identified by the Request-URI, and also
>     MAY have side effects on other resources; i.e., new resources may be
>     created, or existing ones modified, by the application of a PATCH.
> 
> 
> So to me that says, 'yeah, patch might monkey with groups of files'.  
> It's left to the server to decide whether that's allowed.  I would 
> imagine this would be based on who is requesting the operation, and 
> whether the operation would succeed on the individual files separately.

I thought I saw something about multiple resources on first read, but I
missed it the second time around. Thanks for pointing it out. This is the
same place you're suggesting to add 'delete' -- I agree.

If it's worth adding some example text, here's a suggestion:

   For example, the common 'diff' utility can generate a patch document
that
   applies to multiple files in a directory hierarchy. A client could
apply
   this patch to a server using the PATCH method on a resource that maps
to a
   directory on the server containing the files to be patched. The
requirement
   for atomicity of the request holds for all affected files.

> It's a pretty well written draft.

Yep, agreed.

Aaron

Date: Wed, 28 Oct 2009 19:48:27 +0100
From: Eliot Lear <[email-masked]>
To: Aaron Stone <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [APPS-REVIEW] review of draft-dusseault-http-patch-15

This is a multi-part message in MIME format.
--------------030001030606070300010806
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Aaron,
> My open question:
> What does one do with a patch document that describes actions on multiple
> resources? Should we leave it assumed that this just doesn't make sense in
> the HTTP context? Or does it make sense, if, say, the resource of the PATCH
> method maps to a directory and the patch document applies to several files
> within that directory? In that case, does anything need to be said about
> the behavior of PATCH for this type of patch?
>
>
>    

Here I think the draft is pretty specific:

    The PATCH
    method affects the resource identified by the Request-URI, and also
    MAY have side effects on other resources; i.e., new resources may be
    created, or existing ones modified, by the application of a PATCH.

So to me that says, 'yeah, patch might monkey with groups of files'.  
It's left to the server to decide whether that's allowed.  I would 
imagine this would be based on who is requesting the operation, and 
whether the operation would succeed on the individual files separately.

It's a pretty well written draft.

Eliot

--------------030001030606070300010806
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Aaron,<br>
<blockquote cite="mid:[email-masked]"
 type="cite">
  <pre wrap="">My open question:
What does one do with a patch document that describes actions on multiple
resources? Should we leave it assumed that this just doesn't make sense in
the HTTP context? Or does it make sense, if, say, the resource of the PATCH
method maps to a directory and the patch document applies to several files
within that directory? In that case, does anything need to be said about
the behavior of PATCH for this type of patch?

  </pre>
</blockquote>
<br>
Here I think the draft is pretty specific:<br>
<br>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<pre>   The PATCH
   method affects the resource identified by the Request-URI, and also
   MAY have side effects on other resources; i.e., new resources may be
   created, or existing ones modified, by the application of a PATCH.
</pre>
<br>
So to me that says, 'yeah, patch might monkey with groups of files'. 
It's left to the server to decide whether that's allowed.  I would
imagine this would be based on who is requesting the operation, and
whether the operation would succeed on the individual files separately.<br>
<br>
It's a pretty well written draft.<br>
<br>
Eliot<br>
</body>
</html>

--------------030001030606070300010806--

Date: Wed, 28 Oct 2009 11:46:12 -0700
From: Aaron Stone <[email-masked]>
To: Eliot Lear <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [APPS-REVIEW] review of draft-dusseault-http-patch-15

Side note: looks like media types for text/unified-diff, text/context-diff
(or should those be application/vnd.gnu...), vcdiff (which has no media
type registered that I could find), etc., should be registered.

My open question:
What does one do with a patch document that describes actions on multiple
resources? Should we leave it assumed that this just doesn't make sense in
the HTTP context? Or does it make sense, if, say, the resource of the PATCH
method maps to a directory and the patch document applies to several files
within that directory? In that case, does anything need to be said about
the behavior of PATCH for this type of patch?

On Wed, 28 Oct 2009 19:00:38 +0100, Eliot Lear <[email-masked]> wrote:
> 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.

I found Section 3.2 to adequately describe which patch formats a server is
willing to accept for a given resource. The Accept-Patch header is defined
to allow multiple patch formats. A client might have to issue both HEAD and
OPTIONS to learn the media type of the document and the patch formats that
can be used, and you might have to add ETags to protect against a PUT
changing the resource type out from under you, etc. etc., but I don't think
the issue you raise exists.

3.2.  Example OPTIONS Request and Response

   [request]

   OPTIONS /example/buddies.xml HTTP/1.1
   Host: www.example.com

   [response]

   HTTP/1.1 200 OK
   Allow: GET, PUT, POST, OPTIONS, HEAD, DELETE, PATCH
   Accept-Patch: application/example, text/example

   The examples show a server that supports PATCH generally using two
   hypothetical patch document formats.

> 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?

Date: Wed, 28 Oct 2009 19:34:43 +0100
From: Eliot Lear <[email-masked]>
To: Julian Reschke <[email-masked]>
Cc: [email-masked], "[email-masked]" <[email-masked]>
Subject: Re: [APPS-REVIEW] review of draft-dusseault-http-patch-15

On 10/28/09 7:33 PM, Julian Reschke wrote:
> Eliot Lear wrote:
>> Thanks, Julian, for your response.  Please see below:
>>
>>> The media type of the payload of the patch request is completely 
>>> orthogonal to the media type of the thing being patched. Yes, that 
>>> means that we need to define one media type per patch format; but 
>>> that's by design in HTTP, methinks.
>>
>> Ok, I understand.  And so you just re-register a new media-type for 
>> the different PATCH method (assuming the type  doesn't already 
>> exist).  Thus the new header.  Okay.  I withdraw my major concern.
>
> Um, which new header? Accept-Patch?

yes.

Date: Wed, 28 Oct 2009 19:33:15 +0100
From: Julian Reschke <[email-masked]>
To: Eliot Lear <[email-masked]>
Cc: [email-masked], "[email-masked]" <[email-masked]>
Subject: Re: [APPS-REVIEW] review of draft-dusseault-http-patch-15

Eliot Lear wrote:
> Thanks, Julian, for your response.  Please see below:
> 
>> The media type of the payload of the patch request is completely 
>> orthogonal to the media type of the thing being patched. Yes, that 
>> means that we need to define one media type per patch format; but 
>> that's by design in HTTP, methinks.
> 
> Ok, I understand.  And so you just re-register a new media-type for the 
> different PATCH method (assuming the type  doesn't already exist).  Thus 
> the new header.  Okay.  I withdraw my major concern.

Um, which new header? Accept-Patch?

BR, Julian

Date: Wed, 28 Oct 2009 19:30:32 +0100
From: Eliot Lear <[email-masked]>
To: Julian Reschke <[email-masked]>
Cc: [email-masked], "[email-masked]" <[email-masked]>
Subject: Re: [APPS-REVIEW] review of draft-dusseault-http-patch-15

Thanks, Julian, for your response.  Please see below:

> The media type of the payload of the patch request is completely 
> orthogonal to the media type of the thing being patched. Yes, that 
> means that we need to define one media type per patch format; but 
> that's by design in HTTP, methinks.

Ok, I understand.  And so you just re-register a new media-type for the 
different PATCH method (assuming the type  doesn't already exist).  Thus 
the new header.  Okay.  I withdraw my major concern.

Date: Wed, 28 Oct 2009 19:08:50 +0100
From: Julian Reschke <[email-masked]>
To: Eliot Lear <[email-masked]>
Cc: [email-masked], "[email-masked]" <[email-masked]>
Subject: Re: [APPS-REVIEW] review of draft-dusseault-http-patch-15

Eliot Lear wrote:
> ...
> 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.
> ...

The media type of the payload of the patch request is completely 
orthogonal to the media type of the thing being patched. Yes, that means 
that we need to define one media type per patch format; but that's by 
design in HTTP, methinks.

> ...

BR, Julian

Date: Wed, 28 Oct 2009 19:00:38 +0100
From: Eliot Lear <[email-masked]>
To: Lisa Dusseault <[email-masked]>, [email-masked], "[email-masked]" <[email-masked]>
Subject: [APPS-REVIEW] review of draft-dusseault-http-patch-15

This is a multi-part message in MIME format.
--------------060602010901010806090507
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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?

--------------060602010901010806090507
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>

<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body bgcolor="#ffffff" text="#000000">
<div class="moz-text-html" lang="x-unicode">I have been selected as the
Applications Area Review Team reviewer
for this draft (for background on apps-review, please see <a
 href="http://www.apps.ietf.org/content/applications-area-review-team"
 title="http://www.apps.ietf.org/content/applications-area-review-team">http://www.apps.ietf.org/content/applications-area-review-team</a>).
<p>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.</p>
<p>Document: draft-dusseault-http-patch-15<br>
Reviewer: Eliot Lear<br>
Review Date: October 28, 2009<br>
</p>
<p>Review Summary:<br>
</p>
<p>This draft is almost ready for publication as a Proposed Standard,
but should address the one major design issue below before proceeding.<br>
</p>
<p>Document Summary:<br>
</p>
<p>This document specifies an additional HTTP method, PATCH, which
operates on a URI in a manner specific to document type.<br>
</p>
<p>Major Issues:<br>
</p>
<p>There is precisely one key design decision in this document that
seems to me at all controversial: <br>
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.<br>
</p>
<p>Minor issues:<br>
</p>
<p>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.<br>
</p>
<p>Nits:<br>
</p>
Section 2, 3rd para, last sentence:<br>
<br>
<blockquote type="cite">
  <pre>i.e., new resources may be
   created, or existing ones modified, by the application of a PATCH</pre>
</blockquote>
<br>
or removed?<br>
<br>
<br>
</div>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</body>
</html>

--------------060602010901010806090507--

Date: Wed, 28 Oct 2009 10:25:09 -0600
From: Peter Saint-Andre <[email-masked]>
To: Eliot Lear <[email-masked]>
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [APPS-REVIEW] [Fwd: Last Call: draft-dusseault-http-patch (PATCH Method for HTTP) to	Proposed Standard]

Thanks, Eliot!

On 10/28/09 10:12 AM, Eliot Lear wrote:
> I'll take it.
> 
> On 10/28/09 4:39 PM, Peter Saint-Andre wrote:
> Any volunteers to complete a review of this AppsArea I-D? Don't be shy
> just because one of our ADs is the author. ;-)
> 
> /psa
> 
> -------- Original Message --------
> Subject: Last Call: draft-dusseault-http-patch (PATCH Method for HTTP)
> to    Proposed Standard
> Date: Tue, 27 Oct 2009 07:40:21 -0700 (PDT)
> From: The IESG<[email-masked]>
> Reply-To: [email-masked]
> To: IETF-Announce<[email-masked]>
> 
> The IESG has received a request from an individual submitter to consider
> the following document:
> 
> - 'PATCH Method for HTTP '
>     <draft-dusseault-http-patch-15.txt>  as a Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> [email-masked] mailing lists by 2009-11-24. Exceptionally,
> comments may be sent to [email-masked] instead. In either case, please
> retain the beginning of the Subject line to allow automated sorting.
> 
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-dusseault-http-patch-15.txt
> 
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11143&rfc_flag=0
> 
> 
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

Date: Wed, 28 Oct 2009 17:12:57 +0100
From: Eliot Lear <[email-masked]>
To: Peter Saint-Andre <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [APPS-REVIEW] [Fwd: Last Call: draft-dusseault-http-patch (PATCH Method for HTTP) to	Proposed Standard]

I'll take it.

On 10/28/09 4:39 PM, Peter Saint-Andre wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Any volunteers to complete a review of this AppsArea I-D? Don't be shy
> just because one of our ADs is the author. ;-)
>
> /psa
>
> - -------- Original Message --------
> Subject: Last Call: draft-dusseault-http-patch (PATCH Method for HTTP)
> to	Proposed Standard
> Date: Tue, 27 Oct 2009 07:40:21 -0700 (PDT)
> From: The IESG<[email-masked]>
> Reply-To: [email-masked]
> To: IETF-Announce<[email-masked]>
>
> The IESG has received a request from an individual submitter to consider
> the following document:
>
> - - 'PATCH Method for HTTP '
>     <draft-dusseault-http-patch-15.txt>  as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> [email-masked] mailing lists by 2009-11-24. Exceptionally,
> comments may be sent to [email-masked] instead. In either case, please
> retain the beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-dusseault-http-patch-15.txt
>
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11143&rfc_flag=0
>
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkroZZcACgkQNL8k5A2w/vx5wQCfSeUIwd1QU6KeYa0dPqvTJcaQ
> vJkAoOzejuoQ4XtKZ8ytXSi1lPiNlh1z
> =hWZW
> -----END PGP SIGNATURE-----
> _______________________________________________
> APPS-REVIEW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-review
>
>    

Date: Wed, 28 Oct 2009 09:39:03 -0600
From: Peter Saint-Andre <[email-masked]>
To: "[email-masked]" <[email-masked]>
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Subject: [APPS-REVIEW] [Fwd: Last Call: draft-dusseault-http-patch (PATCH Method for HTTP) to	Proposed Standard]

Any volunteers to complete a review of this AppsArea I-D? Don't be shy
just because one of our ADs is the author. ;-)

/psa

- -------- Original Message --------
Subject: Last Call: draft-dusseault-http-patch (PATCH Method for HTTP)
to	Proposed Standard
Date: Tue, 27 Oct 2009 07:40:21 -0700 (PDT)
From: The IESG <[email-masked]>
Reply-To: [email-masked]
To: IETF-Announce <[email-masked]>

The IESG has received a request from an individual submitter to consider
the following document:

- - 'PATCH Method for HTTP '
   <draft-dusseault-http-patch-15.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2009-11-24. Exceptionally,
comments may be sent to [email-masked] instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-dusseault-http-patch-15.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11143&rfc_flag=0

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce

Date: Thu, 22 Oct 2009 09:21:16 -0700
From: Lisa Dusseault <[email-masked]>
To: Peter Saint-Andre <[email-masked]>
Cc: [email-masked]
Subject: Re: [APPS-REVIEW] template

As the Second Life community says,  "Ossm".

Lisa

(if you say it out loud it sounds like "awesome".  took me a while.)

On Thu, Oct 22, 2009 at 9:10 AM, Peter Saint-Andre <[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/21/09 5:08 PM, Eric Burger wrote:
>> I was too lazy to build a template (thanks for doing one!). However,
>> folks found it useful to have links to sample reviews. I would
>> incorporate that, or sample text, on the wiki page.
>
> Links provided at http://www.apps.ietf.org/node/14
>
> /psa
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkrgg98ACgkQNL8k5A2w/vygBACcDcI514pM16zbR4M3lr5dc+/t
> sU4AoLuxZ6dotS6VkJBmjWKJtDYhEta5
> =jSCq
> -----END PGP SIGNATURE-----
> _______________________________________________
> APPS-REVIEW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-review
>

Date: Thu, 22 Oct 2009 10:10:07 -0600
From: Peter Saint-Andre <[email-masked]>
To: Eric Burger <[email-masked]>
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Cc: [email-masked]
Subject: Re: [APPS-REVIEW] template

On 10/21/09 5:08 PM, Eric Burger wrote:
> I was too lazy to build a template (thanks for doing one!). However,
> folks found it useful to have links to sample reviews. I would
> incorporate that, or sample text, on the wiki page.

Links provided at http://www.apps.ietf.org/node/14

/psa

From: Eric Burger <[email-masked]>
To: Peter Saint-Andre <[email-masked]>
Date: Wed, 21 Oct 2009 19:08:21 -0400
Cc: [email-masked]
Subject: Re: [APPS-REVIEW] template

I was too lazy to build a template (thanks for doing one!). However,  
folks found it useful to have links to sample reviews. I would  
incorporate that, or sample text, on the wiki page.

On Oct 21, 2009, at 5:54 PM, Peter Saint-Andre wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I've made a brief template for use in our reviews:
>
> http://www.apps.ietf.org/node/14
>
> Feedback is welcome.
>
> Peter
>
> - --
> Peter Saint-Andre
> https://stpeter.im/
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkrfgy8ACgkQNL8k5A2w/vyy0ACffX7LGL+XYl2cCztculw3Fe1X
> iuoAniPdfMWHJaxVrZL1sQPdb4AElpev
> =rdhU
> -----END PGP SIGNATURE-----
> _______________________________________________
> APPS-REVIEW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-review

Date: Wed, 21 Oct 2009 16:44:29 -0600
From: Peter Saint-Andre <[email-masked]>
To: Aaron Stone <[email-masked]>
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [APPS-REVIEW] template

On 10/21/09 4:40 PM, Aaron Stone wrote:
> Meta review: is it possible to get descriptive uris?

Hey, http://www.apps.ietf.org/node/14 is a fine URL. :P

I've tried to set description URLs but I think I don't have permissions
in our Drupal installation to do that (or Drupal is configured to not
allow it). I'll ask our Drupal administrator about it...

/psa

From: Aaron Stone <[email-masked]>
To: Peter Saint-Andre <[email-masked]>
Date: Wed, 21 Oct 2009 15:40:05 -0700
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [APPS-REVIEW] template

Meta review: is it possible to get descriptive uris?

On Oct 21, 2009, at 2:54 PM, Peter Saint-Andre <[email-masked]>  
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I've made a brief template for use in our reviews:
>
> http://www.apps.ietf.org/node/14
>
> Feedback is welcome.
>
> Peter
>
> - --
> Peter Saint-Andre
> https://stpeter.im/
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkrfgy8ACgkQNL8k5A2w/vyy0ACffX7LGL+XYl2cCztculw3Fe1X
> iuoAniPdfMWHJaxVrZL1sQPdb4AElpev
> =rdhU
> -----END PGP SIGNATURE-----
> _______________________________________________
> APPS-REVIEW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-review

Date: Wed, 21 Oct 2009 15:54:55 -0600
From: Peter Saint-Andre <[email-masked]>
To: [email-masked]
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Subject: [APPS-REVIEW] template

I've made a brief template for use in our reviews:

http://www.apps.ietf.org/node/14

Feedback is welcome.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

Date: Fri, 16 Oct 2009 12:45:54 -0600
From: Peter Saint-Andre <[email-masked]>
To: [email-masked]
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Subject: [APPS-REVIEW] team update

At the Stockholm meeting, Eric Burger asked me if I could take over
leadership of the apps-review team from him. Because Lisa and Alexey
were so convincing, I agreed. Here's what I've been up to:

1. Moved our web page to http://www.apps.ietf.org/node/13

2. Currently recruiting all AppsArea WG chairs to join the team so that
we have a larger team roster and thus a smaller load on each member

Thanks to Marc Blanchet, Eliot Lear, Xiadong Lee, Enrico Marocco, and
Aaron Stone for answering the call for help. Expect more team members soon.

Next, I'll start sending out requests to review a few documents in our
queue, first among them:

draft-bryan-metalink
draft-ietf-geopriv-held-identity-extensions

If you would like to step forward to review one of those I-Ds, please
let me know, otherwise I will start pinging people individually.

And of course if you have suggestions for ways to improve the
apps-review team (e.g., a template for reviews, a page for tracking
review assignments, etc.), please do send them along.

Thanks!

Peter

- --
Peter Saint-Andre
https://stpeter.im/