Meeting notes from 23 Feb 2004 Users & Groups design meeting

Attending: AndiVajda, TedLeung, HeikkiToivonen, BrianDouglasSkinner, MitchKapor, ChaoLam

Next meeting:

• at noon on Wednesday, 25 Feb 2004
• rescheduled for Tuesday, 16 March 2004, 2:45 to 4:15
• rescheduled for Monday, 15 March 2004, 1:00 to 2:30 -- see notes

Resolution about Layering:

[Resolution] We should have three distinct layers in content model, like this:

Open Issues about Layering:

• [Action Item] We need to go through the existing content model and think about which kinds belong in the Chandler core. We should refactor the content model and pick a good separation between (a) Chandler core content model and (b) PIM content model.

• [Open Issue] What kinds should be included in the Chandler core? Mitch suggests we consider these kinds:
  • File -- a Chandler item that has an attribute that points to an old-fashioned file in the OS file system, like a spreadsheet file or a MS Word doc
  • Conversation -- a Chandler "Conversation" item, attached to a Content Item
  • Note
  • Contact
  • Mail Message
  • IM

Other Resolutions:

1. [Resolution] In the Users And Groups Design doc, we should use the term "principal" in the place where we had originally used "user".
2. [Resolution] We should have a kind called Principal. A principal represents another Chandler user who you share content with. In the cognitive model of the person using Chandler, a contact and a principal will usually be identical. In the content model, the Principal Kind will have attributes that keep track of some sort of identity or authorization information (maybe in the form of a username and password, or maybe in the form of some sort of certificate or encryption key). A principal item might also have an attribute that points to all the access permissions that I've granted to this principal.
3. [Resolution] Each contact in my address book will typically have at most one associated principal item, although some contacts might have more than one principal item (for example, in my "Sara" contact I might have a "Sara at home" principal and a "Sara at work" principal).
4. [Resolution] There should be a many-to-many relationship between Contacts and Principals
5. [Resolution] The Principal kind should be defined in the Repository layer, as part of the core data model.
6. [Resolution] The Contact kind should not be defined in the Repository layer, as part of the core data model.
7. [Resolution] The Contact kind should be a sub-kind of Content Item.
8. [Resolution] The Principal kind should be a sub-kind of Item, not Content Item.
9. [Resolution] A principal can "contain" sub-principals.

Remaining Open Issues:

1. [Open question] Does a Principal represent "another Chandler user who you share content with", or "a specific repository belonging to another Chandler user who you share content with"? If I want to share my calendar with Chris, and Chris has Chandler installed at home and at work, do I share my calendar with "Chris", or with "Chris at home"? At which level do we associate the access permissions? Do we do automatic sync with one repository or with both? At which level do we keep track of what items need to be refreshed?
2. [Open question] If a Principal item really represents "a specific repository belonging to another Chandler user who you share content with" rather than "another Chandler user who you share content with", then should we use some word other than "Principal"? Maybe something like "Foriegn Repository"?
3. [Open question] In the user's mental model, we have Contacts and Groups. A group can have many contacts in it. A contact cannot have any other contacts in it. In the repository layer we just have Principals, where any principal can have sub-principals. How do we reconcile those two models?
4. [Open question] Should there be a kind called "Group"?
5. [Open question] Is there a 1-to-1 relationship between Group and Principal (each Group is a user-level representation of a repository-level Principal)?
6. [Open question] Can we say that Group will be defined in the same layer at Contact?
7. [Open question] Can we say that Group will be a sub-kind of Content Item?
8. [Open question] Should we have a kind that represents an "access permission"?
9. [Open question] Can an "access permission" be given just for Content Items, or to other types of items as well?
10. [Open question] Should we have a kind that represents an "X.509 Certificate"? Or maybe a Type instead of a Kind?
11. [Open question] Does each Principal have an X.509 Certificate?
12. [Open question] Is there a notion of a "me" Contact? How is that modeled? Is there a notion of a "me" Principal?
13. [Open question] Let's say I have a two computers, one at work and one at home, and each one has it's own copy of Chandler and it's own repository. I can share items between them using normal sharing. Is that sort of sharing just like sharing between any two repositories, or is it somehow different? Do these two repositories "know" that they belong to the same "me" Contact, or the same Principal? Do they automatically transfer Certificate info for the Principals of other people they share with?
14. [Open question] What are the attributes of a Principal?
    • one or both of the following
      • a list of sub-principals of this principal?
      • a super-principal of this principal?
    • a list of access permissions granted to this principal?
    • one but not both of the following:
      • a list of Contacts that this principal is associated with?
      • a single Group that this principal is associated with?
    • a notification queue, which has a list of items (or a list of changes to items) that need to be transmitted to the foriegn repository whenever we can next connect to the foriegn repository
    • a connection address, so that we know how to find the foriegn repository and start a conversation with it (should this really be a list of addresses, some of which might use different routes or transports?)
    • an X.509 Certificate that we got from the Principal, with
      • a "verfied" bit, which is true iff we have exchanged thumbprints to confirm the X.509 Certificate
      • a "trusted" bit, which is true iff the Certificate was created by a CA that we trust
      • a "revoked" bit, which is true iff this Certificate has been revoked or expired
    • a note about which X.509 Certificate we gave to the Principal, with
      • a "verfied" bit, which is true iff we have exchanged thumbprints to confirm the X.509 Certificate
      • a "revoked" bit, which is true iff we have revoked this Certificate
    • a revokation queue, which might have a Certificate in it if we need to revoke our Certificate whenever we can next connect to the foriegn repository
15. [Open question] What are the attributes of a Contact?
    • can we agree that a contact will look like this?
16. [Open question] What are the attributes of a Group?
    • exactly one Principal associated with this Group
    • a list of the sub-Groups in this Group
    • a list of the Contacts in this Group
      • and, for each Contact in the list, we optionally keep track of
        • which phone number within the Contact is the chosen phone number
        • which email address within the Contact is the chosen email address
        • which Principal within the Contact is the chosen Principal
        • which IM address within the Contact is the chosen IM address
        • which Contact Section within the Contact is the chosen Contact Section
17. [Open question] What does a "connection address" or "sharing address" look like? How do we find the foriegn repository and start a conversation with it?

Contributors

• BrianDouglasSkinner - 16 Mar 2004