W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2004

Re: FYI: I-D ACTION:draft-dusseault-http-patch-02.txt

From: Jeffrey Mogul <Jeff.Mogul@hp.com>
Date: Fri, 09 Jul 2004 17:51:17 -0700
Message-Id: <200407100051.i6A0pHqx008964@wera.hpl.hp.com>
To: Lisa Dusseault <lisa@osafoundation.org>
Cc: ietf-http-wg@w3.org, Jamie Lokier <jamie@shareable.org>

    Note that modeling the delta as an instance manipulation -- and using 
    IM header -- would possibly create a dependency on RFC 3229.  But it's 
    not really the same as 3229 because that spec doesn't define the IM 
    header as a client request header -- so we'd also have to define what 
    the server must do with the IM header and which instance manipulations 
    it had to support.

I don't think RFC3229 in any way prohibits the use of IM headers
on requests.  In fact, it says:

         Nothing in this specification specifically precludes the use of
         a delta encoding for the body of a PUT request.  However, no
         mechanism currently exists for the client to discover if the
         server can interpret such messages, and so we do not attempt to
         specify how they might be used.

However, there's no reason why you couldn't define a new header
name to carry instance-manipulation values in a request ("R-IM",
for example), and then define whatever semantics you need for it.
The specification for IM in RFC3229 is only a few paragraphs
(plus some examples) so this is not a big deal.

I would think, in any case, that no matter what mechanism you
choose, you either need a way for the client to discover what
delta-encoding formats the server supports (analogous to
Accept-range, but please don't create another Accept-*
response header name!) or for the server to gracefully recover
from a client that tries a format it doesn't grok.  That is,
I think this is orthogonal to whether you use something like
the RFC3229 approach.

You might still decide, for other reasons, not to use the
instance/instance-manipulation approach, but don't let RFC3229
get in your way if you decide in favor of it.


P.S.: RFC3229 is a Proposed Standard.  So it can be changed,
if you think that's the right approach.
Received on Friday, 9 July 2004 20:51:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:38 UTC