[Design] Re: [Please review] Updates to Stamping, aka Edit/Update Spec

[Brian Kirsch]

Hi Mimi,
> 1. If Sender of the message (Send as: byline field) is not the same  
> as the From: field, then the message requires an EIML attachment.
>

This concerns me. Although from a technical standpoint this is doable  
I am worried that users will not
understand that the from has to be different to start a Edit / Update  
work-flow.

Does anyone else think this might be confusing?

-Brian

On Feb 15, 2007, at 9:44 PM, Mimi Yin wrote:

>
> On Feb 14, 2007, at 6:02 PM, Brian Kirsch wrote:
>
>> Hi Mimi,
>> I reviewed the spec and there is a lot of detail on how the  
>> stamping UI and Content model interact for the Edit / Update work- 
>> flows. These look really good.
>>
>> I would like to clean up the section regarding the sending and  
>> receiving of items via email.
>
>> First, there is no mention of EIM records. These are now the  
>> transport mechanism for Chandler data in mail messages and are  
>> very important.
>
> Yes, I was hoping to capture that in the Email spec after talking  
> more with you and others. It wasn't clear to my from my notes,  
> exactly how this would work. I will incorporate the stuff below  
> into the Email spec?
>
>>
>> Every mail sent from Chandler must by definition have an EIML  
>> attachment that represents the item otherwise there would be no  
>> way to trigger the edit / update workflow.
>>
>> It is the same notion as every mailed Event including an .ics  
>> attachment.
>>
>> Speaking of .ics, for the Edit / Update work-flows there is no  
>> need for .ics files.
>>
>> Chandler still send .ics attachments with messages that are  
>> stamped as an Event. But the .ics attachments are useful only for  
>> other clients (ICal) and not for Chandler. Everything will be  
>> based of the EIML records.
>>
>
> Yes. In the Edit/Update workflows though, I wanted to show how  
> sending and updating from Chandler will work with both Chandler and  
> non-Chandler users.
>
>> A Chandler to Chandler communication (Chandler Headers) will never  
>> utilize the .ics file since the EIML attachment in the message  
>> takes precedence.
>
> Okay, I can clarify that in the spec.
>
>>
>> The only time a .ics file would be processed is if the mail  
>> message did not contain an EIML attachment. Which by definition  
>> means it was not sent from a Chandler client.
>
> Yup
>
>>
>> Just to clarify, every user participating in an Edit / Update will  
>> receive an email containing some text representing the workflow  
>> even the sender.
>>
>> Chandler will ignore any messages sent from itself i.e. it won't  
>> try to parse the EIML information. The message is meant as a  
>> notification in the users email client.
>
> Yes, I believe that's in there.
>
>>
>> Since for Preview, we will have only three stamping types I would  
>> like more detail on exactly what the user should see in the body  
>> of a mail message sent from Chandler and viewed in his or her  
>> email client.
>
> I believe there is a pass at this in the Email spec, but I will  
> revisit that to make sure it is still up to date. Roughly, it  
> should be something like this:
>
> POSSIBLE KIND-COMBINATIONS:
> + Message
> + Task
> + Event
> + Recurring Event
> + All-day Event
> + Recurring All-day Event
>
> ===
> xxx sent you a <KIND> from Chandler at xxx:
>
> From:
> To:
> CC:
>
> <TITLE> at <Location> from/on <DATE/TIME> <OPTIONAL TIME ZONE>  
> until <OPTIONAL RECURRENCE END-DATE>
>
> <NOTES>
>
> ===
>
> Language for recurring events:
> Daily: Every day from xxx to yyy.
> Weekly: Tuesdays from xxx to yyy.
> Biweekly: Every other Tuesday from xxx to yyy.
> Monthly: Every month on the 17th from xxx to yyy.
>
>>
>> As we currently do with events some attempt should be made to  
>> bottle up the attribute info in to a textual representation.
>
> Yup.
>
>>
>> The spec mentions taking additional attributes and placing them in  
>> the body of the message.
>>
>> Which attributes would this be for a Task Stamp? A Communication  
>> Stamp? etc.
>
>>
>> Also the mail message body and the Chandler note body are now  
>> complete separate entities in an Edit / Update workflow. Which  
>> gives us much more flexibility.
>
> Great, I will keep that in mind and spec out both what appears in  
> the Chandler body and what appears in the Message body.
>
>>
>> The EIML will contain the body text of the item intended to be  
>> viewed in Chandler. The mail message body will contain information  
>> intended to be viewed in another mail.
>>
>> The spec mentions an Edit / Update workflow around an Event  
>> invitation. An Edit / Update workflow can occur on any Item in  
>> Chandler regardless of stamping. I.e. as long as the item is  
>> sendable (has a communication stamp) then it can participate. Is  
>> this correct?
>
> Yes.
>
>>
>>
>> Overall, I think the spec looks really good.
>>
>> The open issues are:
>> 1. What type of messages get a EIML attachment (stamped as task,  
>> event, etc)?
>
> I think every kind of item could potentially get an EIML  
> attachment. Even plain messages have an extra Chandler 'alarm'  
> field that is non-standard. Also, there are all those funky  
> Addressing fields stuff where the From field isn't necessarily the  
> Sender, etc...
>
>> 2. Is there a way to prevent having to attach EIML to every  
>> message sent from Chandler?
>
> Can we figure out when/if the Addressing fields are non-standard  
> and only attach EIML in those cases? Okay, so I think the criteria  
> are:
>
>
> Also, I need to note that:
> BCC, Triage status, Alarms and Event status are never sent out in  
> the EIML attachment. If users are sharing those attributes in a  
> shared collection, we will just let the sharing sync update those  
> attributes. Email messages and subsequent Updates will never send  
> out those attributes, because we can't tell if the email recipients  
> are sharees.
>
>>
>>
>>
>> If we can flush out these last mail related details we should be  
>> good to go :)
>>
>> -Brian
>
>