gmane.ietf.message-headers

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 Information: http://swordapp.org/sword-v2/sword-v2-specifications/


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


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


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

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 originally specified in RFC 2068 and
   later obsoleted in RFC 2616.  The MIME header field
   Content-Base was also obsoleted (RFC 2557 section 12).

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

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.

First part of LC for draft-yevstifeyev-http-headers-not-recognized summary

Mykyta Yevstifeyev — 2010-12-31T06:12:29

Hello all,

This message summarizes the first part of Last Call for 
draft-yevstifeyev-http-headers-not-recognized.

The LC for this draft was requested on 11 December, and it entered it on 
13 December. The LC period of 1 month has been appointed for this 
document. The LC discussions occurred on httpbis WG mailing list and 
IETF Discussion. Taking these discussions into consideration, 2 new 
versions of the draft has been uploaded during the first part of LC.

The -09 one added the digitalized 'Model of Work' section that described 
the usage and behavior if senders, receivers of and middle-boxes 
transferring messages with 'H-N-R' header field. Also some typographical 
errors were corrected.

The -10 version reflected almost all major LC comments. Among other:

    * replaced 'header' with 'header field' in all instances;
    * elaboration of model of work;
    * other typographical errors.

The diffs of initial version -08 to -10 are available here:

https://tools.ietf.org/rfcdiff?url1=draft-yevstifeyev-http-headers-not-recognized-10&difftype=--html&submit=Go!&url2=draft-yevstifeyev-http-headers-not-recognized-08

LC will last for 2 weeks more. I'll submit the updated version of the 
draft near the 10 December and inform you. Any suggestions are still 
welcome.

Happy New Year to everybody!

All the best,
Mykyta Yevstifeyev

P.S. Apologizing if you receive multiple copies of the message. Mykyta.

provisional registration Memento-Datetimeheader

Herbert Van de Sompel — 2010-09-29T17:18:00

provisional registration Content-Datetimeheader

Herbert Van de Sompel — 2010-05-20T14:49:06

provisional registration Accept-Datetimeheader

Herbert Van de Sompel — 2010-05-20T14:45:14