idnits 2.17.1 draft-johnston-http-category-header-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 5, 2010) is 5015 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: 1 error (**), 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 Google 4 Intended status: Experimental July 5, 2010 5 Expires: January 6, 2011 7 Web Categories 8 draft-johnston-http-category-header-01 10 Abstract 12 This document specifies the Category header-field for HyperText 13 Transfer Protocol (HTTP), which enables the sending of taxonomy 14 information in HTTP headers. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on January 6, 2011. 33 Copyright Notice 35 Copyright (c) 2010 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 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 52 2. Categories . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. The Category Header Field . . . . . . . . . . . . . . . . . . . 4 54 3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 56 4.1. Category Header Registration . . . . . . . . . . . . . . . 5 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 58 6. Internationalisation Considerations . . . . . . . . . . . . . . 5 59 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 61 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 62 Appendix A. Notes on use with HTML . . . . . . . . . . . . . . . . 7 63 Appendix B. Notes on use with Atom . . . . . . . . . . . . . . . . 7 64 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . . 8 65 Appendix D. Change Log (to be removed by RFC Editor before 66 publication) . . . . . . . . . . . . . . . . . . . . . 8 67 D.1. draft-johnston-http-category-header-00 . . . . . . . . . . 8 68 D.2. draft-johnston-http-category-header-01 . . . . . . . . . . 8 69 Appendix E. Outstanding Issues . . . . . . . . . . . . . . . . . . 8 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 1. Introduction 74 A means of indicating categories for resources on the web has been 75 defined by Atom [RFC4287]. This document defines a framework for 76 exposing category information in the same format via HTTP headers. 78 The atom:category element conveys information about a category 79 associated with an entry or feed. A given atom:feed or atom:entry 80 element MAY have zero or more categories which MUST have a "term" 81 attribute (a string that identifies the category to which the entry 82 or feed belongs) and MAY also have a scheme attribute (an IRI that 83 identifies a categorization scheme) and/or a label attribute (a 84 human-readable label for display in end-user applications). 86 Similarly a web resource may be associated with zero or more 87 categories as indicated in the Category header-field(s). These 88 categories may be divided into separate vocabularies or "schemes" 89 and/or accompanied with human-friendly labels. 91 [[ Feedback is welcome on the ietf-http-wg@w3.org mailing list, 92 although this is NOT a work item of the HTTPBIS WG. ]] 94 1.1. Requirements Language 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in BCP 14, [RFC2119], as 99 scoped to those conformance targets. 101 This document uses the Augmented Backus-Naur Form (ABNF) notation of 102 [RFC2616], and explicitly includes the following rules from it: 103 quoted-string, token. Additionally, the following rules are included 104 from [RFC3986]: URI. 106 2. Categories 108 In this specification, a category is a grouping of resources by 109 'term', from a vocabulary ('scheme') identified by an IRI [RFC3987]. 110 It is comprised of: 112 o A "term" which is a string that identifies the category to which 113 the resource belongs. 115 o A "scheme" which is an IRI that identifies a categorization scheme 116 (optional). 118 o An "label" which is a human-readable label for display in end-user 119 applications (optional). 121 A category can be viewed as a statement of the form "resource is from 122 the {term} category of {scheme}, to be displayed as {label}", for 123 example "'Loewchen' is from the 'dog' category of 'animals', to be 124 displayed as 'Canine'". 126 3. The Category Header Field 128 The Category entity-header provides a means for serialising one or 129 more categories in HTTP headers. It is semantically equivalent to 130 the atom:category element in Atom [RFC4287]. 132 Category = "Category" ":" #category-value 133 category-value = term *( ";" category-param ) 134 category-param = ( ( "scheme" "=" <"> scheme <"> ) 135 | ( "label" "=" quoted-string ) 136 | ( "label*" "=" enc2231-string ) 137 | ( category-extension ) ) 138 category-extension = token [ "=" ( token | quoted-string ) ] 139 enc2231-string = 140 term = token 141 scheme = URI 143 Each category-value conveys exactly one category but there may be 144 multiple category-values for each header-field and/or multiple 145 header-fields per [RFC2616]. 147 Note that schemes are REQUIRED to be absolute URLs in Category 148 headers, and MUST be quoted if they contain a semicolon (";") or 149 comma (",") as these characters are used to separate category-params 150 and category-values respectively. 152 The "label" parameter is used to label the category such that it can 153 be used as a human-readable identifier (e.g. a menu entry). 154 Alternately, the "label*" parameter MAY be used encode this label in 155 a different character set, and/or contain language information as per 156 [RFC2231]. When using the enc2231-string syntax, producers MUST NOT 157 use a charset value other than 'ISO-8859-1' or 'UTF-8'. 159 3.1. Examples 161 NOTE: Non-ASCII characters used in prose for examples are encoded 162 using the format "Backslash-U with Delimiters", defined in Section 163 5.1 of [RFC5137]. 165 For example: 166 Category: dog 168 indicates that the resource is in the "dog" category. 169 Category: dog; label="Canine"; scheme="http://purl.org/net/animals" 171 indicates that the resource is in the "dog" category, from the 172 "http://purl.org/net/animals" scheme, and should be displayed as 173 "Canine". 175 The example below shows an instance of the Category header encoding 176 multiple categories, and also the use of [RFC2231] encoding to 177 represent both non-ASCII characters and language information. 178 Category: dog; label="Canine"; scheme="http://purl.org/net/animals", 179 lowchen; label*=UTF-8'de'L%c3%b6wchen"; 180 scheme="http://purl.org/net/animals/dogs" 182 Here, the second category has a label encoded in UTF-8, uses the 183 German language ("de"), and contains the Unicode code point \u'00F6' 184 ("LATIN SMALL LETTER O WITH DIAERESIS"). 186 4. IANA Considerations 188 4.1. Category Header Registration 190 This specification adds an entry for "Category" in HTTP to the 191 Message Header Registry [RFC3864] referring to this document: 192 Header Field Name: Category 193 Protocol: http 194 Status: standard 195 Author/change controller: 196 IETF (iesg@ietf.org) 197 Internet Engineering Task Force 198 Specification document(s): 199 [ this document ] 201 5. Security Considerations 203 The content of the Category header-field is not secure, private or 204 integrity-guaranteed, and due caution should be exercised when using 205 it. 207 6. Internationalisation Considerations 209 Category header-fields may be localised depending on the Accept- 210 Language header-field, as defined in section 14.4 of [RFC2616]. 212 Scheme IRIs in atom:category elements may need to be converted to 213 URIs in order to express them in serialisations that do not support 214 IRIs, as defined in section 3.1 of [RFC3987]. This includes the 215 Category header-field. 217 7. References 219 7.1. Normative References 221 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 222 Requirement Levels", BCP 14, RFC 2119, March 1997. 224 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 225 Word Extensions: 226 Character Sets, Languages, and Continuations", RFC 2231, 227 November 1997. 229 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 230 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 231 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 233 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 234 Procedures for Message Header Fields", BCP 90, RFC 3864, 235 September 2004. 237 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 238 Resource Identifier (URI): Generic Syntax", STD 66, 239 RFC 3986, January 2005. 241 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 242 Identifiers (IRIs)", RFC 3987, January 2005. 244 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom 245 Syndication Format", RFC 4287, December 2005. 247 [RFC5137] Klensin, J., "ASCII Escaping of Unicode Characters", 248 BCP 137, RFC 5137, February 2008. 250 7.2. Informative References 252 [I-D.nottingham-http-link-header] 253 Nottingham, M., "Web Linking", 254 draft-nottingham-http-link-header-10 (work in progress), 255 May 2010. 257 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. 258 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 259 RFC 2068, January 1997. 261 [W3C.REC-html401-19991224] 262 Hors, A., Jacobs, I., and D. Raggett, "HTML 4.01 263 Specification", World Wide Web Consortium 264 Recommendation REC-html401-19991224, December 1999, 265 . 267 [W3C.WD-html5-20100624] 268 Hickson, I., "HTML5", World Wide Web Consortium WD WD- 269 html5-20100624, June 2010, 270 . 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-20100624], 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 [I-D.nottingham-http-link-header] (on which this document was 314 based), the authors of [RFC2068] for specification of the Link: 315 header-field on which this is based and all those who commented upon, 316 encouraged and gave feedback to this draft. 318 Appendix D. Change Log (to be removed by RFC Editor before publication) 320 D.1. draft-johnston-http-category-header-00 322 Initial draft based on draft-nottingham-http-link-header-05 324 D.2. draft-johnston-http-category-header-01 326 Updated references, affiliation and tickled for IETF-78. 328 Appendix E. Outstanding Issues 330 [[ to be removed by the RFC editor should document proceed to 331 publication as an RFC. ]] 333 The following issues are oustanding and should be addressed: 335 1. Is extensibility of Category headers necessary as is the case for 336 Link: headers? If so, what are the use cases? 338 2. Is supporting multi-lingual representations of the same 339 category(s) necessary? If so, what are the risks of doing so? 341 3. Is a mechanism for maintaining Category header-fields required? 342 If so, should it use the headers themselves or some other 343 mechanism? 345 4. Does this proposal conflict with others in the same space? If 346 so, is it an improvement on what exists? 348 Author's Address 350 Sam Johnston 351 Google 352 Brandschenkestrasse, 110 353 Zuerich 8002 354 CH 356 Email: sj@google.com