idnits 2.17.1 draft-mutz-http-attributes-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 250 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 6 characters in excess of 72. ** There are 30 instances of lines with control characters in the document. ** The abstract seems to contain references ([3], [4], [6]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 146 has weird spacing: '...vels of a...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 12, 1996) is 10152 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 206, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 210, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 219, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1630 (ref. '1') ** Obsolete normative reference: RFC 1738 (ref. '2') (Obsoleted by RFC 4248, RFC 4266) ** Downref: Normative reference to an Informational RFC: RFC 1945 (ref. '3') -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 1759 (ref. '6') (Obsoleted by RFC 3805) Summary: 16 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 HTTP Working Group A. Mutz, Hewlett-Packard 2 INTERNET-DRAFT L. Montulli, Netscape 3 L. Masinter, Xerox 5 Expires December 12, 1996 June 12, 1996 7 User-Agent Display Attributes Headers 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, and 13 its working groups. Note that other groups may also distribute working 14 documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or made obsolete by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference material 18 or to cite them other than as "work in progress". 19 To learn the current status of any Internet-Draft, please check the 20 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 21 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 22 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 23 ftp.isi.edu (US West Coast). 24 Distribution of this document is unlimited. Please send comments to the 25 HTTP working group at . Discussions of the 26 working group are archived at 27 . General discussions about 28 HTTP and the applications which use HTTP should take place on the mailing list. 31 This is an initial draft intended for soliciting comments and should not 32 be released in any production software system. 34 Abstract 36 User-Agent Display Attributes Headers provide a means for an HTTP client 37 [3] to inform a server about its display capabilities. This memo 38 describes the syntax for introducing this information into an HTTP 39 transmission. The intent is to express a client's capabilities such that 40 a capable server may present documents in a preferred form. If such a 41 preferred form is not available, the server should still provide the 42 requested documents. 44 This specification is intended as an extension to HTTP/1.1 [4]. 46 Introduction 48 Purpose 50 The Hypertext Transfer Protocol (HTTP) is protocol for distributed, 51 collaborative, hypermedia information systems. 52 At present it relies on the client's ability to present visual 53 information in a usable fashion without information about the client's 54 display characteristics. The presence of large images, video, and 55 other visual information in HTML documents has strained this model. 56 HTML documents suitable for a certain video monitor size are often less 57 usable on displays of much smaller or larger resolution, such as PDA's 58 and high-resolution printers. 60 This specification defines message headers as an extension to the 61 protocol referred to as HTTP. This extension enables a client to inform 62 a server regarding its display capabilities. The server may then 63 provide a variant of the resource more suitable for the display. This 64 variant would typically have higher or lower resolution images (for 65 example) as appropriate. In the case of a printer client, the result 66 would be higher quality output. In the case of a PDA, the result would 67 be faster transmission. These display attribute headers should be 68 suitable for use with the negotiation mechanisms of HTTP. The presence 69 of these headers must not cause a request to be failed for lack of the 70 variant resouce. 72 Operation 74 When a server receives an HTTP request including UA-attrib message 75 headers, it may use this information to indicate a variant of a resource 76 most appropriate for the client's display. The variants are expected to 77 differ primarily in image size and color content, but other variations 78 such as shorter text descriptions are also foreseeable. 79 The number of variants should be limited to provide efficient caching 80 since the number of variants could become very large. 82 UA-attrib headers can indicate display size (in pixels), window size (in 83 pixels), display resolution (in pixels/inch), color capability and bit- 84 depth, and display media type. The physical dimensions of the display 85 can be inferred from the display size and display resolution. These are 86 presented formally in the Notation section. 88 Five UA-attrib headers are defined. 90 User-Agent Attributes: 92 UA-pixels: x 94 The available display size of the client's device is transmitted in 95 total (horizontal) x (vertical) pixel number, for example: UA- 96 pixels: 1024x768. The intent is to expose a maximum capability rather 97 than a preferred size such as current browser window, with the 98 presumption that a user would prefer to resize a window than request a 99 new set of resources. In the case of paper media, the size should 100 represent the printable area rather than the physical sheet size (to 101 avoid clipping of contents). 103 For the case of an embedded object, this should be the size of the 104 embedding frame. 106 UA-windowpixels: x 108 The window size of the client's application is transmitted in total 109 (horizontal) x (vertical) pixel number, for example: UA- 110 pixels: 640x300. The intent is to relay the client's preferred window 111 size, with the presumption that a user would like to view the available 112 resources in this window. 114 The authors are debating the utility of this field, and it is included 115 here for discussion. 117 UA-resolution: 119 The display device resolution is transmitted in pixels per inch. For 120 example: UA-resolution: 72. 122 The authors recognize English units are not universal, but desire to 123 avoid multiple unit definitions. 125 UA-media: 127 The display device media is indicated with an ASCII token. Basic token 128 values are: screen, stationary, transparency, envelope, or continuous- 129 long. Other values may be defined. Except for `screen', these tokens 130 are a subset of the Printer MIB MediaType set defined in RFC-1759 [6]. 131 They are defined as: 132 screen: a refreshable display 133 stationary: separately cut sheets of an opaque material 134 transparency: separately cut sheets of a transparent material 135 envelope: envelopes that can be used for conventional mailing 136 purposes 137 continuous-short: continuously connected sheets of an opaque 138 material connected along the short edge 140 UA-color: 142 The display color capabilities are indicated with a combination of an 143 ASCII token and a parameter describing the number of color channel 144 bits available. Token values must be: grey or color. Values of 145 are typically (but not limited to) 2, 8, or 24. For example: grey8 146 indicates a display capable of representing an image in 256 levels of a 147 single color, while color8 indicates a display capable of representing 148 an image with a palette of 256 colors. 150 The authors recognize the issue of color model may be raised, but have 151 concluded for this draft multiple color models such as CMYK and display 152 gamma are not included. The RGB color model with gamma 2.2 is 153 assumed. 155 Negotiation 157 The use of a UA-attrib should not cause a request to fail. The intent 158 is to request a preferred presentation rather than a basic inability to 159 present a resource (such as inability to handle a MIME type.) 161 Notation 163 UA-attrib related syntax is specified here relative to the definitions 164 and rules of the HTTP specifications. 166 Header fields 168 UA-attrib defines 4 new specific header fields, UA-pixels, UA- 169 resolution, UA-media, and UA-color to be added to HTTP/1.1. These 170 attributes may be used together or independently. The header fields are 171 defined as follows: 173 UA-pixels = "UA-pixels" ":" horizontal "x" vertical 174 UA-windowpixels = "UA-windowpixels" ":" horizontal "x" vertical 175 UA-resolution = "UA-resolution" ":" ppi 176 UA-media = "UA-media" ":" media 177 UA-color = "UA-color" ":" ("grey" | "color") colorbits 178 horizontal = 1*DIGIT 179 vertical = 1*DIGIT 180 ppi = 1*DIGIT 181 media = token | ("screen" | "stationary" | "transparency" | 182 "envelope" | "continuous-short") 183 colorbits = 1*DIGIT 185 Examples of the above attributes: 187 UA-pixels: 1024x768 188 indicates a 1024x768 display 189 UA-windowpixels: 640x300 190 indicates a 640x300 display window 191 UA-resolution: 72 192 indicates a 72 dpi display 193 UA-media: stationary 194 indicates the display is a cut sheet of opaque material, such as 195 paper. 196 UA-color: color24 197 indicates the display supports 24-bit (8-bit/channel) color. 199 Acknowledgments 201 This document has benefited from the comments of Ho John Lee, Brian Behlendorf 202 and Koen Holtman. 204 References 206 [1] T. Berners-Lee. "Universal Resource Identifiers in WWW." A 207 Unifying Syntax for the Expression of Names and Addresses of Objects 208 on the Network as used in the World-Wide Web." RFC 1630, CERN, June 209 1994. 210 [2] T. Berners-Lee, L. Masinter, M. McCahill. 211 "Uniform Resource Locators (URL)." RFC 1738, CERN, Xerox PARC, 212 University of Minnesota, December 1994. 213 [3] T. Berners-Lee, R. Fielding, H. Frystyk. 214 "Hypertext Transfer Protocol -- HTTP/1.0." RFC 1945." MIT/LCS, UC 215 Irvine, May 1996. 216 [4] T. Berners-Lee, R. Fielding,I J. Gettys, J. Mogul, H. Frystyk. 217 "Hypertext Transfer Protocol - HTTP/1.1." Work in progress." MIT/LCS, 218 UC Irvine, May 1996. 219 [5] R. Braden. 220 "Requirements for Internet hosts - application and support." STD 3, 221 RFC 1123, IETF, October 1989. 222 [6] R. Smith, F. Wright, T. Hastings, S. Zilles, J. Gyllenskog. "Printer 223 MIB." RFC 1759." IETF, March 1995 225 Authors' Addresses 227 Larry Masinter 228 Xerox Palo Alto Research Center 229 3333 Coyote Hill Road 230 Palo Alto CA 94304 231 Phone: +1 415 812 4365 232 Fax +1 415 812 4333 233 Email: masinter@parc.xerox.com 235 Lou Montulli 236 Netscape Communications Corp. 237 501 E. Middlefield Rd. 238 Mountain View, CA 94043, USA 239 Phone +1 415 528 2600 240 Email: montulli@netscape.com 242 Andrew H. Mutz 243 Hewlett-Packard Company 244 1501 Page Mill Road 3U-3 245 Palo Alto CA 94304, USA 246 Fax +1 415 857 4691 247 Email: mutz@hpl.hp.com