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

Henrik Levkowetz <> Thu, 09 December 2010 09:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 06E473A6AB4 for <>; Thu, 9 Dec 2010 01:55:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.464
X-Spam-Status: No, score=-102.464 tagged_above=-999 required=5 tests=[AWL=-0.091, 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 L2TGiLX2egUS for <>; Thu, 9 Dec 2010 01:55:21 -0800 (PST)
Received: from ( [IPv6:2a01:3f0:0:31:214:22ff:fe21:bb]) by (Postfix) with ESMTP id 651A23A6AA1 for <>; Thu, 9 Dec 2010 01:55:21 -0800 (PST)
Received: from ([2a01:3f0:1:0:21e:c2ff:fe13:7e3e]:55122 by with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <>) id 1PQdEs-0005dW-Eb; Thu, 09 Dec 2010 10:56:40 +0100
Message-ID: <>
Date: Thu, 09 Dec 2010 10:56:38 +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: Jim Schaad <>
References: <p0624081bc9249d506bb8@[]> <> <017901cb9776$a596ce10$f0c46a30$>
In-Reply-To: <017901cb9776$a596ce10$f0c46a30$>
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
Cc:, 'Paul Hoffman' <>
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: Thu, 09 Dec 2010 09:55:23 -0000


On 2010-12-09 08:56 Jim Schaad said:
> Henrik,
> I can definitely understand the desire to say all lists are non-public to
> begin with (and they don't necessarily have good names).  I would like to
> discuss more where you see the complexity as come from the ability to do
> lists of lists.  I can see various problems that you might be looking at,
> but could see different ways of solving the problem which might make things
> easier but still keep some of the flexibility of having nested lists.

It's not that these things can't be solved, it's more a matter of both
specification and implementation (*not* just the implementation) of this
particular feature becoming several times more complex for very little gain.

It's better to start out with something which will handle 90% of the needs
and is simple, and then see which itch is most urgent to scratch once that's
in place.



> Problems that I can see:
> 1.  Looking for loops - This is always a problem and eliminating nesting
> does solve this one.
> 2.  Making included lists "live" - One possible solution to this would be to
> just make the computation of my query (i.e. build up the logic) from the
> current state of the list I included, without actually letting me know or
> doing a dynamic update if the list I include changes.  This makes loop
> detection easier since it is done when I save my query, it allows me to
> build up my query in pieces (which can be useful) and it allows me to look
> at the pieces of my query later which can be nice because a total list which
> sends me updates can be made up of smaller lists that I want to use for the
> html view.   This does mean that changes made to child lists would not be
> reflected up dynamically - although it is possible that the fact it has not
> propagated is send out.
> 3.  The simple act of including a list - If we did a static build of the
> query, this would not be any different from allowing me to build a complex
> OR/AND statement.  If it is a dynamic query builder then yes it does add
> significant complexity.
> 4.  The UI for managing the multitude of lists is complex.  I don't think
> this would be any more complex than the ability to build a decent sized
> query along the order of.  Show me "(All Security area documents in IETF
> Lass call) OR (All PKIX documents) OR (All docs with "SMIME" in the document
> name) OR (all documents written by "Schaad")
> 5.  Dealing with items that appear multiple times is going to have to be
> dealt with if any sort of complex grammar is allowed - so I don't that that
> would be an issue that is solved by eliminating embedded lists.
> Jim
>> -----Original Message-----
>> From: [mailto:datatracker-rqmts-
>>] On Behalf Of Henrik Levkowetz
>> Sent: Wednesday, December 08, 2010 2:26 AM
>> To: Paul Hoffman
>> Cc:
>> Subject: Re: [datatracker-rqmts] Publicly-readable and private/anonymous
> lists
>> 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 list.
>> 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.
>> Regards,
>> 	Henrik
>> 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
>> _______________________________________________
>> datatracker-rqmts mailing list