[Simple] Re: WGLC: draft-ietf-simple-filter-format-01.txt

[Paul Kyzivat <pkyzivat at cisco.com>]

Hisham,

The following are comments on the draft in response to your request for 
a review. Please take these with a grain of salt - I haven't been 
following the work (just for lack of time), and I don't know much about 
XPath either, on which this is based. Feel free to push back if these 
comments are misguided.

	Paul

General comment:

I don't know whether to join this argument or not, but I see that this 
document uses extensive normative language that is redundant with what 
the xml schema defines. I am somewhat inclined to agree that the xml 
should be authoritative and so text descriptions should use 
non-normative language for things covered by the schema. But I would be 
happy if this document follows whatever approach is generally considered 
 the WG (or ietf) sanctioned approach.

Section 3.2:

Says may have uri or domain element. Says domain defines the domain of 
the resources the filter applies to. I think I know what that means, but 
it would be nice to be more explicit - namely that it selects resources 
whose uri is a sip uri with a matching domain part.

Says:
   The URI attribute MAY also carry a domain.  In this case, the filter
   applies to resources in that domain.

I *think* this means to say "the <filter> may carry a domain", refering 
to the 'domain' attribute. But I am far from sure of this based on the 
text. *If* that is the case then it partially resolves my prior comment. 
But not fully, because it still doesn't define what "resources in that 
domain" means. I presume this is all about full or partial text matching 
against URIs. Given that different kinds of URIs have differing matching 
rules, this whole subject deserves more explanation.

The description of the <filter> element *does* include normative text 
that isn't in the schema - namely that there must be at least one of 
<what> and <trigger>. While I don't know enough xml to say how, I 
suspect there is a way to describe this case in the schema. If so, it 
would be preferable to do so. (In English, I think you could define a 
type consisting of a sequence of 0 or 1 <what> and 0 or 1 <trigger>. 
Then you could define <filter> to contain 1 or more of that type.)

Section 3.3:

says:
   The <what> element MAY contain one or more <include> elements and one
   or more <exclude> elements.  However, the <what> element MUST contain
   at least one <include> element.  When more than one <include> element
   has been defined, the result is the union of all the <include>
   elements.  When more than one <exclude> element has been defined, the
   result is the union of all the <exclude> elements.

This isn't entirely clear, especially when there are both <include> and 
<exclude> elements. It isn't really possible to define the meaning here 
because it isn't yet clear what "union" applies to. In reality I think 
you are operating on trees, not sets, so set operations don't really 
apply. Are suitable semantics for this available in XPath? I think the 
semantics are *reasonably* obvious intuitively, but the challenge is to 
define them normatively.

Says:
   When identifying XML elements, the value may consist of two parts
   (similar to XPath [9]): the XML element selector and the condition
   (comparison and logical expressions).  The syntax is defined in
   section Section 4 (see the definition of "selection".)

The exact relationship to XPath is confusing. Is there a normative 
relationship? The reference indicates yes, but exactly what is drawn 
normatively from it, rather than being copied and subsetted? It appears, 
here and in later sections, that the syntax is being redefined, but the 
semantics is being referenced. This could be a lot clearer.

Section 3.3.2

Not clear how <exclude> interacts with the rule that <include> must 
include other mandatory elements:

- what if <exclude> references something that is unconditionally mandatory?

- what if <exclude> references a mandatory sub-element of an optional 
element that is referenced by <include>?

Says:
   The <exclude> element MUST NOT be used if there are no <include>
   element(s) in the same content filter.

But an <include> element is mandatory. So this is moot.

Section 3.4.1:

Says:
   The <changed> element is used to identify the XML element or
   attribute, from the package specific XML document, that must change,
   compared to the previous XML document,
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

How is 'previous XML document' defined? Is it replaced each time an 
update to the document is received? Or for a particular subscriber, is 
it the version last selected for delivery to the subscriber?

Apparently the <changed> element needn't contain any of changed-from, 
changed-to, or changed-by. I suppose that means it just tests for 
changes of any sort. Is that what is intended? In that case, what 
constitutes a change? Must the value be updated with a *different* 
value, or simply be updated, possibly with an identical value?

For <changed> without attributes, or with changed-from or changed-to, 
how is the comparison done? Is it literal string comparison, or type 
specific comparison? (If type specific, what if the type is unknown to 
the server? (Consider a case where an element containing a URI is 
changed from "sip:foo at bar" to "sip:foo at BAR".)

Is there a constraint on the type of element that changed-by is applied 
to? Must it be decimal? Must the change be in a particular direction?

Section 5.4:

I find this example inconsistent with my understanding of the uri 
attribute. I thought it acted as a restriction on what the filter 
applies to. In this case I would expect that the subscription itself 
would have been addressed to sip:buddylist at domain.com, and the uri 
parameter used only to restrict a filter to a particular buddy in the list.

Section 5.6:

I have the same problem here as in 5.4, but it is even clearer, because 
the uri attribute is sued both ways. AFAIK there never is a presence 
document for sip:buddies at domain.com - only ones for each of the buddies. 
So the uri attribute shouldn't match anything.

Section 6 (schema):

The attribute 'domain' of <filter> is of type 'anyURI'. While I am an 
xml neophite this seems wrong.





_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple