On Sun, Jun 28, 2009 at 10:44 PM, <span dir="ltr"><<a href="mailto:shlomo.swidler@gmail.com" target="_blank">shlomo.swidler@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>On Sun, Jun 28, 2009 at 3:48 AM, Sam Johnston<<a href="mailto:samj@samj.net" target="_blank">samj@samj.net</a>> wrote:<br>
> The categories were derived from Atom so in dropping it for individual<br>
> resources we're going to have to reinvent it (think HTTP headers).<br><snip></div>
I would prefer to have the categories implemented in the HTTP headers<br>
for single-resource responses.<br>
<div></div></blockquote><div><br>Ok so I've written up an IETF Internet-Draft (<a href="http://tools.ietf.org/html/draft-johnston-http-category-header-00" target="_blank">draft-johnston-http-category-header-00</a>) which specifies a Category: HTTP header based on atom:category (that is, with a term and optional scheme and label). This means there's one less resason to use Atom for individual resources. I've also devised (but not yet documented) a simple, intuitive mechanism for updating (or at least suggesting updates) to these metadata headers.<br>
<br>Although we can't reference I-Ds directly from the OCCI standard (as they're only valid for 6 months from the most recent revision), even if it doesn't proceed to a permanent status the content is also available under the usual OGF IPR rules and <a href="http://creativecommons.org/licenses/by-sa/3.0/" target="_blank">CC-BY-SA</a> for good measure.<br>
<br>Sam<br><br><pre>Internet Engineering Task Force S. Johnston<br>Internet-Draft Australian Online Solutions<br>Intended status: Experimental July 1, 2009<br>
Expires: January 2, 2010<br><br><br> Web Categories<br> draft-johnston-http-category-header-00<br><br>Status of this Memo<br><br> This Internet-Draft is submitted to IETF in full conformance with the<br>
provisions of BCP 78 and BCP 79.<br><br> Internet-Drafts are working documents of the Internet Engineering<br> Task Force (IETF), its areas, and its working groups. Note that<br> other groups may also distribute working documents as Internet-<br>
Drafts.<br><br> Internet-Drafts are draft documents valid for a maximum of six months<br> and may be updated, replaced, or obsoleted by other documents at any<br> time. It is inappropriate to use Internet-Drafts as reference<br>
material or to cite them other than as "work in progress."<br><br> The list of current Internet-Drafts can be accessed at<br> <a href="http://www.ietf.org/ietf/1id-abstracts.txt" target="_blank">http://www.ietf.org/ietf/1id-abstracts.txt</a>.<br>
<br> The list of Internet-Draft Shadow Directories can be accessed at<br> <a href="http://www.ietf.org/shadow.html" target="_blank">http://www.ietf.org/shadow.html</a>.<br><br> This Internet-Draft will expire on January 2, 2010.<br>
<br>Copyright Notice<br><br> Copyright (c) 2009 IETF Trust and the persons identified as the<br> document authors. All rights reserved.<br><br> This document is subject to BCP 78 and the IETF Trust's Legal<br>
Provisions Relating to IETF Documents in effect on the date of<br>
publication of this document (<a href="http://trustee.ietf.org/license-info" target="_blank">http://trustee.ietf.org/license-info</a>).<br> Please review these documents carefully, as they describe your rights<br> and restrictions with respect to this document.<br>
<br>Abstract<br><br> This document specifies the Category header-field for HyperText<br> Transfer Protocol (HTTP), which enables the sending of taxonomy<br> information in HTTP headers.<br><br><br><br>Johnston Expires January 2, 2010 [Page 1]<br>
<br>Internet-Draft Abbreviated Title July 2009<br><br><br>Table of Contents<br><br> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3<br> 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3<br>
2. Categories . . . . . . . . . . . . . . . . . . . . . . . . . . 3<br> 3. The Category Header Field . . . . . . . . . . . . . . . . . . . 4<br> 3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 4<br>
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5<br> 4.1. Category Header Registration . . . . . . . . . . . . . . . 5<br> 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5<br>
6. Internationalisation Considerations . . . . . . . . . . . . . . 5<br> 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6<br> 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6<br>
7.2. Informative References . . . . . . . . . . . . . . . . . . 6<br> Appendix A. Notes on use with HTML . . . . . . . . . . . . . . . . 7<br> Appendix B. Notes on use with Atom . . . . . . . . . . . . . . . . 7<br>
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . . 8<br> Appendix D. Document History . . . . . . . . . . . . . . . . . . . 8<br> Appendix E. Outstanding Issues . . . . . . . . . . . . . . . . . . 8<br>
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9<br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br>Johnston Expires January 2, 2010 [Page 2]<br>
<br>Internet-Draft Abbreviated Title July 2009<br><br><br>1. Introduction<br><br> A means of indicating categories for resources on the web has been<br> defined by Atom [RFC4287]. This document defines a framework for<br>
exposing category information in the same format via HTTP headers.<br><br> The atom:category element conveys information about a category<br> associated with an entry or feed. A given atom:feed or atom:entry<br> element MAY have zero or more categories which MUST have a "term"<br>
attribute (a string that identifies the category to which the entry<br> or feed belongs) and MAY also have a scheme attribute (an IRI that<br> identifies a categorization scheme) and/or a label attribute (a<br> human-readable label for display in end-user applications).<br>
<br> Similarly a web resource may be associated with zero or more<br> categories as indicated in the Category header-field(s). These<br> categories may be divided into separate vocabularies or "schemes"<br>
and/or accompanied with human-friendly labels.<br><br> [[ Feedback is welcome on the <a href="mailto:ietf-http-wg@w3.org" target="_blank">ietf-http-wg@w3.org</a> mailing list,<br> although this is NOT a work item of the HTTPBIS WG. ]]<br>
<br>1.1. Requirements Language<br><br> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",<br> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this<br>
document are to be interpreted as described in BCP 14, [RFC2119], as<br> scoped to those conformance targets.<br><br> This document uses the Augmented Backus-Naur Form (ABNF) notation of<br> [RFC2616], and explicitly includes the following rules from it:<br>
quoted-string, token. Additionally, the following rules are included<br> from [RFC3986]: URI.<br><br><br>2. Categories<br><br> In this specification, a category is a grouping of resources by<br> 'term', from a vocabulary ('scheme') identified by an IRI [RFC3987].<br>
It is comprised of:<br><br> o A "term" which is a string that identifies the category to which<br> the resource belongs.<br><br> o A "scheme" which is an IRI that identifies a categorization scheme<br>
(optional).<br><br><br><br><br><br>Johnston Expires January 2, 2010 [Page 3]<br> <br>Internet-Draft Abbreviated Title July 2009<br><br><br> o An "label" which is a human-readable label for display in end-user<br>
applications (optional).<br><br> A category can be viewed as a statement of the form "resource is from<br> the {term} category of {scheme}, to be displayed as {label}", for<br> example "'Loewchen' is from the 'dog' category of 'animals', to be<br>
displayed as 'Canine'".<br><br><br>3. The Category Header Field<br><br> The Category entity-header provides a means for serialising one or<br> more categories in HTTP headers. It is semantically equivalent to<br>
the atom:category element in Atom [RFC4287].<br><br> Category = "Category" ":" #category-value<br> category-value = term *( ";" category-param )<br> category-param = ( ( "scheme" "=" <"> scheme <"> )<br>
| ( "label" "=" quoted-string )<br> | ( "label*" "=" enc2231-string )<br> | ( category-extension ) )<br> category-extension = token [ "=" ( token | quoted-string ) ]<br>
enc2231-string = <extended-value, see [RFC2231], Section 7><br> term = token<br> scheme = URI<br><br> Each category-value conveys exactly one category but there may be<br> multiple category-values for each header-field and/or multiple<br>
header-fields per [RFC2616].<br><br> Note that schemes are REQUIRED to be absolute URLs in Category<br> headers, and MUST be quoted if they contain a semicolon (";") or<br> comma (",") as these characters are used to separate category-params<br>
and category-values respectively.<br><br> The "label" parameter is used to label the category such that it can<br> be used as a human-readable identifier (e.g. a menu entry).<br> Alternately, the "label*" parameter MAY be used encode this label in<br>
a different character set, and/or contain language information as per<br> [RFC2231]. When using the enc2231-string syntax, producers MUST NOT<br> use a charset value other than 'ISO-8859-1' or 'UTF-8'.<br>
<br>3.1. Examples<br><br> NOTE: Non-ASCII characters used in prose for examples are encoded<br> using the format "Backslash-U with Delimiters", defined in Section<br> 5.1 of [RFC5137].<br><br><br><br><br>
Johnston Expires January 2, 2010 [Page 4]<br> <br>Internet-Draft Abbreviated Title July 2009<br><br><br> For example:<br> Category: dog<br><br> indicates that the resource is in the "dog" category.<br>
Category: dog; label="Canine"; scheme="<a href="http://purl.org/net/animals" target="_blank">http://purl.org/net/animals</a>"<br><br> indicates that the resource is in the "dog" category, from the<br>
"<a href="http://purl.org/net/animals" target="_blank">http://purl.org/net/animals</a>" scheme, and should be displayed as<br>
"Canine".<br><br> The example below shows an instance of the Category header encoding<br> multiple categories, and also the use of [RFC2231] encoding to<br> represent both non-ASCII characters and language information.<br>
Category: dog; label="Canine"; scheme="<a href="http://purl.org/net/animals" target="_blank">http://purl.org/net/animals</a>",<br> lowchen; label*=UTF-8'de'L%c3%b6wchen";<br>
scheme="<a href="http://purl.org/net/animals/dogs" target="_blank">http://purl.org/net/animals/dogs</a>"<br>
<br> Here, the second category has a label encoded in UTF-8, uses the<br> German language ("de"), and contains the Unicode code point \u'00F6'<br> ("LATIN SMALL LETTER O WITH DIAERESIS").<br>
<br><br>4. IANA Considerations<br><br>4.1. Category Header Registration<br><br> This specification adds an entry for "Category" in HTTP to the<br> Message Header Registry [RFC3864] referring to this document:<br>
Header Field Name: Category<br> Protocol: http<br> Status: standard<br> Author/change controller:<br> IETF (<a href="mailto:iesg@ietf.org" target="_blank">iesg@ietf.org</a>)<br> Internet Engineering Task Force<br>
Specification document(s):<br>
[ this document ]<br><br><br>5. Security Considerations<br><br> The content of the Category header-field is not secure, private or<br> integrity-guaranteed, and due caution should be exercised when using<br> it.<br>
<br><br>6. Internationalisation Considerations<br><br> Category header-fields may be localised depending on the Accept-<br><br><br><br>Johnston Expires January 2, 2010 [Page 5]<br> <br>Internet-Draft Abbreviated Title July 2009<br>
<br><br> Language header-field, as defined in section 14.4 of [RFC2616].<br><br> Scheme IRIs in atom:category elements may need to be converted to<br> URIs in order to express them in serialisations that do not support<br>
IRIs, as defined in section 3.1 of [RFC3987]. This includes the<br> Category header-field.<br><br><br>7. References<br><br>7.1. Normative References<br><br> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate<br>
Requirement Levels", BCP 14, RFC 2119, March 1997.<br><br> [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded<br> Word Extensions: Character Sets, Languages, and<br>
Continuations", RFC 2231, November 1997.<br><br> [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,<br> Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext<br> Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.<br>
<br> [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration<br> Procedures for Message Header Fields", BCP 90, RFC 3864,<br> September 2004.<br><br> [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform<br>
Resource Identifier (URI): Generic Syntax", STD 66,<br> RFC 3986, January 2005.<br><br> [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource<br> Identifiers (IRIs)", RFC 3987, January 2005.<br>
<br> [RFC4287] Nottingham, M. and R. Sayre, "The Atom Syndication<br> Format", RFC 4287, December 2005.<br><br> [RFC5137] Klensin, J., "ASCII Escaping of Unicode Characters",<br> RFC 5137, February 2008.<br>
<br>7.2. Informative References<br><br> [OCCI] Open Grid Forum (OGF), Edmonds, A., Metsch, T., Johnston,<br> S., and A. Richardson, "Open Cloud Computing Interface<br> (OCCI)", <<a href="http://purl.org/occi" target="_blank">http://purl.org/occi</a>>.<br>
<br> [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.<br> Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",<br><br><br><br>Johnston Expires January 2, 2010 [Page 6]<br>
<br>Internet-Draft Abbreviated Title July 2009<br><br><br> RFC 2068, January 1997.<br><br> [W3C.REC-html401-19991224]<br> Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01<br>
Specification",<br> <<a href="http://www.w3.org/TR/1999/REC-html401-19991224" target="_blank">http://www.w3.org/TR/1999/REC-html401-19991224</a>>.<br><br> [W3C.WD-html5-20090423]<br>
Hyatt, D. and I. Hickson, "HTML 5", April 2009,<br>
<<a href="http://www.w3.org/TR/2009/WD-html5-20090423" target="_blank">http://www.w3.org/TR/2009/WD-html5-20090423</a>>.<br><br> [draft-nottingham-http-link-header]<br> Nottingham, M., "Web Linking",<br>
draft-nottingham-http-link-header-05 (work in progress),<br> April 2009.<br><br> [rel-tag-microformat]<br> Celik, T., Marks, K., and D. Powazek, "rel="tag"<br> Microformat", <<a href="http://microformats.org/wiki/rel-tag" target="_blank">http://microformats.org/wiki/rel-tag</a>>.<br>
<br><br>Appendix A. Notes on use with HTML<br><br> In the absence of a dedicated category element in HTML 4<br> [W3C.REC-html401-19991224] and HTML 5 [W3C.WD-html5-20090423],<br> category information (including user supllied folksonomy<br>
classifications) MAY be exposed using HTML A and/or LINK elements by<br> concatenating the scheme and term:<br> category-link = scheme term<br> scheme = URI<br> term = token<br><br> These category-links MAY form a resolveable "tag space" in which case<br>
they SHOULD use the "tag" relation-type per [rel-tag-microformat].<br><br> Alternatively META elements MAY be used:<br><br> o where the "name" attribute is "keywords" and the "content"<br>
attribute is a comma-separated list of term(s)<br><br> o where the "http-equiv" attribute is "Category" and the "content"<br> attribute is a comma-separated list of category-value(s)<br>
<br><br>Appendix B. Notes on use with Atom<br><br> Where the cardinality is known to be one (for example, when<br> retrieving an individual resource) it MAY be preferable to render the<br><br><br><br>Johnston Expires January 2, 2010 [Page 7]<br>
<br>Internet-Draft Abbreviated Title July 2009<br><br><br> resource natively over HTTP without Atom structures. In this case<br> the contents of the atom:content element SHOULD be returned as the<br>
HTTP entity-body and metadata including the type attribute and atom:<br> category element(s) via HTTP header-field(s).<br><br> This approach SHOULD NOT be used where the cardinality is guaranteed<br> to be one (for example, search results which MAY return one result).<br>
<br><br>Appendix C. Acknowledgements<br><br> The author would like to thank Mark Nottingham for his work on Web<br> Linking [draft-nottingham-http-link-header] (on which this document<br> was based) and to the authors of [RFC2068] for specification of the<br>
Link: header-field on which this is based.<br><br> The author would like to thank members of the OGF's Open Cloud<br> Computing Interface [OCCI] working group for their contributions and<br> others who commented upon, encouraged and gave feedback to this<br>
draft.<br><br><br>Appendix D. Document History<br><br> [[ to be removed by the RFC editor should document proceed to<br> publication as an RFC. ]]<br><br> -00<br><br> * Initial draft based on draft-nottingham-http-link-header-05<br>
<br><br>Appendix E. Outstanding Issues<br><br> [[ to be removed by the RFC editor should document proceed to<br> publication as an RFC. ]]<br><br> The following issues are oustanding and should be addressed:<br><br>
1. Is extensibility of Category headers necessary as is the case for<br> Link: headers? If so, what are the use cases?<br><br> 2. Is supporting multi-lingual representations of the same<br> category(s) necessary? If so, what are the risks of doing so?<br>
<br> 3. Is a mechanism for maintaining Category header-fields required?<br> If so, should it use the headers themselves or some other<br> mechanism?<br><br><br><br>Johnston Expires January 2, 2010 [Page 8]<br>
<br>Internet-Draft Abbreviated Title July 2009<br><br><br> 4. Does this proposal conflict with others in the same space? If<br> so, is it an improvement on what exists?<br><br><br>
Author's Address<br><br> Sam Johnston<br> Australian Online Solutions<br> GPO Box 296<br> Sydney, NSW 2001<br><br> Email: <a href="mailto:samj@samj.net" target="_blank">samj@samj.net</a><br> URI: <a href="http://samj.net/" target="_blank">http://samj.net/</a><br>
<br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br>Johnston Expires January 2, 2010 [Page 9]<br>
<br></pre><br></div></div>