OASIS Advanced Message Queuing Protocol (AMQP) TC

  • 1.  Groups - AMQP Management v1.0 WD07 uploaded

    Posted 02-21-2014 16:28
    Document Name : AMQP Management v1.0 WD07 Description Fairly minor changes from WD06. Added definitions of successful and unsuccessful responses and centralized description of common failure status codes. Stated that the body of a response message resulting from an unsuccessful operation is undefined and should be ignored by the client. Download Latest Revision Public Download Link Submitter : Mr. David Ingham Group : OASIS Advanced Message Queuing Protocol (AMQP) TC Folder : Working Documents Date submitted : 2014-02-21 08:27:49


  • 2.  Re: [amqp] Groups - AMQP Management v1.0 WD07 uploaded

    Posted 02-27-2014 14:50
    Hi David, I had a look at this version and I have some comments / questions: 1) The chapter 3.1 - which specifies the application properties which are common for all requests - contains the locales property defined as a list - I assume it should either use a different type or be moved to the message body similarly as you did it with the attributes list in the QUERY request in WD06 version. 2) Again in the chapter 3.1, it says that the body must be an amqp-value section containing a single map. However the QUERY request (3.4.1.1) says that the body must consist of an amqp-value section containing a list of string elements. I would assume that we need to pack the list into the map as required by chapter 3.1, or? 3) Originally, we had most of the parameters in the application properties but now it is mixed between application properties and the message body. On an example of the QUERY request, is there some reason why do we still have the entityType, offset or count in the application properties? Does it bring any advantage? Would it be easier to have everything apart from the operation and type in the message body? Thanks & Regards Jakub From: David Ingham <david.ingham@microsoft.com> To: amqp@lists.oasis-open.org, Date: 21/02/2014 17:28 Subject: [amqp] Groups - AMQP Management v1.0 WD07 uploaded Sent by: <amqp@lists.oasis-open.org> ------------------------------------------------------------- Document Name: AMQP Management v1.0 WD07 Description Fairly minor changes from WD06. Added definitions of successful and unsuccessful responses and centralized description of common failure status codes. Stated that the body of a response message resulting from an unsuccessful operation is undefined and should be ignored by the client. Download Latest Revision Public Download Link Submitter: Mr. David Ingham Group: OASIS Advanced Message Queuing Protocol (AMQP) TC Folder: Working Documents Date submitted: 2014-02-21 08:27:49 ------------------------------------------------------------- ---------------------------------------------------------------------------- Deutsche Börse Services s.r.o. Managing Directors/Geschäftsführung: Michael Gassmann, Mats Andersson. Limited liability company with registered office at Sokolovská 662/136B, CZ-186 00 Prague 8 recorded in the Commercial Register IC: 275 77 015. Maintained by the city court in Prague, Sec. C, File No. 116874. ----------------------------------------- Diese E-Mail enthaelt vertrauliche oder rechtlich geschuetzte Informationen. Wenn Sie nicht der beabsichtigte Empfaenger sind, informieren Sie bitte sofort den Absender und loeschen Sie diese E-Mail. Das unbefugte Kopieren dieser E-Mail oder die unbefugte Weitergabe der enthaltenen Informationen ist nicht gestattet. The information contained in this message is confidential or protected by law. If you are not the intended recipient, please contact the sender and delete this message. Any unauthorised copying of this message or unauthorised distribution of the information contained herein is prohibited. Legally required information for business correspondence/ Gesetzliche Pflichtangaben fuer Geschaeftskorrespondenz: http://deutsche-boerse.com/letterhead


  • 3.  RE: [amqp] Groups - AMQP Management v1.0 WD07 uploaded

    Posted 02-27-2014 15:33
    1) I'll fix that... I'd suggest we use a comma separated list or something 2) That's a mistake in 3.1, the type of the body will be dependent upon the operation - I'll fix 3) In general I think it is better to have the parameters in the message properties rather than the body. Certainly in cases like create where you want to distinguish between attributes of the operation and attributes of the entity you want to be created. The attributes parameter is rather a special case... ideally it should be in the header - I really don't like where it is now. We could have put them in the header as a comma separated list within a string or something (I think I probably prefer that approach) - though that would have required more parsing on the server side. I'm open if anyone has any strong feeling on this. -- Rob Legally required information for business correspondence/Gesetzliche Pflichtangaben für Geschäftskorrespondenz: http://www.jpmorgan.com/pages/international/germany/email