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

["Jim Schaad" <[e-mail]>]

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.

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: [e-mail] [mailto:datatracker-rqmts-
> [e-mail]] On Behalf Of Henrik Levkowetz
> Sent: Wednesday, December 08, 2010 2:26 AM
> To: Paul Hoffman
> Cc: [e-mail]
> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/datatracker-rqmts
> >
> _______________________________________________
> datatracker-rqmts mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/datatracker-rqmts