[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [VCARDDAV] Gen-ART LC review ofdraft-ietf-vcarddav-carddav-09.txt (fwd)
Hi folks,
The GenART review of CardDAV brought up two issues for which I have
proposed resolutions as documented below. Both of these are considered
changes that we need WG consensus on.
1) The first point relates to a requirement for clients to support TLS.
Currently the spec says nothing except that servers MUST support it. I
propose added a statement that clients SHOULD support TLS. There was some
debate as to whether that ought to be a MUST. Please comment.
2) The second point relates to "warnings" in clients when contact data is
made "public". The current text states that clients MAY warn users in such
cases. It was felt this was too weak. I have proposed some alternative text
(seen at the bottom of the forwarded message below) that turns the MAY into
a SHOULD and clarifies a bit more under what circumstances this might
occur. Please comment.
------------ Forwarded Message -----------
Date: October 15, 2009 9:51:01 AM -0400
From: Cyrus Daboo <cyrus at daboo.name>
To: Alexey Melnikov <alexey.melnikov at isode.com>, Brian E Carpenter
<brian.e.carpenter at gmail.com>
cc: draft-ietf-vcarddav-carddav at tools.ietf.org, General Area Review Team
<gen-art at ietf.org>, vcarddav-chairs at tools.ietf.org
Subject: Re: Gen-ART LC review ofdraft-ietf-vcarddav-carddav-09.txt
Hi Alexey,
--On October 13, 2009 11:54:39 AM +0100 Alexey Melnikov
<alexey.melnikov at isode.com> wrote:
I would be happy with that; it's probably something to be checked with
the WG since it's a change in normative requirements.
I wonder if this needs to be phrased as "Clients MUST implement TLS
support, SHOULD use it"?
I think MUST is too strong. There a situations where a client may exist on
a private network (e.g. a server farm with a carddav server and a webapp
accessing it) where there is no need for TLS, or they may exist in an
environment where some other form of security layer is present (e.g.
ipsec). Implementors of such clients should not be burdening with
implementing TLS if they don't need it.
On the same lines,
Clients MAY choose to warn users when they create address data in a
public address book, copy or move address data into public address
books, or change access privileges in such a way as to expose address
data to unauthenticated users.
Why isn't that a SHOULD?
I am a little nervous about putting such a requirement on a client.
First of all, what does it really mean to "warn" a user? An alert, an
icon, a noise? Does it happen only the first time they do an action, or
each time? SHOULD seems a little strong when the nature of the warning
is really going to be implementation dependent.
That said, if there is consensus for this change, it may be necessary to
explain a little more what "warn" means.
Yes, that is a problem. I'm not a privacy expert, but it does seem like
something that could one day end up as bad news. ("XYZ Corporation
revealed private data for 27,000 customers, FCC investigation alleges.
We just followed the IETF standard, says XYZ spokesman.") I think it
needs a little thought.
I think SHOULD is better here.
And yes, I think some explanation of what "warns" mean is needed, as well
as some possible description of "remember my answer" checkbox (or
similar).
OK, I can change that paragraph to
Clients SHOULD warn users in an appropriate fashion when they copy or
move address data from a private address book to a shared address book
(one accessible by other authenticated users only) or public address
book (one accessible by unauthenticated users). Clients SHOULD provide
a clear indication as to which address books are private, shared or
public. Clients SHOULD provide an appropriate warning when changing
access privileges for a private or shared address book with data so as
to allow unauthenticated users access.
Is that reasonable?
--
Cyrus Daboo
---------- End Forwarded Message ----------
--
Cyrus Daboo
--- Begin Message ---
Hi Alexey,
--On October 13, 2009 11:54:39 AM +0100 Alexey Melnikov
<alexey.melnikov at isode.com> wrote:
I would be happy with that; it's probably something to be checked with
the WG since it's a change in normative requirements.
I wonder if this needs to be phrased as "Clients MUST implement TLS
support, SHOULD use it"?
I think MUST is too strong. There a situations where a client may exist on
a private network (e.g. a server farm with a carddav server and a webapp
accessing it) where there is no need for TLS, or they may exist in an
environment where some other form of security layer is present (e.g.
ipsec). Implementors of such clients should not be burdening with
implementing TLS if they don't need it.
On the same lines,
Clients MAY choose to warn users when they create address data in a
public address book, copy or move address data into public address
books, or change access privileges in such a way as to expose address
data to unauthenticated users.
Why isn't that a SHOULD?
I am a little nervous about putting such a requirement on a client.
First of all, what does it really mean to "warn" a user? An alert, an
icon, a noise? Does it happen only the first time they do an action, or
each time? SHOULD seems a little strong when the nature of the warning
is really going to be implementation dependent.
That said, if there is consensus for this change, it may be necessary to
explain a little more what "warn" means.
Yes, that is a problem. I'm not a privacy expert, but it does seem like
something that could one day end up as bad news. ("XYZ Corporation
revealed private data for 27,000 customers, FCC investigation alleges.
We just followed the IETF standard, says XYZ spokesman.") I think it
needs a little thought.
I think SHOULD is better here.
And yes, I think some explanation of what "warns" mean is needed, as well
as some possible description of "remember my answer" checkbox (or
similar).
OK, I can change that paragraph to
Clients SHOULD warn users in an appropriate fashion when they copy or
move address data from a private address book to a shared address book
(one accessible by other authenticated users only) or public address
book (one accessible by unauthenticated users). Clients SHOULD provide
a clear indication as to which address books are private, shared or
public. Clients SHOULD provide an appropriate warning when changing
access privileges for a private or shared address book with data so as
to allow unauthenticated users access.
Is that reasonable?
--
Cyrus Daboo
--- End Message ---