idnits 2.17.1 draft-johnston-http-category-header-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 1, 2009) is 5385 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2068 (Obsoleted by RFC 2616) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Johnston 3 Internet-Draft Australian Online Solutions 4 Intended status: Experimental July 1, 2009 5 Expires: January 2, 2010 7 Web Categories 8 draft-johnston-http-category-header-00 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on January 2, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document specifies the Category header-field for HyperText 47 Transfer Protocol (HTTP), which enables the sending of taxonomy 48 information in HTTP headers. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 54 2. Categories . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. The Category Header Field . . . . . . . . . . . . . . . . . . . 4 56 3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 58 4.1. Category Header Registration . . . . . . . . . . . . . . . 5 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 60 6. Internationalisation Considerations . . . . . . . . . . . . . . 5 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 63 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 64 Appendix A. Notes on use with HTML . . . . . . . . . . . . . . . . 7 65 Appendix B. Notes on use with Atom . . . . . . . . . . . . . . . . 7 66 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . . 8 67 Appendix D. Document History . . . . . . . . . . . . . . . . . . . 8 68 Appendix E. Outstanding Issues . . . . . . . . . . . . . . . . . . 8 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 1. Introduction 73 A means of indicating categories for resources on the web has been 74 defined by Atom [RFC4287]. This document defines a framework for 75 exposing category information in the same format via HTTP headers. 77 The atom:category element conveys information about a category 78 associated with an entry or feed. A given atom:feed or atom:entry 79 element MAY have zero or more categories which MUST have a "term" 80 attribute (a string that identifies the category to which the entry 81 or feed belongs) and MAY also have a scheme attribute (an IRI that 82 identifies a categorization scheme) and/or a label attribute (a 83 human-readable label for display in end-user applications). 85 Similarly a web resource may be associated with zero or more 86 categories as indicated in the Category header-field(s). These 87 categories may be divided into separate vocabularies or "schemes" 88 and/or accompanied with human-friendly labels. 90 [[ Feedback is welcome on the ietf-http-wg@w3.org mailing list, 91 although this is NOT a work item of the HTTPBIS WG. ]] 93 1.1. Requirements Language 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in BCP 14, [RFC2119], as 98 scoped to those conformance targets. 100 This document uses the Augmented Backus-Naur Form (ABNF) notation of 101 [RFC2616], and explicitly includes the following rules from it: 102 quoted-string, token. Additionally, the following rules are included 103 from [RFC3986]: URI. 105 2. Categories 107 In this specification, a category is a grouping of resources by 108 'term', from a vocabulary ('scheme') identified by an IRI [RFC3987]. 109 It is comprised of: 111 o A "term" which is a string that identifies the category to which 112 the resource belongs. 114 o A "scheme" which is an IRI that identifies a categorization scheme 115 (optional). 117 o An "label" which is a human-readable label for display in end-user 118 applications (optional). 120 A category can be viewed as a statement of the form "resource is from 121 the {term} category of {scheme}, to be displayed as {label}", for 122 example "'Loewchen' is from the 'dog' category of 'animals', to be 123 displayed as 'Canine'". 125 3. The Category Header Field 127 The Category entity-header provides a means for serialising one or 128 more categories in HTTP headers. It is semantically equivalent to 129 the atom:category element in Atom [RFC4287]. 131 Category = "Category" ":" #category-value 132 category-value = term *( ";" category-param ) 133 category-param = ( ( "scheme" "=" <"> scheme <"> ) 134 | ( "label" "=" quoted-string ) 135 | ( "label*" "=" enc2231-string ) 136 | ( category-extension ) ) 137 category-extension = token [ "=" ( token | quoted-string ) ] 138 enc2231-string = 139 term = token 140 scheme = URI 142 Each category-value conveys exactly one category but there may be 143 multiple category-values for each header-field and/or multiple 144 header-fields per [RFC2616]. 146 Note that schemes are REQUIRED to be absolute URLs in Category 147 headers, and MUST be quoted if they contain a semicolon (";") or 148 comma (",") as these characters are used to separate category-params 149 and category-values respectively. 151 The "label" parameter is used to label the category such that it can 152 be used as a human-readable identifier (e.g. a menu entry). 153 Alternately, the "label*" parameter MAY be used encode this label in 154 a different character set, and/or contain language information as per 155 [RFC2231]. When using the enc2231-string syntax, producers MUST NOT 156 use a charset value other than 'ISO-8859-1' or 'UTF-8'. 158 3.1. Examples 160 NOTE: Non-ASCII characters used in prose for examples are encoded 161 using the format "Backslash-U with Delimiters", defined in Section 162 5.1 of [RFC5137]. 164 For example: 165 Category: dog 167 indicates that the resource is in the "dog" category. 168 Category: dog; label="Canine"; scheme="http://purl.org/net/animals" 170 indicates that the resource is in the "dog" category, from the 171 "http://purl.org/net/animals" scheme, and should be displayed as 172 "Canine". 174 The example below shows an instance of the Category header encoding 175 multiple categories, and also the use of [RFC2231] encoding to 176 represent both non-ASCII characters and language information. 177 Category: dog; label="Canine"; scheme="http://purl.org/net/animals", 178 lowchen; label*=UTF-8'de'L%c3%b6wchen"; 179 scheme="http://purl.org/net/animals/dogs" 181 Here, the second category has a label encoded in UTF-8, uses the 182 German language ("de"), and contains the Unicode code point \u'00F6' 183 ("LATIN SMALL LETTER O WITH DIAERESIS"). 185 4. IANA Considerations 187 4.1. Category Header Registration 189 This specification adds an entry for "Category" in HTTP to the 190 Message Header Registry [RFC3864] referring to this document: 191 Header Field Name: Category 192 Protocol: http 193 Status: standard 194 Author/change controller: 195 IETF (iesg@ietf.org) 196 Internet Engineering Task Force 197 Specification document(s): 198 [ this document ] 200 5. Security Considerations 202 The content of the Category header-field is not secure, private or 203 integrity-guaranteed, and due caution should be exercised when using 204 it. 206 6. Internationalisation Considerations 208 Category header-fields may be localised depending on the Accept- 209 Language header-field, as defined in section 14.4 of [RFC2616]. 211 Scheme IRIs in atom:category elements may need to be converted to 212 URIs in order to express them in serialisations that do not support 213 IRIs, as defined in section 3.1 of [RFC3987]. This includes the 214 Category header-field. 216 7. References 218 7.1. Normative References 220 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 221 Requirement Levels", BCP 14, RFC 2119, March 1997. 223 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 224 Word Extensions: Character Sets, Languages, and 225 Continuations", RFC 2231, November 1997. 227 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 228 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 229 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 231 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 232 Procedures for Message Header Fields", BCP 90, RFC 3864, 233 September 2004. 235 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 236 Resource Identifier (URI): Generic Syntax", STD 66, 237 RFC 3986, January 2005. 239 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 240 Identifiers (IRIs)", RFC 3987, January 2005. 242 [RFC4287] Nottingham, M. and R. Sayre, "The Atom Syndication 243 Format", RFC 4287, December 2005. 245 [RFC5137] Klensin, J., "ASCII Escaping of Unicode Characters", 246 RFC 5137, February 2008. 248 7.2. Informative References 250 [OCCI] Open Grid Forum (OGF), Edmonds, A., Metsch, T., Johnston, 251 S., and A. Richardson, "Open Cloud Computing Interface 252 (OCCI)", . 254 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. 255 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 256 RFC 2068, January 1997. 258 [W3C.REC-html401-19991224] 259 Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01 260 Specification", 261 . 263 [W3C.WD-html5-20090423] 264 Hyatt, D. and I. Hickson, "HTML 5", April 2009, 265 . 267 [draft-nottingham-http-link-header] 268 Nottingham, M., "Web Linking", 269 draft-nottingham-http-link-header-05 (work in progress), 270 April 2009. 272 [rel-tag-microformat] 273 Celik, T., Marks, K., and D. Powazek, "rel="tag" 274 Microformat", . 276 Appendix A. Notes on use with HTML 278 In the absence of a dedicated category element in HTML 4 279 [W3C.REC-html401-19991224] and HTML 5 [W3C.WD-html5-20090423], 280 category information (including user supllied folksonomy 281 classifications) MAY be exposed using HTML A and/or LINK elements by 282 concatenating the scheme and term: 283 category-link = scheme term 284 scheme = URI 285 term = token 287 These category-links MAY form a resolveable "tag space" in which case 288 they SHOULD use the "tag" relation-type per [rel-tag-microformat]. 290 Alternatively META elements MAY be used: 292 o where the "name" attribute is "keywords" and the "content" 293 attribute is a comma-separated list of term(s) 295 o where the "http-equiv" attribute is "Category" and the "content" 296 attribute is a comma-separated list of category-value(s) 298 Appendix B. Notes on use with Atom 300 Where the cardinality is known to be one (for example, when 301 retrieving an individual resource) it MAY be preferable to render the 302 resource natively over HTTP without Atom structures. In this case 303 the contents of the atom:content element SHOULD be returned as the 304 HTTP entity-body and metadata including the type attribute and atom: 305 category element(s) via HTTP header-field(s). 307 This approach SHOULD NOT be used where the cardinality is guaranteed 308 to be one (for example, search results which MAY return one result). 310 Appendix C. Acknowledgements 312 The author would like to thank Mark Nottingham for his work on Web 313 Linking [draft-nottingham-http-link-header] (on which this document 314 was based) and to the authors of [RFC2068] for specification of the 315 Link: header-field on which this is based. 317 The author would like to thank members of the OGF's Open Cloud 318 Computing Interface [OCCI] working group for their contributions and 319 others who commented upon, encouraged and gave feedback to this 320 draft. 322 Appendix D. Document History 324 [[ to be removed by the RFC editor should document proceed to 325 publication as an RFC. ]] 327 -00 329 * Initial draft based on draft-nottingham-http-link-header-05 331 Appendix E. Outstanding Issues 333 [[ to be removed by the RFC editor should document proceed to 334 publication as an RFC. ]] 336 The following issues are oustanding and should be addressed: 338 1. Is extensibility of Category headers necessary as is the case for 339 Link: headers? If so, what are the use cases? 341 2. Is supporting multi-lingual representations of the same 342 category(s) necessary? If so, what are the risks of doing so? 344 3. Is a mechanism for maintaining Category header-fields required? 345 If so, should it use the headers themselves or some other 346 mechanism? 348 4. Does this proposal conflict with others in the same space? If 349 so, is it an improvement on what exists? 351 Author's Address 353 Sam Johnston 354 Australian Online Solutions 355 GPO Box 296 356 Sydney, NSW 2001 358 Email: samj@samj.net 359 URI: http://samj.net/