draft-koenig-privicons-03.txt
Bill McQuillan <McQuilWP <at> pobox.com>
2011-12-05 20:54:06 GMT
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.60109 <at> ulikoenig.com>
> Date: Mon, 05 Jul 2010 23:59:00 +0200
> From: Ulrich Koenig <rfc <at> ulikoenig.com>
> To: Jan Schallaboeck <uld62 <at> 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
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.com>
.
You can send both objections and your statements of support directly to
me (if you wish) or to the mailing list.
Please send your responses by the end of April 29th.
Alexey,
as an APPSAWG co-chair
Please do feel free to review what's there and comment, and also submit suggestions for other cases that
might be of interest to record for future implementers.
-MSK
RSS Feed