RE: Distributed Authoring Proposals
My own proposal to deal with this solution is the content-nature header.
It is a way of saying "This is what this resource will be used to
> -----Original Message-----
> From: Larry Masinter [SMTP:firstname.lastname@example.org]
> Sent: Tuesday, March 25, 1997 7:00 PM
> To: Roy T. Fielding
> Cc: email@example.com
> Subject: Re: Distributed Authoring Proposals
> >I think in MIME that "message" and "multipart" are treated specially.
> >They're not just "application", they're media type where the sender
> >intends for the recipient to actually unwrap the message. I don't
> >you should *ever* store something as "multpart". Rather, a content
> >negotiated resource is "multpart/alternative", message/http is just
> >another wrapper around the HTTP message as if the wrapper weren't
> > That is true for the MIME recipient, but not for the MIME sender.
> > Unlike in MIME, WEBDAV represents the process of establishing on the
> > server the content of future sends, and therefore anything that
> > might be sent in the future must be acceptable as data and not
> > as control actions.
> Roy, is this true for PUT in general, or are you thinking that
> WEBDAV has some other special action? Is the PUT body in general
> required to be "this is what you will send as the content of
> future GET requests", or is it more complex than that?
> For example, if we're storing a document with server-side includes,
> would you use PUT, or STORE-SOURCE, or PUT to a different URL?
> I wish I felt confident that WEBDAV actually had addressed these
> fundamental simple operations, before we went off onto long
> flights of design around COPY and MOVE and establishing metadata.