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

[Henrik Levkowetz <[e-mail]>]

Jim,

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.


Regards,

	Henrik

> 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
> 
>