EWS Managed API have two properties:ConversaionId and ConversationIndex
What is the difference between them? I guess ConversationId is the the ConversationIndex of the first mail in the conversation which is essentially of 22 bytes, while ConversationIndex is the index of that particular reply in the conversation thread, essentially of 22 bytes + multiples of 5 bytes for each reply in the conversation. Is it like that?
Also ConversationId is accessible only with Exchange Server 2010 onwards. So cant we access ConversationId in the Exchange Server 2007?
Correct, you can't access ConversationId in Exchange 2007.
The ConversationId identifies the conversation. The ConversationIndex represents the message’s position relative to the original message. ConversationId is not the ConversationIndex of the first mail. Here are some sample values I just grabbed off a new message.
<t:ConversationId Id="AAQkADIwM2ZlM2ZlLWMwYjctNDg2Ny04MDU0LTVkMTFmM2IxY2ZjZQAQACkRMjewk3RHldv8l7aTV2s=/>
<t:ConversationIndex>AQHPkWCfKREyN7CTdEeV2/yXtpNXaw==</t:ConversationIndex>
<t:ConversationTopic>test message</t:ConversationTopic>
It should be noted that ConversationId does not appear to be unique per entirely different conversation threads.
Meaning, while you can be assured that two conversations that don't share the same ConversationId are definitely not related, the converse -- that the same ConversationId guarantees the same "email thread" -- as popularly understood (people answering each other in a chain) -- does not appear to be the case.
I have discovered multiple instances of the same ConversationId on the same email Subject (every now and then) even though the cascade is not off the original.
So for example if HR sends out a "Thought of the Day" email freshly each day to a given group X, this may have the same ConversationId even if they are new chains.
This is problematic if one is sorting emails on a website from payroll by, say, "RE: your 401k" and two distinct conversations are conflated.
Related
I am using outlook rest api to interact with my emails. I am storing my emails in a SQL database. The message response object has a filed called ID which according to the documentation is "The unique identifier of the message.". But I can see this id is same for multiple emails.
What is the exact behaviour of Id field??
You need to make sure you're comparing them in a case-sensitive manner. They do not repeat.
#ptwo There are two types of IDs, one of them is called 'ID', which is unique for every email, the other one is conversationID, which can be the same for the emails that are part of the same conversation (Reply, Reply All,...). You should not make ConversationID a primary key in your database table.
Mail user agents usually display threads of Emails by chaining messages together according to the In-Reply-To and References header fields that contain the Message-IDs of other messages. Although a mail usually only replies to one other message, it may be the case that one message answers multiple others. The standard allows multiple entries in both fields. What can I expect when I send an email that References or is In-Reply-To multiple IDs this way?
Is it good practice to do so?
Does it confuse widespread MUAs?
Is there any common ground on how to display such a message in a
threaded view?
The "In-Reply-To:" field will contain the contents of the
"Message-ID:" field of the message to which this one is a reply (the
"parent message"). If there is more than one parent message, then
the "In-Reply-To:" field will contain the contents of all of the
parents' "Message-ID:" fields. If there is no "Message-ID:" field in
any of the parent messages, then the new message will have no "In-
Reply-To:" field.
Technically there COULD be a reason where you would reply to multiple emails and it would be valid to place multiple message ids in the In-Reply-To header. I can’t think of any program that actually supports this. As to MUAs they won’t care the delivery that the MUA cares about is the To, Cc, Bcc headers.
The In-Reply-To header and References header would control how threads are displayed. Not sure if any mail clients would have an issue handling the multiple In-Reply-To headers. 99% of the time there would only be a single message ID in the In-Reply-To header. So it’s feasible mail applications won’t support it. However they would support the additional reference entries. And this shouldn’t pose an issue.
I collect the appointments in an Exchange calendar with a SOAP FindItem call. This returns single events and (custom) occurrences of recurring events.
When processing these I use GetItem to retrieve the ID of the master event for each occurrence (ItemType=citOccurrence). After that is done, I can determine if I still need to store the master event internally (and retrieve all its details), or if I have already done so.
But with many occurrence of the same recurring event (especially with unending ones) in a longer FindItem period, this means having to do a lot of GetItem 'get master' calls to the server (with the 1st one resulting in 'you must store the master' and all the others in 'you already have this master').
I have looked at the properties returned with BaseShape AllProperties and it seems that ConversationId could be a property that I can use to identify occurrences of the same master event. Sample data for test events:
<t:ItemId Id="AAMk[snip]AAEA==" ChangeKey="DwAAABYAAABs2/j8u1jEQJde5BzoAC+PAAC5aMZ/"/>
<t:Subject>Occurrence</t:Subject>
<t:ConversationId Id="AAQkADgyMTc3ZTI4LTU1ZmItNGI5Yy04YzVjLTk2MjFiZjY5ODkyYgAQANxmlGQ/3ahArhg+mv+UJSo="/>
<t:ItemId Id="AAMk[snip]AAEA==" ChangeKey="DwAAABYAAABs2/j8u1jEQJde5BzoAC+PAAC5aMZ/"/>
<t:Subject>Modified occurrence</t:Subject>
<t:ConversationId Id="AAQkADgyMTc3ZTI4LTU1ZmItNGI5Yy04YzVjLTk2MjFiZjY5ODkyYgAQANxmlGQ/3ahArhg+mv+UJSo="/>
<t:ItemId Id="AAMk[snip]RrAAA=" ChangeKey="DwAAABYAAABs2/j8u1jEQJde5BzoAC+PAAC5aMaA"/>
<t:Subject>New single event</t:Subject>
<t:ConversationId Id="AAQkADgyMTc3ZTI4LTU1ZmItNGI5Yy04YzVjLTk2MjFiZjY5ODkyYgAQAMRNQtffkIdFvs73IVVJObM="/>
<t:ItemId Id="AAMk[snip]AAEA==" ChangeKey="DwAAABYAAABs2/j8u1jEQJde5BzoAC+PAAC5aMZ/"/>
<t:Subject>Occurrence</t:Subject>
<t:ConversationId Id="AAQkADgyMTc3ZTI4LTU1ZmItNGI5Yy04YzVjLTk2MjFiZjY5ODkyYgAQANxmlGQ/3ahArhg+mv+UJSo="/>
<t:ItemId Id="AAMk[snip]RtAAA=" ChangeKey="DwAAABYAAABs2/j8u1jEQJde5BzoAC+PAAC5aMaG"/>
<t:Subject>Meeting</t:Subject>
<t:ConversationId Id="AAQkADgyMTc3ZTI4LTU1ZmItNGI5Yy04YzVjLTk2MjFiZjY5ODkyYgAQAOZVB7gVSTJCtmZMMcXVBfQ="/>
Question: Is ConversationId a reliable property to use for this?
Notes:
From reading around I get the impression that is primarily used for messages, not appointments.
There is a similar question here but that does not definitively answer mine.
Also, there are some issues retrieving ConversationId under Exchange 2007, but they seem solvable.
(Edited to add) A quick test shows that ConversationID, UID, and even InstanceIndex are all candidates. Which is the 'definitive' one?
Try iCalUID (I think that is the property, but I could be off a little). If you have a multi-room meeting, the UID will be the same for appointments in both rooms. I've not checked in some time, but I believe it will also be the same for instances of the same master.
I have recently been working with javamail. Right now, I am trying to store all mails in a file. For such a thing, one would need a unique ID, so I assumend UID would fit best here. However, I noticed something odd: A mail in the "Inbox" Folder with the subject "Hello" has the UID 10. If I fetched the same message from the "All Messages" folder, I'd get the same Message(because I am in "All Messages") with the same content, but with a different UID.
This isn't actually that much of a problem, however, is it possible that two completely different mails from different folders might have the same UID? In this case, I would have to overthink the way i store mails.
Thanks in advance.
The UIDs are not JavaMail UIDs, they're IMAP UIDs, defined by the IMAP RFC.
The UIDs are unique per-folder, based on the UIDVALIDITY value for the folder. There is no unique ID for the folder itself.
Depending on your needs, you might consider using the Message-ID for the message, although note that while it's very, very likely to be unique, there's no guarantee that it is unique, and there's no guarantee that it exists for every message.
I want to implement a simple conversation feature, where each conversation has a set of messages between two users. My question is, if I have a reference from a message to a conversation, whether I should have a reference the other way as well.
Right now, each message has conversationId. To retrieve all the messages the belong to a certain conversation, I should do Message.find({conversationId: ..}). If I had stored an array of messages in a conversation object, I could do conversation.messages.
Which way is the convention?
It all depends on usage patterns. First, you normalize: 1 conversation has many messages, 1 message belongs to 1 conversation. That means you've got a 1-to-many (1:M) relationship between conversations and messages.
In a 1:M relationship, the SQL standard is to assign the "1" as a foreign key to each of the "M". So, each message would have the conversationId.
In Mongo, you have the option of doing the opposite via arrays. Like you said, you could store an array of messageIds in the conversation. This gets pretty messy because for every new message, you have to edit the conversation doc. You're essentially doubling your writes to the DB & keeping the 2 writes in sync is completely on you (e.g. what if the user deletes a message & it's not deleted from the conversation?).
In Mongo, you also have to consider the difference between 1:M and 1:F (1-to-few). Many times, it's advantageous to nest 1:F relationships, ie make the "F" a subdoc of the "1". There is a limit: each doc cannot exceed 16MB (this may lift in future versions). The advantage of nesting subdocs is you have atomic transactions because it's all the same doc, not to mention subscriptions in a pub/sub are easier. This may work, but if you've got a group-chat with 20 friends that's been going on for the last 4 years, you might have to get clever (cap it, start a new conversation, etc.)
Nesting would be my recommendation, although your origin idea of assigning a conversationId to each message works too (make sure to index!).