Privacy Preferences for E-Mail Messages
draft-koenig-privicons-02

Abstract

This document proposes a syntax and semantics as an extension of the Internet Message Format (e-mail message) allowing a Sending User of an e-mail message to express his or her preference for how the message content is to be handled by the Receiving Users. For this purpose, semantics of sets of different character combinations ("Privicons") are described. These can syntactically be integrated either in the first-line of the body, in the subject line and/or in a dedicated header of any e-mail message. The Privicons icon set consists of six different icons. They'll be machine readable. The Privicons concept is partly borrowing its approach from the concept of emoticons. For example, to express that the content may be forwarded and even be published. The Sending User could use the Privicon "[>]", which may be followed by an additional explanations, such as "please share".

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on December 05, 2011.

Copyright Notice

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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.

Table of Contents

• 1. Introduction
• 1.1. Overview
• 1.2. Relations to other standards
• 1.3. Terminology and Conventions
• 2. Syntax
• 2.1. Definitions
• 2.2. First-Line(s) of Message body
• 2.3. Subject Line
• 2.4. Header
• 2.5. Footer
• 2.6. Authoritative or Parsing order - Conflicts
• 2.7. Syntax error
• 2.8. HTML-Messages
• 3. Semantics
• 3.1. Privicons
• 3.1.1. [X] Keep private
• 3.1.2. [/] Don't print
• 3.1.3. [=] Delete after reading, I days or on date
• 3.1.4. [-] No attribution
• 3.1.5. [o] Keep internal
• 3.1.6. [>] Please share
• 3.2. Multiple Privicons
• 4. IANA Considerations
• 5. Security Considerations
• 6. Acknowledgements
• 7. References
• Appendix A. Example e-mail message
• Appendix B. Informative example requirements for e-mail message user agents
• Appendix B.1. User agent behaviour
• Appendix B.1.1. Terms
• Appendix B.1.2. [X] Keep secret
• Appendix B.1.2.1. EVENT: Forward/Reply to third Person
• Appendix B.1.3. [/] Don't print
• Appendix B.1.3.1. EVENT: Printing e-mail message
• Appendix B.1.4. [=] Delete after reading, I days or on date
• Appendix B.1.4.1. EVENT: Closing Mail
• Appendix B.1.4.1.1. Option a) delete after reading
• Appendix B.1.4.1.2. Option b) delete after X days
• Appendix B.1.4.1.3. Option c) delete on date
• Appendix B.1.5. [-] No attribution
• Appendix B.1.5.1. EVENT: reply, forward, store
• Appendix B.1.6. [o] Keep internal
• Appendix B.1.7. [>] Please share
• Appendix B.2. Confirmation/Affirmation of preferences
• Appendix B.3. Transparency (OPTIONAL)
• Appendix C. Graphical Representation of the State Machine
• Authors' Addresses

1. Introduction

1.1. Overview

Privicons describe a vocabulary of icons as an extension of the Internet Message Format (e-mail message) for users to indicate how their e-mail message should be treated. The icons are based on ASCII symbols so that they can appear as embedded graphics or plain text and include a variety of instructions such as "don't print," "internal use only," and "confidential". It is partly borrowing its approach from the concept of emoticons. For example to express, that the content can be forwarded and even be published, the Sending User could use the Privicon "[>]", which may be followed by an additional explanations, such as "please share".

This document proposes a syntax [syntax] and semantics [semantics] allowing a Sending User of an e-mail message to express his or her preference for how the e-mail message content should be handled by the Receiving Users. For this purpose, semantics of sets of different character combinations ("Privicons") are described. These can syntactically be integrated either in the first-line of the body, in the subject line and/or in a dedicated header of any e-mail message. The Privicons icon set has six different icons. They will be machine readable.

Importantly, the user can override all requests transmitted by Privicons: The approach is grounded in reminder over hard-coded solutions that indiscriminately restrict speech. Therefore, the icons are merely asking the Receiving User of an e-mail to follow the Sending User's preference. Other than DRM oriented approaches, Privicons embraces the concept of code-based norms approach. This means, that the approach relies on social norms to be followed by the Receiving User, rather than technical enforcement mechanisms. However, technical means may be used to support this (for example, specifications see example e-mail message [implementation]).

Note: The specific character combinations for each Privicon is currently undergoing user testing, it therefore might and will most certainly change during the progression of this draft.

1.2. Relations to other standards

This specification extends [RFC5322] - Internet Message Format by defining certain syntax for the first-line(s) of the body, the subject line and an additional header field.

1.3. Terminology and Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

• The term "User Agent" (often also Mail User Agent, UA, MUA) is used as defined in Section-2.3.3 in [RFC5321]
• The terms "Sending User" and "Receiving User" are related to a user using the User Agent either sending or receiving an e-mail message. A Sending User is a user that sends an e-mail message to a Receiving User. A Receiving User is a user that receives an e-mail message from a Sending User.
• The term "Line" is used as defined by SMTP Section-2.3.8 in [RFC5322] thereof
• The term "full-date" is used as defined by Section-5.6 in [RFC3339].
• The term Privacy Preference describes the intention the user had when she has sent a specific e-mail message. It can be expressed with the Privicons described in this RFC.

2. Syntax

In this section, the syntax if the Privicon e-mail extension is defined. For semantics [semantics], please see next section. A User can indicate a Privacy Preference as lined out below in the following ways:

• by making available selection of the Privicons, which SHOULD be provided by the user agent,
• by inserting a Privicon in the subject line - by inserting a Privicon in the first-line of the body.

A e-mail message fully compliant with this RFC will be called a Privicon Message, it

Overview [Overview]

• MUST contain a header [header] with Privacy Preferences,
• SHOULD contain subject [subject] with Privicon,
• SHOULD have first-line [first-line] and footer [footer]
• and MAY generate an HTML version.

The following section describes how the Privicon status of an e-mail message is determined, concerning the privacy preferences described in

2.1. Definitions

element1 | element2

Elements separated by a bar ("|") are alternatives, e.g., "yes | no" will accept yes or no.

"literal"

Quotation marks surround literal text. Unless stated otherwise, the text is case-insensitive.

whitespace

" "

whatever

Some arbitrary text.

date

Will be substituted by a "full-date", [RFC3339].

privicon

= ("[X]"|"[/]"|"[=]"|"[=0]"|"[=I]"|"[=date]"|"[-]"|"[o]"|"[>]") - the Privicon token. It contains all valid Privicons, the Privicon icon set.

I

I will be substituted by an integer number >= 0.

description

Contains the description of the Privicon as defined in Semantics [semantics].

subject

Is the e-mail message subject field, see [RFC5322].

CRLF

Is the carriage return/line feed pair written in this document as "CRLF". A line is a series of characters that is delimited with the two characters carriage-return and line-feed; that is, the carriage return (CR) character (ASCII value 13) followed immediately by the line feed (LF) character (ASCII value 10), as described in section2.1 in [RFC5322]

2.2. First-Line(s) of Message body

An indication of the Privacy Preference can be given in the first line of the body of an e-mail message.

The expression MUST be followed by a text giving a short explanation the meaning of the expressions. It is RECOMMENDED to use the following text, although localization into other languages is also encouraged, albeit not lined out in this document.

firstLine

= privicon whitespace "-" whitespace description

For example:

[X] - Keep private

[/] - Don't print

[=] - Delete after reading

[=0] - Delete after reading

[=I] - Delete after I days

[=date] - Delete on date

[-] - No attribution

[o] - Keep internal

[>] - Please share

After the first-line, a second line, with an additional privacy preference may follow if the combination [combination] is permitted.

2.3. Subject Line

An indication of the Privacy Preference can be given in the beginning of a subject line of an e-mail message using the following expression:

privicon whitespace subject

or

whatever whitespace privicon whitespace subject

For example:

[X] This is the subject of the e-mail message

[/] This is the subject of the e-mail message

[=] This is the subject of the e-mail message

[=4] This is the subject of the e-mail message

[=1980-01-01] This is the subject of the e-mail message

[-] This is the subject of the e-mail message

[o] This is the subject of the e-mail message

[>] This is the subject of the e-mail message

or

Re: [X] This is the subject of the e-mail message

Fwd: [/] This is the subject of the e-mail message

2.4. Header

An indication of the Privacy Preference MAY be given in the header of an e-mail message, for this purpose the following field is defined, extending in section 3.6 in [RFC5322] the field definition, thereof.

priviconfield

= "Privicon:" whitespace privicon CRLF

The possible values of the Privicon token are described in Definitions [Definitions]

2.5. Footer

Separated by --

The Footer MAY be located within the signature as described in section 4.3 in [RFC3676] . It contains a paragraph that describes what the Sending User of the e-mail message intended when she chooses the selected Privicon.

A clarification MAY be added that a conflict between header and first-line would lead to the first-line to be authoritative.

footer

= CRLF "-- " CRLF footertext

footertext

= firstline CRLF description

For example:

--

[X] - Keep private

The "Keep secret" Privicon asks the Receiving User to keep the received e-mail message secret.

Note: Footnote may violates [RFC1855] Page4 - do not use more than 4 lines signature.

The Footnote is just informative not authoritative

2.6. Authoritative or Parsing order - Conflicts

When parsed, the authoritative order of the different elements is as follows:

1. first-line in body [first-line]
2. subject [subject]
3. header [header]

If only one Privicon is found, it has always the same meaning, no matter if it is defined in first-line in body, subject or header.

2.7. Syntax error

After syntax error, the most restrictive case is assumed.

For example "Delete after ??? days" will be transformed into "Delete immediately")

2.8. HTML-Messages

In HTML-Messages the “Privicon” are OPTIONAL represented with graphical icons. Example icons can be found in Annex. Embedded icons MUST be included into the Message and MUST NOT be loaded from an Internet Server. This is important avoid a loss of privacy for the receiving user. It also causes in some cases problems with SSL-Encryption in web based e-mail message user agents (MUA).

The graphical representation MUST contain the ASCII-Icon as Alternate-Text.

If the "Privicon" is included in the First Line of Body, the “description” MUST also be displayed in next to the Privicon.

3. Semantics

3.1. Privicons

The Privicons icon set has six different icons. The meaning of the icons will be described in this section. It is important, that Privicons always just meant to be a nice way of asking somebody to do something.

3.1.1. [X] Keep private

The "Keep private" Privicon asks the Receiving User to keep the received e-mail message private.

3.1.2. [/] Don't print

The "Don't print" Privicon asks the Receiving User to not print the received e-mail message.

3.1.3. [=] Delete after reading, I days or on date

The "Delete after reading/I days" Privicon asks the Receiving User to delete the e-mail message no later than a specified period. There are four different cases: Terminology and Conventions [terms].

1. [=] delete after reading
2. [=0] delete after reading
3. [=I] delete after I days
4. [=date] delete on date

"I" and "date" are defined in

3.1.4. [-] No attribution

The "No attribution" Privicon asks the Receiving User to not attribute, name or mention the original Sending User of the e-mail message in any kind. At the same time the Receiving User may quote, follow or paraphrase the content, facts and opinions voiced in the original e-mail message. In other words, the Receiving User is free to use the information received, but neither the identity nor the affiliation of the Sending User may be revealed.

3.1.5. [o] Keep internal

The "Keep internal" Privicon asks the Receiving User to present this e-mail message only to those people that are common friends, or otherwise part of a group of people are in a relation to both the Sending User and the Receiving User. Note that the judgement, whether a person belongs to this group is solely upon the Receiving User unless otherwise indicated by the Sending User. The "Keep internal" just indicates, that a Receiving User SHOULD give some further thought on which she is sending the e-mail message to, and that the Sending User does not want the e-mail message to be forwarded arbitrarily.

3.1.6. [>] Please share

The "Please share" Privicon asks the Receiving User to share this e-mail message with everyone, as she likes. It may be supplemented by further instructions on licensing for clarifying the copyright status.

3.2. Multiple Privicons

Possible:

Y

Impossible:

N

Subject to discussion:

?

Does not apply:

X

As secondary option, potentially, and if first preference is overruled:

4. IANA Considerations

This document introduces a new field in the e-mail header, as described in the header [header] section.

5. Security Considerations

The extensions to the e-mail message Format described in this document does not change the fundamental nature of the SMTP service and hence does not create any new security exposures in and of itself.

6. Acknowledgements

In alphabetical order:

• Andreas M. Brændhaugen, Designer, San Francisco
• Laurent Bussard, European Microsoft Innovation Center
• Ryan Calo, Stanford University
• Alissa Cooper, Oxford Internet Institute
• Ethan Forrest, Stanford University
• Marit Hansen, Unabhängiges Landeszentrum für Datenschutz Schleswig-Holstein
• Alexey Melnikov, Isode
• Ulrich Pinsdorf, European Microsoft Innovation Center
• Thomas Rössler, W3C
• Max Senges, Google Inc.
• Hannes Tschofenig, Nokia Siemens Networks

7. References

Appendix A. Example e-mail message

This is an example Privicon e-mail message [example].

Message-ID: <4C3203D3.60109@ulikoenig.com>
Date: Mon, 05 Jul 2010 23:59:00 +0200
From: Ulrich Koenig <rfc@ulikoenig.com>
To: Jan Schallaboeck <uld62@datenschutzzentrum.de>
Subject: [>] last update for Privicons RFC
Privicon: [>]
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable
[>] Please share

Hey Jan,

please check the IETF Website for our Privicons RFC! ;)

best Ulrich

--=20
[>] Please share
The "Please share" Privicon asks the Receiving User to share this
e-mail message with everyone she likes.

Appendix B. Informative example requirements for e-mail message user agents

Appendix B.1. User agent behaviour

This section gives developers of e-mail message user agents (MUA) or plug-ins for MUAs instructions how to integrate the Privicons in the client.

An MUA implementing this RFC MUST enable the user at any time to overrule the received Privicon. The user SHOULD also be able to set a default for always overruling in her client. The rest of the instructions in this section are OPTIONAL.

If the user agent displays an e-mail message that contains one or more Privicons it SHOULD display the icon and its meaning in a salient way. If the icon is displayed by the user agent it MAY hide the Privicon in Subject and Body of the e-mail message. The user agent MAY localise the explaining text.

Appendix B.1.1. Terms

confirm

A confirm pop-up or any other visible notion that yields active interaction by the user (i.e. clicking a button). The user SHOULD be able to disable a part or all confirmations.

inform

A pop-up, or any other visible notion, that SHOULD yield confirmation. Such notification SHOULD be enabled by default. The user SHOULD be able to disable the notification by default.

Appendix B.1.2. [X] Keep secret

The "Keep private" Privicon asks the Receiving User to keep the received e-mail message secret.

Appendix B.1.2.1. EVENT: Forward/Reply to third Person

If the Receiving User wants to forward or reply-to the e-mail message to a third person, that is not the original Sending User, than the Receiving User MUST be informed, that she is going to violate the included Privicon and she MUST confirm that she is willing to do this before the e-mail message is sent.

OPTIONAL: Transparency [Transparency] applies.

Appendix B.1.3. [/] Don't print

Appendix B.1.3.1. EVENT: Printing e-mail message

If the Receiving User wants to print the e-mail message, she MUST be informed that she is going to violate the included Privicon and she MUST confirm that she is willing to do this before printing is started.

Appendix B.1.4. [=] Delete after reading, I days or on date

Appendix B.1.4.1. EVENT: Closing Mail

If the Receiving User closes the e-mail message, she MUST be informed, that the e-mail message SHOULD be deleted after X days.

The user MUST confirm whenever she closes the e-mail message, hat the e-mail message is deleted immediately.

The client SHOULD enable the user to choose a default option.

Note: if e-mail messages are displayed in list mode, then the confirmation will be raised, when opening the next e-mail message.

Appendix B.1.4.1.1. Option a) delete after reading

The above confirmation MUST ask the user, whether

• ignore, do not decide now, ask me again next time,
• delete or move into a "to be deleted" folder, as indicated in the preferences or
• ask again after a specified period.

Appendix B.1.4.1.2. Option b) delete after X days

The above confirmation MUST ask the user, whether

• ignore, do not decide now, ask me again next time,
• delete now,
• delete after X days automatically or
• ask me in X days.

Appendix B.1.4.1.3. Option c) delete on date

The above confirmation MUST ask the user, whether

• ignore, do not decide now, ask me again next time,
• delete now,
• delete on date automatically or
• ask me on date.

Appendix B.1.5. [-] No attribution

Appendix B.1.5.1. EVENT: reply, forward, store

If the Receiving User wants to forward or reply to a third person or store the e-mail message, she MUST be informed, that the Sending User doesn't want to be mentioned and MUST confirm that she is willing to overrule the Sending Users wish or remove any occurrence of the Sending User in the e-mail message (Header and Body). The removal of the Sending User MAY be done by the user agent automatically.

OPTIONAL: Transparency [Transparency] applies.

Appendix B.1.6. [o] Keep internal

If the Receiving User has defined what "internal" means to her, the following rules in the "Keep internal" subsection only apply if at least one of the Receiving Users are not part of her internal definition.

If the Receiving User wants to forward or reply the e-mail message to a third person, the user MUST be informed that she SHOULD check if the third person is really part of the group that the Sending User intended to be internal and MUST confirm that she really to send this e-mail message.

OPTIONAL: Transparency [Transparency] applies.

Appendix B.1.7. [>] Please share

The client SHOULD notice the user, that the content of the e-mail message can be published. If the Sending User has transmitted a license for publishing the content, it SHOULD also be displayed.

Appendix B.2. Confirmation/Affirmation of preferences

Note this may be for further versions, but might yield legal implications: Before opening the e-mail message containing a Privicon, the User Agent SHOULD inform the user what the user is asked to do with the option to reject the e-mail message. To reject an e-mail message means the Sending User is notified, that the e-mail message is rejected and has been deleted at User Agent's side before reading. Not to reject the e-mail message does not mean, that the receiving user accepts the requested conditions, see [RFC3461].

Appendix B.3. Transparency (OPTIONAL)

If a Receiving User forwards or replies an e-mail message containing a Privicon to a third person, the original Sending User OPTIONAL get a copy via carbon copy or a blind carbon copy by default. The Receiving User MUST be able overrule this. She also SHOULD be able to disable the default sending of a copy in the user preferences.

Appendix C. Graphical Representation of the State Machine

There is a graphical representation of the Privicons, that MAY be used by MUAs, see Figure [graph].

In the PS/PDF version of this specification, the 
graphical representation of the Privicons can be
found here.

Authors' Addresses