gmane.ietf.message-headers

Re: Packaging, was: provisional registration: packaged content over http (5 headers)

Julian Reschke — 2012-01-17T14:57:15

I think this is something for apps-discuss.


So will the resource at the target URI continue to be the packaged 
variant? If not, you really shouldn't use PUT here.



Either 400, or you'd have to define a new status code.


OK, but how does this affect processing?


Potentially a media type parameter?

Best regards, Julian

Re: Packaging, was: provisional registration: packaged content over http (5 headers)

Richard Jones — 2012-01-17T14:49:08

Hi Julian,

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


Is this something we can do through this or another IETF list?



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.




Ok, interesting; what response should be returned?




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

Re: provisional registration: packaged content over http (5 headers)

Richard Jones — 2012-01-17T14:30:49

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

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.





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?





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 uploadin

Re: provisional registration: packaged content over http (5 headers)

Julian Reschke — 2012-01-17T09:08:57

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

Packaging, was: provisional registration: packaged content over http (5 headers)

Julian Reschke — 2012-01-17T09:05:25

+1


POST *and* PUT?


No. 415 is for unsupported media types.


 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

Re: provisional registration: packaged content over http (5 headers)

Julian Reschke — 2012-01-17T08:58:31

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

Re: provisional registration: packaged content over http (5 headers)

Graham Klyne — 2012-01-17T08:44:16

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

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

Packagi

provisional registration: packaged contentover http (5 headers)

Richard Jones — 2011-12-22T17:31:48

Dear All,

Please find the details of 5 http headers that I'd like to request
provisional registration of, on behalf of the SWORD (
http://www.swordapp.org/) protocol.  Please let me know if I've
misunderstood any parts of the procedure.

Many thanks,

Richard Jones


MESSAGE HEADER FIELD SUBMISSION TEMPLATES


Packaging

Header field name: Packaging
Applicable protocol: HTTP
Status: provisional
Author/Change controller: Richard Jones c/o UKOLN, University of Bath;
rich.d.jones< at >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< at >gmail.com
Specification Document:
http://sword-app.svn.sourceforge.net/viewvc/sword-app/spec/tags/sword-2.0/SWORD001.html?revision=377
Related I

Re: For review: Base

Frank Ellermann — 2011-09-15T09:25:57

JFTR: [IANA #488571]

Re: For review: Content-Base (update formime)

Frank Ellermann — 2011-09-15T09:20:12

JFTR: [IANA #488569]

Re: For review: Content-Base (update forhttp)

Frank Ellermann — 2011-09-15T09:18:53

JFTR: [IANA #488568]

Re: For review: Content-Base (update forhttp)

Mykyta Yevstifeyev — 2011-09-08T14:17:19

This is fine.  I think the template is ready to be submitted to IANA.

Mykyta

Re: For review: Content-Base (see previous message for the MIME variant)

Frank Ellermann — 2011-09-01T21:25:08


Joke, you could of course ask the IESG if RFC 2557 or
RFC 2616 somehow made it on standards track *without*
an IETF Last Call.  Especially for RFC 2616 it could
explain some oddities, if nobody ever checked this DS.

But more seriously I think that there were Last Calls,
including "Content-Base was deleted" in RFC 2616, and
the slightly more convoluted "removed" + "MUST never
send" + "not any more a part of this standard" blurb
in RFC 2557.

These were simple technical errors in RFC 4021 and in
RFC 4229.  For the latter the author agrees to fix the
registry, cf.
<URL:http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03224.html>

I could submit this as erratum for RFC 4021, but that
can result in about *six years* of processing, example:
<URL:http://www.rfc-editor.org/errata_search.php?eid=499>

-Frank

For review: Content-Base (update for mime)

Frank Ellermann — 2011-09-01T20:54:16

PERMANENT MESSAGE HEADER FIELD REGISTRATION TEMPLATE:

Header field name:
   Content-Base

Applicable protocol:
   mime

Status:
   obsoleted

Author/Change controller:
   IETF

Specification document(s):
   RFC 2557 section 12,
   <URL:http://tools.ietf.org/html/rfc2557#section-12>
   RFC 2110 section 4.2,
   <URL:http://tools.ietf.org/html/rfc2110#section-4.2>

Related information:
   Content-Base was originally specified in RFC 2110 and
   later obsoleted in RFC 2557.  Content-Base replaced an
   older Base header field in RFC 1808, using the common
   Content-* style for MIME header field names.

For review: Content-Base (update for http)

Frank Ellermann — 2011-09-01T20:46:53


I've intentionally used the RFCs *obsoleting* Content-Base
instead of the obsolete RFCs *specifying* Content-Base,
because the request modifies existing (and wrt the status
incorrect) registry entries.  The original RFCs can be
found by their references in RFC 2616 and RFC 2557.  The
original RFCs are mentioned in the "related information"
of the templates.

It's apparently possible to have two "specifications" in
registry entries, so I'll just *add* the original RFC as
suggested by you (see below for the http Content-Base).

-Frank
-----------------------------------------------------
PERMANENT MESSAGE HEADER FIELD REGISTRATION TEMPLATE:

Header field name:
   Content-Base

Applicable protocol:
   http

Status:
   obsoleted

Author/Change controller:
   IETF

Specification document(s):
   RFC 2616 section 19.6.3,
   <URL:http://tools.ietf.org/html/rfc2616#section-19.6.3>
   RFC 2068, section 14.11,
   <URL:http://tools.ietf.org/html/rfc2068#section-14.11>

Related information:
   Content-Base was original

Re: For review: Content-Base (see previous message for the MIME variant)

Mykyta Yevstifeyev — 2011-08-30T08:36:41

The same as with MIME header field:


Mykyta

29.08.2011 22:58, Frank Ellermann wrote:

Re: [apps-discuss] 'Base' and 'Content-Base' header fields

Mykyta Yevstifeyev — 2011-08-30T08:35:22

Yes, please proceed with this registration.  A nit: specification should 
say RFC 2110, Section 4.2, so that it is:


Mykyta

29.08.2011 22:47, Frank Ellermann wrote:

For review: Content-Base (see previousmessage for the MIME variant)

Frank Ellermann — 2011-08-29T19:58:54

PERMANENT MESSAGE HEADER FIELD REGISTRATION TEMPLATE:

Header field name:
   Content-Base

Applicable protocol:
   http

Status:
   obsoleted

Author/Change controller:
   IETF

Specification document(s):
   RFC 2616 section 19.6.3
   <URL:http://tools.ietf.org/html/rfc2616#section-19.6.3>

Related information:
   Content-Base was originally specified in RFC 2068 and
   later obsoleted in RFC 2616.  The MIME header field
   Content-Base was also obsoleted (RFC 2557 section 12).

Re: [apps-discuss] 'Base' and 'Content-Base'header fields

Frank Ellermann — 2011-08-29T19:47:57

PERMANENT MESSAGE HEADER FIELD REGISTRATION TEMPLATE:

Header field name:
  Content-Base

Applicable protocol:
  mime

Status:
  obsoleted

Author/Change controller:
  IETF

Specification document(s):
  RFC 2557 section 12
  <URL:http://tools.ietf.org/html/rfc2557#section-12>

Related information:
  Content-Base was originally specified in RFC 2110 and
  later obsoleted in RFC 2557.  Content-Base replaced an
  older Base header field in RFC 1808, using the common
  Content-* style for MIME header field names.

For review: Base

Frank Ellermann — 2011-08-29T17:58:13

PERMANENT MESSAGE HEADER FIELD REGISTRATION TEMPLATE:

Header field name:
   Base

Applicable protocol:
   mime

Status:
   obsoleted

Author/Change controller:
   IETF

Specification document(s):
   RFC 1808 section 3.1
   <URL:http://tools.ietf.org/html/rfc1808#section-3.1>

Related information:
   Content-Base specified in RFC 2557 and before in RFC 2110
   roughly covers the idea of the RFC 1808 Base header field.
   RFC 2396 section 5.1 is similar to RFC 1808 section 3.1,
   and contains a reference to RFC 2110 replacing the former
   Base header field.

Re: Last Call Summaryondraft-yevstifeyev-http-headers-not-recognized

Julian Reschke — 2011-01-08T17:24:25

 > ...

I don't see how (a) using HTTP warnings would resolve the problems other 
people see, (b) how the use of warnings makes this proposal any better, 
nor (c) that warnings are actually applicable here (see 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p6-cache-12.html#rfc.section.3.6>).


We might create a registry when/if when there are actually requests for 
new Warning values.


Best regards, Julian