- From: Suma Potluri <suma@soe.ucsc.edu>
- Date: Tue, 15 Aug 2006 16:01:09 -0700 (PDT)
- To: w3c-dist-auth@w3.org
> OK, there are two ways to approach that: > > 1) either make sure that each of the patch formats indeed has it's own > MIME type, > > 2) use generic types, and have an additional request header specify the > type of operation. > > From a spec writing point of view, 1) seems to be preferable to me. If > you choose 2), you will essentially have to invent a new registry for > types (IANA??), and have to maintain specifications for these types > (which can be just pointers to existing specs). It's not entirely clear > to me how this is better than registering MIME types for these formats. > Since using the content-type header for the patch format seems to be the preferable in general, we could update the draft accordingly. The required patch format text/normal-diff could be the used for text files and another (optional??) patch format application/gdiff could be used for all resources. The normal-diff format for text files seems to be preferable over the gdiff format because it is a widely used diff format and could be easily generated by the clients using the existing tools. We can include the MIME type registration information in the draft for text/normal-diff and application/gdiff patch formats. Jim Whitehead didn't think that there would be any issue with the IPR requirements for the gdiff patch format. But if anyone knows better, we'd like to know. > Binary append would be the standard use case. Text append could take > advantage of re-encoding. Thus, I could append to a text/* resource > without having to know it's encoding. > OK I agree that APPEND could be a special case of the PATCH method. And if there is sufficient interest to keep the append free from the patch formats, we could define a new MIME type such as application/entity-append as you've suggested earlier. -Suma
Received on Tuesday, 15 August 2006 23:01:23 UTC