OASIS Advanced Message Queuing Protocol (AMQP) TC

I doubt that we need filters that can interoperate with everything. I just need a JMS filter that can is understood by JMS providers. OpenMAMA doesn't need to understand that filter and I don't need to understand a SMTP filter. -- Andreas Mueller IIT Software GmbH, Bremen/Germany http://www.swiftmq.com Am 14.02.2012 um 12:44 schrieb Raphael Cohn: > I think we need to start a sub-group, and define a process for filter extensions. Filters are a complex subject, and JMS isn't the only use case they need to support. Even then, a JMS selector needs to have a defined mapping to AMQP concepts. > > In particular, there's a need for more than one 'dialect', particularly so we can interoperate with OpenMAMA, MQTT, SMTP and, preferably, a native AMQP encoding which allows to access the full fidelity of information present in AMQP structured messages. > > Raph > > Raphael Cohn > Chief Architect, StormMQ > Secretary, OASIS AMQP Standard > raphael.cohn@StormMQ.com > StormMQ Limited > > UK Office: > Gateshead int'l Business Centre, Mulgrave Terrace, Gateshead, NE8 1AN, United Kingdom > Telephone: +44 845 3712 567 > > Registered office: > 16 Anchor Street, Chelmsford, Essex, CM2 0JY, United Kingdom > StormMQ Limited is Registered in England and Wales under Company Number 07175657 > StormMQ.com > > > > On 14 February 2012 11:04, Andreas Mueller <am@iit.de> wrote: > > Am 07.02.2012 um 10:32 schrieb Andreas Mueller: > >> Currently I'm using these filter declarations: >> >> <section name="filter-types"> >> <type class="composite" name="no-local-filter" source="list" provides="filter"> >> <descriptor name="amqp:no-local-filter:list" code="0x0000412B:0x00000000"/> >> </type> >> <type class="restricted" name="jms-selector-filter" provides="filter" source="string"> >> <descriptor name="amqp:jms-selector-filter:string" code="0x0000412B:0x00000001"/> >> </type> >> </section> > > Well, I can't continue here until I know from which range I can use to generate descriptor code for the above filters. The current code 0x0000412B is the IANA code for IIT. But it's important that we have a code assigned from AMQP to ensure that all brokers capable of using NoLocal and JMS filters understand the very same filters. > > I suggest we use a range from 200 to 255 for filters so the above no-local-filter would have code 0x00000000:0x000000C8 and the jms-selector-filter code 0x00000000:0x000000C9. > > What do I need to do to get this done? > > -- > Andreas Mueller > IIT Software GmbH, Bremen/Germany > http://www.swiftmq.com > > > > > > IIT Software GmbH > Fahrenheitstr. 1, D28359 Bremen, Germany > Tel: +49 421 2208-166, Fax: +49 421 2208-167 > Amtsgericht Bremen, HRB 18624, Geschaeftsfuehrer: Andreas Mueller > Steuernummer: 71/572/04100, VAT: DE199945912 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: amqp-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: amqp-help@lists.oasis-open.org > > IIT Software GmbH Fahrenheitstr. 1, D28359 Bremen, Germany Tel: +49 421 2208-166, Fax: +49 421 2208-167 Amtsgericht Bremen, HRB 18624, Geschaeftsfuehrer: Andreas Mueller Steuernummer: 71/572/04100, VAT: DE199945912

Yes, but we need to make sure that a decision in haste now doesn't cripple a good standard. And I'd actually argue it'd be far more preferable to have a filtering mechanism that is a superset of the world capable of representing such needs, rather than opaque text strings. A rhetorical questions that springs to mind - are you planning to put in JMS versioning in those filters? There's a lot here. It's an open conversation that's only just started, and can have many conclusions. I'd like to rope in Dave, Rob, and Rafi, too, when we're finished on the CSD, because they've all expressed interesting views here. Raph Raphael Cohn Chief Architect, StormMQ Secretary, OASIS AMQP Standard raphael.cohn@StormMQ.com StormMQ Limited UK Office: Gateshead int'l Business Centre, Mulgrave Terrace, Gateshead, NE8 1AN, United Kingdom Telephone: +44 845 3712 567 Registered office: 16 Anchor Street, Chelmsford, Essex, CM2 0JY, United Kingdom StormMQ Limited is Registered in England and Wales under Company Number 07175657 StormMQ.com On 14 February 2012 12:01, Andreas Mueller < am@iit.de > wrote: I doubt that we need filters that can interoperate with everything. I just need a JMS filter that can is understood by JMS providers. OpenMAMA doesn't need to understand that filter and I don't need to understand a SMTP filter. -- Andreas Mueller IIT Software GmbH, Bremen/Germany http://www.swiftmq.com Am 14.02.2012 um 12:44 schrieb Raphael Cohn: > I think we need to start a sub-group, and define a process for filter extensions. Filters are a complex subject, and JMS isn't the only use case they need to support. Even then, a JMS selector needs to have a defined mapping to AMQP concepts. > > In particular, there's a need for more than one 'dialect', particularly so we can interoperate with OpenMAMA, MQTT, SMTP and, preferably, a native AMQP encoding which allows to access the full fidelity of information present in AMQP structured messages. > > Raph > > Raphael Cohn > Chief Architect, StormMQ > Secretary, OASIS AMQP Standard > raphael.cohn@StormMQ.com > StormMQ Limited > > UK Office: > Gateshead int'l Business Centre, Mulgrave Terrace, Gateshead, NE8 1AN, United Kingdom > Telephone: +44 845 3712 567 > > Registered office: > 16 Anchor Street, Chelmsford, Essex, CM2 0JY, United Kingdom > StormMQ Limited is Registered in England and Wales under Company Number 07175657 > StormMQ.com > > > > On 14 February 2012 11:04, Andreas Mueller < am@iit.de > wrote: > > Am 07.02.2012 um 10:32 schrieb Andreas Mueller: > >> Currently I'm using these filter declarations: >> >> <section name="filter-types"> >>      <type class="composite" name="no-local-filter" source="list" provides="filter"> >>              <descriptor name="amqp:no-local-filter:list" code="0x0000412B:0x00000000"/> >>      </type> >>      <type class="restricted" name="jms-selector-filter" provides="filter" source="string"> >>              <descriptor name="amqp:jms-selector-filter:string" code="0x0000412B:0x00000001"/> >>      </type> >> </section> > > Well, I can't continue here until I know from which range I can use to generate descriptor code for the above filters. The current code 0x0000412B is the IANA code for IIT. But it's important that we have a code assigned from AMQP to ensure that all brokers capable of using NoLocal and JMS filters understand the very same filters. > > I suggest we use a range from 200 to 255 for filters so the above no-local-filter would have code 0x00000000:0x000000C8 and the jms-selector-filter code  0x00000000:0x000000C9. > > What do I need to do to get this done? > > -- > Andreas Mueller > IIT Software GmbH, Bremen/Germany > http://www.swiftmq.com > > > > > > IIT Software GmbH > Fahrenheitstr. 1, D28359 Bremen, Germany > Tel: +49 421 2208-166 , Fax: +49 421 2208-167 > Amtsgericht Bremen, HRB 18624, Geschaeftsfuehrer: Andreas Mueller > Steuernummer: 71/572/04100 , VAT: DE199945912 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: amqp-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: amqp-help@lists.oasis-open.org > > IIT Software GmbH Fahrenheitstr. 1, D28359 Bremen, Germany Tel: +49 421 2208-166 , Fax: +49 421 2208-167 Amtsgericht Bremen, HRB 18624, Geschaeftsfuehrer: Andreas Mueller Steuernummer: 71/572/04100 , VAT: DE199945912 --------------------------------------------------------------------- To unsubscribe, e-mail: amqp-unsubscribe@lists.oasis-open.org For additional commands, e-mail: amqp-help@lists.oasis-open.org

I would prefer to have exactly such a provider-dependend opaque filter that could be a JMS selector, regex whatever. AMQP does not need to define the syntax/semantics of the filter. It just needs to provide a way to pass a filter to the broker. -- Andreas Mueller IIT Software GmbH, Bremen/Germany http://www.swiftmq.com Am 14.02.2012 um 13:02 schrieb Raphael Cohn: > Yes, but we need to make sure that a decision in haste now doesn't cripple a good standard. And I'd actually argue it'd be far more preferable to have a filtering mechanism that is a superset of the world capable of representing such needs, rather than opaque text strings. A rhetorical questions that springs to mind - are you planning to put in JMS versioning in those filters? There's a lot here. > > It's an open conversation that's only just started, and can have many conclusions. I'd like to rope in Dave, Rob, and Rafi, too, when we're finished on the CSD, because they've all expressed interesting views here. > > Raph > > Raphael Cohn > Chief Architect, StormMQ > Secretary, OASIS AMQP Standard > raphael.cohn@StormMQ.com > StormMQ Limited > > UK Office: > Gateshead int'l Business Centre, Mulgrave Terrace, Gateshead, NE8 1AN, United Kingdom > Telephone: +44 845 3712 567 > > Registered office: > 16 Anchor Street, Chelmsford, Essex, CM2 0JY, United Kingdom > StormMQ Limited is Registered in England and Wales under Company Number 07175657 > StormMQ.com > > > > On 14 February 2012 12:01, Andreas Mueller <am@iit.de> wrote: > I doubt that we need filters that can interoperate with everything. I just need a JMS filter that can is understood by JMS providers. OpenMAMA doesn't need to understand that filter and I don't need to understand a SMTP filter. > > -- > Andreas Mueller > IIT Software GmbH, Bremen/Germany > http://www.swiftmq.com > > Am 14.02.2012 um 12:44 schrieb Raphael Cohn: > > > I think we need to start a sub-group, and define a process for filter extensions. Filters are a complex subject, and JMS isn't the only use case they need to support. Even then, a JMS selector needs to have a defined mapping to AMQP concepts. > > > > In particular, there's a need for more than one 'dialect', particularly so we can interoperate with OpenMAMA, MQTT, SMTP and, preferably, a native AMQP encoding which allows to access the full fidelity of information present in AMQP structured messages. > > > > Raph > > > > Raphael Cohn > > Chief Architect, StormMQ > > Secretary, OASIS AMQP Standard > > raphael.cohn@StormMQ.com > > StormMQ Limited > > > > UK Office: > > Gateshead int'l Business Centre, Mulgrave Terrace, Gateshead, NE8 1AN, United Kingdom > > Telephone: +44 845 3712 567 > > > > Registered office: > > 16 Anchor Street, Chelmsford, Essex, CM2 0JY, United Kingdom > > StormMQ Limited is Registered in England and Wales under Company Number 07175657 > > StormMQ.com > > > > > > > > On 14 February 2012 11:04, Andreas Mueller <am@iit.de> wrote: > > > > Am 07.02.2012 um 10:32 schrieb Andreas Mueller: > > > >> Currently I'm using these filter declarations: > >> > >> <section name="filter-types"> > >> <type class="composite" name="no-local-filter" source="list" provides="filter"> > >> <descriptor name="amqp:no-local-filter:list" code="0x0000412B:0x00000000"/> > >> </type> > >> <type class="restricted" name="jms-selector-filter" provides="filter" source="string"> > >> <descriptor name="amqp:jms-selector-filter:string" code="0x0000412B:0x00000001"/> > >> </type> > >> </section> > > > > Well, I can't continue here until I know from which range I can use to generate descriptor code for the above filters. The current code 0x0000412B is the IANA code for IIT. But it's important that we have a code assigned from AMQP to ensure that all brokers capable of using NoLocal and JMS filters understand the very same filters. > > > > I suggest we use a range from 200 to 255 for filters so the above no-local-filter would have code 0x00000000:0x000000C8 and the jms-selector-filter code 0x00000000:0x000000C9. > > > > What do I need to do to get this done? > > > > -- > > Andreas Mueller > > IIT Software GmbH, Bremen/Germany > > http://www.swiftmq.com > > > > > > > > > > > > IIT Software GmbH > > Fahrenheitstr. 1, D28359 Bremen, Germany > > Tel: +49 421 2208-166, Fax: +49 421 2208-167 > > Amtsgericht Bremen, HRB 18624, Geschaeftsfuehrer: Andreas Mueller > > Steuernummer: 71/572/04100, VAT: DE199945912 > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: amqp-unsubscribe@lists.oasis-open.org > > For additional commands, e-mail: amqp-help@lists.oasis-open.org > > > > > > > > > > IIT Software GmbH > Fahrenheitstr. 1, D28359 Bremen, Germany > Tel: +49 421 2208-166, Fax: +49 421 2208-167 > Amtsgericht Bremen, HRB 18624, Geschaeftsfuehrer: Andreas Mueller > Steuernummer: 71/572/04100, VAT: DE199945912 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: amqp-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: amqp-help@lists.oasis-open.org > > IIT Software GmbH Fahrenheitstr. 1, D28359 Bremen, Germany Tel: +49 421 2208-166, Fax: +49 421 2208-167 Amtsgericht Bremen, HRB 18624, Geschaeftsfuehrer: Andreas Mueller Steuernummer: 71/572/04100, VAT: DE199945912

There in lies the road to incompatibility, leading from the door of vendor expediency... Raphael Cohn Chief Architect, StormMQ Secretary, OASIS AMQP Standard raphael.cohn@StormMQ.com StormMQ Limited UK Office: Gateshead int'l Business Centre, Mulgrave Terrace, Gateshead, NE8 1AN, United Kingdom Telephone: +44 845 3712 567 Registered office: 16 Anchor Street, Chelmsford, Essex, CM2 0JY, United Kingdom StormMQ Limited is Registered in England and Wales under Company Number 07175657 StormMQ.com On 14 February 2012 12:13, Andreas Mueller < am@iit.de > wrote: I would prefer to have exactly such a provider-dependend opaque filter that could be a JMS selector, regex whatever. AMQP does not need to define the syntax/semantics of the filter. It just needs to provide a way to pass a filter to the broker. -- Andreas Mueller IIT Software GmbH, Bremen/Germany http://www.swiftmq.com Am 14.02.2012 um 13:02 schrieb Raphael Cohn: > Yes, but we need to make sure that a decision in haste now doesn't cripple a good standard. And I'd actually argue it'd be far more preferable to have a filtering mechanism that is a superset of the world capable of representing such needs, rather than opaque text strings. A rhetorical questions that springs to mind - are you planning to put in JMS versioning in those filters? There's a lot here. > > It's an open conversation that's only just started, and can have many conclusions. I'd like to rope in Dave, Rob, and Rafi, too, when we're finished on the CSD, because they've all expressed interesting views here. > > Raph > > Raphael Cohn > Chief Architect, StormMQ > Secretary, OASIS AMQP Standard > raphael.cohn@StormMQ.com > StormMQ Limited > > UK Office: > Gateshead int'l Business Centre, Mulgrave Terrace, Gateshead, NE8 1AN, United Kingdom > Telephone: +44 845 3712 567 > > Registered office: > 16 Anchor Street, Chelmsford, Essex, CM2 0JY, United Kingdom > StormMQ Limited is Registered in England and Wales under Company Number 07175657 > StormMQ.com > > > > On 14 February 2012 12:01, Andreas Mueller < am@iit.de > wrote: > I doubt that we need filters that can interoperate with everything. I just need a JMS filter that can is understood by JMS providers. OpenMAMA doesn't need to understand that filter and I don't need to understand a SMTP filter. > > -- > Andreas Mueller > IIT Software GmbH, Bremen/Germany > http://www.swiftmq.com > > Am 14.02.2012 um 12:44 schrieb Raphael Cohn: > > > I think we need to start a sub-group, and define a process for filter extensions. Filters are a complex subject, and JMS isn't the only use case they need to support. Even then, a JMS selector needs to have a defined mapping to AMQP concepts. > > > > In particular, there's a need for more than one 'dialect', particularly so we can interoperate with OpenMAMA, MQTT, SMTP and, preferably, a native AMQP encoding which allows to access the full fidelity of information present in AMQP structured messages. > > > > Raph > > > > Raphael Cohn > > Chief Architect, StormMQ > > Secretary, OASIS AMQP Standard > > raphael.cohn@StormMQ.com > > StormMQ Limited > > > > UK Office: > > Gateshead int'l Business Centre, Mulgrave Terrace, Gateshead, NE8 1AN, United Kingdom > > Telephone: +44 845 3712 567 > > > > Registered office: > > 16 Anchor Street, Chelmsford, Essex, CM2 0JY, United Kingdom > > StormMQ Limited is Registered in England and Wales under Company Number 07175657 > > StormMQ.com > > > > > > > > On 14 February 2012 11:04, Andreas Mueller < am@iit.de > wrote: > > > > Am 07.02.2012 um 10:32 schrieb Andreas Mueller: > > > >> Currently I'm using these filter declarations: > >> > >> <section name="filter-types"> > >>      <type class="composite" name="no-local-filter" source="list" provides="filter"> > >>              <descriptor name="amqp:no-local-filter:list" code="0x0000412B:0x00000000"/> > >>      </type> > >>      <type class="restricted" name="jms-selector-filter" provides="filter" source="string"> > >>              <descriptor name="amqp:jms-selector-filter:string" code="0x0000412B:0x00000001"/> > >>      </type> > >> </section> > > > > Well, I can't continue here until I know from which range I can use to generate descriptor code for the above filters. The current code 0x0000412B is the IANA code for IIT. But it's important that we have a code assigned from AMQP to ensure that all brokers capable of using NoLocal and JMS filters understand the very same filters. > > > > I suggest we use a range from 200 to 255 for filters so the above no-local-filter would have code 0x00000000:0x000000C8 and the jms-selector-filter code  0x00000000:0x000000C9. > > > > What do I need to do to get this done? > > > > -- > > Andreas Mueller > > IIT Software GmbH, Bremen/Germany > > http://www.swiftmq.com > > > > > > > > > > > > IIT Software GmbH > > Fahrenheitstr. 1, D28359 Bremen, Germany > > Tel: +49 421 2208-166 , Fax: +49 421 2208-167 > > Amtsgericht Bremen, HRB 18624, Geschaeftsfuehrer: Andreas Mueller > > Steuernummer: 71/572/04100 , VAT: DE199945912 > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: amqp-unsubscribe@lists.oasis-open.org > > For additional commands, e-mail: amqp-help@lists.oasis-open.org > > > > > > > > > > IIT Software GmbH > Fahrenheitstr. 1, D28359 Bremen, Germany > Tel: +49 421 2208-166 , Fax: +49 421 2208-167 > Amtsgericht Bremen, HRB 18624, Geschaeftsfuehrer: Andreas Mueller > Steuernummer: 71/572/04100 , VAT: DE199945912 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: amqp-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: amqp-help@lists.oasis-open.org > > IIT Software GmbH Fahrenheitstr. 1, D28359 Bremen, Germany Tel: +49 421 2208-166 , Fax: +49 421 2208-167 Amtsgericht Bremen, HRB 18624, Geschaeftsfuehrer: Andreas Mueller Steuernummer: 71/572/04100 , VAT: DE199945912

Am 14.02.2012 um 13:12 schrieb Raphael Cohn: > There in lies the road to incompatibility, leading from the door of vendor expediency... This lies in any extension / capabilities mechanism. The AMQP spec is complicated enough. We don't need another AMQP monster filter… -- Andreas Mueller IIT Software GmbH, Bremen/Germany http://www.swiftmq.com IIT Software GmbH Fahrenheitstr. 1, D28359 Bremen, Germany Tel: +49 421 2208-166, Fax: +49 421 2208-167 Amtsgericht Bremen, HRB 18624, Geschaeftsfuehrer: Andreas Mueller Steuernummer: 71/572/04100, VAT: DE199945912

I think we want a simple way for implementers and communities to experiment with particular extensions prior to any standardisation effort by OASIS. Filtering is an obvious area for this sort of thing and there are others. That's not to say a formal standard is not a good thing. It is simply that we want to allow emergence of 'grass-roots' interoperable extensions before getting a full standard out. My suggestion would be to use symbolic descriptors either in a domain assigned to experimental work or conforming to a particular pattern (e.g. prefixed by 'x-'). These would not be official OASIS standards at this point but would allow collaborative efforts externally to be useful to users and to prove out different approaches which would be valuable feedback into any standardisation effort.

Filters are not part of the spec; they are maintained in a registry (non-normative refs) on the AMQP/OASIS web site. What I want to know is a) what ideas have been discussed already? b) is there already content, e.g. filters, capabilities? c) is it necessary to create a sub-group or can we just maintain it in a nonformal way? Important for me as a JMS provider is to get 2 AMQP-registered filters, NoLocal and JMS Selector, which can be shared among JMS providers. Currently I'm using these 2 filters but with IANA numbers for IIT. So these filters work fine with SwiftMQ but no other JMS provider will recognize the descriptor code as a NoLocal or JMS Selector filter. -- Andreas Mueller IIT Software GmbH, Bremen/Germany http://www.swiftmq.com Am 14.02.2012 um 17:13 schrieb Gordon Sim: > I think we want a simple way for implementers and communities to experiment with particular extensions prior to any standardisation effort by OASIS. Filtering is an obvious area for this sort of thing and there are others. > > That's not to say a formal standard is not a good thing. It is simply that we want to allow emergence of 'grass-roots' interoperable extensions before getting a full standard out. > > My suggestion would be to use symbolic descriptors either in a domain assigned to experimental work or conforming to a particular pattern (e.g. prefixed by 'x-'). > > These would not be official OASIS standards at this point but would allow collaborative efforts externally to be useful to users and to prove out different approaches which would be valuable feedback into any standardisation effort. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: amqp-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: amqp-help@lists.oasis-open.org > IIT Software GmbH Fahrenheitstr. 1, D28359 Bremen, Germany Tel: +49 421 2208-166, Fax: +49 421 2208-167 Amtsgericht Bremen, HRB 18624, Geschaeftsfuehrer: Andreas Mueller Steuernummer: 71/572/04100, VAT: DE199945912

(a) I believe Rob and I forwarded you on an old proposal of a filter language. This would need some reworking to take advantage of the late improvements to the codec, but would provide an effective way to do extremely powerful filtering. (b) So yes, there's some content (c) Yes, I think a group's an excellent idea. I'd be happy to contribute what we have for others to play with. Right now, though, we're keen to put all our efforts into getting the CSD and final AMQP 1-0 spec out the door. Raph Raphael Cohn Chief Architect, StormMQ Secretary, OASIS AMQP Standard raphael.cohn@StormMQ.com StormMQ Limited UK Office: Gateshead int'l Business Centre, Mulgrave Terrace, Gateshead, NE8 1AN, United Kingdom Telephone: +44 845 3712 567 Registered office: 16 Anchor Street, Chelmsford, Essex, CM2 0JY, United Kingdom StormMQ Limited is Registered in England and Wales under Company Number 07175657 StormMQ.com On 14 February 2012 17:22, Andreas Mueller < am@iit.de > wrote: Filters are not part of the spec; they are maintained in a registry (non-normative refs) on the AMQP/OASIS web site. What I want to know is a) what ideas have been discussed already? b) is there already content, e.g. filters, capabilities? c) is it necessary to create a sub-group or can we just maintain it in a nonformal way? Important for me as a JMS provider is to get 2 AMQP-registered filters, NoLocal and JMS Selector, which can be shared among JMS providers. Currently I'm using these 2 filters but with IANA numbers for IIT. So these filters work fine with SwiftMQ but no other JMS provider will recognize the descriptor code as a NoLocal or JMS Selector filter. -- Andreas Mueller IIT Software GmbH, Bremen/Germany http://www.swiftmq.com Am 14.02.2012 um 17:13 schrieb Gordon Sim: > I think we want a simple way for implementers and communities to experiment with particular extensions prior to any standardisation effort by OASIS. Filtering is an obvious area for this sort of thing and there are others. > > That's not to say a formal standard is not a good thing. It is simply that we want to allow emergence of 'grass-roots' interoperable extensions before getting a full standard out. > > My suggestion would be to use symbolic descriptors either in a domain assigned to experimental work or conforming to a particular pattern (e.g. prefixed by 'x-'). > > These would not be official OASIS standards at this point but would allow collaborative efforts externally to be useful to users and to prove out different approaches which would be valuable feedback into any standardisation effort. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: amqp-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: amqp-help@lists.oasis-open.org > IIT Software GmbH Fahrenheitstr. 1, D28359 Bremen, Germany Tel: +49 421 2208-166 , Fax: +49 421 2208-167 Amtsgericht Bremen, HRB 18624, Geschaeftsfuehrer: Andreas Mueller Steuernummer: 71/572/04100 , VAT: DE199945912 --------------------------------------------------------------------- To unsubscribe, e-mail: amqp-unsubscribe@lists.oasis-open.org For additional commands, e-mail: amqp-help@lists.oasis-open.org

Hi guys, It's fantastic news that we have people that care about this.  I would like to suggest that someone take the lead (like Laurie has in the MS Goal group and Ram in the Transfer group) and put out an email say that we're going to put together a small group to discuss this issue and resolve it.  Anyone interested can then email that person and (voila) we have a group of interested parties that can get the job done quickly. What say?  Who's willing to play the lead role (doesn't have to be the most technical person ... often a good idea if it isn't)? cheers...angus On Feb-14-12, at 9:42 AM, Raphael Cohn wrote: (a) I believe Rob and I forwarded you on an old proposal of a filter language. This would need some reworking to take advantage of the late improvements to the codec, but would provide an effective way to do extremely powerful filtering. (b) So yes, there's some content (c) Yes, I think a group's an excellent idea. I'd be happy to contribute what we have for others to play with. Right now, though, we're keen to put all our efforts into getting the CSD and final AMQP 1-0 spec out the door. Raph Raphael Cohn Chief Architect, StormMQ Secretary, OASIS AMQP Standard raphael.cohn@StormMQ.com StormMQ Limited UK Office: Gateshead int'l Business Centre, Mulgrave Terrace, Gateshead, NE8 1AN, United Kingdom Telephone: +44 845 3712 567 Registered office: 16 Anchor Street, Chelmsford, Essex, CM2 0JY, United Kingdom StormMQ Limited is Registered in England and Wales under Company Number 07175657 StormMQ.com On 14 February 2012 17:22, Andreas Mueller < am@iit.de > wrote: Filters are not part of the spec; they are maintained in a registry (non-normative refs) on the AMQP/OASIS web site. What I want to know is a) what ideas have been discussed already? b) is there already content, e.g. filters, capabilities? c) is it necessary to create a sub-group or can we just maintain it in a nonformal way? Important for me as a JMS provider is to get 2 AMQP-registered filters, NoLocal and JMS Selector, which can be shared among JMS providers. Currently I'm using these 2 filters but with IANA numbers for IIT. So these filters work fine with SwiftMQ but no other JMS provider will recognize the descriptor code as a NoLocal or JMS Selector filter. -- Andreas Mueller IIT Software GmbH, Bremen/Germany http://www.swiftmq.com Am 14.02.2012 um 17:13 schrieb Gordon Sim: > I think we want a simple way for implementers and communities to experiment with particular extensions prior to any standardisation effort by OASIS. Filtering is an obvious area for this sort of thing and there are others. > > That's not to say a formal standard is not a good thing. It is simply that we want to allow emergence of 'grass-roots' interoperable extensions before getting a full standard out. > > My suggestion would be to use symbolic descriptors either in a domain assigned to experimental work or conforming to a particular pattern (e.g. prefixed by 'x-'). > > These would not be official OASIS standards at this point but would allow collaborative efforts externally to be useful to users and to prove out different approaches which would be valuable feedback into any standardisation effort. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: amqp-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: amqp-help@lists.oasis-open.org > IIT Software GmbH Fahrenheitstr. 1, D28359 Bremen, Germany Tel: +49 421 2208-166 , Fax: +49 421 2208-167 Amtsgericht Bremen, HRB 18624, Geschaeftsfuehrer: Andreas Mueller Steuernummer: 71/572/04100 , VAT: DE199945912 --------------------------------------------------------------------- To unsubscribe, e-mail: amqp-unsubscribe@lists.oasis-open.org For additional commands, e-mail: amqp-help@lists.oasis-open.org

Hi guys It looks like the old specs have vanished from AMQP .org These were published by the WG and need to be discoverable somewhere.  Where have they been put? alexis