RFC 2534

Media Features for Display, Print, and Fax

📅 published March 1999, from ietf

RFC 2534: Media Features for Display, Print, and Fax 🎀

Okay bestie, this one is the Media Features spec, and it's giving "tell the server what your screen can do so it sends the right version." 💖 Here's the header info: it was written by L. Masinter (Xerox Corporation), D. Wing (Cisco Systems, Inc.), A. Mutz (Jutvision Corporation), and K. Holtman (TUE), for the Network Working Group. It's on the Standards Track and dates from March 1999. The header doesn't list any RFCs it obsoletes or updates, so it's standing on its own. 🌸

Status of this Memo ✨

This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited. 🦋

Copyright (C) The Internet Society (1999). All Rights Reserved.

Abstract 🧚

This spec defines some common media features for describing image resolution, size, color, and image representation methods. These are the features that web browsing, printing, and fax apps all have in common. They're registered for use within the framework of [REG]. 💅

1. Introduction 🌈

This whole thing started because web browsers needed a way to send their display characteristics to a web server, so the server could pick the right representation. 🖥️

This spec defines some common media features [REG] that let a recipient tell a sender what its message handling is capable of. The sender can then send the variant of the message that fits the recipient best. 💌

The variants are usually higher or lower resolution images, for example. If you're sending to a printer, you get higher quality output. If you're sending to a small screen device (like a cellphone or a portable digital assistant), you get faster transmission. ⚡

Media features can show up in lots of different protocol situations. The ones defined here can describe a display or printer's dimensions, resolution, and color capability. You can infer the physical dimensions of a display from its display size and display resolution. For paper output, the paper size can be written as a token from a list of standard paper sizes. All of this is laid out formally in the Notation section. 📐

2. Media Feature Registrations 💖

This section defines several media features, using the form specified in [REG]. 📝

2.1 Image Size 📏

  • Media Feature tag name(s):

pix-x pix-y

  • ASN.1 identifier associated with this feature tag:

1.3.6.1.8.1.1 1.3.6.1.8.1.2

  • Summary of the media features indicated by this feature tag:

These features tell you the recipient's display size for display or print, measured in pixels. pix-x is the horizontal dimension and pix-y is the vertical one. 🖼️

  • Values appropriate for use with this feature tag:

Signed Integer

  • The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms:

Display and print apps where the media choice depends on how big the recipient device is. For example, a web app running on a 240x480 display might serve different HTML pages than one meant for a 1024x768 display. 📱💻

2.2 Resolution 🔍

  • Media Feature tag name:

dpi

  • ASN.1 identifier associated with this feature tag:

1.3.6.1.8.1.3

  • Summary of the media features indicated by this feature tag:

This feature tells you the resolution the recipient can display or print without loss, measured in pixels per inch. Resolution is usually described as dots-per-inch rather than in SI units [SI]. Values for dpi can be written as a rational to accommodate resolution on SI-based devices. For example, dpi=19558/100 can represent a resolution of 77 dots per centimeter. 🤓

  • Values appropriate for use with this feature tag:

Rational

  • The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms:

Printing and fax apps usually pick the representation of a transmitted document based on the recipient's resolution rather than its pixel size. 🖨️

  • Examples of typical use:

Choosing which version of a printable document to send to a printer. 🖨️✨

  • Considerations particular to use in individual applications, protocols, services, or negotiation mechanisms:

Software apps are usually unaware of the display's resolution. Heads up that some devices have different resolutions in different directions, which means their individual pixels aren't square. This feature only covers uniform resolution though, so those devices aren't fully captured here. 👀

2.3 Registration of 'ua-media' 🎨

  • Media Feature tag name(s):

ua-media

  • ASN.1 identifier associated with this feature tag:

1.3.6.1.8.1.4

  • Summary of the media features indicated by this feature tag:

This feature tells you the recipient's device media, given as a simple token. 📄

  • Values appropriate for use with this feature tag:

Token with an equality relationship. Values include:

screen           A refreshable display
screen-paged     a refreshable display which cannot scroll
stationery       Separately cut sheets of an opaque material
transparency     Separately cut sheets of a transparent material
envelope         Envelopes that can be used for conventional
                 mailing purposes
envelope-plain   Envelopes that are not preprinted and have no
                 windows
continuous       Continuously connected sheets of an opaque
                 material
  • The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms:

Most of these values are useful for printing apps, or for telling printing apart from display. 🖨️🆚🖥️

  • Examples of typical use:

This is typically used to choose between a rendition meant to be printed and one meant to be displayed. 🎯

  • Considerations particular to use in individual applications, protocols, services, or negotiation mechanisms:

Other media values weren't included because their usefulness seemed relative. 🤷‍♀️

  • Interoperability considerations:

Interoperability with the Internet Print Protocol means some additional feature values may need to be registered later. 🔗

2.4 Paper Size 📄

  • Media Feature tag name(s):

paper-size

  • ASN.1 identifier associated with this feature tag:

1.3.6.1.8.1.5

  • Summary of the media features indicated by this feature tag:

For stationery, it's often useful to know the size of the display being used. Absolute resolution and pixel sizes are more precise and predictable, but some apps find it handy to also provide the paper size. Heads up that not all of the paper necessarily has a printable area. 📃

  • Values appropriate for use with this feature tag:

Token with an equality relationship. Typical values include:

letter        8.5x11.0 inches
a4            210x297 mm
b4            250x353 mm
a3            297x420 mm
legal         8.5x14 inches
  • The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms:

This feature tag seems most useful for printing apps. 🖨️💅

  • Examples of typical use:

Choosing between an a4 and a letter size rendition of the same printable document. 📑

2.5 Color and greyscale 🌷

  • Media Feature tag name(s):

color

  • ASN.1 identifier associated with this feature tag:

1.3.6.1.8.1.6

  • Summary of the media features indicated by this feature tag:

This feature gives you a big-picture level of capability to represent (or need for) handling color, picked from a limited set of choices. 🌈

  • Values appropriate for use with this feature tag:

Token with an equality relationship. Values include:

  • binary: black-and-white, or other bi-level capability. ⚫⚪
  • grey: more than two levels of intensity. For example, at least two bits of grey-scale data. 🩶
  • limited: availability of a small number of colors, like what a highlight printer, pen plotter, or limited color display might offer. This is useful for business graphics. At the lowest level, this means at least one color other than black (a "highlight color"). At the high end, it's a small number of colors (less than 32). No implication is made that any particular color is available. 📊
  • mapped: pixel color values are mapped in some specifiable way to a multi-component color space. There are enough levels of display to represent a continuous tone photographic image, but the result gets mapped into a more limited space. 📸
  • full: the ability (or at least the willingness) to represent a full color image and present it. Full continuous tone color capability. 🌟
  • The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms:

Web apps can choose between color, grey, or binary representations. Fax or printing apps might choose between color and non-color renditions, for example. 🌐🖨️

  • Examples of typical use:

Someone making a map of directions to a restaurant might make a different map for each kind of value. 🗺️🍓

  • Intended usage:

COMMON

Authors' Addresses ✨

Okay bestie, here are the four legends who wrote this one 🫶 Their contact info is right below, copied exactly:

Larry Masinter
Xerox Corporation
Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto CA 94304

Fax +1 650 812 4333
EMail: masinter@parc.xerox.com
Dan Wing
Cisco Systems, Inc.
101 Cooper Street
Santa Cruz, CA 95060  USA

Phone: +1 831 457 5200
Fax:   +1 831 457 5208
EMail: dwing@cisco.com
Andrew H. Mutz
Jutvision Corporation
124 University Avenue Suite 202
Palo Alto CA 94301

Phone: +1 650 325 6787
Fax:   +1 650 325 9337
Email: mutz@alum.mit.edu
Koen Holtman
Technische Universiteit Eindhoven
Postbus 513
Kamer HG 6.57
5600 MB Eindhoven (The Netherlands)

EMail: koen@win.tue.nl

Copyright (C) The Internet Society (1999). All Rights Reserved. 💖

Okay so the copyright vibe is super generous, ngl 🦋 You can copy this doc and hand it out to people, and you can make derivative works that comment on it or explain it or help people build with it. You can publish and distribute all of that, in whole or in part, with no restrictions of any kind. The one condition is that the copyright notice and this paragraph stay on every single copy and derivative work 🎀

Now, the doc itself is a different story. You're not allowed to modify it in any way, like deleting the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are pretty specific: you can do it when you're developing Internet standards, but then the copyright procedures in the Internet Standards process must be followed, or you can translate it into a language that isn't English 🌸

The permissions granted above are perpetual, which means the Internet Society and its successors or assigns will never take them back 👑

Last but not least, the info in this doc is handed over "AS IS", and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE is not making any promises here. They disclaim ALL WARRANTIES, express or implied, including any guarantee that using the info won't infringe anyone's rights, and any implied warranties of merchantability or fitness for a particular purpose. Not a vibe, but it's the truth 💀✨

📦 where this page comes from