Re: Content-Location matching Location for POST of a media resource

["Thomas Broyer" <t.broyer@xxxxxxxxx>]

2007/11/28, Brian Smith:
>
> Thanks for reminding me of that. RFC5023 is contradictory to the spirit
> of RFC2616 here. Just from reading RFC2616, if I post an image, and the
> server saves a copy of the image at location X, then I would expect the
> Location header to be the URI of the image. AtomPub requires the
> creation of two resources, but clearly the image would is the primary
> resource and the MLE is a secondary resource, so I would expect the
> image's URI to end up in the Location header.

Look at it from the other end: whether you send an Atom Entry Document
or something else, you're creating an entry. In the specific case
where you don't send an Atom Entry Document, this bits you sent are
stored side-by-side to the created entry (but they really could be
base64-encoded in the atom:content).

> But, at least RFC5023 is very clear on the subject.

As I said several times when we were discussing this, I don't consider
the "Media Resource" and "Entry" cases any different. A server should
be explicitly allowed to accept image/png bits and store them
base64-encoded in the created entry's atom:content; moreover, a server
should be explicitly allowed to accept base64-encoded bits in an
atom:content and store them as two resources (call them Media Link
Entry and Media Resource if you like). A server should also be
explicitly allowed to accept an OpenDocument document and create a
single Entry resource with metadata extracted from the document and
content being the document's content transformed to HTML.
(the key word here is "explicitly")

In other words, this is just a matter of storage (being able to
download the "Media Resource" bits without the Atom Entry Document
"envelope"), but the purpose is always to create an Atom Entry; so
having that entry's IRI in the Location header of the 201 response is
not at all in contradiction with RFC2616 (IMO).

-- 
Thomas Broyer