(this mail covers only sections 1. and 2. - I have notes on the other sections which I will type up hopefully tomorrow)
Since it is talking about "SQL filter expressions"Â(plural) I think the last clause should beginÂ"allow for"Ârather than "allows for"Âbut maybe it will all read better by reversing the ordering a bit:
SQL filter expressions allow for complex filter conditions. Their definition leans on the SQL-92 standard just as the familiar SQL selector syntax used by Java Message Service (JMS) specification does.
2. Filter Expressions
2.1 Overview
First para:Â"Filter expressions are evaluated by an AMQP container against messages flowing into or out of the AMQP container".Â
This is incorrect - filter expressions are only ever evaluated on messages flowing out (i.e. at the source) and not on messages flowing in (at the target).
Filter expressions MUST evaluate to a Boolean âtrueâ or âfalseâ result, except when the filter _expression_ evaluation fails in which case the evaluation result is NULL. For details on handling evaluation failures, see section 2.3
This feels a little weird as it makes seems to elevate null into a value rather than the absence of a value. The capitalisation of null as NULL is also inconsistent with the core specification (Boolean is also inconsistent with the rendering of the AMQP type as boolean - all lower case).
Perhaps we could say something like:
Successful evaluation of a filter _expression_ against a message will result in a boolean result: true or false.ÂWhere _expression_ evaluation fails (for instance through an attempt to compare between values of types which cannot be compared), the evaluation is neitherÂtrueÂnor falseÂbut instead can be considered to be unknowable - that is null.
Third para:ÂThe body (data, amqp-value, or amqp-sequence) of an AMQP message holds binary data that is opaque to the AMQP container and might carry encrypted data or might be encoded with non-AMQP encodings.Â
This is incorrect - only if the type of the body is data is the value opaque, possibly encrypted or encoded with non-AMQP encodings.
Perhaps: "The body (data, amqp-value, or amqp-sequence sections) may be large, unstructured and intentionally opaque to intermediary containers. For these reasons filters against the body sections are intentionally out of scope for this specification."
2.2 Connection and Link Capabilities
Only capabilities exchange on the open frame is discussed.
First para:ÂOn connection establishment, a partner MUST
indicate whether and which filter expressions it supports through the exchange
of connection capabilities (see Section 2.7.1 [[AMQP]]).
This is not strictly correct. In the case where the other container sent the first open, a container is only requiredÂto advise on connection capabilities that it supports and the initiator indicates that it desires. That is, if a client opens a connection and does not supply any desired capabilities, then by 2.7.1 the server can assume that the client will never use those capabilities and therefore they don't need to be advertised.
2.3 Error Handling
first para: "The handling of filters might fail when filters are configured in the system, like when attaching a link with a source filter whereby the filter is being validated and validation fails. Handling might also fail when the filter is executed against a given message, like evaluating SQL filter that tries to perform a mathematical division by an application-property value and that value is zero in a given message."
I'm not sure that it makes much sense to talk of "handling filters". Filters are subject to two types of failure - 1. Definitional failure, where simply attempting to construct the filter fails (for instance due to a syntax error), 2. Evaluation failure, where the filter is well formed, but the filter cannot be evaluated meaningfully against a particular message (for instance testing whether the application-property "foo" is greater than the integral value 4, where for a given message the value associated with the application-property "foo" is a binary value representing the jpeg encoding of a picture of a cat.
In general I think we should say that definitional failures should cause the link to be detached with an error. Ideally this detach should be immediately upon the partner attempting to create the link, however some containers may defer constructing the filter until a message needs to have the filter evaluated, in which case the container may detach the link at that point.
For evaluation failure we should say that the message should not be sent by the source. Implementations may choose to treat evaluation failure as equivalent to the filter evaluating to false; or may perform some additional action (such as moving the message to a different node for later diagnostic interpretation).
second para:ÂIn all failure cases, the filter evaluates to NULL, and therefore all grouping filter expressions in which the filter is included summarily also evaluate to NULL.
The issue with the above is that it prevents the traditional short-circuiting logic in AND and OR processing, such that an ANDÂfilter will fail as soon as a single filter being ANDed fails (and for OR if a single TRUE is returned then other filters may never be evaluated).
I think we should allow for such logic short-circuiting... So, for AND, if no filter returns false, but at least one filter returns null, then the result of the AND is null. For OR, if no filter returns true, but at least one filter returns null, then the result of the OR is null. NOT null is null.
2.3.1 Source Filters
First of all, what is a "source filter"? Or rather what filter is not a source filter?
first para: "When a filter is applied by a receiver to the source of a link during attach, the sender (the source) SHOULD validate the filter. In particular, it is strongly RECOMMENDED to validate the syntax of SQL filters for correctness during the attach operation."
Technically receivers don't apply filters. Each side simply defines what it thinks both sides of the link should look like. In the case where a container only establishes a link when its partner sends an unsolicited attach then it is functionally indistinguishable from the receiver "applying" the filter - but that is not what the protocol actually defines... So...
"If a container establishes sending link on receipt of an unsolicited attach by its partner, and the attachÂfrom its partner contains a filter on the source, the container SHOULD validate the filter before sending its own attach with the same filter defined at its source."
Overall I think this subsection needs a bit more work, and probably should be merged into its parent. We should also give more concrete error codes rather than simply talking about "appropriate" ones.
=========================
as above, I have notes on Sections 3-6, which I shall to writeÂup shortly.Â