Network Working Group U. Koenig
Internet-Draft J. Schallaboeck
Intended status: Experimental Unabhaengiges Landeszentrum
Expires: January 6, 2011 fuer Datenschutz
Schleswig-Holstein
July 5, 2010
Privacy Preferences for E-Mail Messages
draft-koenig-privicons-00
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 6 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 to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Koenig & Schallaboeck Expires January 6, 2011 [Page 1]
Internet-Draft Privicons July 2010
This Internet-Draft will expire on January 6, 2011.
Copyright Notice
Copyright (c) 2010 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 BSD License.
Koenig & Schallaboeck Expires January 6, 2011 [Page 2]
Internet-Draft Privicons July 2010
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 . . . . . . . . . . . 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 MUAs . . . . . . 13
B.1. User agent behaviour . . . . . . . . . . . . . . . . . . . 13
B.1.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . 13
B.1.2. [X] Keep secret . . . . . . . . . . . . . . . . . . . 14
B.1.3. [/] Don't print . . . . . . . . . . . . . . . . . . . 14
B.1.4. [=] Delete after reading/X days . . . . . . . . . . . 14
B.1.5. [-] No attribution . . . . . . . . . . . . . . . . . . 16
B.1.6. [o] Keep internal . . . . . . . . . . . . . . . . . . 16
B.1.7. [>] Please share . . . . . . . . . . . . . . . . . . . 16
B.2. Confirmation/Affirmation of preferences . . . . . . . . . 16
B.3. Transparency - optional . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Koenig & Schallaboeck Expires January 6, 2011 [Page 3]
Internet-Draft Privicons July 2010
1. Introduction
1.1. Overview
Privicons describes 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 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 has 6 different icons. They'll be machine
readable.
Importantly, all requests transmitted by Privicons can be overridden
by the user: The approach is grounded in reminder over hard-coded
solutions that indiscriminately restrict speech. So 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 an 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 January 6, 2011 [Page 4]
Internet-Draft Privicons July 2010
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] in clause 5.6.
o The term Privacy Preference describes the intention the user had
when she has sended 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 January 6, 2011 [Page 5]
Internet-Draft Privicons July 2010
o and MAY generate an HTML version.
The following section describes how the Privicon status of an e-mail
message is determined, in regard to 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 are also
encouraged, albeit not lined out in this document.
Koenig & Schallaboeck Expires January 6, 2011 [Page 6]
Internet-Draft Privicons July 2010
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
[-] - No attribution
[o] - Keep internal
[>] - Please share
After a this 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
[=4] This is the subject of the e-mail message
Koenig & Schallaboeck Expires January 6, 2011 [Page 7]
Internet-Draft Privicons July 2010
[=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 January 6, 2011 [Page 8]
Internet-Draft Privicons July 2010
[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 6 different icons. The meaning of the
icons will be described in this section. It is important, that
Privicons always just meant do be a nice way of asking somebody to do
something.
Koenig & Schallaboeck Expires January 6, 2011 [Page 9]
Internet-Draft Privicons July 2010
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
The "Delete after reading/I days" Privicon asks the Receiving User to
delete the e-mail message no later than a specified period of time.
There are three different cases:
1. [=] delete after reading
2. [=0] delete after reading
3. [=I] delete after I days
I stands for an integer number >= 0.
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 who she is sending the e-mail message to, and that
the Sending User does not want the e-mail message to be forwarded
arbitrarily.
Koenig & Schallaboeck Expires January 6, 2011 [Page 10]
Internet-Draft Privicons July 2010
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 makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
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 January 6, 2011 [Page 11]
Internet-Draft Privicons July 2010
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 January 6, 2011 [Page 12]
Internet-Draft Privicons July 2010
October 2008.
Appendix A. Example e-mail message
Message-ID: <4C3203D3.60109@datenschutzzentrum.de>
Date: Mon, 05 Jul 2010 23:59:00 +0200
From: Ulrich Koenig <ULD61@datenschutzzentrum.de>
Organization: Unabhaengiges Landeszentrum fuer Datenschutz Schleswig-Holstein
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 Uli
--=20
[<] Please share
The "Please share" Privicon asks the Receiving User to share this e-mail message with everyone she likes.
Example of an e-mail message using a Privicon
Appendix B. Informative example requirements for MUAs
B.1. User agent behaviour
An e-mail message user agent 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.
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.
B.1.1. Terms
Koenig & Schallaboeck Expires January 6, 2011 [Page 13]
Internet-Draft Privicons July 2010
confirm a confirm pop-up or any other visible notion that yields
active interaction by the user (i.e. clicking a button).
inform a pop-up, or any other visible notion, that SHOULD yield
confirmation. such informations should be on on default, but can
be turned of in the preferences, either in general or on a case by
case basis.
User Agent Preferences to be defined
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 send. If the Receiving User forwards or
replies the e-mail message, the Sending User MAY also gets a copy via
blind carbon copy.
B.1.2.2. EVENT: Store e-mail message
If the Receiving User wants to save the e-mail message to the hard
disk, the Receiving User SHOULD be warned that she is going to
violate the included Privicon.
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/X days
B.1.4.1. EVENT: Closing Mail
If the Receiving User closes the e-mail message, she MUST be
informed, the the e-mail message SHOULD be deleted after X days.
The client MUST request confirmation of the user, whenever she closes
Koenig & Schallaboeck Expires January 6, 2011 [Page 14]
Internet-Draft Privicons July 2010
the e-mail message to delete the e-mail message immediately.
Note: if e-mail messages are displayed in list mode, then the warning
is to be raised, when opening the next e-mail message.
Option a) delete after reading
The above confirmation must ask the user, whether
o ignore/do not decide now /ask me again next time (default)
o delete/trash or move into a "to be deleted" folder, as indicated
in the preferences
o ask again after a specified period
Option b) delete after X days
o ignore/do not decide now /ask me again next time (default)
o delete now
o delete after X days automatically
o ask me in X days if on previous closing of the e-mail message no
indication has been given.
o check-box: Always use this option (Remark: not available for first
option (ignore), indicate where to change this in preferences)
B.1.4.1.1. Preferences
Indicate preferences for the above options (3a/b) on defaults: a)
likewise b)on delete after X days, always a)delete now, delete after
X days automatically, ask me in X days.
Deletion can either mean:
o move to the trash (standard emptying cycles apply)
o delete immediately (default
o move to a dedicated folder (such as "to be deleted")
Koenig & Schallaboeck Expires January 6, 2011 [Page 15]
Internet-Draft Privicons July 2010
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.
B.1.5.2. Transparency
If the e-mail message is forwarded/replied to a third person the
Sending User MAY get a copy via blind carbon copy.
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 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.
If forward/reply: carbon copy to original Sending User
B.1.7. [>] Please share
The client SHOULD notice the user, that the content of the e-mail
message can be published. If the 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].
Koenig & Schallaboeck Expires January 6, 2011 [Page 16]
Internet-Draft Privicons July 2010
B.3. Transparency - optional
If a user forwards or replies an e-mail message to a third person,
the original Sending User will get a copy via carbon copy/ blind
carbon copy by default.
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 January 6, 2011 [Page 17]