This is a proposal to meet some of the requirements of ZeroPointFiveCollectionSharingWorkflowsSpec, such that every sharee of a shared collection can see the status and role of the other sharees.

Mimi's current mockups show various sharees with different status and roles (top) and who created and last modified the share, and when.

Sharee types:

• Editor
• Viewer
• Off
• Pending Editor (Editor but greyed-out)
• Pending Viewer (not shown in mockup but would be "Viewer" greyed out)

Other information:

• Created by (shown as 'me')
• Creation timestamp
• Last modified by (shown as 'lori')
• Last-modified timestamp

Editor means that the user has read/write privilege and is actively synchronizing the collection.

Viewer means that the user has read privilege and is actively synchronizing the collection.

Off means that the user has chosen not to synchroninze the collection (and we don't show whether they have read/write permission). We call this "inactive" in the property value.

Pending means that the user was invited to share the collection but has never done so, yet -- the invitation may have been mis-addressed, spam filtered, unseen, deleted or whatever. In this case we do want to show whether they would be editor/viewer as well.

Finally, the mockups also show who created the share and who last updated it, and this proposal shows how we can share that information as well.

The privileges (read and write) need to be enforced by the server, but the rest of the information doesn't need to be enforced, so we model the status information (active/inactive/pending, created by and last-updated-by) as dead properties. In WebDAV terminology, that means that the clients maintain the property data on the server for purposes of coordination, but the property is "dead" because the server doesn't maintain the value of that property in any way.

Status Property Definitions

We can split the status into five properties. All three properties are in the OSAF namespace (TBD). The granularity is so high because it will encourage other clients (non-Chandler clients) to also use these properties -- e.g. it makes the date properties very simple and interoperable.

Overall Issue:: how do we identify other Chandler users? Do we use one ID which we map to other identifiers?

Share Creator property

Name: share-creator Value: User information of some kind Description: This property is created by the creator of the share, the first time the collection is uploaded to the server. This property never needs to be changed after that date. Issues: The display in ZeroPointFiveCollectionSharingWorkflowsSpec only shows the user's name (e.g. "lori"). However, the intent described is that you can mouse over the user's name and get more information about that user. So we probably need a display name and a userid of some kind, if not several userids. Example:

  <share-created-by xmlns="http://www.osafoundation.org"
                    xmlns:D="DAV:">
    <full-name>Lisa Dusseault</full-name>
    <email><D:href>mailto:lisa@osafoundation.org</D:href></email>
    <sharing-account>
      <D:href>http://sharing.osafoundation.org/principals/lisa</D:href>
    </sharing-account>
    <xmpp><D:href>xmpp://lisaDusseault@psg.com</D:href></xmpp>
  </share-created-by>

Share Last Updated By property

Name: share-last-updated-by Value: User information Description: This property is created by the creator of the share, then anybody who changes the information in the share needs to set a new value when they have done so. Example: Probably the same as share-created-by

Share-created property

Name: share-creation-date Value: date Example:

  <share-creation-date xmlns="http://www.osafoundation.org">20040818T10:04</share-creation-date>

Share last updated property

Name: share-updated-date Value: date/time stamp Example: see share-creation-date

Sharee status property

Name: sharing-status Value: XML Description: this needs to contain the active/inactive/pending information, to complement the access control information, for each sharee. The creator of the share initially creates this property and sets everybody to the "pending" status (except the creator themselves). Then, after that, each user's client is responsible for updating their status after synchronizing. Example:

  <sharing-status xmlns="http://www.osafoundation.org"
                  xmlns:D="DAV:">
    <sharee>
      <userid><D:href>http://sharing.osafoundation.org/principals/lisa</D:href></userid>
      <status>active</status>
    </share>
    <sharee>
      <userid><D:href>http://sharing.osafoundation.org/principals/mitch</D:href></userid>
      <status>inactive</status>
    </share>
    <sharee>
      <userid><D:href>http://sharing.osafoundation.org/principals/mimi</D:href></userid>
      <status>pending</status>
    </share>
  </sharing-status>

SUGGESTION: Put active/inactive in one property, and pending/confirmed in another property -- we might as well be closer to Donn's model.

-- LisaDusseault - 28 Oct 2004