Imported from previous forum
[ original email was from Roseate L. Wagner - roseate@exchange.ml.com ]
Hi,
Can blank be considered as a valid value for a fix tag?
Eg. if someone sending tagn= ^A with blanks as the value of tags, should it be allowed or be rejected?
Please kindly advise.
Regards,
Roseate
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> Hi,
> Can blank be considered as a valid value for a fix tag?
>
> Eg. if someone sending tagn= ^A with blanks as the value of tags, should it be allowed or be rejected?
While tag=[SOH] is strictly prohibited, I can’t think of anything offhand that explicitly prohibts tag=[variable number of spaces][SOH].
Still, I wonder why anyone would want to send it. Even though the FIX spec might not specifically prohibit it, some firms might be more restrictive and reject it anyway. (Just think of the support nightmare that could happen: “No, I’m talking about the ClOrdID that is 36 spaces, that ClOrdID is 37 spaces!”)
[ original email was from Jiryih Tsaur - jiryih.tsaur@us.cibc.com ]
> > Hi,
> > Can blank be considered as a valid value for a fix tag?
> >
> > Eg. if someone sending tagn= ^A with blanks as the value of tags, should it be allowed or be rejected?
>
> While tag=[SOH] is strictly prohibited, I can’t think of anything offhand that explicitly prohibts tag=[variable number of spaces][SOH].
>
> Still, I wonder why anyone would want to send it. Even though the FIX spec might not specifically prohibit it, some firms might be more restrictive and reject it anyway. (Just think of the support nightmare that could happen: “No, I’m talking about the ClOrdID that is 36 spaces, that ClOrdID is 37 spaces!”)
>
>
A tag without a value gives no information and should not be sent. I would reject it as recommended in FIX 4.3 specification volume 1 Introduction, FIX PROTOCOL SYNTAX, FIX “Tag=Value” SYNTAX,
"A Reject message is the appropriate response to a tag with no value."
Jiryih Tsaur
[ original email was from John Prewett - jprewett@lavatrading.com ]
> A tag without a value gives no information and should not be sent. I would reject it as recommended in FIX 4.3 specification volume 1 Introduction, FIX PROTOCOL SYNTAX, FIX “Tag=Value” SYNTAX,
>
> "A Reject message is the appropriate response to a tag with no value."
>
> Jiryih Tsaur
>
Maybe you would reject it and that’s your right. Unfortunately, “tag=<space><soh>” has a value (a single space) and therefore you shouldn’t reject it.
The point that Ryan is making is that "tag=<one or more spaces><soh>" is perfectly valid syntax according to all the recent FIX standards. A value of one or more spaces is still a valid value.
Even more importantly, a single space could most certainly be considered a useful value for tag 58 in a message of type EMail (MsgType=C) or News (MsgType=B).
Email or News messages can contain multiple occurrences of tag 58.
If you wanted to put a blank line in the middle of your email for formatting purposes, one way of doing it would be to have a field of "58=<space><soh>".
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> Even more importantly, a single space could most certainly be considered a useful value for tag 58 in a message of type EMail (MsgType=C) or News (MsgType=B).
> Email or News messages can contain multiple occurrences of tag 58.
> If you wanted to put a blank line in the middle of your email for formatting purposes, one way of doing it would be to have a field of "58=<space><soh>".
In this (very) limited case, I can see an argument in favor of this practice.
What I’m concerned about, though, is firms using it as a way of getting around the required/conditionally required field rules. I.e. if someone sends an order with ClOrdID=[SPACE][SOH], they are technically within their rights, however I question their sanity. 
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> "A Reject message is the appropriate response to a tag with no value."
I would think that a tag with no value would be the Tag=[SOH] case, and that is clearly non-compliant. But in the example given, the data is one or more spaces, which I consider a value. (Now whether it’s a MEANINGFUL value is another matter entirely.)
FIX doesn’t really do anything to define the character set with the exception of making [SOH] off limits for non-binary fields. Technically, even Tag=[NULL][SOH] would be compliant, although I’d guess that if a firm were to stick a NULL in a field, it may cause some engines to break or consider the entire message invalid. Even if the message is accepted, I’d think that there is a good chance the field might end up being truncated.
Now there’s the issue of what’s compliant and what makes sense. Sending a field containing one or more spaces might comply with the letter of the law, but I can’t think of any good reason to do it. It seems like a way to sneak around the field requirements imposed by the spec. So in that case, I can hardly fault a firm for rejecting it.
[ original email was from Leigh Thompson - lthompson@sfe.com.au ]
> > “A Reject message is the appropriate response to a tag with no value.”
>
> I would think that a tag with no value would be the Tag=[SOH] case, and that is clearly non-compliant. But in the example given, the data is one or more spaces, which I consider a value. (Now whether it’s a MEANINGFUL value is another matter entirely.)
>
> FIX doesn’t really do anything to define the character set with the exception of making [SOH] off limits for non-binary fields. Technically, even Tag=[NULL][SOH] would be compliant, although I’d guess that if a firm were to stick a NULL in a field, it may cause some engines to break or consider the entire message invalid. Even if the message is accepted, I’d think that there is a good chance the field might end up being truncated.
>
> Now there’s the issue of what’s compliant and what makes sense. Sending a field containing one or more spaces might comply with the letter of the law, but I can’t think of any good reason to do it. It seems like a way to sneak around the field requirements imposed by the spec. So in that case, I can hardly fault a firm for rejecting it.
>
To help this discussion with a real world example, (and a good reason) the SFE has recently implemented further customisation of its already customised FIX 4.0 specification.
After market consultation SFE has enhanced the functionality on its trading platform to increase the Participant anonymity available pre and post trade execution.
Specifically, at a FIX level this meant replacement of firm mnemonics (previously defined as a 3 character code e.g UBS) with 3 space characters. Using our customised FIX specification as an example, the following tags have been set to 3 space chars to provide anonymity.
<5052> labelled as QuoteFirm.
<5031> labelled as LastBuyer
<5032> labelled as LastSeller.
<5043> labelled as AskFirm
<5046> labelled as BidFirm
The utilisation of the 3 space characters was deemed the best possible solution for the replacement of the firm mnemonic, without having a large programming/testing effort required to alter the trading system.
Obviously vendors may have have problems handling the 3 space characters depending upon their FIX engine and backend, however our testing indicated few if any problems.
I’d certainly be interested to hear of any vendors or institutions that have had problems relating to use of the space character as the value for a tag.
regards