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

Richard Jones <rich.d.jones@gmail.com> Tue, 17 January 2012 14:30 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 C619021F86D8 for <ietf-message-headers@ietfa.amsl.com>; Tue, 17 Jan 2012 06:30:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.467
X-Spam-Level:
X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[AWL=0.131, 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 NQOlgs8ehnAx for <ietf-message-headers@ietfa.amsl.com>; Tue, 17 Jan 2012 06:30:50 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8271E21F86C4 for <ietf-message-headers@ietf.org>; Tue, 17 Jan 2012 06:30:50 -0800 (PST)
Received: by ggnr5 with SMTP id r5so3712604ggn.31 for <ietf-message-headers@ietf.org>; Tue, 17 Jan 2012 06:30:50 -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=aDMrNbzZAdMOTsQdKYM3zZmFh/yfpHE5h8pLRTU/5CQ=; b=kqj6QTnm2gV5K3Obu/rEGnCjKo6QkaiVjDHfAwTpBYUmeTapv2cZd5xoV4wAdkxBvt Hre2Xv5dhSpI649k0EGeFT3AlV/NkU11LJO/lpWQbYWN7J1TKq+Z8rDU91NwlqYIqApG 58+Yi4i+T8Pzz+ng9BaAXNytt+CbeF4rpnfQE=
MIME-Version: 1.0
Received: by 10.50.180.138 with SMTP id do10mr17852486igc.20.1326810649940; Tue, 17 Jan 2012 06:30:49 -0800 (PST)
Received: by 10.231.183.9 with HTTP; Tue, 17 Jan 2012 06:30:49 -0800 (PST)
In-Reply-To: <4EF5E9FB.2090009@ninebynine.org>
References: <CACEoUB2mQpmXowez2s4mZSanALRoZLSmkNZ5JK=FoDk041kGkw@mail.gmail.com> <4EF5E9FB.2090009@ninebynine.org>
Date: Tue, 17 Jan 2012 14:30:49 +0000
Message-ID: <CACEoUB3pfN5sE6rB0+xmBP4xuqQWhzW5swGgcREN-G11H=BHVg@mail.gmail.com>
From: Richard Jones <rich.d.jones@gmail.com>
To: Graham Klyne <GK@ninebynine.org>
Content-Type: multipart/alternative; boundary="14dae934060b7953b704b6ba2d0b"
Cc: ietf-message-headers@ietf.org
Subject: Re: [Ietf-message-headers] 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:30:52 -0000

Hi Folks,

Thanks for the feedback; I've got some inline comments to see if I
understand what changes I need to make ...

My comments below notwithstanding, I don't think there are any specific
> problems for provisional registration (but I think further discussion would
> be needed for progression to permanent registration).
>

At this stage we're absolutely only looking for provisional registration;
there are other discussions which need to take place before we can see if
we have the resources to go full standards track with any of this.



> (By way of full disclosure to other readers, I have been a technical
> advisor to the SWORD project which is presenting these proposals.)
>
>
> On 22/12/2011 17:31, Richard Jones wrote:
>
>> Packaging
>>
>> Header field name: Packaging
>> Applicable protocol: HTTP
>> Status: provisional
>> Author/Change controller: Richard Jones c/o UKOLN, University of Bath;
>> rich.d.jones@gmail.com
>> Specification Document:
>> http://sword-app.svn.**sourceforge.net/viewvc/sword-**
>> app/spec/tags/sword-2.0/**SWORD001.html?revision=377<http://sword-app.svn.sourceforge.net/viewvc/sword-app/spec/tags/sword-2.0/SWORD001.html?revision=377>
>> Related Information: http://swordapp.org/sword-v2/**
>> sword-v2-specifications/<http://swordapp.org/sword-v2/sword-v2-specifications/>
>>
>>
>> Accept-Packaging
>>
>> Header field name: Accept-Packaging
>> Applicable protocol: HTTP
>> Status: provisional
>> Author/Change controller: Richard Jones c/o UKOLN, University of Bath;
>> rich.d.jones@gmail.com
>> Specification Document:
>> http://sword-app.svn.**sourceforge.net/viewvc/sword-**
>> app/spec/tags/sword-2.0/**SWORD001.html?revision=377<http://sword-app.svn.sourceforge.net/viewvc/sword-app/spec/tags/sword-2.0/SWORD001.html?revision=377>
>> Related Information: http://swordapp.org/sword-v2/**
>> sword-v2-specifications/<http://swordapp.org/sword-v2/sword-v2-specifications/>
>>
>
> [[
> 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.
>
> 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
> 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).
> ]]
>
> 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 ..."


Ok, good point.  I wanted to try and spin these as not so SWORD specific
(and then to re-use them in the SWORD protocol).  So just substituting
SHOULD for MAY will be sufficient?



>  On-Behalf-Of
>>
>> Header field name: On-Behalf-Of
>> Applicable protocol: HTTP
>> Status: provisional
>> Author/Change controller: Richard Jones c/o UKOLN, University of Bath;
>> rich.d.jones@gmail.com
>> Specification Document:
>> http://sword-app.svn.**sourceforge.net/viewvc/sword-**
>> app/spec/tags/sword-2.0/**SWORD001.html?revision=377<http://sword-app.svn.sourceforge.net/viewvc/sword-app/spec/tags/sword-2.0/SWORD001.html?revision=377>
>> Related Information: http://swordapp.org/sword-v2/**
>> sword-v2-specifications/<http://swordapp.org/sword-v2/sword-v2-specifications/>
>>
>>
>> In-Progress
>>
>> Header field name: In-Progress
>> Applicable protocol: HTTP
>> Status: provisional
>> Author/Change controller: Richard Jones c/o UKOLN, University of Bath;
>> rich.d.jones@gmail.com
>> Specification Document:
>> http://sword-app.svn.**sourceforge.net/viewvc/sword-**
>> app/spec/tags/sword-2.0/**SWORD001.html?revision=377<http://sword-app.svn.sourceforge.net/viewvc/sword-app/spec/tags/sword-2.0/SWORD001.html?revision=377>
>> Related Information: http://swordapp.org/sword-v2/**
>> sword-v2-specifications/<http://swordapp.org/sword-v2/sword-v2-specifications/>
>>
>
> [[
> The In-Progress request header MAY be used by the client to inform the
> server that the current content payload is not yet complete in some
> unspecified way during PUT, POST or DELETE. For example, there may by
> further content packages that the client plans to deliver to the server
> before the full content has been delivered, or the client may need to carry
> out other actions against the server before confirming that the server can
> proceed to fully process the content. Exact interpretation of this header
> is left to the server, so it is necessary that server/client pairs will
> have to have a common understanding of its meaning which is beyond the
> scope of this document.
> ]]
>
> This feels to me like an abuse of the HTTP protocol - if it modifies the
> intent of the method, that would be wrong, but that's not what I think is
> intended. Rather, it seems to modify the interpretation of the resource
> identified by the request URI, which makes me wonder if the intent might
> not be better conveyed by using a different server-designated URI for the
> parts.


Yeah, this is a tricky one to explain, and clearly needs more work.  Let me
try again here, and then if that makes sense I can fold it back into the
docs:

In-Progress is intended as a guiding hand for the client to use to tell the
server that it should expect more content to be delivered to this web
resource before it can be considered "complete".  The following scenarios
would necessitate its usage:

- you are uploading a number of files via a client in a number of discrete
upload steps.  At each file upload, the file (which may be a package) is
sent to the server, which accepts the deposit.  But you don't want the
server to inject the content into any kind of workflow (e.g. for
re-publication on the web) until you have finished uploading all of the
files, so the In-Progress header tells the server that it should expect
more related content in future requests.  On your final upload either omit
the header or send In-Progress: false to tell the server that it can go
ahead and start its workflows.

- you are uploading content from a number of sources.  Perhaps a content
package from a research management/information system and related research
data from lab equipment.  They both pertain to the same "object" on the
server, but will be delivered an uncertain times and from different
sources.  By using In-Progress, both depositors can tell the server that
more data is coming for that object and it is not yet finished.

We had extensive discussion about how to pitch this, and there was some
suggestion about embedding the In-Progress information into the request
/body/ rather than the headers, but this would require specific treatment
of the package itself, which we wanted to avoid.  I think of it as like a
more decoupled version of Transfer-Encoding: chunked.  So, if we can find a
way to describe this which makes sense and doesn't appear to impact the
other purposes of HTTP, that would be good.  Thoughts?



>
>  Metadata-Relevant
>>
>> Header field name: Metadata-Relevant
>> Applicable protocol: HTTP
>> Status: provisional
>> Author/Change controller: Richard Jones c/o UKOLN, University of Bath;
>> rich.d.jones@gmail.com
>> Specification Document:
>> http://sword-app.svn.**sourceforge.net/viewvc/sword-**
>> app/spec/tags/sword-2.0/**SWORD001.html?revision=377<http://sword-app.svn.sourceforge.net/viewvc/sword-app/spec/tags/sword-2.0/SWORD001.html?revision=377>
>> Related Information: http://swordapp.org/sword-v2/**
>> sword-v2-specifications/<http://swordapp.org/sword-v2/sword-v2-specifications/>
>>
>
> [[
> The Metadata-Relevant request header MAY be used by the client to instruct
> the server to (attempt to) extract metadata from the supplied content
> package, during PUT, POST or DELETE. Content packages commonly contain both
> file content and metadata about its contents, and during unpacking servers
> may process this metadata in a way which is meaningful to them. If the
> content package is being supplied to an HTTP resource which is not
> interested in metadata, then it may be that the enclosed information will
> not be correctly or adequately treated. This directive allows the client to
> indicate to the server that there is metadata contained within the package
> which may be of interest to related resources (for example a resource which
> contains the resource receiving the content), and that the server should be
> free to update those resources accordingly.
> ]]
>
> Do you *really* mean for this to be applicable to HTTP DELETE operations?
>

No, sorry, good catch; will fix in the next revision.


>
> (A bit of Googling - e.g. http://www.spenceruresk.com/**
> 2011/11/http-delete-requests-**that-include-a-body/<http://www.spenceruresk.com/2011/11/http-delete-requests-that-include-a-body/>,
> http://stackoverflow.com/**questions/299628/is-an-entity-**
> body-allowed-for-an-http-**delete-request<http://stackoverflow.com/questions/299628/is-an-entity-body-allowed-for-an-http-delete-request>- suggests that there's no specific prohibition of sending data/metadata
> with a DELETE request, but that any such attempt is unlikely to be handled
> dependably by existing software.  And it's really not clear what it would
> mean to send metadata about a resource that is being deleted.)
>
> Did you consider the option that the relevance of metadata might be
> conveyed by a parameter on the Packaging header field?  This header doesn't
> seem to have any purpose independently of the Packaging hea


I think there's a risk in combining these, because you could imagine that
there is relevant metadata in, say, a PDF, and if this was part of the
Packaging header you couldn't re-use this header outside of that context.

Cheers,

Richard