Re: [Ietf-message-headers] Packaging, was: provisional registration: packaged content over http (5 headers)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ietf-message-headers] Packaging, was: provisional registration: packaged content over http (5 headers)
On 2012-01-17 15:49, Richard Jones wrote:
Hi Julian,
On Tue, Jan 17, 2012 at 9:05 AM, Julian Reschke <julian.reschke at gmx.de
<mailto:julian.reschke at gmx.de>> wrote:
On 2012-01-17 09 <tel:2012-01-17%2009>:44, Graham Klyne wrote:
...
[[
The Packaging header applies to resources delivered over HTTP
which are
comprised of component resources, and is for uniquely
identifying these
well structured packaged objects in a similar way that
Content-Type does
for MIME formats.
]]
I think this would be a good opportunity to canvas for
information about
whether any other projects are addressing similar issues w.r.t.
conveying information about packaging or composite object formats in
HTTP. I'm pretty sure this isn't a one-off problem.
+1
Is this something we can do through this or another IETF list?
I think this is something for apps-discuss.
Packaging doesn't really fall into the role of a content-type, as it
doesn't say anything about the nature of purpose of the packaged
content. But it also is not really a content transfer encoding,
as it
may convey application-relevant metadata in addition to simply
encoding
content for transfer.
The nearest I can think of that has been addressed in the IETF
is the
MHTML work from some years ago, which uses multipart/related
structures
to bundle up the content of a web page
(http://tools.ietf.org/html/ rfc2557
<http://tools.ietf.org/html/rfc2557>). But that doesn't really
work in
this case, as SWORD and related applications are already using a
number
of alternative formats that don't easily map into a
multipart/related or
similar MIME encapsulation structure.
[[
The Packaging request header SHOULD be used by the client during
HTTP
POST to give information to the server about the packaging
format used
to construct the content being POSTed or PUT. Servers SHOULD use
this
POST *and* PUT?
Yes. The use case is that if you've POSTed a package before, you might
want to replace it, so you could PUT a new package (potentially in a
different format) to the original package URI.
So will the resource at the target URI continue to be the packaged
variant? If not, you really shouldn't use PUT here.
information to unpack the supplied content into its component
parts. If
the server does not understand the package format it MUST either
store
the content as delivered without unpacking or respond with 415
(Unsupported Media Type).
]]
No. 415 is for unsupported media types.
Ok, interesting; what response should be returned?
Either 400, or you'd have to define a new status code.
It is not clear from this text that the SHOULD here applies to
implementations of SWORD. For the header specification document,
I think
it would be better to avoid such normative claims about its use,
which
might be read as claiming that any HTTP client SHOULD use the
header.
e.g. just say "The Packaging request header may be used by a
client ..."
>From the description in the spec it's not clear to me at all how
this is supposed to work, and why it is needed in addition to the
Content-Type. I'm sure there's a reason, but it really would be good
to add more explanations.
The main issue is that Content-Type is for the mimetype, which would be
something like application/zip, whereas the Packaging header allows us
to define what is inside the zip; for example, it may by a BagIt, or a
METS package, or such?
OK, but how does this affect processing?
Do you imagine a way in which the packaging could be included in the
Content-Type? We did look into Media Formats, but their general
adoption level seemed quite low, and this approach felt simpler.
Potentially a media type parameter?
Best regards, Julian
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
