Re: [Ietf-message-headers] Packaging, was: provisional registration: packaged content over http (5 headers)

[Julian Reschke <[e-mail]>]

On 2012-01-17 15:49, Richard Jones wrote:
> Hi Julian,
>
> On Tue, Jan 17, 2012 at 9:05 AM, Julian Reschke <[e-mail]
> <mailto:[e-mail]>> 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