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

Richard Jones <rich.d.jones@gmail.com> Tue, 17 January 2012 14:49 UTC

Return-Path: <rich.d.jones@gmail.com>
X-Original-To: ietf-message-headers@ietfa.amsl.com
Delivered-To: ietf-message-headers@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41C6921F8525 for <ietf-message-headers@ietfa.amsl.com>; Tue, 17 Jan 2012 06:49:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.499
X-Spam-Level:
X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RwFp9HS-v7hE for <ietf-message-headers@ietfa.amsl.com>; Tue, 17 Jan 2012 06:49:09 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 60B6221F8518 for <ietf-message-headers@ietf.org>; Tue, 17 Jan 2012 06:49:09 -0800 (PST)
Received: by iaae16 with SMTP id e16so11491236iaa.31 for <ietf-message-headers@ietf.org>; Tue, 17 Jan 2012 06:49:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SZ/CEOmDd17E344xtBhiUJh2f9oqAbhUTao1epoIjwY=; b=G+M9d2zzXnErpP+MR5XQnSezLzvvcwLyMWQu5I7eZ4Vm1/BZPpXCQlhz9qbXhmXI18 9wH7fyN1L/sbesUY9urPyQlruksuqbAspH2U35KPQsSH2CJaGLTbUjzCjHHQcUg8uHtc uy8AHBjYaSnsqSvvUTAr4kEs+6tm2lLwI27v4=
MIME-Version: 1.0
Received: by 10.50.155.166 with SMTP id vx6mr15210250igb.16.1326811749039; Tue, 17 Jan 2012 06:49:09 -0800 (PST)
Received: by 10.231.183.9 with HTTP; Tue, 17 Jan 2012 06:49:08 -0800 (PST)
In-Reply-To: <4F1539D5.9000002@gmx.de>
References: <CACEoUB2mQpmXowez2s4mZSanALRoZLSmkNZ5JK=FoDk041kGkw@mail.gmail.com> <4F1534E0.6040006@ninebynine.org> <4F1539D5.9000002@gmx.de>
Date: Tue, 17 Jan 2012 14:49:08 +0000
Message-ID: <CACEoUB19kh_MSOO9BahceLimcBP+2O01rAgtf=_rgKXd_O-tGA@mail.gmail.com>
From: Richard Jones <rich.d.jones@gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Content-Type: multipart/alternative; boundary=e89a8f3ba963fc3eb404b6ba6ec8
Cc: ietf-message-headers@ietf.org
Subject: Re: [Ietf-message-headers] Packaging, was: provisional registration: packaged content over http (5 headers)
X-BeenThere: ietf-message-headers@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion list for header fields used in Internet messaging applications." <ietf-message-headers.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-message-headers>, <mailto:ietf-message-headers-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-message-headers>
List-Post: <mailto:ietf-message-headers@ietf.org>
List-Help: <mailto:ietf-message-headers-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-message-headers>, <mailto:ietf-message-headers-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Jan 2012 14:49:10 -0000

Hi Julian,

On Tue, Jan 17, 2012 at 9:05 AM, Julian Reschke <julian.reschke@gmx.de>wrote;wrote:

> On 2012-01-17 09: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?


>
>  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>)7>).
>> 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.



>
>  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?



>
>  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?

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.

Cheers,

Richard