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

[Graham Klyne <[e-mail]>]

[Resending: the original got stuck in moderation, didn't make it to the list]

Hi Richard,

A couple of comments here...

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

(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;
> [e-mail]
> Specification Document:
> 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/
>
>
> Accept-Packaging
>
> Header field name: Accept-Packaging
> Applicable protocol: HTTP
> Status: provisional
> Author/Change controller: Richard Jones c/o UKOLN, University of Bath;
> [e-mail]
> Specification Document:
> 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/

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

> 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;
> [e-mail]
> Specification Document:
> 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/
>
>
> In-Progress
>
> Header field name: In-Progress
> Applicable protocol: HTTP
> Status: provisional
> Author/Change controller: Richard Jones c/o UKOLN, University of Bath;
> [e-mail]
> Specification Document:
> 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/

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

> Metadata-Relevant
>
> Header field name: Metadata-Relevant
> Applicable protocol: HTTP
> Status: provisional
> Author/Change controller: Richard Jones c/o UKOLN, University of Bath;
> [e-mail]
> Specification Document:
> 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/

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

(A bit of Googling - e.g. 
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 
- 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 header.

#g
--