1. Topics Ahead …. What would the WG produce? Charter description of what we do Things we don’t do

2. Deliverables Possible documents 1.Architecture 2.BLAST Protocol 3.Schema describing state & state changes in XML 4.How a client addresses the mailbox in the CPP system mail Store BLAST Protocol Notification Service Event: UnseenMsgs=567 XMPP Server SIP Server same administrative domain CPP SystemClients IMAP?

3. Charter (Big picture before scoping) This WG goal is to allow mail stores to use existing presence systems to announce state changes in the mail store. The group will define a protocol to deliver information from the mail store to a notification server that is a part of one or more presence systems. Additionally the group will define the information that is required for common client operations and provide a naming scheme for each presence protocol so that it is clear how a given mailbox in the mail store is addressed as a resource in the presence systems.

4. Charter (Security Issues) The presence system will authorize the clients to retrieve the data. The notification server is constrained to be in the same administrative domain as the mail store, trusted with the information the mail store sends to it, and that there are no bandwidth limitations between the two.

5. Charter (Consumers) The state is meant for consumption by clients that are automata not humans

6. Charter (Type of state) The information to be delivered in base spec: –Number of messages that are: seen, unseen, and deleted Possible Extensions: –Information about most recent message including: UID, From, To, date, abbreviated subject and possibly abbreviated body –Counts by message type (fax, voicemail, mail) –Information about list of personal mailbox names available –Current quota limit both in number of messages and octets and if current usage is above or below specific thresholds

7. Charter (Filtering) Initially the WG will support filtering on only mailbox name and type of state

8. Charter (named mailbox) Support selectable mailbox names but no support for names that embed a query to create a new virtual mailbox.

9. Charter (Limitations) Did we mention this was –NOT IMAP OVER SIP Does not deliver the full state of the mail store

10. Charter (BLAST Protocol) The protocol from the mail store to the notification server is a simple protocol that simply pushes state from the mail store to notification server. It is assumed that they are in the same trust domain and once the mail store has determined it has connected to the correct notification server, it can send all information with no other authorization and the notification server will deal with authorizations for access to the data. The notification server will assume that all state has been delivered to it and is refreshed within a defined period to keep the mail store and notification server in sync.

11. Questions Do we have any common clue on what we want to do? Do we have people interested in building such a system? Do we have people who will write drafts? Do we have people that will review drafts and participate in meetings? Step 0: Come DOWN on use cases –Check if people will do that set –Check this arch works for that set –Think about the authorization / delegation of blast in the use case