Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 954496

Summary: Address string grammar description missing in the doc
Product: Red Hat Enterprise MRG Reporter: Petr Matousek <pematous>
Component: Messaging_Programming_ReferenceAssignee: Jared MORGAN <jmorgan>
Status: CLOSED CURRENTRELEASE QA Contact: Petr Matousek <pematous>
Severity: high Docs Contact:
Priority: unspecified    
Version: 2.3CC: esammons, gsim, mmurray
Target Milestone: 3.0   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 954473 Environment:
Last Closed: 2015-01-22 15:27:28 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 954473    
Bug Blocks:    

Description Petr Matousek 2013-04-22 12:15:21 UTC
+++ This bug was initially created as a clone of Bug #954473 +++

Description of problem:
There was a description of address string grammar in the doc for MRG2.2 and prior versions.

Please see:
http://documentation-devel.engineering.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/2/html-single/Programming_in_Apache_Qpid/index.html#sect-Programming_in_Apache_Qpid-Addresses-Address_String_Grammar

This paragraph is missing in the current Programming reference. I believe that this paragraph is very useful and shall be definitely covered by doc.

I am also missing proper node policies description (create, delete, assert). 
The node policies were also somehow described in the MRG2.2 a prior doc, but a bit more detailed description is desired, (ie. how are the policies applied).

Version-Release number of selected component (if applicable):
Messaging Programming Reference - revision 2.0.0-31

How reproducible:
n/a

Steps to Reproduce:
n/a
  
Actual results:
Address string grammar description missing
Node policies description missing

Expected results:
Address string grammar described in the doc
Node policies described in the doc

Comment 2 Petr Matousek 2013-10-15 08:26:12 UTC
It's great that the address string grammar was updated to highlight changes between the amqp0-10 and 1.0 protocols. But the amqp1.0 grammar is not perfectly correct yet, ie:

1. Link scoped x-subscribe element not supported over AMQP 1.0.
2. delete policies are not supported via amqp1.0

on the other hand, some elements are available only for amqp1.0, ie:

3. amqp1.0 supports nested map of 'properties' in the node map 

I propose to check the the address string grammar correctness with Gordon.

Comment 4 Gordon Sim 2013-10-16 09:10:38 UTC
The 'delete' option is not supported for 1.0 . Neither is x-subscribe within link as you mention. In 1.0, node supports 'properties' with a nested map as a value (this is preferred to x-declare; x-declare is just a convenience that will in effect automatically create the properties map) and 'capabilities' with either a single string or a list of strings as the value. Again for 1.0, the link section supports a 'filter' whose value is a map containing three items: 'name', an application chosen name for the filter, 'descriptor', a numeric or symbol (i.e. string) descriptor identifying the type of the filter, 'value'  whose value is dictated by the type of filter (e.g. string for legacy-amqp-direct-binding and map for legacy-amqp-headers-binding).

Comment 8 Petr Matousek 2013-10-17 14:18:51 UTC
The content looks good now, I would recommend to remove notes/footnotes [2],[3],[4],[5] because from the amqp1.0 grammar below it is clear that the elements are not supported and it is not necessary to point this explicitly out.

I would leave the note [6], but I propose following change:
- [6] The new properties nested map is recommended over the equivalent x-declare + [6] The use of new properties nested map is recommended. The x-declare map is supported as a convenience and is automatically converted to a properties map before sending to the broker.

(because it is not completely true that the maps are equivalent.)

But that's only a suggestion from my point of view. If you prefer to leave the notes as it is, I am going to move to verify.

Comment 16 Petr Matousek 2013-10-29 09:04:19 UTC
Content approved.

Version-Release number of selected component (if applicable):
Messaging Programming Reference - revision 0.0.0-9

-> VERIFIED