Imported from previous forum
[ original email was from helland - ehelland@mfi.com ]
I was told that it is easier to establish standards through FIX than through Swift. could someone educate me on this process?
[ original email was from Yevgeniy Tovshteyn - yevgeniy@javtech.com ]
tag numbers from 5000 to 9999 are user defined fields and could be used for the custom purposes that are not covered with standard FIX protocol. If they become popular, they might be introduced in the new version of FIX protocol as standard. This is the fate of many fields in the FIX protocol - they first were user defined.
> I was told that it is easier to establish standards through FIX than through Swift. could someone educate me on this process?
>
There is more to the process than use of user defined fields (something we actually discourage and rather try to satisfy as many of those needs in new releases of the protocol as are beneficial to all).
Suggestions/requests for changes to the protocol are brought forward to the FIX Technical Committee for consideration. The majority of those requests originate from these FIX website discussion pages and undergo public review, comment, and discussion. The Technical Committee reviews and votes on each proposed change for a new version of the protocol. The net result of the approved changes serve as the basis for the first draft of the next release of the specification. This draft is publicly announced to registered members of this website and the press. The first draft is available to anyone and undergoes a public review period (3-5 weeks). The Technical Committee is then responsible for reviewing and voting on proposed changes or issues which have been brought forth relative to that draft release. The net result of this forms the second draft release which is also publicly announced and available for a similar period of time. At the end of the second draft period, the protocol is generally closed to additions. The Technical Committee is responsible for reviewing and incorporating the feedback from that draft release into a final draft. The final draft primarily serves the purpose of validating syntax, spelling, and consistency. The final draft is generally only available for a week and then the protocol version is officially released.
A lot of work goes on behind the scenes and many of the major functional changes (i.e. adding support for a new asset classes, adding better support for the needs sending orders to exchanges, etc) are worked on via Working Groups with direction from the Technical Committee. The Technical Committte receives its direction from the Global Steering Committee.
There is definitely a process associated establishing new releases of the protocol. I am not that familiar with the Swift process. We feel that the process for FIX is open, public, and receives a significant amount of review by the industry participants who actually implement FIX.
> tag numbers from 5000 to 9999 are user defined fields and could be used for the custom purposes that are not covered with standard FIX protocol. If they become popular, they might be introduced in the new version of FIX protocol as standard. This is the fate of many fields in the FIX protocol - they first were user defined.
>
>
> > I was told that it is easier to establish standards through FIX than through Swift. could someone educate me on this process?
> >
>
I would be interesting in knowing how to go about proposing new fields. In addition to suggesting them in discussion, how might I "reserve" some tag numbers for those I would propose?
> There is more to the process than use of user defined fields (something we actually discourage and rather try to satisfy as many of those needs in new releases of the protocol as are beneficial to all).
>
> Suggestions/requests for changes to the protocol are brought forward to the FIX Technical Committee for consideration. The majority of those requests originate from these FIX website discussion pages and undergo public review, comment, and discussion. The Technical Committee reviews and votes on each proposed change for a new version of the protocol. The net result of the approved changes serve as the basis for the first draft of the next release of the specification. This draft is publicly announced to registered members of this website and the press. The first draft is available to anyone and undergoes a public review period (3-5 weeks). The Technical Committee is then responsible for reviewing and voting on proposed changes or issues which have been brought forth relative to that draft release. The net result of this forms the second draft release which is also publicly announced and available for a similar period of time. At the end of the second draft period, the protocol is generally closed to additions. The Technical Committee is responsible for reviewing and incorporating the feedback from that draft release into a final draft. The final draft primarily serves the purpose of validating syntax, spelling, and consistency. The final draft is generally only available for a week and then the protocol version is officially released.
>
> A lot of work goes on behind the scenes and many of the major functional changes (i.e. adding support for a new asset classes, adding better support for the needs sending orders to exchanges, etc) are worked on via Working Groups with direction from the Technical Committee. The Technical Committte receives its direction from the Global Steering Committee.
>
> There is definitely a process associated establishing new releases of the protocol. I am not that familiar with the Swift process. We feel that the process for FIX is open, public, and receives a significant amount of review by the industry participants who actually implement FIX.
>
>
>
> > tag numbers from 5000 to 9999 are user defined fields and could be used for the custom purposes that are not covered with standard FIX protocol. If they become popular, they might be introduced in the new version of FIX protocol as standard. This is the fate of many fields in the FIX protocol - they first were user defined.
> >
> >
> > > I was told that it is easier to establish standards through FIX than through Swift. could someone educate me on this process?
> > >
> >
>
The Technical Committee has established a document in which we will be tracking proposed changes. The website is a great way to propose a simple change. If you propose a change we can have the Technical Committee review it. If the proposed change involves a series of fields, new messages, etc. then it is best to draft a document which summarizes the what, how, and why type issues. Some proposed changes will likely involve a working group to flush out the issues. For new fields that the Technical Committee has agreed will be part of the next version of the protocol we can reserve "real" vs. "user defined" tag numbers.
> I would be interesting in knowing how to go about proposing new fields. In addition to suggesting them in discussion, how might I "reserve" some tag numbers for those I would propose?
>
> > There is more to the process than use of user defined fields (something we actually discourage and rather try to satisfy as many of those needs in new releases of the protocol as are beneficial to all).
> >
> > Suggestions/requests for changes to the protocol are brought forward to the FIX Technical Committee for consideration. The majority of those requests originate from these FIX website discussion pages and undergo public review, comment, and discussion. The Technical Committee reviews and votes on each proposed change for a new version of the protocol. The net result of the approved changes serve as the basis for the first draft of the next release of the specification. This draft is publicly announced to registered members of this website and the press. The first draft is available to anyone and undergoes a public review period (3-5 weeks). The Technical Committee is then responsible for reviewing and voting on proposed changes or issues which have been brought forth relative to that draft release. The net result of this forms the second draft release which is also publicly announced and available for a similar period of time. At the end of the second draft period, the protocol is generally closed to additions. The Technical Committee is responsible for reviewing and incorporating the feedback from that draft release into a final draft. The final draft primarily serves the purpose of validating syntax, spelling, and consistency. The final draft is generally only available for a week and then the protocol version is officially released.
> >
> > A lot of work goes on behind the scenes and many of the major functional changes (i.e. adding support for a new asset classes, adding better support for the needs sending orders to exchanges, etc) are worked on via Working Groups with direction from the Technical Committee. The Technical Committte receives its direction from the Global Steering Committee.
> >
> > There is definitely a process associated establishing new releases of the protocol. I am not that familiar with the Swift process. We feel that the process for FIX is open, public, and receives a significant amount of review by the industry participants who actually implement FIX.
> >
> >
> >
> > > tag numbers from 5000 to 9999 are user defined fields and could be used for the custom purposes that are not covered with standard FIX protocol. If they become popular, they might be introduced in the new version of FIX protocol as standard. This is the fate of many fields in the FIX protocol - they first were user defined.
> > >
> > >
> > > > I was told that it is easier to establish standards through FIX than through Swift. could someone educate me on this process?
> > > >
> > >
> >
>