[This message was posted by Hanno Klein of Deutsche Börse Systems <hanno.kl...@deutsche-boerse.com> to the "General Q/A" discussion forum at http://fixprotocol.org/discuss/22. You can reply to it on-line at http://fixprotocol.org/discuss/read/e010bd56 - PLEASE DO NOT REPLY BY MAIL.]
Not sure if I understand the exact issue(s) you are addressing. The proposal defines a component block and proposes an extension of the User Response message to include this block. I do not see a reason why the block cannot be re-used as-is for other messages. The message-specific criteria are part of the new component and they are optional. You can have more than one throttle and some could be specific to message types and others not. Messages sent by an order submitter can only use ThrottleInst and would not justify a component. Messages received by the order submitter have three fields which could be put into a component. However, this would create an asymmetry between request and response. At this point I would rather wait, especially since components only affect a FIXML syntax. The approach to put Throttle-Inst/Status/CountIndicator into the body and not the header has its drawbacks in general but I support the proposal as it stands now. We add them to the current messages but every new set of request/response messages should have them and one might forget to add them if the firm submitting the proposal does not need throttling. > > The public comment period ends on April 2, 2010. > > Here are a couple of additional thoughts regarding this: > > Considering the initial proposal, it seems that there should really be > two component blocks introduced - one for session-establishment, and one > for message-specific criteria, right? > > The way the proposal reads right now, there's one discreet component > block which is used for session-establishment, but then it goes on to > mention specific modifications to invidual messages. Wouldn't it make > more sense to introduce a second component block for the throttle > criteria/hints being incorporated into those messages? According to the > proposal, almost all of the message modification involve adding the same > field (or fields) to individual messages, so would it make more sense to > incorporate those fields into a separate component block and then apply > that component block to those messages instead? > > Thanks, > > Russ [You can unsubscribe from this discussion group by sending a message to mailto:unsubscribe+100932...@fixprotocol.org] -- You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to fix-proto...@googlegroups.com. To unsubscribe from this group, send email to fix-protocol+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/fix-protocol?hl=en.
