Abstract: | This specification provides an algorithm to consistently generate colors given a string. The string can be a nickname, a JID or any other piece of information. All clients generate the same color, which provides easier recognition of identifiers across clients and user interface elements. |
Author: | Jonas Wielicki |
Copyright: | © 1999 – 2017 XMPP Standards Foundation. SEE LEGAL NOTICES. |
Status: | ProtoXEP |
Type: | Standards Track |
Version: | 0.0.1 |
Last Updated: | 2017-05-04 |
WARNING: This document has not yet been accepted for consideration or approved in any official manner by the XMPP Standards Foundation, and this document is not yet an XMPP Extension Protocol (XEP). If this document is accepted as a XEP by the XMPP Council, it will be published at <http://xmpp.org/extensions/> and announced on the <standards@xmpp.org> mailing list.
1. Introduction
2. Requirements
3. Algorithms
3.1. Angle generation
3.2. Corrections for Color Vision Deficiencies
3.2.1. Red/Green-blindness
3.2.2. Blue-blindness
3.3. CbCr generation
3.4. CbCr to RGB
3.5. Adapting the Color for specific Background Colors
4. Use Cases
4.1. Adding colors to participants of a conversation
4.2. Auto-Generating Avatars
5. Business Rules
6. Implementation Notes
6.1. Gamma Correction
7. Accessibility Considerations
8. Security Considerations
9. Design Considerations
9.1. Other variants of the YCbCr color space
9.2. Hue-Saturation-Value/Lightness color space
10. IANA Considerations
11. XMPP Registrar Considerations
Appendices
A: Document Information
B: Author Information
C: Legal Notices
D: Relation to XMPP
E: Discussion Venue
F: Requirements Conformance
G: Notes
H: Revision History
Colors provide a valuable visual cue to recognize text. Recognition of colors works much faster than recognition of text. Together with the length and overall shape of a piece of text (such as a nickname), a color provides a decent amount of entropy to distinguish a reasonable amount of entities.
The color generation mechanism should provide the following features:
Input: An identifier, encoded as octets of UTF-8 (RFC 3269 [1]).
Output: Angle in the CbCr plane.
Note: The goal of this algorithm is to convert arbitrary text into a scalar value which can then be used to calculate a color. As it happens, the CbCr plane of the YCbCr space determines the color (while Y merely defines the lightness); thus, an angle in the CbCr plane serves as a good scalar value to select a color.
Input: Angle in the CbCr plane.
Output: Angle in the CbCr plane.
Note: This algorithm will re-map the angle to map it away from ranges which can not be distinguished by people with the respective Color Vision Deficiencies.
Divide the angle by two.
Divide the angle by two and add π/2 (half Pi).
Input: Angle in the CbCr plane, from the previous algorithm.
Output: Values for Cb and Cr in the YCbCr BT.601 color space in the range from -0.5 to 0.5.
Form a vector from the angle and project it to edges of a quad in 2D space with edge length 1 around (0, 0). The resulting coordinates are Cb and Cr:
float cr = sin(angle); float cb = cos(angle); float factor; if (abs(cr) > abs(cb)) { factor = 0.5 / abs(cr); } else { factor = 0.5 / abs(cb); } cb = cb * factor; cr = cr * factor;
Input: Values for Cb and Cr in the YCbCr BT.601 color space in the range from -0.5 to 0.5; Value for Y.
Output: Values for Red (R), Green (G) and Blue (B) in the RGB color space in the range from 0 to 1.
Note: The recommended value for Y is 0.732. See Gamma Correction for a discussion on the choice of Y.
float r = 2*(1 - KR)*cr + y; float b = 2*(1 - KB)*cb + y; float g = (y - KR*r - KB*b)/KG;
Input: RGB values for the color to adapt (Ri, Gi, Bi) and for the background color to adapt to (Rb, Gb, Bb), in the range from 0 to 1 each.
Output: Values for Red (Rc), Green (Gc) and Blue (Bc) in the RGB color space in the range from 0 to 1.
rb = 1-rb; gb = 1-gb; bb = 1-bb;
rc = 0.2*rb + 0.8*ri; gc = 0.2*gb + 0.8*gi; bc = 0.2*bb + 0.8*bi;
Implementations may colorize the participants of a conversation with an individual color to make them easier to distinguish.
In such cases, the color SHOULD be generated as described in the Algorithms section. The input used SHOULD be, in descending order of preference, (a) the name assigned in the roster, (b) the nickname from the conversation, (c) the bare JID.
Implementations may want to show a picture in connection with a contact even if the contact does not have an avatar defined (e.g. via User Avatar (XEP-0084) [2]).
In such cases, auto-generating an avatar SHOULD happen as follows:
An implementation may choose a different value for Y depending on whether the sink for the R, G and B values expects Gamma Encoded or Gamma Decoded values. The recommended default of 0.732 is 0.5 to the power of 0.45, that is, a Gamma Encoded 0.5.
Modifications to Y SHOULD NOT be used to correct for bright/dark backgrounds. Implementations should instead use the algorithm described in Adapting the Color for specific Background Colors for that.
As outlined above, implementations MUST offer the Red/Green-Blindness and Blue-Blindness corrections as defined in the Corrections for Color Vision Deficiencies section. Users MUST be allowed to choose between:
The last option is important for users with monochromatic view.
This specification extracts a bit more information from an entity and shows it alongside the existing information to the user. As the algorithm is likely to produce different colors for look-alikes (see Best Practices to Prevent JID Mimicking (XEP-0165) [3] for examples) in JIDs, it may add additional protection against attacks based on those.
In the worst case, this specification does not worsen security.
The following alternatives to the YCbCr BT.601 colorspace were considered and eventually rejected:
The other common YCbCr variants, BT.709 and BT.2020, do not achieve a brightness across the color space as uniform as BT.601 does. Adapting the Y value for uniform luminosity across the range for CbCr would have complicated the algorithm with little or no gain.
The HSV and HSL color spaces fail to provide uniform luminosity with fixed value/lightness and saturation parameters. Adapting those parameters for uniform luminosity across the hue range would have complicated the algorithm with litte to no gain.
This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [4].
This document requires no interaction with the XMPP Registrar [5].
Series: XEP
Number: xxxx
Publisher: XMPP Standards Foundation
Status:
ProtoXEP
Type:
Standards Track
Version: 0.0.1
Last Updated: 2017-05-04
Approving Body: XMPP Council
Dependencies: None
Supersedes: None
Superseded By: None
Short Name: colors
This document in other formats:
XML
PDF
Email:
jonas@wielicki.name
JabberID:
jonas@wielicki.name
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.
The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.
Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.
Errata can be sent to <editor@xmpp.org>.
The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".
1. RFC 3269: UTF-8, a transformation format of ISO 10646 <http://tools.ietf.org/html/rfc3269>.
2. XEP-0084: User Avatar <https://xmpp.org/extensions/xep-0084.html>.
3. XEP-0165: Best Practices to Prevent JID Mimicking <https://xmpp.org/extensions/xep-0165.html>.
4. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.
5. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <https://xmpp.org/registrar/>.
Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/
First draft.
(jwi)END