Re: [datatracker-rqmts] Publicly-readable and private/anonymous lists

Henrik Levkowetz <> Wed, 08 December 2010 10:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 958A03A68F5 for <>; Wed, 8 Dec 2010 02:25:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.486
X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bIHJvqG0CjeJ for <>; Wed, 8 Dec 2010 02:25:03 -0800 (PST)
Received: from ( [IPv6:2a01:3f0:0:31:214:22ff:fe21:bb]) by (Postfix) with ESMTP id 8182D3A68BD for <>; Wed, 8 Dec 2010 02:25:01 -0800 (PST)
Received: from ([2a01:3f0:1:0:21e:c2ff:fe13:7e3e]:57750 by with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <>) id 1PQHDb-0005Fh-2i; Wed, 08 Dec 2010 11:25:56 +0100
Message-ID: <>
Date: Wed, 08 Dec 2010 11:25:50 +0100
From: Henrik Levkowetz <>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Paul Hoffman <>
References: <p0624081bc9249d506bb8@[]>
In-Reply-To: <p0624081bc9249d506bb8@[]>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 2a01:3f0:1:0:21e:c2ff:fe13:7e3e
X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000)
X-SA-Exim-Scanned: Yes (on
Subject: Re: [datatracker-rqmts] Publicly-readable and private/anonymous lists
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 08 Dec 2010 10:25:22 -0000

Hi Paul,

Looking this over, both specification and implementation of these
notification specifications ('lists') seems to becoming more and
more complex, and I'm not convinced that the complexity buys us a
lot.  The whole issue comes about because of the decision that
people should be able to include another list in their notification

I would like to do away with the whole complexity of this by saying
(at least for this round -- we can always re-open this again when
we have some practical experience with the first implementation) --
by saying that lists can't include other lists, and all lists are
anonymous and unpublished.



On 2010-12-08 03:36 Paul Hoffman said:
> Greetings again. It's time to spin up this list again, and a few people have told me that specifying how public lists are publicly-readable and how private/anonymous lists are created and managed will unblock a bunch of other open issues. There was a lot of interest in these topics at the mic in Beijing.
> The current text is below. This is just starting text, and it doesn't cover the idea that some private/anonymous lists might have publicly-readable counterparts if the list owner wants.
> So, please say what you think should be done here. Do you have a preference between private and anonymous? Do you have ideas for public lists?
> To facilitate the discussion, there will be a WebEx-based telechat on Friday, December 17. Information on that comes in the next message. If we have great consensus before the telechat, we can use that time to move on other open issues.
> --Paul Hoffman
> ======================================
> 2.1.3.  Requirement: Some lists must be able to be private or anonymous
>    Seeing a list of drafts that covers multiple areas of interest can
>    tell you something about the person who created the list.  For
>    example, you might be able to guess that they might be looking for a
>    job in a different field by looking at their list of drafts of
>    interest.  Of course, anyone can follow individual drafts today
>    without having that be exposed; however, following a particular group
>    of drafts can reveal information about a person.
>    There is a open issue about whether lists should be default be
>    private/anonymous or public, and how that default should be manifest
>    in the eventual UI for creating lists.
>    The first proposed methods that might keep lists private/anonymous
>    are:
>    o  Private lists might only be available using passwords or some
>       other common authentication mechanism.  This would require that
>       the Datatracker have a subscription process for users that could
>       assign passwords, and a per-user process for adding lists to a
>       user account.  (If the current Datatracker username and login
>       scheme is used, the interface needs to be improved so that getting
>       a new login, and changing one's password, are significantly
>       easier.)
>    o  Anonymous lists might be assigned random URLs from a very large
>       (2^128) namespace, and the user who creates a list does not tell
>       others the assigned URL.  This method makes it impossible for
>       someone to search the entire set of assigned lists.  Given that
>       the URLs for lists are most likely going to be copy-and-pasted
>       anyway, having long random strings in the list's URL is not an
>       impediment.
> 2.1.4.  Requirement: It must be easy for IETF leadership and individuals
>         to make lists they create publicly-readable
>    Private or anonymous lists are fine for individuals, but publicly-
>    readable lists can magnify the value to the whole community.  In
>    fact, some early commenters on this document emphasized that
>    publicly-readable lists will be more valuable to the IETF than
>    helping individuals track documents that are only of interest to
>    them.
>    Probably the easiest method to implement publicly-readable lists is
>    to make them read-only aliases for private or anonymous lists.  This
>    would allow the list originators to control the contents of the list
>    as normal, but also allow anyone to view the results in the
>    Datatracker and/or subscribe to notifications.  There may be other
>    methods that would also make sense, and this section might change in
>    the future.
>    Publicly-readable lists should have short URLs that can be
>    transcribed without relying on copy-and-paste.  The names in the URLs
>    for lists that are associated with IETF activities (initially, the
>    lists created by WG chairs and ADs) can be mnemonic, but other public
>    lists should have names that are not mnemonic in order to prevent
>    name-squatting.
>    It is important to note that publicly-readable lists can only be
>    changed by the owners.  Allowing many people to change the contents
>    of a list would probably lead to lists that are not very useful to
>    typical users.
>    Proposed later requirements include having the Datatracker list all
>    of the publicly-readable lists (or certainly at least the ones
>    associated with IETF activities), and having links from WG pages in
>    Datatracker to the publicly-readable lists maintained by the WG
>    chairs.
> _______________________________________________
> datatracker-rqmts mailing list