Cyrus Daboo wrote:
Hi Alexey,
--On October 13, 2009 11:54:39 AM +0100 Alexey Melnikov
<[email protected]> 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.
Leaving "client SHOULD use TLS" would be Ok with me, but the rest of
IESG might disagree.
So anyway, I've added this as an RFC Editor note.
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?
I like that. Added as an RFC Editor note.
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
