gmane.ietf.message-headers

Re: HTTP 'Origin' permanent and provisional

Bjoern Hoehrmann — 2013-03-07T01:05:33

This has been fixed on http://www.iana.org/assignments/message-headers
and the two addresses above have been changed to indicate they are now
obsolete (and should, instead, redirect to the new address soon).

Re: [websec] HTTP 'Origin' permanent andprovisional

Bjoern Hoehrmann — 2013-02-14T18:18:50

Excellent. I gave up grepping for "same" after the first couple of hits.
I agree that Graham should just go ahead and ask IANA to remove the re-
dundant entry (I'd have done that, copying ietf-message-headers, had I
found the text above).

Re: [websec] HTTP 'Origin' permanent andprovisional

Mark Nottingham — 2013-02-14T05:04:34

We've been talking for a while about revising 3864; it needs a lot more than this done.

Cheers,


On 14/02/2013, at 7:54 AM, Julian Reschke <julian.reschke< at >gmx.de> wrote:


--
Mark Nottingham   http://www.mnot.net/

Re: [websec] HTTP 'Origin' permanent and provisional

SM — 2013-02-13T20:32:12

Hi Julian,
At 12:24 13-02-2013, Julian Reschke wrote:

It's easier to fix the bug first.

The following could be used:

   "When a new entry is recorded in the permanent message header field
    registry, IANA will remove any corresponding entries (with the same
    field name and protocol) from the provisional registry."

That avoids overlapping values.

Regards,
-sm

Re: [websec] HTTP 'Origin' permanent andprovisional

Barry Leiba — 2013-02-13T20:30:58

Indeed.  I've already suggested to Yoav, off list, how to get this
fixed in this case.

I will talk with IANA in Orlando about dealing with it systematically.

Barry, Applications AD

Re: HTTP 'Origin' permanent and provisional

SM — 2013-02-13T19:44:59

Hi Bjoern,

[Cc to Websec as it is their document]

At 09:37 13-02-2013, Bjoern Hoehrmann wrote:

No.  IANA did what it was requested to do.  Anyway, in my opinion, it 
would have to be fixed (process stuff).

Regards,
-sm

HTTP 'Origin' permanent and provisional

Bjoern Hoehrmann — 2013-02-13T17:37:07

Hi,

  http://www.iana.org/assignments/message-headers/prov-headers.html and
http://www.iana.org/assignments/message-headers/perm-headers.html list
the "Origin" header for HTTP, one per RFC 6454 and one from an earlier
W3C registration. Is that as it should be?

regards,

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.