I agree that the URL should be returned as a header, and in fact
there may be other bit sof metadata whioch would be server-generated
and would be returned at the same time. I have changed the spec to
read
"Return object headers
The method shall return a set (possibly empty) of object headers for
the newly posted object. If a URL has been assigned by the server,
then that may be included. Similarly, if a URN has been assigned,
then that shall be returned. Other things which may be returned
include for example the expiry-date if any. The server may return
the entire metadata for the object (as in the HEAD command), or a
subset of it.
The object body shall not be returned, so the transaction shall end
with the blank line terminating the headers."
I would expect one could use the same code for implementing HEAD
to a large extent. On getting the returned header, the client would
sync up its internal data on the object, which is incomplete until
the post has happened.
2. At the same time I feel like changing the Live-URL: fields
to a
URI: blah vary=version, language, content-type
field. I didn't get any feedback on that. Seemed sensible though,
cleaner. Any objections? **** Speak now...
3. The message-boundary.
> Secondly, how should "message boundary" work? I've seen
> Content-type: text/html, boundary="string"
> and
> Message-Boundary: string
It is a pain that MIME defines it in the first form, and only for
Content-type multipart. I guess we would do best to go
the same way. Where have you seen the second method?
(I would prefer it on the encoding rather than the type field)
Tim
Tim