idnits 2.17.1 draft-koenig-privicons-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 07, 2012) is 4313 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'X' is mentioned on line 594, but not defined == Missing Reference: '-' is mentioned on line 668, but not defined Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group U. Koenig 3 Internet-Draft J. Schallaboeck 4 Intended status: Experimental Unabhaengiges Landeszentrum 5 Expires: December 9, 2012 fuer Datenschutz 6 Schleswig-Holstein 7 June 07, 2012 9 Privacy Preferences for E-Mail Messages 10 draft-koenig-privicons-04 12 Abstract 14 This document proposes a syntax and semantics as an extension of the 15 Internet Message Format (e-mail message) allowing a Sending User of 16 an e-mail message to express his or her preference for how the 17 message content is to be handled by the Receiving Users. For this 18 purpose, semantics of sets of different character combinations 19 ("Privicons") are described. These can syntactically be integrated 20 either in the first-line of the body, in the subject line and/or in a 21 dedicated header of any e-mail message. The Privicons icon set 22 consists of six different icons. They will be machine-readable. The 23 Privicons concept is partly borrowing its approach from the concept 24 of emoticons. For example, to express that the content may be 25 forwarded and even be published. The Sending User could use the 26 Privicon "[>]", which may be followed by an additional explanations, 27 such as "please share". 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on December 9, 2012. 46 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.2. Relations to other standards . . . . . . . . . . . . . . . 4 66 1.3. Terminology and Conventions . . . . . . . . . . . . . . . 5 67 2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 69 2.2. First-Line(s) of Message body . . . . . . . . . . . . . . 6 70 2.3. Subject Line . . . . . . . . . . . . . . . . . . . . . . . 7 71 2.4. Header . . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 2.5. Footer . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 2.6. Authoritative or Parsing order - Conflicts . . . . . . . . 9 74 2.7. Syntax error . . . . . . . . . . . . . . . . . . . . . . . 9 75 2.8. HTML-Messages . . . . . . . . . . . . . . . . . . . . . . 9 76 3. Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 3.1. Privicons . . . . . . . . . . . . . . . . . . . . . . . . 10 78 3.1.1. [X] Keep private . . . . . . . . . . . . . . . . . . . 10 79 3.1.2. [/] Don't print . . . . . . . . . . . . . . . . . . . 10 80 3.1.3. [=] Delete after reading, I days or on date . . . . . 10 81 3.1.4. [-] No attribution . . . . . . . . . . . . . . . . . . 10 82 3.1.5. [o] Keep internal . . . . . . . . . . . . . . . . . . 11 83 3.1.6. [>] Please share . . . . . . . . . . . . . . . . . . . 11 84 3.2. Multiple Privicons . . . . . . . . . . . . . . . . . . . . 11 85 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 86 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 87 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 88 7. Normative References . . . . . . . . . . . . . . . . . . . . . 12 89 Appendix A. Example e-mail message . . . . . . . . . . . . . . . 13 90 Appendix B. Informative example requirements for e-mail 91 message user agents . . . . . . . . . . . . . . . . . 14 92 B.1. User agent behaviour . . . . . . . . . . . . . . . . . . . 14 93 B.1.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . 14 94 B.1.2. [X] Keep secret . . . . . . . . . . . . . . . . . . . 14 95 B.1.3. [/] Don't print . . . . . . . . . . . . . . . . . . . 15 96 B.1.4. [=] Delete after reading, I days or on date . . . . . 15 97 B.1.5. [-] No attribution . . . . . . . . . . . . . . . . . . 16 98 B.1.6. [o] Keep internal . . . . . . . . . . . . . . . . . . 16 99 B.1.7. [>] Please share . . . . . . . . . . . . . . . . . . . 16 100 B.2. Confirmation/Affirmation of preferences . . . . . . . . . 17 101 B.3. Transparency (OPTIONAL) . . . . . . . . . . . . . . . . . 17 102 Appendix C. Graphical Representation of the State Machine . . . . 17 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 105 1. Introduction 107 1.1. Overview 109 Privicons describe a vocabulary of icons as an extension of the 110 Internet Message Format (e-mail message) for users to indicate how 111 their e-mail message should be treated. The icons are based on ASCII 112 symbols so that they can appear as embedded graphics or plain text 113 and include a variety of instructions such as "don't print," 114 "internal use only," and "confidential". It is partly borrowing its 115 approach from the concept of emoticons. For example to express, that 116 the content can be forwarded and even be published, the Sending User 117 could use the Privicon "[>]", which may be followed by an additional 118 explanations, such as "please share". 120 This document proposes a syntax (Section 2) and semantics (Section 3) 121 allowing a Sending User of an e-mail message to express his or her 122 preference for how the e-mail message content should be handled by 123 the Receiving Users. For this purpose, semantics of sets of 124 different character combinations ("Privicons") are described. These 125 can syntactically be integrated either in the first-line of the body, 126 in the subject line and/or in a dedicated header of any e-mail 127 message. The Privicons icon set has six different icons. They will 128 be machine-readable. 130 Importantly, the user can override all requests transmitted by 131 Privicons: The approach is grounded in reminder over hard-coded 132 solutions that indiscriminately restrict speech. Therefore, the 133 icons are merely asking the Receiving User of an e-mail to follow the 134 Sending User's preference. Other than DRM oriented approaches, 135 Privicons embraces the concept of code-based norms approach. This 136 means, that the approach relies on social norms to be followed by the 137 Receiving User, rather than technical enforcement mechanisms. 138 However, technical means may be used to support this (for example, 139 specifications see example e-mail message (Appendix B)). 141 Note: The specific character combinations for each Privicon is 142 currently undergoing user testing, it therefore might and will most 143 certainly change during the progression of this draft. 145 1.2. Relations to other standards 147 This specification extends [RFC5322] - Internet Message Format by 148 defining certain syntax for the first-line(s) of the body, the 149 subject line and an additional header field. 151 1.3. Terminology and Conventions 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in [RFC2119]. 157 o The term "User Agent" (often also Mail User Agent, UA, MUA) is 158 used as defined in Section-2.3.3 in [RFC5321] 160 o The terms "Sending User" and "Receiving User" are related to a 161 user using the User Agent either sending or receiving an e-mail 162 message. A Sending User is a user that sends an e-mail message to 163 a Receiving User. A Receiving User is a user that receives an 164 e-mail message from a Sending User. 166 o The term "Line" is used as defined by SMTP Section-2.3.8 in 167 [RFC5322] thereof 169 o The term "full-date" is used as defined by Section-5.6 in 170 [RFC3339]. 172 o The term Privacy Preference describes the intention the user had 173 when she has sent a specific e-mail message. It can be expressed 174 with the Privicons described in this RFC. 176 2. Syntax 178 In this section, the syntax if the Privicon e-mail extension is 179 defined. For semantics (Section 3), please see next section. A User 180 can indicate a Privacy Preference as lined out below in the following 181 ways: 183 o by making available selection of the Privicons, which SHOULD be 184 provided by the user agent, 186 o by inserting a Privicon in the subject line - by inserting a 187 Privicon in the first-line of the body. 189 An e-mail message fully compliant with this RFC will be called a 190 Privicon Message, it 192 o MUST contain a header (Section 2.4) with Privacy Preferences, 194 o SHOULD contain subject (Section 2.3) with Privicon, 196 o SHOULD have first-line (Section 2.2) and footer (Section 2.5) 197 o and MAY generate an HTML version. 199 The following section describes how the Privicon status of an e-mail 200 message is determined, concerning the privacy preferences described 201 in Overview (Section 1.1) 203 2.1. Definitions 205 element1 | element2 Elements separated by a bar ("|") are 206 alternatives, e.g., "yes | no" will accept yes or no. 208 "literal" Quotation marks surround literal text. Unless stated 209 otherwise, the text is case-insensitive. 211 whitespace " " 213 whatever Some arbitrary text. 215 date Will be substituted by a "full-date", [RFC3339]. 217 privicon = 218 ("[X]"|"[/]"|"[=]"|"[=0]"|"[=I]"|"[=date]"|"[-]"|"[o]"|"[>]") - 219 the Privicon token. It contains all valid Privicons, the Privicon 220 icon set. 222 I I will be substituted by an integer number >= 0. 224 description Contains the description of the Privicon as defined in 225 Semantics (Section 3). 227 subject Is the e-mail message subject field, see [RFC5322]. 229 CRLF Is the carriage return/line feed pair written in this document 230 as "CRLF". A line is a series of characters that is delimited 231 with the two characters carriage-return and line-feed; that is, 232 the carriage return (CR) character (ASCII value 13) followed 233 immediately by the line feed (LF) character (ASCII value 10), as 234 described in section2.1 in [RFC5322] 236 2.2. First-Line(s) of Message body 238 An indication of the Privacy Preference can be given in the first 239 line of the body of an e-mail message. 241 The expression MUST be followed by a text giving a short explanation 242 the meaning of the expressions. It is RECOMMENDED to use the 243 following text, although localization into other languages is also 244 encouraged, albeit not lined out in this document. 246 firstLine = privicon whitespace "-" whitespace description 248 For example: 250 [X] - Keep private 252 [/] - Don't print 254 [=] - Delete after reading 256 [=0] - Delete after reading 258 [=I] - Delete after I days 260 [=date] - Delete on date 262 [-] - No attribution 264 [o] - Keep internal 266 [>] - Please share 268 After the first-line, a second line, with an additional privacy 269 preference may follow if the combination (Section 3.2) is permitted. 271 2.3. Subject Line 273 An indication of the Privacy Preference can be given in the beginning 274 of a subject line of an e-mail message using the following 275 expression: 277 privicon whitespace subject 279 or 281 whatever whitespace privicon whitespace subject 283 For example: 285 [X] This is the subject of the e-mail message 287 [/] This is the subject of the e-mail message 289 [=] This is the subject of the e-mail message 291 [=4] This is the subject of the e-mail message 293 [=1980-01-01] This is the subject of the e-mail message 295 [-] This is the subject of the e-mail message 297 [o] This is the subject of the e-mail message 299 [>] This is the subject of the e-mail message 301 or 303 Re: [X] This is the subject of the e-mail message 305 Fwd: [/] This is the subject of the e-mail message 307 2.4. Header 309 An indication of the Privacy Preference MAY be given in the header of 310 an e-mail message, for this purpose the following field is defined, 311 extending in section 3.6 in [RFC5322] the field definition, thereof. 313 priviconfield = "Privicon:" whitespace privicon CRLF 315 The possible values of the Privicon token are described in 316 Definitions (Section 2.1) 318 2.5. Footer 320 Separated by -- 322 The Footer MAY be located within the signature as described in 323 section 4.3 in [RFC3676] . It contains a paragraph that describes 324 what the Sending User of the e-mail message intended when she chooses 325 the selected Privicon. 327 A clarification MAY be added that a conflict between header and 328 first-line would lead to the first-line to be authoritative. 330 footer = CRLF "-- " CRLF footertext 332 footertext = firstLine CRLF description 334 For example: 336 -- 338 [X] - Keep private 340 The "Keep secret" Privicon asks the Receiving User to keep the 341 received e-mail message secret. 343 Note: Footnote may violates [RFC1855] Page4 - do not use more than 4 344 lines signature. 346 The Footnote is just informative not authoritative 348 2.6. Authoritative or Parsing order - Conflicts 350 When parsed, the authoritative order of the different elements is as 351 follows: 353 1. first-line in body (Section 2.2) 355 2. subject (Section 2.3) 357 3. header (Section 2.4) 359 If only one Privicon is found, it has always the same meaning, no 360 matter if it is defined in first-line in body, subject or header. 362 2.7. Syntax error 364 After syntax error, the most restrictive case is assumed. 366 For example "Delete after ??? days" will be transformed into "Delete 367 immediately") 369 2.8. HTML-Messages 371 In HTML-Messages, the "Privicon" are OPTIONAL represented with 372 graphical icons. Example icons can be found in Annex. Embedded 373 icons MUST be included into the Message and MUST NOT be loaded from 374 an Internet Server. This is important avoid a loss of privacy for 375 the receiving user. It also causes in some cases problems with SSL- 376 Encryption in web based e-mail message user agents (MUA). 378 The graphical representation MUST contain the ASCII-Icon as 379 Alternate-Text. 381 If the "Privicon" is included in the First Line of Body, the 382 "description" MUST also be displayed in next to the Privicon. 384 3. Semantics 386 3.1. Privicons 388 The Privicons icon set has six different icons. The meaning of the 389 icons will be described in this section. It is important, that 390 Privicons always just meant to be a nice way of asking somebody to do 391 something. 393 3.1.1. [X] Keep private 395 The "Keep private" Privicon asks the Receiving User to keep the 396 received e-mail message private. 398 3.1.2. [/] Don't print 400 The "Don't print" Privicon asks the Receiving User to not print the 401 received e-mail message. 403 3.1.3. [=] Delete after reading, I days or on date 405 The "Delete after reading/I days" Privicon asks the Receiving User to 406 delete the e-mail message no later than a specified period. There 407 are four different cases: 409 1. [=] delete after reading 411 2. [=0] delete after reading 413 3. [=I] delete after I days 415 4. [=date] delete on date 417 "I" and "date" are defined in Terminology and Conventions 418 (Section 1.3). 420 3.1.4. [-] No attribution 422 The "No attribution" Privicon asks the Receiving User to not 423 attribute, name or mention the original Sending User of the e-mail 424 message in any kind. At the same time the Receiving User may quote, 425 follow or paraphrase the content, facts and opinions voiced in the 426 original e-mail message. In other words, the Receiving User is free 427 to use the information received, but neither the identity nor the 428 affiliation of the Sending User may be revealed. 430 3.1.5. [o] Keep internal 432 The "Keep internal" Privicon asks the Receiving User to present this 433 e-mail message only to those people that are common friends, or 434 otherwise part of a group of people are in a relation to both the 435 Sending User and the Receiving User. Note that the judgement, 436 whether a person belongs to this group is solely upon the Receiving 437 User unless otherwise indicated by the Sending User. The "Keep 438 internal" just indicates, that a Receiving User SHOULD give some 439 further thought on which she is sending the e-mail message to, and 440 that the Sending User does not want the e-mail message to be 441 forwarded arbitrarily. 443 3.1.6. [>] Please share 445 The "Please share" Privicon asks the Receiving User to share this 446 e-mail message with everyone, as she likes. It may be supplemented 447 by further instructions on licensing for clarifying the copyright 448 status. 450 3.2. Multiple Privicons 452 Possible: Y 454 Impossible: N 456 Does not apply: X 458 As secondary option, potentially, and if first preference is 459 overruled: 461 +-----+-----+-----+-----+-----+-----+-----+ 462 | | [X] | [/] | [=] | [-] | [o] | [>] | 463 +-----+-----+-----+-----+-----+-----+-----+ 464 | [X] | X | Y | Y | N | N | N | 465 | [/] | Y | X | Y | Y | Y | Y | 466 | [=] | Y | Y | X | Y | Y | N | 467 | [-] | N | Y | Y | X | Y | Y | 468 | [o] | N | N | Y | Y | X | N | 469 | [>] | N | Y | N | Y | N | X | 470 +-----+-----+-----+-----+-----+-----+-----+ 472 Table 1: Matrix of all combinations of Privicons. 474 4. IANA Considerations 476 This document introduces a new field in the e-mail header, as 477 described in the header (Section 2.4) section. 479 5. Security Considerations 481 The extensions to the e-mail message Format described in this 482 document does not change the fundamental nature of the SMTP service 483 and hence does not create any new security exposures in and of 484 itself. 486 6. Acknowledgements 488 In alphabetical order: 490 Andreas M. Braendhaugen, Designer, San Francisco 492 Laurent Bussard, European Microsoft Innovation Center 494 Ryan Calo, Stanford University 496 Alissa Cooper, Oxford Internet Institute 498 Ethan Forrest, Stanford University 500 Marit Hansen, Unabhaengiges Landeszentrum fuer Datenschutz 501 Schleswig-Holstein 503 Alexey Melnikov, Isode 505 Ulrich Pinsdorf, European Microsoft Innovation Center 507 Thomas Roessler, W3C 509 Max Senges, Google Inc. 511 Hannes Tschofenig, Nokia Siemens Networks 513 7. Normative References 515 [RFC1855] Hambridge, S., "Netiquette Guidelines", RFC 1855, 516 October 1995. 518 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 519 Requirement Levels", BCP 14, RFC 2119, March 1997. 521 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 522 Internet: Timestamps", RFC 3339, July 2002. 524 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 525 Extension for Delivery Status Notifications (DSNs)", 526 RFC 3461, January 2003. 528 [RFC3676] Gellens, R., "The Text/Plain Format and DelSp Parameters", 529 RFC 3676, February 2004. 531 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 532 October 2008. 534 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 535 October 2008. 537 Appendix A. Example e-mail message 539 This is an example Privicon e-mail message (Figure 1). 541 Message-ID: <4C3203D3.60109@ulikoenig.com> 542 Date: Mon, 05 Jul 2010 23:59:00 +0200 543 From: Ulrich Koenig 544 To: Jan Schallaboeck 545 Subject: [>] last update for Privicons RFC 546 Privicon: [>] 547 Content-Type: text/plain; charset=ISO-8859-15 548 Content-Transfer-Encoding: quoted-printable 549 [>] Please share 551 Hey Jan, 553 please check the IETF Website for our Privicons RFC! ;) 555 best Ulrich 557 --=20 558 [>] Please share 559 The "Please share" Privicon asks the Receiving User to share this 560 e-mail message with everyone she likes. 562 Figure 1: Example of an e-mail message using a Privicon 564 Appendix B. Informative example requirements for e-mail message user 565 agents 567 B.1. User agent behaviour 569 This section gives developers of e-mail message user agents (MUA) or 570 plug-ins for MUAs instructions how to integrate the Privicons in the 571 client. 573 An MUA implementing this RFC MUST enable the user at any time to 574 overrule the received Privicon. The user SHOULD also be able to set 575 a default for always overruling in her client. The rest of the 576 instructions in this section are OPTIONAL. 578 If the user agent displays an e-mail message that contains one or 579 more Privicons it SHOULD display the icon and its meaning in a 580 salient way. If the icon is displayed by the user agent it MAY hide 581 the Privicon in Subject and Body of the e-mail message. The user 582 agent MAY localise the explaining text. 584 B.1.1. Terms 586 confirm A confirm pop-up or any other visible notion that yields 587 active interaction by the user (i.e. clicking a button). The user 588 SHOULD be able to disable a part or all confirmations. 590 inform A pop-up, or any other visible notion, that SHOULD yield 591 confirmation. Such notification SHOULD be enabled by default. 592 The user SHOULD be able to disable the notification by default. 594 B.1.2. [X] Keep secret 596 The "Keep private" Privicon asks the Receiving User to keep the 597 received e-mail message secret. 599 B.1.2.1. EVENT: Forward/Reply to third Person 601 If the Receiving User wants to forward or reply-to the e-mail message 602 to a third person, that is not the original Sending User, than the 603 Receiving User MUST be informed, that she is going to violate the 604 included Privicon and she MUST confirm that she is willing to do this 605 before the e-mail message is sent. 607 OPTIONAL: Transparency (Appendix B.3) applies. 609 B.1.3. [/] Don't print 611 B.1.3.1. EVENT: Printing e-mail message 613 If the Receiving User wants to print the e-mail message, she MUST be 614 informed that she is going to violate the included Privicon and she 615 MUST confirm that she is willing to do this before printing is 616 started. 618 B.1.4. [=] Delete after reading, I days or on date 620 B.1.4.1. EVENT: Closing Mail 622 If the Receiving User closes the e-mail message, she MUST be 623 informed, that the e-mail message SHOULD be deleted after X days. 625 The user MUST confirm whenever she closes the e-mail message, hat the 626 e-mail message is deleted immediately. 628 The client SHOULD enable the user to choose a default option. 630 Note: if e-mail messages are displayed in list mode, then the 631 confirmation will be raised, when opening the next e-mail message. 633 B.1.4.1.1. Option a) delete after reading 635 The above confirmation MUST ask the user, whether 637 o ignore, do not decide now, ask me again next time, 639 o delete or move into a "to be deleted" folder, as indicated in the 640 preferences or 642 o ask again after a specified period. 644 B.1.4.1.2. Option b) delete after X days 646 The above confirmation MUST ask the user, whether 648 o ignore, do not decide now, ask me again next time, 650 o delete now, 652 o delete after X days automatically or 654 o ask me in X days. 656 B.1.4.1.3. Option c) delete on date 658 The above confirmation MUST ask the user, whether 660 o ignore, do not decide now, ask me again next time, 662 o delete now, 664 o delete on date automatically or 666 o ask me on date. 668 B.1.5. [-] No attribution 670 B.1.5.1. EVENT: reply, forward, store 672 If the Receiving User wants to forward or reply to a third person or 673 store the e-mail message, she MUST be informed, that the Sending User 674 doesn't want to be mentioned and MUST confirm that she is willing to 675 overrule the Sending Users wish or remove any occurrence of the 676 Sending User in the e-mail message (Header and Body). The removal of 677 the Sending User MAY be done by the user agent automatically. 679 OPTIONAL: Transparency (Appendix B.3) applies. 681 B.1.6. [o] Keep internal 683 If the Receiving User has defined what "internal" means to her, the 684 following rules in the "Keep internal" subsection only apply if at 685 least one of the Receiving Users are not part of her internal 686 definition. 688 If the Receiving User wants to forward or reply the e-mail message to 689 a third person, the user MUST be informed that she SHOULD check if 690 the third person is really part of the group that the Sending User 691 intended to be internal and MUST confirm that she really to send this 692 e-mail message. 694 OPTIONAL: Transparency (Appendix B.3) applies. 696 B.1.7. [>] Please share 698 The client SHOULD notice the user, that the content of the e-mail 699 message can be published. If the Sending User has transmitted a 700 license for publishing the content, it SHOULD also be displayed. 702 B.2. Confirmation/Affirmation of preferences 704 Note this may be for further versions, but might yield legal 705 implications: Before opening the e-mail message containing a 706 Privicon, the User Agent SHOULD inform the user what the user is 707 asked to do with the option to reject the e-mail message. To reject 708 an e-mail message means the Sending User is notified, that the e-mail 709 message is rejected and has been deleted at User Agent's side before 710 reading. Not to reject the e-mail message does not mean, that the 711 receiving user accepts the requested conditions, see [RFC3461]. 713 B.3. Transparency (OPTIONAL) 715 If a Receiving User forwards or replies an e-mail message containing 716 a Privicon to a third person, the original Sending User OPTIONAL get 717 a copy via carbon copy or a blind carbon copy by default. The 718 Receiving User MUST be able overrule this. She also SHOULD be able 719 to disable the default sending of a copy in the user preferences. 721 Appendix C. Graphical Representation of the State Machine 723 There is a graphical representation of the Privicons, that MAY be 724 used by MUAs, see Figure (Figure 2). 726 In the PS/PDF version of this specification, the 727 graphical representation of the Privicons can be 728 found here. 730 Figure 2: Graphical representation of the Privicons. 732 Authors' Addresses 734 Ulrich Koenig 735 Unabhaengiges Landeszentrum fuer Datenschutz Schleswig-Holstein 736 Duesternbrooker Weg 70 737 Kiel, Schleswig-Holstein 24105 738 Germany 740 Phone: +49-431-988-1220 741 Fax: +49-431-988-1223 742 Email: rfc@ulikoenig.com 743 URI: https://www.datenschutzzentrum.de 744 Jan Schallaboeck 745 Unabhaengiges Landeszentrum fuer Datenschutz Schleswig-Holstein 746 Holstenstr. 98 747 Kiel, Schleswig-Holstein 24103 748 Germany 750 Phone: +49-431-988-1220 751 Fax: +49-431-988-1223 752 Email: uld62@datenschutzzentrum.de 753 URI: https://www.datenschutzzentrum.de