MozillaWiki

Calendar:ITIP and iMIP Support: Difference between revisions

Calendar Discussion

Calendar:ITIP and iMIP Support (view source)

Revision as of 21:28, 22 March 2006

430 bytes added ,  22 March 2006
→‎New Presentation Phase
No edit summary
Line 29: Line 29:
=== New Presentation Phase ===
=== New Presentation Phase ===
The user receives and opens an iMIP compliant, text/calendar content type MIME encoded message through email. iMIP messages include the iTIP method specification as an extra parameter on the content-type. For example, a message containing a meeting request will specify:
The user receives and opens an iMIP compliant, text/calendar content type MIME encoded message through email. iMIP messages include the iTIP method specification as an extra parameter on the content-type. For example, a message containing a meeting request will specify:
“Content-Type:text/calendar; method=request;�? as its content type.
“Content-Type:text/calendar; method=request;�? as its content type.


If this method is present, then iMIP defines several security and anti-spoofing features that we should adhere to. These items are relatively simple items such as ensuring that the sender of the message matches the sender as specified in the iTIP portion of the message, that the method matches etc. I believe that we will not need to do true iCAL parsing of the iTIP portion of the message in order to satisfy these security requirements. The MIME parser will call the “GatherLine�? function of nsISimpleMimeConverterStub.cpp for each line of the VCALENDAR file. For security checks, we can watch for lines with properties that we are interested in verifying (such as ORGANIZER), and set a flag for each security check that we clear as we parse the VCALENDAR text.
If this method is present, then iMIP defines several security and anti-spoofing features that we should adhere to. These items are relatively simple items such as ensuring that the sender of the message matches the sender as specified in the iTIP portion of the message, that the method matches etc. I believe that we will not need to do true iCAL parsing of the iTIP portion of the message in order to satisfy these security requirements. The MIME parser will call the “GatherLine�? function of nsISimpleMimeConverterStub.cpp for each line of the VCALENDAR file. For security checks, we can watch for lines with properties that we are interested in verifying (such as ORGANIZER), and set a flag for each security check that we clear as we parse the VCALENDAR text.


Next, in the EndGather function, before the “ConvertToHTML�? function is called on our ltnMimeConverter implementation, we will call a new method on that interface that writes the value of the security flag to the ltnMimeConverter object. Therefore, when ConvertToHTML is called, the ltnMimeConverter will know whether or not the message has passed iMIP security. This is important because the iMIP specification states that if the message does not pass the security checks, it should be  disregarded.  
:Using a different parses for security is a very bad idea. You have to maintain two parsers, which means that it's more likely to have bugs. Thinking "I don't need all the information, I can use a simpler" parser will fail, because the parser will be nearly as complex. You have to taking escaping into account, the place in the document, etc. So: just use the normal parser. --[[User:Mvl|mvl]] 13:28, 22 March 2006 (PST)
 
Next, in the EndGather function, before the “ConvertToHTML�? function is called on our ltnMimeConverter implementation, we will call a new method on that interface that writes the value of the security flag to the ltnMimeConverter object. Therefore, when ConvertToHTML is called, the ltnMimeConverter will know whether or not the message has passed iMIP security. This is important because the iMIP specification states that if the message does not pass the security checks, it should be  disregarded.  


A generalized sequence diagram for this model is as follows:<br>
A generalized sequence diagram for this model is as follows:<br>
[[Image:IMipSecDiag.png|Simplified sequence diagram for iMIP Security Support]]
[[Image:IMipSecDiag.png|Simplified sequence diagram for iMIP Security Support]]


Once the ltnMimeConverter is called, its job is to properly format the raw VCALENDAR data and present that data to the user, allowing the user to choose among appropriate actions in response to the method specified in the iTIP component. For example, the appropriate responses to a “REQUEST�? could be presented to the user as “Accept, Decline, Tentatively Accept, Reschedule�?. (See [[Calendar:iTIP_iMIP_Use_Cases]]). A different iTIP method will have a different set of appropriate actions, and should present a different set of options to the userthe appropriate actions will change.  
Once the ltnMimeConverter is called, its job is to properly format the raw VCALENDAR data and present that data to the user, allowing the user to choose among appropriate actions in response to the method specified in the iTIP component. For example, the appropriate responses to a “REQUEST�? could be presented to the user as “Accept, Decline, Tentatively Accept, Reschedule�?. (See [[Calendar:iTIP_iMIP_Use_Cases]]). A different iTIP method will have a different set of appropriate actions, and should present a different set of options to the userthe appropriate actions will change.  


Due to limitations of an HTML-only display, we wish to consider overriding the normal “message�? display and using a new Lightning XUL window specifically tailored to meeting requests. I envision one XBL/XUL window that would change based on what type of iTIP message it is displaying and the responses that the user may choose from. This window should be similar to the Edit Event window so that it will remain intuitive to users of Lightning, and it should only display as much data is needed. Please refer to [[Calendar:iMIP_XUL_GUI_Design]] for mock-ups and discussions of this UI.
Due to limitations of an HTML-only display, we wish to consider overriding the normal “message�? display and using a new Lightning XUL window specifically tailored to meeting requests. I envision one XBL/XUL window that would change based on what type of iTIP message it is displaying and the responses that the user may choose from. This window should be similar to the Edit Event window so that it will remain intuitive to users of Lightning, and it should only display as much data is needed. Please refer to [[Calendar:iMIP_XUL_GUI_Design]] for mock-ups and discussions of this UI.


In this XUL window (or in a follow-up window), the user must choose:<br><br>
In this XUL window (or in a follow-up window), the user must choose:<br><br>
Line 53: Line 55:
Now, there are some restrictions in the Thunderbird MIME handling model that we would not want to buck. For instance, this XUL window needs to be launched after the MIME handling is completed (otherwise we run the risk of interfering with the connection to the mail server). Therefore, launching the XUL window directly from the ltnMimeConverter may not be the proper place to do it. A better place may be the [http://lxr.mozilla.org/seamonkey/source/mailnews/base/resources/content/mailWindowOverlay.js#2227 mailWindowOverlay.js]::OnMsgLoaded callback. By adding the XUL handling here, we can also edit the UI controls in Thunderbird to ensure that the message displays properly (for instance, marking the message as read after displaying the XUL window, or changing the way the iMIP message is displayed in the thread pane).
Now, there are some restrictions in the Thunderbird MIME handling model that we would not want to buck. For instance, this XUL window needs to be launched after the MIME handling is completed (otherwise we run the risk of interfering with the connection to the mail server). Therefore, launching the XUL window directly from the ltnMimeConverter may not be the proper place to do it. A better place may be the [http://lxr.mozilla.org/seamonkey/source/mailnews/base/resources/content/mailWindowOverlay.js#2227 mailWindowOverlay.js]::OnMsgLoaded callback. By adding the XUL handling here, we can also edit the UI controls in Thunderbird to ensure that the message displays properly (for instance, marking the message as read after displaying the XUL window, or changing the way the iMIP message is displayed in the thread pane).


We should not limit the ability of future Thunderbird clients from implementing their own “text/calendar�? content handling (separate from Lightning). Therefore, in the OnMessageLoaded function, the code will attempt to instantiate a lightning specific XPCOM object that contains the iTIP message and iTIP state which was generated by the ltnMimeConverter.  This XPCOM object will be called calIMIPListSvc. It will contain a list of iTIP information generated by ltnMimeConverter, referenced by the message-ID from the original email message. If the call to instantiate this object fails, then the OnMessageLoaded function will know that Lightning is either not installed or not working, and it will simply continue.
We should not limit the ability of future Thunderbird clients from implementing their own “text/calendar�? content handling (separate from Lightning). Therefore, in the OnMessageLoaded function, the code will attempt to instantiate a lightning specific XPCOM object that contains the iTIP message and iTIP state which was generated by the ltnMimeConverter.  This XPCOM object will be called calIMIPListSvc. It will contain a list of iTIP information generated by ltnMimeConverter, referenced by the message-ID from the original email message. If the call to instantiate this object fails, then the OnMessageLoaded function will know that Lightning is either not installed or not working, and it will simply continue.


The XUL Window will be instantiated from the calIMipListSvc object.
The XUL Window will be instantiated from the calIMipListSvc object.
Mvl
Confirmed users
503

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/22786"