Subject: Comments on draft-dusseault-http-patch-06

From: Julian Reschke <[email-masked]>
Date: Sun, 17 Oct 2004 11:47:53 +0200

Hi,

below are some first comments on 
<http://ietf.org/internet-drafts/draft-dusseault-http-patch-06.txt>.

Best regards, Julian

C-06-01, Change to IM

I think this change goes into the wrong direction. As far as I can tell, 
there was a consensus to use the Content-Type header to identify the 
patch format. The open issue was to define one required patch format 
(with no IPR issues) and to make sure that there was a MIME type 
registered for it. This is the problem we should be solving. See also 
Roy Fielding's comment in 
<http://lists.w3.org/Archives/Public/ietf-http-wg/2004AprJun/0086.html>:

 >> The IM header field serves no other purpose than to duplicate
what content-type is already defined to perform, and has the
added complexity of reinterpreting the meaning of the existing
error messages in HTTP that tell the client when a type is not
supported.  This is not the same problem as addressed in delta
encoding (i.e., server push replication) and does not need IM
as a solution.  Failure to define vcdiff and gdiff in the media type
registry is no excuse for adding complexity to HTTP.  I would
rather see the specification define "application/vcdiff" and
"application/gdiff" in the appendices, which it is certainly
capable of doing on behalf of the IETF, rather than allow media
type registration exemptions just because the owners had no
need for those types. <<

So in general, I think the draft needs to revert back to the -05 format. 
I'll report a few other problems with this change separately, though.

C-06-02, Section 2

<http://greenbytes.de/tech/webdav/draft-dusseault-http-patch-06.html#rfc.section.2>

"A set of changes for a resource is itself a document, called a delta 
encoding."

I'm confused about whether a "delta encoding" is a patch format (as 
identified in the IM header) or a particular instance of a patch request 
body See first para of section 3.1). Could you please clarify?

C-06-03, Section 2

<http://greenbytes.de/tech/webdav/draft-dusseault-http-patch-06.html#rfc.section.2>

"Servers SHOULD support PATCH and the vcdiff delta encoding for all 
authorable resources..."

As far as I can tell, there's an open issue with the IPR on vcdiff, as 
reported by Roy Fielding in 
<http://lists.w3.org/Archives/Public/ietf-http-wg/2004AprJun/0086.html>:

 >> Servers SHOULD NOT support the VCDIFF format until its IP restrictions
are clarified and made available royalty-free for all uses of HTTP,
at a minimum, and not just use within HTTP/1.1 as defined in 2001. <<

C-06-04, Section 3.1, para 4

<http://greenbytes.de/tech/webdav/draft-dusseault-http-patch-06.html#rfc.section.3.1.p.4>

"The PATCH request MAY include a Content-Type header which is the 
content-type of the resource to which the delta encoding is to be applied."

That seems to break HTTP semantics, because the Content-Type header is 
supposed to identify the type of the request body, not the one of the 
entity it's applied to. Furthermore, the information seems to be 
completely useless unless you specifify what a server is to do in case 
of a mismatch.

C-03-08, Section 3.2.2

2) Make this optional for servers that do not care about WebDAV.

3) Stick to RFC3253's terminology (the names identify conditions, not 
errors, thus

s/DAV:delta-format-unsupported/p:delta-format-supported/
s/DAV:delta-format-forbidden-on-resource/p:delta-format-allowed-on-resource/
s/DAV:delta-format-badly-formatted/p:delta-documented-well-formatted/
s/DAV:delta-empty-resource/p:delta-format-applies-to-empty/
S/DAV:patch-result-invalid/p:patch-result-valid/

-05 update: Right now it's unclear whether this is normative. If it is,
the reference to RFC3253 needs to be moved into the Normative References
section.

E-05-01, Abbreviations

...should be expanded the first time they appear in the next.

E-05-02, Security considerations

The one mentioned doesn't seem to be a *Security* consideration at all. 
It's more about correctness/robustness, isn't it?

E-06-01, mailing list

Mention the mailing list where document feedback should be sent to 
somewhere.

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Lisa Dusseault <[email-masked]>
Date: Sun, 17 Oct 2004 15:52:11 -0700

Jeffrey Mogul suggested this change from the -05 model; I think it 
works at least as well as the model where the request body is modelled 
as an instance.  It's entirely consistent with RFC3229's model.  And 
instead of using the IANA MIME type registry, it uses the IANA 
instance-manipulation registry.  Do you have any technical objections 
to using the IM header and the instance-manipulation values?

> completely useless unless you specifify what a server is to do in case 

The model of HTTP used by RFC3229 is one in which the Content-Type 
header applies to the entity's body type.  Then when an instance 
manipulation is applied the request body might end up in gzip format or 
in a patch format, but the Content-Type doesn't change.  The proposal 
does specify what to do in case of a mismatch -- the server is 
requested to change the MIME type of the resource to the new one 
provided by the client.

BTW, the change to call the patch documents "delta encodings" is also 
to be more consistent with RFC3229 now that I understand it better.

I really don't know what to do about the IPR issue around VCDIFF since 
I am not a lawyer; since the IESG already made RFC3284 into a Standards 
Track document, I assume this will be acceptable.

Thanks,
Lisa

---

From: Roy T. Fielding <[email-masked]>
Date: Sun, 17 Oct 2004 22:45:24 -0700

> to using the IM header and the instance-manipulation values?

I already gave my technical objections.  HTTP doesn't allow it.  You
can't just redefine the messaging model of HTTP (and, in this case,
MIME) while defining a method.  There is no way to do that in HTTP
because there is no way to check that all servers between the client
and the origin are aware of this abuse before sending the message,
nor is there any technical reason for redefining an existing header
field to mean something other than what is in two Draft Standards.

In short, the IM suggestion is a dead end.  It will not survive IESG
review and it will not be deployed, just as RFC 3229 has not been
deployed.  If you continue down this path, then I formally request that
you stop abusing the method that I already defined and change the
method name to something that I can ignore, like "VCDIFF".

....Roy

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 18 Oct 2004 10:21:49 -0700

On Oct 17, 2004, at 10:45 PM, Roy T. Fielding wrote:

>> works at least as well as the model where the request body is 
>> modelled as an instance.  It's entirely consistent with RFC3229's 
>> model.  And instead of using the IANA MIME type registry, it uses the 
>> IANA instance-manipulation registry.  Do you have any technical 
>> objections to using the IM header and the instance-manipulation 
>> values?
>
> I already gave my technical objections.

I've searched through the earlier mail I'd cached from you on this 
topic, can you point out which are the technical objections?  It's been 
my impression that there are duelling theories of HTTP here, and most 
of the arguments were theoretical.  One of the duelling theories may be 
revisionist; one of those theories may better match what the original 
authors had in mind; I don't know.  Personally I'm more interested in 
what works better, partly for PATCH in specific and partly for HTTP 
extensibility in general.

> HTTP doesn't allow it.  You
> MIME) while defining a method.

Why is this redefining MIME?  I understand how it's a different 
messaging model of HTTP from the one you prefer, but I don't understand 
how it redefines MIME.  As I understand it, RFC3229 uses MIME types to 
describe the entity or instance without redefining MIME.

As for redefining the messaging model of HTTP: RFC2616 has other 
headers that refer to the entity or the instance, and not to the 
message body.  For example, "The MD5 digest is computed based on the 
content of the entity-body, including any content-coding that has been 
applied, but not including any transfer-encoding applied to the 
message-body."   That means that Content-MD5 is calculated from what 
RFC3229 labels an "instance".  It seems to me that RFC3229 only defined 
a name, "instance", for something which already existed.

I do realize that RFC2616 is ambiguous, and I don't mean to justify one 
theory based on legalistic readings of the spec.  On the one hand, 
RFC2616 says "Content-Type specifies the media type of the underlying 
data.".  On the other hand, RFC2616 says "Any HTTP/1.1 message 
containing an entity-body SHOULD include a Content-Type header field 
defining the media type of that body."  Both these sentences are in 
section 7.2.1! The first sentence seems to support RFC3229's model; the 
second sentence seems to support your (Roy's) preferred model.  
Standards are rarely perfect; ambiguous language like this leaves lots 
of room for interpretation of how the model can be refined and how HTTP 
can be extended.  So I tend to devalue arguments based only on selected 
text from the standard; I'd like to hear more arguments based on 
harmful intermediary interactions or implementation concerns.

> There is no way to do that in HTTP

I'm definitely sympathetic to concerns about intermediaries (that's why 
I'm doing PATCH -- because I'm worried about the way XCAP is redefining 
PUT and GET).  However, I don't yet understand what an intermediary 
might do with a new method it hasn't seen before (PATCH) that has a 
header it has seen before (Content-Type) that could be harmful.  An 
intermediary can't cache the body of a method it hasn't seen before 
(e.g. PROPPATCH request and response bodies are similarly uncached in 
practice).  An intermediary can apply transfer-encodings but I don't 
see how that could be harmful.  For example, an intermediary could 
apply chunked transfer encoding to a PATCH body in either the PATCH -05 
proposal or the PATCH -06 proposal without harm.  Or am I missing 
something?  What else can an intermediary do and how might it be 
harmful?

I did realize one advantage of the PATCH with IM approach, and that is 
to create a new resource of a specified type.  For example:

        PATCH /file.ics HTTP/1.1
        Host: www.example.com
        Content-Type: text/calendar;component=VEVENT
        IM: vcdiff
        If-Match: "e0023aa4e"
        Content-Length: 100

        [vcdiff-bytes]

 >>Response:

        HTTP/1.1 201 Created
        ...

This would create a new file of type text/calendar.  With the PATCH -05 
proposal, there wasn't a way to use PATCH to create a new resource and 
assign the correct MIME type to begin with.

So what's the consensus here or do we need more light on these issues 
before we can reach a consensus?  Do any implementors have 
implementation considerations related to this issue, and are there 
realistic intermediary problems as I already asked?  How much of a 
religious war is it?    I'm not personally religious on this, I'm 
caught between the duelling theories and I'd just like to understand 
the practical considerations better.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Mon, 18 Oct 2004 19:43:00 +0200

Lisa Dusseault wrote:
> text from the standard; I'd like to hear more arguments based on harmful 
> intermediary interactions or implementation concerns.

Quoting the section fully 
(<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.7.2.1>):

 >> 7.2.1 Type

When an entity-body is included with a message, the data type of that 
body is determined via the header fields Content-Type and 
Content-Encoding. These define a two-layer, ordered encoding model:

        entity-body := Content-Encoding( Content-Type( data ) )

Content-Type specifies the media type of the underlying data. 
Content-Encoding may be used to indicate any additional content codings 
applied to the data, usually for the purpose of data compression, that 
are a property of the requested resource. There is no default encoding.

Any HTTP/1.1 message containing an entity-body SHOULD include a 
Content-Type header field defining the media type of that body. If and 
only if the media type is not given by a Content-Type field, the 
recipient MAY attempt to guess the media type via inspection of its 
content and/or the name extension(s) of the URI used to identify the 
resource. If the media type remains unknown, the recipient SHOULD treat 
it as type "application/octet-stream".  <<

I think that's clear enough, specifically the first sentence.

> assign the correct MIME type to begin with.

If this is a required feature, it could be implemented using a new 
request header.

Anyway, if the change between 05 and 06 just was based on the problems 
registering a MIME tyoe, then I think that was the wrong approach to 
solving it.

Proposal: as both GDIFF (unclear IPR and no MIME type) and VCDIFF 
(unclear source license and complexity?) seem to be problematic as 
REQUIRED delta format, we may want to sit down and come up with a really 
simple delta format and use *that* in the PATCH spec (either in-line or 
in a separate document).

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 18 Oct 2004 11:24:06 -0700

> REQUIRED delta format, we may want to sit down and come up with a 
> really simple delta format and use *that* in the PATCH spec (either 
> in-line or in a separate document).

That sure sounds reasonable; are you up for that?  I'm not given my 
other responsibilities right now.  Does anybody know if diff -e is 
standardizable?

I have also looked into a standard XML diff format, and talked to 
Adrian Mouat about standardizing his format.
  - code: http://treepatch.sourceforge.net/  or 
http://diffxml.sourceforge.net/
  - dissertation/specification: 
http://prdownloads.sourceforge.net/diffxml/dissertation.ps?download

I would think diff formats would generally be better off defined in 
separate documents so that they can be reused, HTTP and PATCH are by no 
means the only applications that could use a standard diff format.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Mon, 18 Oct 2004 21:40:59 +0200

Lisa Dusseault wrote:

> I have also looked into a standard XML diff format, and talked to Adrian 
> Mouat about standardizing his format.

I probably wouldn't have the time to take ownership, but I certainly 
would want to help. IMHO, the goal should be to have a very simple 
format for binary diffs, similar with functionality equivalent with GDIFF.

Re: "diff -e": this is part of the GNU Diff documentation 
(<http://www.gnu.org/software/diffutils/manual/html_node/Detailed-Normal.html#Detailed%20Normal>), 
so it should be possible to use it without IPR-fear :-)

Best regards, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 18 Oct 2004 16:18:50 -0700

On Oct 18, 2004, at 10:21 AM, Lisa Dusseault wrote:
> messaging model of HTTP from the one you prefer, but I don't 
> understand how it redefines MIME.  As I understand it, RFC3229 uses 
> MIME types to describe the entity or instance without redefining MIME.

Content-Type is a MIME header field.  It is defined by MIME.
MIME and HTTP share a header field space, which was discussed
extensively in 1994.  The Area Directors (at that time) absolutely
forbid HTTP to redefine the meaning of existing e-mail header fields
because there was general concern that such messages might leak out
into the e-mail space and cause rampant confusion.

> RFC3229 labels an "instance".

That is incorrect.  3229 defines instance (what I had been calling
"representation" since 1996, but which doesn't appear in 2616 because
Jeff objected to the name and the other editors were unwilling to
choose one name over another, but that is a much longer story) as
what would be transferred in a 200 response.  The entity-body, in
contrast, is the sequence of octets inside the message-body after
decoding the transfer-encoding (if any).  Thus, Content-MD5 is
calculated based on what is in the message, not the "instance".
See section 9 of RFC 3229.

> It seems to me that RFC3229 only defined a name, "instance", for 
> something which already existed.

Yeah, for "representation", which is only the same as entity-body when
it is a 200 response to a GET request.  RFC 3229 defines 226 responses.

> I do realize that RFC2616 is ambiguous, and I don't mean to justify 
> one theory based on legalistic readings of the spec.  On the one hand, 
> section 7.2.1! The first sentence seems to support RFC3229's model; 
> the second sentence seems to support your (Roy's) preferred model.  
> of room for interpretation of how the model can be refined and how 
> HTTP can be extended.  So I tend to devalue arguments based only on 
> selected text from the standard; I'd like to hear more arguments based 
> on harmful intermediary interactions or implementation concerns.

There is nothing ambiguous about those two statements, and certainly
not the rest of 7.2.1.  Content-Type is an optional field that defaults
to application/octet-stream.  That is the only reason it says SHOULD.

> I'm definitely sympathetic to concerns about intermediaries (that's 
> why I'm doing PATCH -- because I'm worried about the way XCAP is 
> redefining PUT and GET).  However, I don't yet understand what an 
> intermediary might do with a new method it hasn't seen before (PATCH) 
> that has a header it has seen before (Content-Type) that could be 
> harmful.  An intermediary can't cache the body of a method it hasn't 
> seen before (e.g. PROPPATCH request and response bodies are similarly 
> uncached in practice).  An intermediary can apply transfer-encodings 
> but I don't see how that could be harmful.  For example, an 
> intermediary could apply chunked transfer encoding to a PATCH body in 
> either the PATCH -05 proposal or the PATCH -06 proposal without harm.  
> Or am I missing something?  What else can an intermediary do and how 
> might it be harmful?

It is harmful because it adds yet another silly exception to a
standard that is already burdened by haphazard design add-ons,
because it would violate what is an unambiguous Draft Standard
protocol definition for how to interpret *any* message as described
in section 7.2.1, and because an entirely new set of status codes
would have to be defined to mean "IM not acceptable" instead of
"media type not acceptable".

> This would create a new file of type text/calendar.  With the PATCH 
> -05 proposal, there wasn't a way to use PATCH to create a new resource 
> and assign the correct MIME type to begin with.

Sure there was.  First, it may already be set by virtue of the URI
chosen for the PATCH.  Second, it can be set by defining a patch
format that has a section for assigning metadata like Content-Type,
along with any other dead properties.  That way, we don't have to
create special-purpose request header fields for every property that
a client might want to set while creating/modifying a resource.

> the practical considerations better.

It isn't duelling theories.  Look at RFC 3229 again, please, and you
will note that Content-Type is NEVER sent in a 226 response.  It can't
be sent in a 226 response because that would violate the messaging model
of HTTP, which overrides anything less than a standards-track document
that explicitly Updates RFC 2616.  RFC 3229 is not being implemented
because it is too complex, almost entirely because of its misinformed
interpretation of what content-codings mean in HTTP.  If it hadn't
tried to play file-games with "instance" encodings and simply stuck
to the already defined representation model, delta-encoding would
have been a trivial extension to HTTP (just as PATCH should be a
trivial variation on PUT).

....Roy