idnits 2.17.1 draft-ietf-conneg-media-features-04.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. Found some kind of copyright notice around line 29 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-19) 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 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 364 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([REG]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (January 4, 1999) is 9237 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'SI' Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Larry Masinter 2 draft-ietf-conneg-media-features-04.txt Koen Holtman 3 Andy Mutz 4 Dan Wing 5 expires in 6 months January 4, 1999 7 Media Features for Display, Print, and Fax 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, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet-Drafts 19 as reference material or to cite them other than as "work in 20 progress." 22 To view the entire list of current Internet-Drafts, please check 23 the "1id-abstracts.txt" listing contained in the Internet-Drafts 24 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 25 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 26 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 27 (US West Coast). 29 Copyright (C) The Internet Society (1997). All Rights Reserved. 31 Abstract 33 This specification defines some common media features for 34 describing image resolution, size, color, and image representation 35 methods that are common to web browsing, printing, and facsimile 36 applications. These features are registered for use within the 37 framework of [REG]. 39 1. Introduction 41 This work was originally motivated by the requirements from web 42 browsers to send the browser's display characteristics to the web 43 server to allow the server to choose an appropriate representation. 45 This specification defines some common media features [REG] by 46 which a recipient may inform a sender as to the characteristics of 47 its message handling. The sender may then provide the variant of 48 the message that is most suitable for the recipient. 50 Different variants would typically be higher or lower resolution 51 images (for example) as appropriate. In the case of a sending to a 52 printer, the result would be higher quality output. In the case of 53 a small screen device (cellphone, portable digital assistant), the 54 result would be faster transmission. 56 Media features may be used in many different protocol situations. 57 Those defined in this specification can indicate the display or 58 printer dimensions, resolution, color capability. The physical 59 dimensions of a display may be inferred from the display size and 60 display resolution. In the case of paper output, the paper size may 61 be expressed as a token from a list of standard paper sizes. These 62 are presented formally in the Notation section. 64 2. Media Feature Registrations 66 This section defines several media features, using the form 67 specified in [REG]. 69 2.1 Image Size 71 - Media Feature tag name(s): 73 pix-x 74 pix-y 76 - ASN.1 identifier associated with this feature tag: 78 ***New assignments by IANA*** 80 - Summary of the media features indicated by this feature tag: 82 These features indicate the display size of the recipient for 83 display or print, measured in pixels; they indicate horizontal 84 (pix-x) and vertical (pix-y) dimensions. 86 - Values appropriate for use with this feature tag: 88 Signed Integer 90 - The feature tag is intended primarily for use in the following 91 applications, protocols, services, or negotiation mechanisms: 93 Display and print applications where different media choices will 94 be made depending on the size of the recipient device. For 95 example, a web application for use on a 240x480 display might use 96 different HTML pages than one intended for use on a 1024x768 97 display. 99 2.2 Resolution 101 - Media Feature tag name: 103 dpi 105 - ASN.1 identifier associated with this feature tag: 107 ***New assignments by IANA*** 109 - Summary of the media features indicated by this feature tag: 111 This feature indicates the resolution that the recipient can 112 display or print without loss, measured in pixels per inch. 113 Typically resolution capability is represented as dots-per-inch 114 rather than in SI units [SI]. Values for dpi may be expressed as a 115 rational to accomodate resolution of SI-based devices; for example 116 dpi=19558/100 can be used to represent a resolution of 77 dots per 117 centimeter. 119 - Values appropriate for use with this feature tag: 121 Rational 123 - The feature tag is intended primarily for use in the following 124 applications, protocols, services, or negotiation mechanisms: 126 Printing and fax applications typically choose representations of 127 a transmitted document depending on the resolution of the 128 recipient rather than pixel size. 130 - Examples of typical use: 132 Choosing a version of a printable document to send to a printer. 134 - Considerations particular to use in individual applications, 135 protocols, services, or negotiation mechanisms: 137 Software applications are typically unaware of the resolution of 138 the display. Note that there exist devices with different 139 resolution in different directions, i.e., individual pixels are 140 not square. However, this feature only encompasses the 141 uniform resolution. 143 2.3 Registration of 'ua-media' 145 - Media Feature tag name(s): 147 ua-media 149 - ASN.1 identifier associated with this feature tag: 151 ***New assignments by IANA*** 153 - Summary of the media features indicated by this feature tag: 155 This feature indicates the recipients device media, indicated with 156 an simple token. 158 - Values appropriate for use with this feature tag: 160 Token with an equality relationship. Values include: 162 screen A refreshable display 163 screen-paged a refreshable display which cannot scroll 164 stationery Separately cut sheets of an opaque material 165 transparency Separately cut sheets of a transparent material 166 envelope Envelopes that can be used for conventional 167 mailing purposes 168 envelope-plain Envelopes that are not preprinted and have no 169 windows 170 continuous Continuously connected sheets of an opaque 171 material 173 - The feature tag is intended primarily for use in the following 174 applications, protocols, services, or negotiation mechanisms: 176 Most of the feature values are useful for printing applications, 177 or to distinguish printing from display. 179 - Examples of typical use: 181 This might typically be used for selecting between a rendition 182 that is intended to be printed and one that is intended to be 183 displayed. 185 - Considerations particular to use in individual applications, 186 protocols, services, or negotiation mechanisms: 188 Other media values were not included because their utility seemed 189 relative. 191 - Interoperability considerations: 193 Interoperability with the Internet Print Protocol means that 194 some additional feature values may need to be registered. 196 2.4 Paper Size 198 - Media Feature tag name(s): 200 paper-size 202 - ASN.1 identifier associated with this feature tag: 204 ***New assignment by IANA*** 206 - Summary of the media features indicated by this feature tag: 208 For stationery, it is often useful to have information about the 209 size of display used. While it is more precise and predictable to 210 use absolute resolution and pixel sizes, some applications find it 211 useful to provide paper size in addition to this information. Note 212 that not all of the paper may have a printable area. 214 - Values appropriate for use with this feature tag: 216 Token with an equality relationship. Typical values include: 218 letter 8.5x11.0 inches 219 a4 210x297 mm 220 b4 250x353 mm 221 a3 297x420 mm 222 legal 8.5x14 inches 224 - The feature tag is intended primarily for use in the following 225 applications, protocols, services, or negotiation mechanisms: 227 This feature tag seems most useful for the printing application. 229 - Examples of typical use: 231 Choosing between a4 and letter size renditions of the same 232 printable document. 234 2.5 Color and greyscale 236 - Media Feature tag name(s): 238 color 240 - ASN.1 identifier associated with this feature tag: 242 ***New assignments by IANA*** 244 - Summary of the media features indicated by this feature tag: 246 This feature indicates a gross level of capability to represent 247 (or need for) for handling of color, out of a limited set of 248 choices. 250 - Values appropriate for use with this feature tag: 252 Token with an equality relationship. Values include: 254 binary black-and-white, or other bi-level capability. 256 grey more than two levels of intensity; for example, 257 at least two bits of grey-scale data 259 limited availability of a small number of colors, such as 260 might be provided by a highlight printer, pen plotter, 261 or limited color display. Such capability is useful 262 for business graphics. At the lowest level of 263 capability, this implies at least one color other than 264 black ("highlight color"). At the high end, a small 265 number (less than 32) colors. No implication is made 266 that any particular color is available. 268 mapped pixel color values are mapped in some specifable way 269 to a multi-component color space. Sufficient levels of 270 display are available to represent a continuous tone 271 photographic image, but the result will be mapped into 272 a more limited space. 274 full ability (or at least willingness) to represent a full 275 color image and present it. Full continuous tone color 276 capability. 278 - The feature tag is intended primarily for use in the following 279 applications, protocols, services, or negotiation mechanisms: 281 Web applications may choose between color, grey, or binary 282 representations. Fax or printing applications might choose 283 between color and non-color renditions, for example. 285 - Examples of typical use: 287 Someone preparing a map of directions to a restaurant might 288 prepare different maps for each kind of value. 290 - Intended usage: 291 COMMON 293 3. Examples of use of features 295 The following examples of feature comparison show how these features 296 can be used to describe various capabilities. The syntax used to 297 express combinations of features is purely illustrative and not 298 normative: 300 pix-x<=1024, pix-y<=768 301 might be used for a 1024x768 display. 303 dpi=300 304 might be used for a 300 dpi printer. 306 paper-size=a4 307 indicates the display size is 210x297mm. 309 4. IANA considerations 311 This document calls for registration of the following feature tags, 312 as per [REG]: pix-x, pix-y, dpi, ua-media, paper-size, color. 313 ASN.1 identifiers should be assigned to each of these and replaced 314 in the body of the registration. 316 5. Acknowledgments 318 This document is based on a previous draft co-authored with Lou 319 Montoulli. It had benefited from the comments of Graham Klyne, Ho 320 John Lee, Brian Behlendorf, Jeff Mogul, Ted Hardie, and Dan Wing. 322 6. References 324 [REG] A. Mutz, T. Hardie. "Feature Tag Registration Procedures", 325 draft-ietf-conneg-feature-reg-03.txt, July 1998. 327 [SI] ISO 1000:1992 "SI units and recommendations for the use of 328 their multiples and of certain other units", International 329 Organization for Standardization, 1992. 331 Author's Addresses 333 Larry Masinter 334 Xerox Palo Alto Research Center 335 3333 Coyote Hill Road 336 Palo Alto CA 94304 337 Fax +1 650 812 4333 338 Email: masinter@parc.xerox.com 340 Dan Wing 341 Cisco Systems, Inc. 342 101 Cooper Street 343 Santa Cruz, CA 95060 USA 344 Phone: +1 831 457 5200 345 Fax: +1 831 457 5208 346 EMail: dwing@cisco.com 348 Andrew H. Mutz 349 Hewlett-Packard Company 350 1501 Page Mill Road 3U-3 351 Palo Alto CA 94304, USA 352 Fax +1 650 857 4691 353 Email: mutz@hpl.hp.com 355 Koen Holtman 356 Technische Universiteit Eindhoven 357 Postbus 513 358 Kamer HG 6.57 359 5600 MB Eindhoven (The Netherlands) 360 Email: koen@win.tue.nl