[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04

Network Working Group                                          U. Koenig
Internet-Draft                                           J. Schallaboeck
Intended status: Experimental                Unabhaengiges Landeszentrum
Expires: July 9, 2011                                  fuer Datenschutz
                                                      Schleswig-Holstein
                                                         January 5, 2011


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

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 Privicosns 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 July 9, 2011.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the



Koenig & Schallaboeck     Expires July 9, 2011                  [Page 1]

Internet-Draft                  Privicons                   January 2011


   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.








































Koenig & Schallaboeck     Expires July 9, 2011                  [Page 2]

Internet-Draft                  Privicons                   January 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Relations to other standards . . . . . . . . . . . . . . .  4
     1.3.  Terminology and Conventions  . . . . . . . . . . . . . . .  5
   2.  Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Definitions  . . . . . . . . . . . . . . . . . . . . . . .  6
     2.2.  First-Line(s) of Message body  . . . . . . . . . . . . . .  6
     2.3.  Subject Line . . . . . . . . . . . . . . . . . . . . . . .  7
     2.4.  Header . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     2.5.  Footer . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     2.6.  Authoritative or Parsing order - Conflicts . . . . . . . .  9
     2.7.  Syntax error . . . . . . . . . . . . . . . . . . . . . . .  9
     2.8.  HTML-Messages  . . . . . . . . . . . . . . . . . . . . . .  9
   3.  Semantics  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     3.1.  Privicons  . . . . . . . . . . . . . . . . . . . . . . . .  9
       3.1.1.  [X] Keep secret  . . . . . . . . . . . . . . . . . . . 10
       3.1.2.  [/] Don't print  . . . . . . . . . . . . . . . . . . . 10
       3.1.3.  [=] Delete after reading, I days or on date  . . . . . 10
       3.1.4.  [-] No attribution . . . . . . . . . . . . . . . . . . 10
       3.1.5.  [o] Keep internal  . . . . . . . . . . . . . . . . . . 10
       3.1.6.  [>] Please share . . . . . . . . . . . . . . . . . . . 11
     3.2.  Multiple Privicons . . . . . . . . . . . . . . . . . . . . 11
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   7.  Normative References . . . . . . . . . . . . . . . . . . . . . 12
   Appendix A.  Example e-mail message  . . . . . . . . . . . . . . . 13
   Appendix B.  Informative example requirements for e-mail
                message user agents . . . . . . . . . . . . . . . . . 13
     B.1.  User agent behaviour . . . . . . . . . . . . . . . . . . . 13
       B.1.1.  Terms  . . . . . . . . . . . . . . . . . . . . . . . . 14
       B.1.2.  [X] Keep secret  . . . . . . . . . . . . . . . . . . . 14
       B.1.3.  [/] Don't print  . . . . . . . . . . . . . . . . . . . 14
       B.1.4.  [=] Delete after reading, I days or on date  . . . . . 14
       B.1.5.  [-] No attribution . . . . . . . . . . . . . . . . . . 15
       B.1.6.  [o] Keep internal  . . . . . . . . . . . . . . . . . . 16
       B.1.7.  [>] Please share . . . . . . . . . . . . . . . . . . . 16
     B.2.  Confirmation/Affirmation of preferences  . . . . . . . . . 16
     B.3.  Transparency (OPTIONAL)  . . . . . . . . . . . . . . . . . 16
   Appendix C.  Graphical Representation of the State Machine . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17








Koenig & Schallaboeck     Expires July 9, 2011                  [Page 3]

Internet-Draft                  Privicons                   January 2011


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 (Section 2) and semantics (Section 3)
   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 (Appendix B)).

   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.






Koenig & Schallaboeck     Expires July 9, 2011                  [Page 4]

Internet-Draft                  Privicons                   January 2011


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].

   o  The term "User Agent" (often also Mail User Agent, UA, MUA) is
      used as defined in Section-2.3.3 in [RFC5321]

   o  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.

   o  The term "Line" is used as defined by SMTP Section-2.3.8 in
      [RFC5322] thereof

   o  The term "full-date" is used as defined by Section-5.6 in
      [RFC3339].

   o  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 (Section 3), please see next section.  A User
   can indicate a Privacy Preference as lined out below in the following
   ways:

   o  by making available selection of the Privicons, which SHOULD be
      provided by the user agent,

   o  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

   o  MUST contain a header (Section 2.4) with Privacy Preferences,

   o  SHOULD contain subject (Section 2.3) with Privicon,

   o  SHOULD have first-line (Section 2.2) and footer (Section 2.5)




Koenig & Schallaboeck     Expires July 9, 2011                  [Page 5]

Internet-Draft                  Privicons                   January 2011


   o  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 Overview (Section 1.1)

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 (Section 3).

   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.



Koenig & Schallaboeck     Expires July 9, 2011                  [Page 6]

Internet-Draft                  Privicons                   January 2011


   firstLine  = privicon whitespace "-" whitespace description

   For example:

      [X] - Keep secret

      [/] - 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 (Section 3.2) 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







Koenig & Schallaboeck     Expires July 9, 2011                  [Page 7]

Internet-Draft                  Privicons                   January 2011


      [=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 (Section 2.1)

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:







Koenig & Schallaboeck     Expires July 9, 2011                  [Page 8]

Internet-Draft                  Privicons                   January 2011


      --

      [X] - Keep secret

      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 (Section 2.2)

   2.  subject (Section 2.3)

   3.  header (Section 2.4)

   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

   Note for Editor: This section is just a placeholder


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.





Koenig & Schallaboeck     Expires July 9, 2011                  [Page 9]

Internet-Draft                  Privicons                   January 2011


3.1.1.  [X] Keep secret

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

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:

   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 Terminology and Conventions
   (Section 1.3).

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



Koenig & Schallaboeck     Expires July 9, 2011                 [Page 10]

Internet-Draft                  Privicons                   January 2011


   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:

                +-----+-----+-----+-----+-----+-----+-----+
                |     | [X] | [/] | [=] | [-] | [o] | [>] |
                +-----+-----+-----+-----+-----+-----+-----+
                | [X] |  X  |  Y  |  Y  |  ?  |  ?  |  N  |
                | [/] |  Y  |  X  |  Y  |  Y  |  Y  |  Y  |
                | [=] |  Y  |  Y  |  X  |  ?  |  ?  |  N  |
                | [-] |  ?  |  Y  |  N  |  X  |  Y  |  Y  |
                | [o] |  ?  |  N  |  N  |  Y  |  X  |  N  |
                | [>] |  N  |  Y  |  N  |  Y  |  N  |  X  |
                +-----+-----+-----+-----+-----+-----+-----+

             Table 1: Matrix of all combinations of Privicons.


4.  IANA Considerations

   This document introduces a new field in the e-mail header, as
   described in the header (Section 2.4) 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.



Koenig & Schallaboeck     Expires July 9, 2011                 [Page 11]

Internet-Draft                  Privicons                   January 2011


6.  Acknowledgements

   In alphabetical order:

      Andreas M. Braendhaugen, Designer, San Francisco

      Laurent Bussard, European Microsoft Innovation Center

      Ryan Calo, Stanford University

      Alissa Cooper, Oxford Internet Institute

      Ethan Forrest, Stanford University

      Marit Hansen, Unabhaengiges Landeszentrum fuer Datenschutz
      Schleswig-Holstein

      Ulrich Pinsdorf, European Microsoft Innovation Center

      Thomas Roessler, W3C

      Max Senges, Google Inc.

      Hannes Tschofenig, Nokia Siemens Networks


7.  Normative References

   [RFC1855]  Hambridge, S., "Netiquette Guidelines", RFC 1855,
              October 1995.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3339]  Klyne, G., Ed. and C. Newman, "Date and Time on the
              Internet: Timestamps", RFC 3339, July 2002.

   [RFC3461]  Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
              Extension for Delivery Status Notifications (DSNs)",
              RFC 3461, January 2003.

   [RFC3676]  Gellens, R., "The Text/Plain Format and DelSp Parameters",
              RFC 3676, February 2004.

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              October 2008.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,



Koenig & Schallaboeck     Expires July 9, 2011                 [Page 12]

Internet-Draft                  Privicons                   January 2011


              October 2008.


Appendix A.  Example e-mail message

   This is an example Privicon e-mail message (Figure 1).

     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.

          Figure 1: Example of an e-mail message using a Privicon


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

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



Koenig & Schallaboeck     Expires July 9, 2011                 [Page 13]

Internet-Draft                  Privicons                   January 2011


   the Privicon in Subject and Body of the e-mail message.  The user
   agent MAY localise the explaining text.

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.

B.1.2.  [X] Keep secret

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

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 (Appendix B.3) applies.

B.1.3.  [/] Don't print

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.

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

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.



Koenig & Schallaboeck     Expires July 9, 2011                 [Page 14]

Internet-Draft                  Privicons                   January 2011


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

B.1.4.1.1.  Option a) delete after reading

   The above confirmation MUST ask the user, whether

   o  ignore, do not decide now, ask me again next time,

   o  delete or move into a "to be deleted" folder, as indicated in the
      preferences or

   o  ask again after a specified period.

B.1.4.1.2.  Option b) delete after X days

   The above confirmation MUST ask the user, whether

   o  ignore, do not decide now, ask me again next time,

   o  delete now,

   o  delete after X days automatically or

   o  ask me in X days.

B.1.4.1.3.  Option c) delete on date

   The above confirmation MUST ask the user, whether

   o  ignore, do not decide now, ask me again next time,

   o  delete now,

   o  delete on date automatically or

   o  ask me on date.

B.1.5.  [-] No attribution

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.



Koenig & Schallaboeck     Expires July 9, 2011                 [Page 15]

Internet-Draft                  Privicons                   January 2011


   OPTIONAL: Transparency (Appendix B.3) applies.

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 (Appendix B.3) applies.

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.

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].

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 (Figure 2).




Koenig & Schallaboeck     Expires July 9, 2011                 [Page 16]

Internet-Draft                  Privicons                   January 2011


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

           Figure 2: Graphical representation of the Privicons.


Authors' Addresses

   Ulrich Koenig
   Unabhaengiges Landeszentrum fuer Datenschutz Schleswig-Holstein
   Holstenstr. 98
   Kiel, Schleswig-Holstein  24103
   Germany

   Phone: +49-431-988-1220
   Fax:   +49-431-988-1223
   Email: rfc@ulikoenig.com
   URI:   https://www.datenschutzzentrum.de


   Jan Schallaboeck
   Unabhaengiges Landeszentrum fuer Datenschutz Schleswig-Holstein
   Holstenstr. 98
   Kiel, Schleswig-Holstein  24103
   Germany

   Phone: +49-431-988-1220
   Fax:   +49-431-988-1223
   Email: uld62@datenschutzzentrum.de
   URI:   https://www.datenschutzzentrum.de




















Koenig & Schallaboeck     Expires July 9, 2011                 [Page 17]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/