Imported from previous forum
Hi,
I am working on the email messages on my component for CBOEDirect ( FIX 4.2 ). There is not much information regarding the EmailThreadID other than it is a unique string. Here are my questiones:
- How long it could be, any specific format?
- Who is responsible for assigning it if is a new thread? I asumme whoever initiate the new thread will take the responsibility. That makes Exchange assigns its and firms assign theirs. How do we make sure these two set of emailThreadID unique? or am I on the wrong track.
Thanks in advance.
Yulei Zhang
MCSD, PH.D.
MicroHedge, Inc.
(312)577-6151
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> 1. How long it could be, any specific format?
As with pretty much all string ID fields in FIX (ClOrdID, OrderID, etc.), there are no specified maximum limits, nor are their formats.
> 2. Who is responsible for assigning it if is a new thread? I asumme whoever initiate the new thread will take the responsibility. That makes Exchange assigns its and firms assign theirs. How do we make sure these two set of emailThreadID unique? or am I on the wrong track.
I don’t have specific knowledge of this message, but I’d imagine that uniqueness isn’t needed. On the contrary, it seems the useful purpose of the field is to group related E-mail messages together. I.e. Party A sends Party B an email with EmailThreadID=123. B replies to the E-mail, and also sets EmailThreadUD=123. A replies to B, and sets EmailThreadID=123 as well. The mail reading client could then, for a given message, extract its thread ID and pull up a chain of all messages relating to it.
ID collisions only happen when both parties wish to start a new thread with the same ID. This can be virtually eliminated by adding some distinctive text identifying your firm to the thread IDs you generate. I.e. the parties in question can send "A123" and "B123" and they are viewed as different threads.
Even if there were such a collision, I don’t know if the severity would be much cause for alarm. It just means that when trying to pull up all messages relating to a thread, more unrelated messages show up in the query.
I haven’t heard of much use of the FIX E-mail message, much less more complex aspects like threading. Is it in widespread use?
CBOEDirect states in their document ( ver 2.0b, vol. 3b, p1 ) that all users are required to be able to receive and response email from CBOE help desk and trading op staff. I called and have not get answer back yet.
Thanks for answer my questions.
> > 1. How long it could be, any specific format?
>
> As with pretty much all string ID fields in FIX (ClOrdID, OrderID, etc.), there are no specified maximum limits, nor are their formats.
>
> > 2. Who is responsible for assigning it if is a new thread? I asumme whoever initiate the new thread will take the responsibility. That makes Exchange assigns its and firms assign theirs. How do we make sure these two set of emailThreadID unique? or am I on the wrong track.
>
> I don’t have specific knowledge of this message, but I’d imagine that uniqueness isn’t needed. On the contrary, it seems the useful purpose of the field is to group related E-mail messages together. I.e. Party A sends Party B an email with EmailThreadID=123. B replies to the E-mail, and also sets EmailThreadUD=123. A replies to B, and sets EmailThreadID=123 as well. The mail reading client could then, for a given message, extract its thread ID and pull up a chain of all messages relating to it.
>
> ID collisions only happen when both parties wish to start a new thread with the same ID. This can be virtually eliminated by adding some distinctive text identifying your firm to the thread IDs you generate. I.e. the parties in question can send “A123” and “B123” and they are viewed as different threads.
>
> Even if there were such a collision, I don’t know if the severity would be much cause for alarm. It just means that when trying to pull up all messages relating to a thread, more unrelated messages show up in the query.
>
> I haven’t heard of much use of the FIX E-mail message, much less more complex aspects like threading. Is it in widespread use?
>