From GK-lists@ninebynine.org Tue Jan 17 00:44:53 2012 Return-Path: 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 5E5FF21F8559 for ; Tue, 17 Jan 2012 00:44:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 zh1FxdyrEQY7 for ; Tue, 17 Jan 2012 00:44:48 -0800 (PST) Received: from relay3.mail.ox.ac.uk (relay3.mail.ox.ac.uk [163.1.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 36B9B21F8575 for ; Tue, 17 Jan 2012 00:44:48 -0800 (PST) Received: from smtp1.mail.ox.ac.uk ([129.67.1.207]) by relay3.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1Rn4eq-0002RI-CA; Tue, 17 Jan 2012 08:44:44 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=Eskarina.local) by smtp1.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Rn4eq-000352-3M; Tue, 17 Jan 2012 08:44:44 +0000 Message-ID: <4F1534E0.6040006@ninebynine.org> Date: Tue, 17 Jan 2012 08:44:16 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Richard Jones References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 08:44:53 -0000 [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; > 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 > 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; > 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 > 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; > 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 > 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; > 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 > 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; > 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 > 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 -- From julian.reschke@gmx.de Tue Jan 17 00:58:42 2012 Return-Path: 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 621C421F8593 for ; Tue, 17 Jan 2012 00:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.552 X-Spam-Level: X-Spam-Status: No, score=-103.552 tagged_above=-999 required=5 tests=[AWL=-0.953, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 dZu7bxOZu9aK for ; Tue, 17 Jan 2012 00:58:38 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id BD7C621F85A5 for ; Tue, 17 Jan 2012 00:58:36 -0800 (PST) Received: (qmail invoked by alias); 17 Jan 2012 08:58:35 -0000 Received: from p3EE27258.dip.t-dialin.net (EHLO [192.168.178.36]) [62.226.114.88] by mail.gmx.net (mp030) with SMTP; 17 Jan 2012 09:58:35 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18f59o8lj0fG+epRc9XVBosmhX+ns8M1gHNGZ/gSg 3qX796tSUc/NJC Message-ID: <4F153837.5030102@gmx.de> Date: Tue, 17 Jan 2012 09:58:31 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Richard Jones References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 08:58:42 -0000 On 2011-12-22 18:31, Richard Jones wrote: > ... > 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 > Related Information: http://swordapp.org/sword-v2/sword-v2-specifications/ > ... Does this field potentially need I18N? The way it's specified now it is stuck with ISO8859-1 with no extension point. Best regards, Julian From julian.reschke@gmx.de Tue Jan 17 01:05:34 2012 Return-Path: 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 8E60F21F869C for ; Tue, 17 Jan 2012 01:05:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.532 X-Spam-Level: X-Spam-Status: No, score=-103.532 tagged_above=-999 required=5 tests=[AWL=-0.933, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 Bo7mxHkiwFZw for ; Tue, 17 Jan 2012 01:05:30 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 1F02421F8628 for ; Tue, 17 Jan 2012 01:05:29 -0800 (PST) Received: (qmail invoked by alias); 17 Jan 2012 09:05:28 -0000 Received: from p3EE27258.dip.t-dialin.net (EHLO [192.168.178.36]) [62.226.114.88] by mail.gmx.net (mp058) with SMTP; 17 Jan 2012 10:05:28 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/4MZwLl634ZTEGjG/7dC+7v0c7dyT8VxL4EM5S24 h6n/mzlmuvGynR Message-ID: <4F1539D5.9000002@gmx.de> Date: Tue, 17 Jan 2012 10:05:25 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Graham Klyne References: <4F1534E0.6040006@ninebynine.org> In-Reply-To: <4F1534E0.6040006@ninebynine.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: ietf-message-headers@ietf.org Subject: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 09:05:34 -0000 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 > 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 POST *and* PUT? > 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. > 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. Best regards, Julian From julian.reschke@gmx.de Tue Jan 17 01:09:07 2012 Return-Path: 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 79CF221F8627 for ; Tue, 17 Jan 2012 01:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.513 X-Spam-Level: X-Spam-Status: No, score=-103.513 tagged_above=-999 required=5 tests=[AWL=-0.914, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 FkF3-mQ6GX9p for ; Tue, 17 Jan 2012 01:09:03 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id B8AA121F8587 for ; Tue, 17 Jan 2012 01:09:02 -0800 (PST) Received: (qmail invoked by alias); 17 Jan 2012 09:09:01 -0000 Received: from p3EE27258.dip.t-dialin.net (EHLO [192.168.178.36]) [62.226.114.88] by mail.gmx.net (mp068) with SMTP; 17 Jan 2012 10:09:01 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+WXoErMLCWTu1NNNFFD6o3j1W1nXVngedfLwVg4O vqau0U7IWoWwxU Message-ID: <4F153AA9.5020805@gmx.de> Date: Tue, 17 Jan 2012 10:08:57 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Richard Jones References: <4F153837.5030102@gmx.de> In-Reply-To: <4F153837.5030102@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 09:09:07 -0000 On 2012-01-17 09:58, Julian Reschke wrote: > On 2011-12-22 18:31, Richard Jones wrote: >> ... >> 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 >> >> Related Information: >> http://swordapp.org/sword-v2/sword-v2-specifications/ >> ... > > Does this field potentially need I18N? The way it's specified now it is > stuck with ISO8859-1 with no extension point. > ... Also, did you consider "From"? "The From request-header field, if given, SHOULD contain an Internet e-mail address for the human user who controls the requesting user agent. The address SHOULD be machine-usable, as defined by "mailbox" in RFC 822 [9] as updated by RFC 1123 [8]: From = "From" ":" mailbox An example is: From: webmaster@w3.org This header field MAY be used for logging purposes and as a means for identifying the source of invalid or unwanted requests. It SHOULD NOT be used as an insecure form of access protection. The interpretation of this field is that the request is being performed on behalf of the person given, who accepts responsibility for the method performed. In particular, robot agents SHOULD include this header so that the person responsible for running the robot can be contacted if problems occur on the receiving end. The Internet e-mail address in this field MAY be separate from the Internet host which issued the request. For example, when a request is passed through a proxy the original issuer's address SHOULD be used. The client SHOULD NOT send the From header field without the user's approval, as it might conflict with the user's privacy interests or their site's security policy. It is strongly recommended that the user be able to disable, enable, and modify the value of this field at any time prior to a request." Best regards, Julian From rich.d.jones@gmail.com Tue Jan 17 06:30:52 2012 Return-Path: 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 ; 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 ; 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 ; Tue, 17 Jan 2012 06:30:50 -0800 (PST) Received: by ggnr5 with SMTP id r5so3712604ggn.31 for ; 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: <4EF5E9FB.2090009@ninebynine.org> Date: Tue, 17 Jan 2012 14:30:49 +0000 Message-ID: From: Richard Jones To: Graham Klyne 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 14:30:52 -0000 --14dae934060b7953b704b6ba2d0b Content-Type: text/plain; charset=ISO-8859-1 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 >> 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; >> 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 >> 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 ..." 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 >> 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; >> 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 >> 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. 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 >> 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? > 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://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 --14dae934060b7953b704b6ba2d0b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Folks,

Thanks for the feedback; I've got some inl= ine 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 woul= d be needed for progression to permanent registration).

At this stage we're absolutely only looking for pro= visional 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.

=A0
(By way of full disclosure to other readers, I have been a technical adviso= r 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@gm= ail.com
Specification Document:
http://sword-app.= svn.sourceforge.net/viewvc/sword-app/spec/tags/sword-2.0/<= /u>SWORD001.html?revision=3D377
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;
rich.d.jones@gm= ail.com
Specification Document:
http://sword-app.= svn.sourceforge.net/viewvc/sword-app/spec/tags/sword-2.0/<= /u>SWORD001.html?revision=3D377
Related Information: http://swordapp.org/sword-v2/sword-v2-= specifications/

[[
The Packaging header applies to resources delivered over HTTP which are com= prised of component resources, and is for uniquely identifying these well s= tructured 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 wh= ether any other projects are addressing similar issues w.r.t. conveying inf= ormation about packaging or composite object formats in HTTP. =A0I'm pr= etty sure this isn't a one-off problem.

Packaging doesn't really fall into the role of a content-type, as it do= esn't say anything about the nature of purpose of the packaged content.= =A0But it also is not really a content transfer encoding, as it may convey= application-relevant metadata in addition to simply encoding content for t= ransfer.

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 bundl= e up the content of a web page (http://tools.ietf.org/html/rfc2557). =A0Bu= t that doesn't really work in this case, as SWORD and related applicati= ons 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 constr= uct the content being POSTed or PUT. Servers SHOULD use this information to= unpack the supplied content into its component parts. If the server does n= ot understand the package format it MUST either store the content as delive= red without unpacking or respond with 415 (Unsupported Media Type).
]]

It is not clear from this text that the SHOULD here applies to implementati= ons of SWORD. =A0For the header specification document, I think it would be= better to avoid such normative claims about its use, which might be read a= s 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. =A0I wanted to try and spin these as no= t so SWORD specific (and then to re-use them in the SWORD protocol). =A0So = just substituting SHOULD for MAY will be sufficient?
=A0


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@gm= ail.com
Specification Document:
http://sword-app.= svn.sourceforge.net/viewvc/sword-app/spec/tags/sword-2.0/<= /u>SWORD001.html?revision=3D377
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;
rich.d.jones@gm= ail.com
Specification Document:
http://sword-app.= svn.sourceforge.net/viewvc/sword-app/spec/tags/sword-2.0/<= /u>SWORD001.html?revision=3D377
Related Information: http://swordapp.org/sword-v2/sword-v2-= specifications/

[[
The In-Progress request header MAY be used by the client to inform the serv= er 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 con= tent 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 p= rocess the content. Exact interpretation of this header is left to the serv= er, 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 in= tent 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 id= entified 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 need= s more work. =A0Let me try again here, and then if that makes sense I can f= old 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 c= onsidered "complete". =A0The following scenarios would necessitat= e its usage:

- you are uploading a number of files via a client in a= number of discrete upload steps. =A0At each file upload, the file (which m= ay be a package) is sent to the server, which accepts the deposit. =A0But y= ou don't want the server to inject the content into any kind of workflo= w (e.g. for re-publication on the web) until you have finished uploading al= l of the files, so the In-Progress header tells the server that it should e= xpect more related content in future requests. =A0On your final upload eith= er omit the header or send In-Progress: false to tell the server that it ca= n go ahead and start its workflows.

- you are uploading content from a number of sources. = =A0Perhaps a content package from a research management/information system = and related research data from lab equipment. =A0They both pertain to the s= ame "object" on the server, but will be delivered an uncertain ti= mes and from different sources. =A0By using In-Progress, both depositors ca= n tell the server that more data is coming for that object and it is not ye= t finished.

We had extensive discussion about how to pitch this, an= d there was some suggestion about embedding the In-Progress information int= o the request /body/ rather than the headers, but this would require specif= ic treatment of the package itself, which we wanted to avoid. =A0I think of= it as like a more decoupled version of Transfer-Encoding: chunked. =A0So, = if we can find a way to describe this which makes sense and doesn't app= ear to impact the other purposes of HTTP, that would be good. =A0Thoughts?<= /div>

=A0

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@gm= ail.com
Specification Document:
http://sword-app.= svn.sourceforge.net/viewvc/sword-app/spec/tags/sword-2.0/<= /u>SWORD001.html?revision=3D377
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 packa= ge, 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 me= tadata, 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 re= source 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 n= ext revision.
=A0

(A bit of Googling - e.g. http://www.spenc= eruresk.com/2011/11/http-delete-requests-that-include-a-body/= , http://stackoverflo= w.com/questions/299628/is-an-entity-body-allowed-for-an-http-= delete-request - suggests that there's no specific prohibiti= on of sending data/metadata with a DELETE request, but that any such attemp= t is unlikely to be handled dependably by existing software. =A0And it'= s really not clear what it would mean to send metadata about a resource tha= t is being deleted.)

Did you consider the option that the relevance of metadata might be conveye= d by a parameter on the Packaging header field? =A0This 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 th= is was part of the Packaging header you couldn't re-use this header out= side of that context.

Cheers,

Richard
--14dae934060b7953b704b6ba2d0b-- From rich.d.jones@gmail.com Tue Jan 17 06:49:10 2012 Return-Path: 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 ; 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 ; 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 ; Tue, 17 Jan 2012 06:49:09 -0800 (PST) Received: by iaae16 with SMTP id e16so11491236iaa.31 for ; 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: <4F1534E0.6040006@ninebynine.org> <4F1539D5.9000002@gmx.de> Date: Tue, 17 Jan 2012 14:49:08 +0000 Message-ID: From: Richard Jones To: Julian Reschke 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 14:49:10 -0000 --e89a8f3ba963fc3eb404b6ba6ec8 Content-Type: text/plain; charset=ISO-8859-1 Hi Julian, On Tue, Jan 17, 2012 at 9:05 AM, Julian Reschke 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). >> 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 --e89a8f3ba963fc3eb404b6ba6ec8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Julian,

On Tue, Jan 17, 2012 at 9:05 A= M, Julian Reschke <julian.reschke@gmx.de> 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?
=A0
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://to= ols.ietf.org/html/rfc2557). But that doesn't really work in<= br> this case, as SWORD and related applications are already using a number
of alternative formats that don't easily map into a multipart/related o= r
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. =A0The 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 o= riginal package URI.

=A0

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?

=A0

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 i= s 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 e= xplanations.

The main issue is that Content-Type is for= the mimetype, which would be something like application/zip, whereas the P= ackaging 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 in= cluded in the Content-Type? =A0We did look into Media Formats, but their ge= neral adoption level seemed quite low, and this approach felt simpler.

Cheers,

Richard
--e89a8f3ba963fc3eb404b6ba6ec8-- From julian.reschke@gmx.de Tue Jan 17 06:57:21 2012 Return-Path: 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 ADF4921F86E5 for ; Tue, 17 Jan 2012 06:57:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.525 X-Spam-Level: X-Spam-Status: No, score=-103.525 tagged_above=-999 required=5 tests=[AWL=-0.926, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 YxMOnJT-RPc5 for ; Tue, 17 Jan 2012 06:57:21 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id A5CDB21F86E0 for ; Tue, 17 Jan 2012 06:57:20 -0800 (PST) Received: (qmail invoked by alias); 17 Jan 2012 14:57:18 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp005) with SMTP; 17 Jan 2012 15:57:18 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19f1g10BaNf5iwzajpz+O4MK1s/Shzq6SiDOId1tw vuQ+QW0jxjV/re Message-ID: <4F158C4B.9090205@gmx.de> Date: Tue, 17 Jan 2012 15:57:15 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Richard Jones References: <4F1534E0.6040006@ninebynine.org> <4F1539D5.9000002@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 14:57:21 -0000 On 2012-01-17 15:49, Richard Jones wrote: > Hi Julian, > > On Tue, Jan 17, 2012 at 9:05 AM, Julian Reschke > 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? 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 > ). 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