HTTP2 Expression of Interest

Here’s my (rather rushed) personal submission to the Internet Engineering Task Force (IETF) in response to their Call for Expressions of Interest in new work around HTTP; specifically, a new wire-level protocol for the semantics of HTTP (i.e., what will become HTTP/2.0), and new HTTP authentication schemes. You can also review the submissions of Facebook, FirefoxGoogle, Microsoft, Twitter and others.

[The views expressed in this submission are mine alone and not (necessarily) those of Citrix, Google, Equinix or any other current, former or future client or employer.]

My primary interest is in the consistent application of HTTP to (“cloud”) service interfaces, with a view to furthering the goals of the Open Cloud Initiative (OCI); namely widespread and ideally consistent interoperability through the use of open standard formats and interfaces.

In particular, I strongly support the use of the existing metadata channel (headers) over envelope overlays (SOAP) and alternative/ancillary representations (typically in JSON/XML) as this should greatly simplify interfaces while ensuring consistency between services. The current approach to cloud “standards” calls on vendors to define their own formats and interfaces and to maintain client libraries for the myriad languages du jour. In an application calling on multiple services this can result in a small amount of business logic calling on various bulky, often poorly written and/or unmaintained libraries. The usual counter to the interoperability problems this creates is to write “adapters” (ala ODBC) which expose a lowest-common-denominator interface, thus hiding functionality and creating an “impedence mismatch”. Ultimately this gives rise to performance, security, cost and other issues.

By using HTTP as intended it is possible to construct (cloud) services that can be consumed using nothing more than the built-in, standards compliant HTTP client. I’m not writing to discuss whether this is a good idea, but to expose a use case that I would like to see considered, and one that we have already applied with an amount of success in the Open Cloud Computing Interface (OCCI).

To illustrate the original scope, versions of HTTP (RFC 2068) included not only the Link header (recently revived by Mark Nottingham in RFC 5988) but also LINK and UNLINK verbs to manipulate it (recently proposed for revival by James Snell). Unfortunately hypertext, and in particular HTML (which includes linking in-band rather than out-of-band) arguably stole HTTP’s thunder, leaving the overwhelming majority of formats that lack in-band linking (images, documents, virtual machines, etc.) high and dry and resulting in inconsistent linking styles (HTML vs XML vs PDF vs DOC etc.). This limited the extent of web linking as well as the utility of HTTP for innovative applications including APIs. Indeed HTTP could easily and simply meet the needs of many “Semantic Web” applications, but that is beyond the scope of this particular discussion.

To illustrate by way of example, consider the following synthetic request/response for an image hosting site which incorporates Web Linking (RFC 5988), Web Categories (draft-johnston-http-category-header) and Web Attributes (yet to be published):

GET /1.jpg HTTP/1.0

HTTP/1.0 200 OK
Content-Length: 69730
Content-Type: image/jpeg
Link:; rel=”license”
Link: /2.jpg; rel=”next”
Category: dog; label=”Dog”; scheme=””
Attribute: name=”Spot”

In order to “animate” resources, consider the use of the Link header to start a virtual machine in the Open Cloud Computing Interface (OCCI):

Link: </compute/123;action=start>; rel=""

The main objection to the use of the metadata channel in this fashion (beyond the application of common sense in determining what constitutes data vs metadata) is implementation issues (e.g. arbitrary limitations, i18n, handling of multiple headers, etc.) which could be largely resolved through specification. For example, the (necessary) use of e.g. RFC 2231 encoding for header values (but not keys) in e.g. RFC 5988 Web Linking gives rise to unnecessary complexity that may lead to interoperability, security and other issues which could be resolved through the specification of Unicode for keys and/or values. Another concern is the absence of features such as a standardised ability to return a collection (e.g. multiple responses). I originally suggested that HTTP 2.0 incorporate such ideas in 2009.

I’ll leave the determination of what would ultimately be required for such applications to the working group (should this use case be considered interesting by others), and while better support for performance, scalability and mobility are obviously required this has already been discussed at length. I strongly support Poul-Henning Kamp’s statement that “I think it would be far better to start from scratch, look at what HTTP/2.0 should actually do, and then design a simple, efficient and future proof protocol to do just that, and leave behind all the aggregations of badly thought out hacks of HTTP/1.1.” (and agree that we should incorporate the concept of a “HTTP Router”) as well as Tim Bray’s statement that: “I’m inclined to err on the side of protecting user privacy at the expense of almost all else” (and believe that we should prevent eavesdroppers from learning anything about an encrypted transaction; something we failed to do with DNSSEC even given alternatives like dnscurve that ensure confidentiality as well as integrity).

Organising the Internet with Web Categories

In order to scratch an itch relating to the Open Cloud Computing Interface (OCCI) I submitted my first Internet-Draft to the IETF this week: Web Categories (draft-johnston-http-category-header).

The idea’s fairly simple and largely inspired by the work of others (most notably the original HTTP and Atom authors, and a guy down under who’s working on another draft). It defines an intuitive mechanism for web servers to express flexible category information for any resource (including opaque/binary/non-HyperText formats) in the HTTP headers, allowing users to categorise web resources into vocabularies or “schemes” and assign human-friendly “labels” in addition to the computer-friendly “terms”.

This approach to taxonomies was lifted directly from (and is thus 100% compatible with) Atom and is another step closer to being able to render individual resources natively over HTTP rather than encoded and wrapped in XML (which gets unwieldly when you’re dealing with multi-gigabyte virtual machines, as we are with OCCI).

It’s anybody’s guess where the document will go from here – it’s currently marked “Experimental” but with any luck it will pique the interest of the standards and/or semantic web community and go on to live a long and happy life.

Internet Engineering Task Force                              S. Johnston
Internet-Draft                               Australian Online Solutions
Intended status: Experimental                               July 1, 2009
Expires: January 2, 2010

                             Web Categories

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on January 2, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.


   This document specifies the Category header-field for HyperText
   Transfer Protocol (HTTP), which enables the sending of taxonomy
   information in HTTP headers.

Johnston                 Expires January 2, 2010                [Page 1]

Internet-Draft              Abbreviated Title                  July 2009

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 3
   2.  Categories  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  The Category Header Field . . . . . . . . . . . . . . . . . . . 4
     3.1.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . 4
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
     4.1.  Category Header Registration  . . . . . . . . . . . . . . . 5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   6.  Internationalisation Considerations . . . . . . . . . . . . . . 5
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
   Appendix A.  Notes on use with HTML . . . . . . . . . . . . . . . . 7
   Appendix B.  Notes on use with Atom . . . . . . . . . . . . . . . . 7
   Appendix C.  Acknowledgements . . . . . . . . . . . . . . . . . . . 8
   Appendix D.  Document History . . . . . . . . . . . . . . . . . . . 8
   Appendix E.  Outstanding Issues . . . . . . . . . . . . . . . . . . 8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 9

Johnston                 Expires January 2, 2010                [Page 2]

Internet-Draft              Abbreviated Title                  July 2009

1.  Introduction

   A means of indicating categories for resources on the web has been
   defined by Atom [RFC4287].  This document defines a framework for
   exposing category information in the same format via HTTP headers.

   The atom:category element conveys information about a category
   associated with an entry or feed.  A given atom:feed or atom:entry
   element MAY have zero or more categories which MUST have a "term"
   attribute (a string that identifies the category to which the entry
   or feed belongs) and MAY also have a scheme attribute (an IRI that
   identifies a categorization scheme) and/or a label attribute (a
   human-readable label for display in end-user applications).

   Similarly a web resource may be associated with zero or more
   categories as indicated in the Category header-field(s).  These
   categories may be divided into separate vocabularies or "schemes"
   and/or accompanied with human-friendly labels.

   [[ Feedback is welcome on the mailing list,
   although this is NOT a work item of the HTTPBIS WG. ]]

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in BCP 14, [RFC2119], as
   scoped to those conformance targets.

   This document uses the Augmented Backus-Naur Form (ABNF) notation of
   [RFC2616], and explicitly includes the following rules from it:
   quoted-string, token.  Additionally, the following rules are included
   from [RFC3986]: URI.

2.  Categories

   In this specification, a category is a grouping of resources by
   'term', from a vocabulary ('scheme') identified by an IRI [RFC3987].
   It is comprised of:

   o  A "term" which is a string that identifies the category to which
      the resource belongs.

   o  A "scheme" which is an IRI that identifies a categorization scheme

Johnston                 Expires January 2, 2010                [Page 3]

Internet-Draft              Abbreviated Title                  July 2009

   o  An "label" which is a human-readable label for display in end-user
      applications (optional).

   A category can be viewed as a statement of the form "resource is from
   the {term} category of {scheme}, to be displayed as {label}", for
   example "'Loewchen' is from the 'dog' category of 'animals', to be
   displayed as 'Canine'".

3.  The Category Header Field

   The Category entity-header provides a means for serialising one or
   more categories in HTTP headers.  It is semantically equivalent to
   the atom:category element in Atom [RFC4287].

   Category           = "Category" ":" #category-value
   category-value     = term *( ";" category-param )
   category-param     = ( ( "scheme" "=" <"> scheme <"> )
                      | ( "label" "=" quoted-string )
                      | ( "label*" "=" enc2231-string )
                      | ( category-extension ) )
   category-extension = token [ "=" ( token | quoted-string ) ]
   enc2231-string     = 
   term               = token
   scheme             = URI

   Each category-value conveys exactly one category but there may be
   multiple category-values for each header-field and/or multiple
   header-fields per [RFC2616].

   Note that schemes are REQUIRED to be absolute URLs in Category
   headers, and MUST be quoted if they contain a semicolon (";") or
   comma (",") as these characters are used to separate category-params
   and category-values respectively.

   The "label" parameter is used to label the category such that it can
   be used as a human-readable identifier (e.g. a menu entry).
   Alternately, the "label*" parameter MAY be used encode this label in
   a different character set, and/or contain language information as per
   [RFC2231].  When using the enc2231-string syntax, producers MUST NOT
   use a charset value other than 'ISO-8859-1' or 'UTF-8'.

3.1.  Examples

   NOTE: Non-ASCII characters used in prose for examples are encoded
   using the format "Backslash-U with Delimiters", defined in Section
   5.1 of [RFC5137].

Johnston                 Expires January 2, 2010                [Page 4]

Internet-Draft              Abbreviated Title                  July 2009

   For example:
   Category: dog

   indicates that the resource is in the "dog" category.
   Category: dog; label="Canine"; scheme=""

   indicates that the resource is in the "dog" category, from the
   "" scheme, and should be displayed as

   The example below shows an instance of the Category header encoding
   multiple categories, and also the use of [RFC2231] encoding to
   represent both non-ASCII characters and language information.
   Category: dog; label="Canine"; scheme="",
             lowchen; label*=UTF-8'de'L%c3%b6wchen";

   Here, the second category has a label encoded in UTF-8, uses the
   German language ("de"), and contains the Unicode code point \u'00F6'

4.  IANA Considerations

4.1.  Category Header Registration

   This specification adds an entry for "Category" in HTTP to the
   Message Header Registry [RFC3864] referring to this document:
   Header Field Name: Category
   Protocol: http
   Status: standard
   Author/change controller:
       IETF (
       Internet Engineering Task Force
   Specification document(s):
       [ this document ]

5.  Security Considerations

   The content of the Category header-field is not secure, private or
   integrity-guaranteed, and due caution should be exercised when using

6.  Internationalisation Considerations

   Category header-fields may be localised depending on the Accept-

Johnston                 Expires January 2, 2010                [Page 5]

Internet-Draft              Abbreviated Title                  July 2009

   Language header-field, as defined in section 14.4 of [RFC2616].

   Scheme IRIs in atom:category elements may need to be converted to
   URIs in order to express them in serialisations that do not support
   IRIs, as defined in section 3.1 of [RFC3987].  This includes the
   Category header-field.

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2231]  Freed, N. and K. Moore, "MIME Parameter Value and Encoded
              Word Extensions: Character Sets, Languages, and
              Continuations", RFC 2231, November 1997.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
              Procedures for Message Header Fields", BCP 90, RFC 3864,
              September 2004.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

   [RFC3987]  Duerst, M. and M. Suignard, "Internationalized Resource
              Identifiers (IRIs)", RFC 3987, January 2005.

   [RFC4287]  Nottingham, M. and R. Sayre, "The Atom Syndication
              Format", RFC 4287, December 2005.

   [RFC5137]  Klensin, J., "ASCII Escaping of Unicode Characters",
              RFC 5137, February 2008.

7.2.  Informative References

   [OCCI]     Open Grid Forum (OGF), Edmonds, A., Metsch, T., Johnston,
              S., and A. Richardson, "Open Cloud Computing Interface
              (OCCI)", .

   [RFC2068]  Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
              Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",

Johnston                 Expires January 2, 2010                [Page 6]

Internet-Draft              Abbreviated Title                  July 2009

              RFC 2068, January 1997.

              Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01

              Hyatt, D. and I. Hickson, "HTML 5", April 2009,

              Nottingham, M., "Web Linking",
              draft-nottingham-http-link-header-05 (work in progress),
              April 2009.

              Celik, T., Marks, K., and D. Powazek, "rel="tag"
              Microformat", .

Appendix A.  Notes on use with HTML

   In the absence of a dedicated category element in HTML 4
   [W3C.REC-html401-19991224] and HTML 5 [W3C.WD-html5-20090423],
   category information (including user supllied folksonomy
   classifications) MAY be exposed using HTML A and/or LINK elements by
   concatenating the scheme and term:
   category-link = scheme term
   scheme        = URI
   term          = token

   These category-links MAY form a resolveable "tag space" in which case
   they SHOULD use the "tag" relation-type per [rel-tag-microformat].

   Alternatively META elements MAY be used:

   o  where the "name" attribute is "keywords" and the "content"
      attribute is a comma-separated list of term(s)

   o  where the "http-equiv" attribute is "Category" and the "content"
      attribute is a comma-separated list of category-value(s)

Appendix B.  Notes on use with Atom

   Where the cardinality is known to be one (for example, when
   retrieving an individual resource) it MAY be preferable to render the

Johnston                 Expires January 2, 2010                [Page 7]

Internet-Draft              Abbreviated Title                  July 2009

   resource natively over HTTP without Atom structures.  In this case
   the contents of the atom:content element SHOULD be returned as the
   HTTP entity-body and metadata including the type attribute and atom:
   category element(s) via HTTP header-field(s).

   This approach SHOULD NOT be used where the cardinality is guaranteed
   to be one (for example, search results which MAY return one result).

Appendix C.  Acknowledgements

   The author would like to thank Mark Nottingham for his work on Web
   Linking [draft-nottingham-http-link-header] (on which this document
   was based) and to the authors of [RFC2068] for specification of the
   Link: header-field on which this is based.

   The author would like to thank members of the OGF's Open Cloud
   Computing Interface [OCCI] working group for their contributions and
   others who commented upon, encouraged and gave feedback to this

Appendix D.  Document History

   [[ to be removed by the RFC editor should document proceed to
   publication as an RFC. ]]


      *  Initial draft based on draft-nottingham-http-link-header-05

Appendix E.  Outstanding Issues

   [[ to be removed by the RFC editor should document proceed to
   publication as an RFC. ]]

   The following issues are oustanding and should be addressed:

   1.  Is extensibility of Category headers necessary as is the case for
       Link: headers?  If so, what are the use cases?

   2.  Is supporting multi-lingual representations of the same
       category(s) necessary?  If so, what are the risks of doing so?

   3.  Is a mechanism for maintaining Category header-fields required?
       If so, should it use the headers themselves or some other

Johnston                 Expires January 2, 2010                [Page 8]

Internet-Draft              Abbreviated Title                  July 2009

   4.  Does this proposal conflict with others in the same space?  If
       so, is it an improvement on what exists?

Author's Address

   Sam Johnston
   Australian Online Solutions
   GPO Box 296
   Sydney, NSW  2001


Johnston                 Expires January 2, 2010                [Page 9]