Phase 1

Requirements

• The client needs to be able to publish, fetch, and remove items to/from the server
• Shared item collections map directly to DAV collections on the server; if an item is a member of multiple item collections, it can be published into multiple DAV collections (duplication is acceptable)
• Items have one or more types, a globally unique ID, and named attributes
• Attribute names belong to globally unique namespaces to prevent collision and to uniquely identify their meaning; each namespace represents a group of related attributes
• Attribute values can be literals or references to other items
• Attributes may be of single cardinality, list, or dictionary
• Cosmo will understand the sharing format, and will convert to and from other formats for non-Chandler clients, such as iCalendar
• Read-only or Read-write access needs to be grantable to other clients
• Chandler must be able to convert the sharing format to and from the external information model form
• Conversion between sharing format and EIM form follows an unchanging algorithm -- i.e., if the sharing schema changes, that will not require a programmer modify the sharing format conversion code

<?xml version="1.0" encoding="UTF-8"?>

<items xmlns="http://schemas.osafoundation.org/sharingformat/1"
    xmlns:con="http://schemas.osafoundation.org/pim/contentitem"
    xmlns:cal="http://schemas.osafoundation.org/pim/contentitem/calendar"
    xmlns:tag="http://schemas.osafoundation.org/pim/contentitem/tags"
    xmlns:pho="http://schemas.osafoundation.org/photo"
    xmlns:cta="http://schemas.osafoundation.org/pim/contact" >

    <item primary="True" uuid="1"> <!-- In this example I used simple uuid values for readability, 
             but real uuids will be in RFC 4122 form, e.g. 611fcf54-296e-11db-b36c-bc8a258a92d5 -->

        <kinds>
            <con:Note/>
            <cal:Event/>
        </kinds>

        <con:title>Example note</con:title> <!-- string -->

        <con:body mimetype="text/plain" encoding="utf-8">VG0IGJyb2tlbg==</con:body> <!-- Lob -->

        <pho:photoBody mimetype="image/jpeg">/9j/4AAQSkZJRSAAMAAA==</pho:photoBody> <!-- Lob -->

        <con:createdOn>2006-08-08 9:50:58.432510 US/Pacific</con:createdOn>

        <con:lastModifiedBy><item ref="4"/></con:lastModifiedBy>

        <tag:tags> <!-- ref collection -->
            <list>
                <value><item ref="2"/></value>
                <value><item ref="3"/></value>
            </list>
        </tag:tags>

        <con:foo>
            <list>
                <value>abc</value>
                <value>def</value>
            </list>
        </con:foo>

        <con:bar>
            <dict>
                <value key="red">abc</value>
                <value key="white">def</value>
                <value key="blue">ghi</value>
            </dict>
        </con:bar>

    </item>

    <item uuid="2">
        <kinds>
            <tag:Tag/>
        </kinds>
        <con:title>Work</con:title>
        <con:createdOn>2006-08-08 9:50:58.432510 US/Pacific</con:createdOn>
        <con:lastModifiedBy><item ref="4"/></con:lastModifiedBy>
    </item>

    <item uuid="3">
        <kinds>
            <tag:Tag/>
        </kinds>
        <con:title>Sharing</con:title>
        <con:createdOn>2006-08-08 9:50:58.432510 US/Pacific</con:createdOn>
        <con:lastModifiedBy><item ref="4"/></con:lastModifiedBy>
    </item>

    <item uuid="4">
        <kinds>
            <cta:Contact/>
        </kinds>
        <con:createdOn>2006-08-08 9:50:58.432510 US/Pacific</con:createdOn>
        <cta:emailAddress>morgen@example.com</cta:emailAddress>
        <cta:firstName>Morgen</cta:firstName>
        <cta:lastName>Sagen</cta:lastName>
    </item>

</items>

Phase 2

Requirements

• The client needs to be able to publish, fetch, and remove items to/from the server
• Items have one or more types, a globally unique ID, and named attributes
• Attribute names belong to globally unique namespaces to prevent collision and to uniquely identify their meaning; each namespace represents a group of related attributes
• Attribute values can be literals or references to other items
• Attributes may be of single cardinality, list, or dictionary
• Items can be designated as being members of any number of tags
• Tags are themselves items
• The client needs to be able to specify which principals have access to an item (including read-only, read-write, and free-busy -- only seeing the "when-ness" of an item)
• Items inherit permissions based on the tags they are in
• Permissions can be set directly on items as well
• The user needs to be able to grant or deny access to portions of an item (i.e., the set of related attributes represented by an attribute namespace) in order to:
  • ...keep parts of an item private (reminders, etc.)
  • ...yet allow the same user to access private data via Scooby or other Chandler installs
  • ...allow users to set values on items they don't have write-access to (setting personal reminders on read-only calendars)
• If an item is updated on the server, it is updated throughout the server (as opposed to the problem we have to day where an item is published separately into each collection it's a member of, and updating it in one collection doesn't automatically updated it elsewhere).
• Chandler must be able to convert the sharing format to and from the external information model form
• Conversion between sharing format and EIM form follows an unchanging algorithm -- i.e., if the sharing schema changes, that will not require a programmer modify the sharing format conversion code

Definitions

• Principal: represents a Ticket, an Account, or a Group (where a Group can contain Accounts or other Groups)
• Access Control Entry (ACE): indicates a certain Principal has a given Permission for a given Item
• Access Control List (ACL): a list of ACEs
• Tag: I'm specifically using "tag" as opposed to "collection" so as not to confuse with DAV collections. From what I understand from the Design team, the terms tag and collection are basically interchangeable.

Proposal

• On Cosmo, Items are in a soup, identified by UUID
• There are two types of Permissions: Read-only and Read-write
• There are special items called Tags which contain an ACL
• The Principal who originally PUTs an item to Cosmo is the "owner" and always has full permission to that item regardless of ACLs
• An Item may be "tagged" (associated with existing Tag items) or "untagged" -- actually, what does this mean in terms of the protocol?
• A Principal's access to an Item is determined by iterating all the Tags associated with that Item and examining the ACEs to see if any match that Principal; the most lenient permission wins (Read-write trumps Read-only). However, perhaps not all Tag ACLs are created equal -- if we relax the restriction on who can tag an item (for the purpose of allowing someone to add a read-only item to their own tag/collection) then we need to ignore certain Tags when it comes to ACLs, otherwise someone could give themselves write access to an item simply by tagging it. Perhaps only the item's original owner's tagging of an item matters, or maybe there are two levels of tagging: tagging by those that have write-access to an item are used to determine ACLs whereas tagging by those who only have read-access to an item are ignored when determining ACLs.
• An Item optionally has an ACL which overrides any Tag-related ACLs
• The attributes of an Item fall into two categories: those that are "core" to that Item, and those that are "annotations"; core attributes live in the body of the item's resource, while annotations live in the resource's DAV properties
• A Principal which has Read-only permission to an item may not alter the body of that item's resource, but they may set/remove DAV properties within that Principal's namespace, and they may have some limited tagging ability so they can add a Read-only item to their own tag/collection -- but that shouldn't affect the ACLs of the item.
• A Principal which has Read-write permission to an item may modify the item's resource or delete it, set/remove DAV properties within that Principal's namespace, and add/remove Tags which then affects the item's ACL. (Note: do we need to limit which Tags can be applied to an item? For example, if we have an OSAF tag which designates which items appear on the shared OSAF collection, can anyone who has Read-access to that Tag add an item to it?)
• Tags need to be hierarchical, and when examining an item's Tags for their ACLs, super-Tags must also be examined.

-- MorgenSagen - 31 Jul 2006