My comments on "Privacy Preferences for E-Mail Messages"
1. Introduction
1.1. Overview
.
.
.
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.
It would be more correct to use the term "header field" rather
than "header" here and in the rest of the document.
.
.
.
1.3. Terminology and Conventions
.
.
.
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.
The definition of Sending User needs to be clarified: is it the
email-address from the Sender: header field? Or one or more of
the email-address from the From: header field?
.
.
.
2. Syntax
.
.
.
o MUST contain a header (Section 2.4) with Privacy Preferences,
This "MUST" seems to conflict with the MAY later in this spec.
.
.
.
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]
These definitions need to be formatted to more clearly
distinguish the term from its definition. Perhaps like the
"privicon" definition.
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 definition of "first line" is not at all clear except for a
TEXT/PLAIN body.
In the case of a TEXT/HTML body, the intent seems to be that the
first line is the topmost "line" visible to the Receiving User.
However, since the "first line" privicon is the determining
specification in the case of disagreements and the MUA is
expected to "enforce" this, the MUA must be able to *find* the
privicon. This could be difficult for the MUA with sophisticated
HTML code.
For bodies such as IMAGE/*, AUDIO/*, VIDEO/*, MODEL/*, or
APPLICATION/* how is the "first line" to be found?
In the case of a MESSAGE/* the first line would be part of the
embedded message's header and would probably cause a parse error.
In the case of MULTIPART/MIXED the first line would presumably be
the "first line" of whatever the first embedded part is. And in
the case of MULTIPART/ALTERNATIVE the first line would have to be
the "first line" of each embedded version with a method of
resolving conflicts there, too.
The remaining MULTIPART/* type bodies would have similar issues.
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.
The use of MUST here without specifying the required text is
unenforceable and is better expressed with a SHOULD.
.
.
.
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.
As mentioned above this MAY conflicts with the MUST earlier in the spec.
priviconfield = "Privicon:" whitespace privicon CRLF
I find the requirement of a single space character following the
colon to be objectionable, this is not Usenet! There should also
be provision for a comment or explanatory text following the
privicon.
.
.
.
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.
The preceding paragraph seems out of place.
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.
This example seems to imply that the "firstLine" is the first
non-blank line, does this also apply to the body "first line"?
Note: Footnote may violates [RFC1855] Page4 - do not use more than 4
lines signature.
The Footnote is just informative not authoritative
By "Footnote" here do you mean "Footer"?
.
.
.
3. Semantics
.
.
.
3.1.2. [/] Don't print
The "Don't print" Privicon asks the Receiving User to not print the
received e-mail message.
It is not clear what privacy issue is being addressed with the
"Don't print" privicon. If the Receiving User can more easily
keep a message private by printing it, locking it in a safe, and
deleting the electonic copy, why would the Sending User object?
What danger does the Sending User prevent with this option?
.
.
.
3.2. Multiple Privicons
Possible: Y
Impossible: N
Does not apply: X
As secondary option, potentially, and if first preference is
overruled:
The preceding paragraph is not clear. Do the privicons "OR"
together or replace the first with the second under some
conditions?
+-----+-----+-----+-----+-----+-----+-----+
| | [X] | [/] | [=] | [-] | [o] | [>] |
+-----+-----+-----+-----+-----+-----+-----+
| [X] | X | Y | Y | N | N | N |
| [/] | Y | X | Y | Y | Y | Y |
| [=] | Y | Y | X | Y | Y | N |
| [-] | N | Y | Y | X | Y | Y |
| [o] | N | N | Y | Y | X | N |
| [>] | N | Y | N | Y | N | X |
+-----+-----+-----+-----+-----+-----+-----+
Table 1: Matrix of all combinations of Privicons.
This table is not symmetrical, so which is the first privicon and
which is the second? Otherwise, explain why [/] and [o] cannot be in
either order.
.
.
.
4. IANA Considerations
This document introduces a new field in the e-mail header, as
described in the header (Section 2.4) section.
The first use of the word "header" in the preceding paragraph is
correct, but the second is not!
.
.
.
Appendix A. Example e-mail message
This is an example Privicon e-mail message (Figure 1).
Message-ID: <4C3203D3(_dot_)60109(_at_)ulikoenig(_dot_)com>
Date: Mon, 05 Jul 2010 23:59:00 +0200
From: Ulrich Koenig <rfc(_at_)ulikoenig(_dot_)com>
To: Jan Schallaboeck <uld62(_at_)datenschutzzentrum(_dot_)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
This example places the (presumably first body line) privicon as
part of the message header and thus will cause a syntax error and
likely make the privicon invisible to the Receiving User.
.
.
.
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 following instructions are OPTIONAL, the use of 12 "MUST"s
in them is hard to justify.
.
.
.
B.1.2. [X] Keep secret
The "Keep private" 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.
It seems to me that the list of *all* of the From: addresses, the
Sender: address, and the To: addresses should be considered as
non-third party addresses since they presumably are all aware of
the message already.
.
.
.
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 preceding paragraph is not clear.
.
.
.
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.
Where is the option to tell the MUA "Do NOT delete, and never
bother me again."?
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.
Where is the option to tell the MUA "Do NOT delete, and never
bother me again."?
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.
Where is the option to tell the MUA "Do NOT delete, and never
bother me again."?
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.
Esactly how can the MUA determine in the *body* that the Sending
User identity has been removed?
.
.
.
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.
Should the Sending User and all Receiving Users be considered as
added to "internal" automatically for the purposed of this reply
of forward?
.
.
.
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.
It may be appropriate to forward the privicons of the original
message, optionally.
--
Bill McQuillan <McQuilWP(_at_)pobox(_dot_)com>