Subject: RE: [Simple] WGLC: Event Filtering

From: [email-masked]
Date: Mon, 5 Jul 2004 15:05:32 +0300

Hi,

Please find below some comments to the filter-format-01 draft:

In the beginning of the subsection 3.3.1 ("include") it is said that an XML attribute can be selected as content to be delivered. However, it is not clear how the selection of the attribute is done in practise (e.g., if the "type" attribute's value 'XML element' is used), and what it means to indicate an XML attribute in the <include>.

The meaning of the sentence 3.3.1: "The <include> element MUST identify one element only, unless the conditional expression results in more than one element with the same name being identified." is a bit unclear. 

3.3.1: "... all other mandatory XML elements and/or attributes must be incorporated in the resulting XML document...": are e.g. optional XML attributes of mandatory XML elements incorporated or not?

3.3.1 (example): "The following example selects the <status> element defined in PIDF XML document [11]. This results in the selection of all the ancestors of <status>. I.e. <basic> and <tuple>." -> I'd rephrase the texts something like this: "The following example selects the <status> element defined in PIDF [11]. This also results in the selection of all mandatory elements related to the <status>, i.e. <basic> and <tuple>."

3.3.1.1: "The syntax is defined in a way ..." -> I'd add a sentence for clarifying the context of the syntax, e.g. something like "The 'xml-element' value is used when the <include> element identifies XML elements. The syntax is defined in a way..."

3.3.1.1.: It'd be good to have at least one example of the selection of an XML attribute.

3.3.2: it'd be good to add e.g. a note about <exclude> vs. mandatory XML element.

3.3.2: the last sentence is basically unnecessary since earlier in the draft it is said that the <what> element must contain at least one <include>.

5.1.(examples) The text talks about first and 2nd filter definition even if there is only one. Additionally, 
the filter definition should contain "xmlns:simple-filter="urn:ietf:params:xml:ns:simple-filter" + similar definitions for pidf and rpid prefixes. Also the <filter-set> element could have the "simple-filter" prefix as also other XML elements seems to have it. This comment applies to all the filter definition examples.

5.3:  The xml document could be corrected as follows: needed namespace prefixes to be defined; "//" to be added to the first <include>; is there something wrong in "//wi:watcher/@wi:status@status"; the trigger part contains two <changed> elements, but isn't it so the trigger never matches if the AND operation is applied to the <changed elements.

6. (XML Schema) Shouldn't the value "token" be removed from "TypeType" definition?

7. (security) "... more than 20 occurences of the <what> ...." -> because there can be only one <what> element per <filter> wouldn't it be more appropriate to list e.g. the <trigger> and/or <filter> element instead?

Other minor issues:
- names of RPID elements should be updated in the filtering XML document examples
- usage of ' vs. " could be aligned through the whole draft
- 5.2.: "... when a certain PIDF [11] tuple changes its <basic> status from 'closed' to 'open'" -> maybe "tuple changes its" part could be rephrased 
- 5.2: the xmlns definition ends with double "" -> should be only one

BR, Eva

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of ext Robert Sparks
> Sent: 30 June, 2004 18:07
> To: [email-masked]
> Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> Subject: [Simple] WGLC: Event Filtering
> 
> 
> This is a SIMPLE working group last call for the following drafts:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-simple-filter-f
> ormat-01.txt
> http://www.ietf.org/internet-drafts/draft-ietf-simple-event-fi
lter-funct-01.txt

Please provide comments to the list or chairs by July 16.

Thanks,
RjS

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 05 Jul 2004 15:45:31 +0300

Hi:

I am sorry for the long e-mail... Here are some comments to the 
filter-format-01.txt draft.

- Section 3, first paragraph reads:

    The filter criteria is an XML document [8] that MUST be well-formed
    and MUST be valid.  The filter criteria XML documents MUST have the
    XML declaration and it SHOULD contain an encoding declaration in the
    XML declaration, for example; "<?xml version='1.0'
    encoding='UTF-8'?>".

First problem, why the document 'MUST be valid'? In other XML documents
created by SIMPLE the statement reads 'SHOULD be valid'. So why the
strength is higher in Filter Criteria documents?

Second problem. I don't understand the value of the above sentence: 'XML
document MUST have the XML declaration' (of course, they are XML
documents) and 'SHOULD contain an encoding declaration'... but you don't
say what the encoding should be, so there is not point in indicating the
encoding declaration if you don't restrict it to some values. My
proposal is to align this statement with the rest of the XML documents
that SIMPLE is producing, and replace the above sentence with:

    A filter criteria is an XML [3] document that MUST be
    well-formed and SHOULD be valid. Filter criteria documents MUST
    be based on XML 1.0 and MUST be encoded using UTF-8.

- Section 3 states:

    The namespace identifier for elements defined by this specification
    is a URN [5], using the namespace identifier 'ietf' defined by [6]
    and extended by [4].  This urn is:
    urn:ietf:params:xml:ns:simple-filter+xml.

The namespace should be "urn:ietf:params:xml:ns:simple-filter" rather 
than "urn:ietf:params:xml:ns:simple-filter+xml".

- Missing link with the MIME type simple-filter+xml. I didn't fine any 
linkage to the simple-filter+xml MIME type.

I am missing some normative text that indicates the following ideas:
a) This specification defines a new MIME type "simpler-filter+xml".
b) Implementations MUST support this MIME type.
c) Filter criteria documents MUST be sent setting the Content-Type to 
"simple-filter+xml".

- Namespaces prefixes. There are many elements that accept a namespace
prefix to identify the correct element. The question is, where is the
binding between the namespace and the prefix defined? None of the
examples show this binding, but all of them refer to "pidf", "rpid",
"wi" namespaces. For instance, this is an excerpt from an example:

          <simple-filter:include type="xml-element">
            //pidf:tuple/pidf:status/pidf:basic[rpid:class="IM"
            or rpid:class="SMS" or rpid:class="MMS"]
          </simple-filter:include>

Where is it define that "rpid" refers to either
urn:ietf:params:xml:ns:pidf:rpid-tuple or
urn:ietf:params:xml:ns:pidf:status:rpid-status? And to which one?

I see two possible solutions. One is that you use the regular
prefix-namespace binding used in XML. The only problem is that this
binding refers to elements that you use in your XML document. However,
you want to prefix ***values*** that refer, in turn, to an XML element.
It is not quite the same thing. For instance, if you want to use rpid
and pidf, you could use the following <filter-set> element.

<filter-set xmlns:n="urn:ietf:params:xml:ns:simple-filter"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="urn:ietf:params:xml:ns:simple-filter"
     xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid-tuple"
     xmlns:pidf="urn:ietf:params:xml:ns:pidf"
     elementFormDefault="qualified"
     attributeFormDefault="unqualified">

The other solution is that you explicitly define some XML <binding>
element as part of your schema. This will be used to define the binding
you use later. Something like:

<filter-set xmlns:n="urn:ietf:params:xml:ns:simple-filter"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="urn:ietf:params:xml:ns:simple-filter"
     elementFormDefault="qualified"
     attributeFormDefault="unqualified">

     <binding xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid-tuple"/>
     <binding xmlns:pidf="urn:ietf:params:xml:ns:pidf"/>

- Section 3.3. The statement 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.

I would like to understand why at least one <include> element must be
present. In other words, why can I just have <what> element that simply
states what I don't want to receive, i.e., a collection of <exclude>
elements and zero <include> elements.

In case something changes in this section, then section 3.3.2 should
change as well:

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

- Section 3.3.1.1. The first paragraph is ok, but the remaining of the
section has nothing to do with the 'type' attribute. I believe the rest
should be moved to Section 4, as it discusses the syntax.

- Section 3.4 states:

    The <trigger> element MAY contain the <changed> element, the <added>
    element or the <removed>, but MUST contain at least one of the three
    elements.  Any combination of the 3 elements is possible.  Multiple
    appearances of those element within a <trigger> element denotes the
    "AND" operation.  This means that updates to a resource that satisfy
    ALL of the <changed>, <added> and <removed> elements' criteria within
    the <trigger> element constitute the content to be delivered.

Question: is there a case where the <added> and <removed> can appear
simultaneously? It would mean: send me element <foo> if it is <added>
and <removed>, which I believe is not possible ever.

- Section 3.4.1 states:

    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, in order to activate the
    trigger and cause the content to be delivered.

If I understand correctly, what changes is not the element itself, but
the value. Can you confirm it?

If the element changes, then it could be, e.g., because a new optional
attribute is added or removed. But I believe that you want to say that
what it has to change is the value, right?

Can you clarify in the text what is the intention?

- Section 3.4.1.3 states:

    A trigger is active when the XML element or attribute identified with
    the <changed> element has changed by the value indicated by this
    attribute from a different value.

So does this element apply to numeric values only? If so, then I guess
this is either an addition or subtraction with respect the current
value (not multiply or division). Therefore, I would propose:

    The 'changed-by' attribute applies only to numerical values and
    indicates a delta with respect the current value that an attribute
    or element (identified in the <changed> element) needs to change
    before it is selected.

    Example: if the 'changed-by' attribute is set to 2, and the current
    value of the element/attribute is 6, the element/attribute is
    selected when it reaches (or exceeds) the value 8 or when it
    decreases to 4 or lower value.

- Section 3.4.2 states:

    The XML element or
    attribute is indicated using the syntax defined in Section 4 for the
    "reference".

I think you should make the above text normative:

    The XML element or attribute MUST be expressed using the syntax
    defined in Section 4 for the "reference" ABNF.

- Section 6, extensibility of the XML schema.

I noticed weird things related to the extensibility of the XML schema. 
While you provide extensibility for new attributes of most elements, 
there is no attribute extensibility to the <what> element. Additionally, 
  I didn't find any possibility to add new elements. I think this should 
be possible, when it is rational.

- Section 6, the "TypeType" definition.

Currently, the "TypeType" is defined as:

      <xs:simpleType name="TypeType">
        <xs:restriction base="xs:string">
          <xs:enumeration value="xml-element"/>
          <xs:enumeration value="namespace"/>
          <xs:enumeration value="token"/>
        </xs:restriction>
      </xs:simpleType>

I believe the "token" value should not be present. Second: in the text 
it is said (a few times) that a filter applies to either an element, an 
attribute or a namespace. But now the "type" definition only considers 
values "xml-element" and "namespace". So how I identify an attribute?

I believe that "xml-element" is sufficient to accommodate attributes, 
because you will have an XPath expression that clearly distinguishes 
elements from attributes. So I am not advocating to add a new 
"attribute" value to the "type" definition, instead I think you need to 
rename the "xml-element" by something more generic, perhaps "xpath" to 
indicate that the value of the element is an XPath expression (or a 
namespace it is so).

Then probably you need to add some discussion, in the text, to indicate 
when to use one or the other.

- I would like to get your opinion on a new feature. I believe it might
be interesting to have rules defined and stored in the server, so that I
can easily activate a filter set or deactivate it. So a filter that is
deactivated is not in used, although is easily available for future
reference or enable it at any time.

I think I would like to see some 'state' attribute in each <filter> or
<filter-set> elements, so that I can "enable" or "disable" easily a
filter, without sending the whole <filter-set> to the server.

- Notation. Some months ago we got an agreement on the notation that we
should be using for XML specifications. I believe the agreement is that,
whenever we refer to an element, we include it within brackets (e.g.,
<element>); an attribute is enclosed in single quotes (e.g.,
'attribute'); a value is enclosed in quotation marks (e.g., "this is a
value").

For instance: the <foo> element contains an optional 'type' attribute
that can get the value "open" or "closed".

This facilitates the reading of the specification. So can you please
revise the document and make the notation consistent according to the
above rules?

- Examples. All the examples should start with a proper XML header, like:

<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="urn:ietf:params:xml:ns:simple-filter">

After that, you don't need to prepend each element in the examples with
a "simple-filter" prefix (that is not even bound anywhere). But this
requires that you change a bit the XML schema to add the default
behavior for elements and attributes. So the schema should start with :

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:simple-filter"
     xmlns="urn:ietf:params:xml:ns:simple-filter"
     xmlns:xs="http://www.w3.org/2001/XMLSchema"
     elementFormDefault="qualified"
     attributeFormDefault="unqualified">

With this change to the schema, then the examples validate without that
prefix, and they are easier to read.

- Section 5.1, example. Shouldn't the value of the <include> element be
prepended with "//pidf:presence" to identify the root element of the 
pidf document?. For example:

          <simple-filter:include type="xml-element">
            //pidf:presence/pidf:tuple/pidf:status/
            pidf:basic[rpid:class="IM" or rpid:class="SMS" or
            rpid:class="MMS"]
          </simple-filter:include>

- Section 5.2, example. Missing one slash "/" before the "/pidf:presence".

- Section 5.3, example. Missing double slashes "//" before the 
"wi:watcher" value in the <include> element.

Also in this example, is it it correct to have a slash "/" prior to the 
at sign "@" in :

            //wi:watcher/@wi:status@status

At least by following the ABNF I thought it wasn't right.

- Section 5.5, typo in title:

    s/Include/include

- Section 3.1, typo in sentence:

    '... document containing the filter criteria is separated from
         the events that makes use of it or from the protocol that
         usually carries it.'

    s/makes/make

- Section 8: I would remove the two paragraphs in this subsection

    A new content type "application/simple-filter+xml" is defined to
    represent an XML MIME for the filter criteria.

    This specification follows the guidelines of RFC3023 [7]

And I would start section 8.1 with:

    This specification registers a new MIME type according to the
    procedures of RFC 2048 [xx] and guidelines in RFC 3023 [yy].

- Section 8.1: Typo in title:

    application/simple-filter+xml mime TYPE

should read:

application/simple-filter+xml MIME type

- Section 8.1: Typo.

    Security considerations: See section 10 of RFC 3023 [7] and section
    Section 8 of this document.

should read

    Security considerations: See section 10 of RFC 3023 [7] and section
    Section 7 of this document.

- Section 8.2: The "URN document" is now RFC 3688.

Best regards,

      Miguel

Robert Sparks wrote:

> http://www.ietf.org/internet-drafts/draft-ietf-simple-filter-format-01.txt
> http://www.ietf.org/internet-drafts/draft-ietf-simple-event-filter-funct-01.txt
> 

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland

---

From: [email-masked]
Date: Wed, 7 Jul 2004 14:31:10 +0300

Hi Eva,

and thanks for the comments. Responses inline...

> Of ext [email-masked]
> Sent: 05.July.2004 15:06
> To: [email-masked]; [email-masked]; Khartabil Hisham
> (Nokia-TP-MSW/Helsinki)
> Subject: RE: [Simple] WGLC: Event Filtering
> 
> 
> Hi,
> 
> In the beginning of the subsection 3.3.1 ("include") it is 
> said that an XML attribute can be selected as content to be 
> delivered. However, it is not clear how the selection of the 
> attribute is done in practise (e.g., if the "type" 
> attribute's value 'XML element' is used), and what it means 
> to indicate an XML attribute in the <include>.

I was thinking of changing the type value from "xml-element" to "xpath" to cover both attribute and element cases. Is that satisfactory?
> 
> The meaning of the sentence 3.3.1: "The <include> element 
> MUST identify one element only, unless the conditional 
> expression results in more than one element with the same 
> name being identified." is a bit unclear. 

Will clarify.

> 
> 3.3.1: "... all other mandatory XML elements and/or 
> attributes must be incorporated in the resulting XML 
> document...": are e.g. optional XML attributes of mandatory 
> XML elements incorporated or not?'

No. I think the text is clear, I you read the paragraph until the end.

"  in
   addition to including the elements identified with the <include>
   element, all other mandatory XML elements and/or attributes must be
   incorporated in the resulting XML document in order to make it valid.
   This, in practice, means that a subscriber defining a filter only
   needs to <include> optional elements and/or attributes, but may
   <include> mandatory elements and/or attributes as well."

> 
> 3.3.1 (example): "The following example selects the <status> 
> element defined in PIDF XML document [11]. This results in 
> the selection of all the ancestors of <status>. I.e. <basic> 
> and <tuple>." -> I'd rephrase the texts something like this: 
> "The following example selects the <status> element defined 
> in PIDF [11]. This also results in the selection of all 
> mandatory elements related to the <status>, i.e. <basic> and <tuple>."

Done.

> 
> 3.3.1.1: "The syntax is defined in a way ..." -> I'd add a 
> sentence for clarifying the context of the syntax, e.g. 
> something like "The 'xml-element' value is used when the 
> <include> element identifies XML elements. The syntax is 
> defined in a way..."

I clarified and moved the text and this example to section 3.3.1.

> selection of an XML attribute.

Added.

> 3.3.2: it'd be good to add e.g. a note about <exclude> vs. 

I put a reference to the <include> section.

> 
> 3.3.2: the last sentence is basically unnecessary since 
> earlier in the draft it is said that the <what> element must 
> contain at least one <include>.

Removed.

> 
> 5.1.(examples) The text talks about first and 2nd filter 
> definition even if there is only one. Additionally, 
> the filter definition should contain 
> "xmlns:simple-filter="urn:ietf:params:xml:ns:simple-filter" + 
> similar definitions for pidf and rpid prefixes.

I don't think this is how it works. The namespaces do not apply to element values. To solve this problem, we need to define a new element that carries prefixes.

> Also the 
> <filter-set> element could have the "simple-filter" prefix as 
> also other XML elements seems to have it. This comment 
> applies to all the filter definition examples.

I don't believe this is right.

> 
> 5.3:  The xml document could be corrected as follows: needed 
> namespace prefixes to be defined; "//" to be added to the 
> first <include>; is there something wrong in 
> "//wi:watcher/@wi:status@status";

Fixed.

> the trigger part contains 
> two <changed> elements, but isn't it so the trigger never 
> matches if the AND operation is applied to the <changed elements.

Seperated them into 2 <trigger> elements.

> 6. (XML Schema) Shouldn't the value "token" be removed from 

Yes.

> 
> 7. (security) "... more than 20 occurences of the <what> 
> ...." -> because there can be only one <what> element per 
> <filter> wouldn't it be more appropriate to list e.g. the 
> <trigger> and/or <filter> element instead?

Yes.

> - names of RPID elements should be updated in the filtering 

Can you be more specific? I only found 1 where "type" was used as an RPID element name.

> - usage of ' vs. " could be aligned through the whole draft

How?

> - 5.2.: "... when a certain PIDF [11] tuple changes its 
> <basic> status from 'closed' to 'open'" -> maybe "tuple 
> changes its" part could be rephrased 

OK.

> - 5.2: the xmlns definition ends with double "" -> should be only one

Done.

Thanks,
Hisham

---

From: [email-masked]
Date: Thu, 8 Jul 2004 13:23:24 +0300

> From: Miguel Garcia [mailto:[email-masked]]
> Sent: 08.July.2004 13:09
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> Cc: [email-masked]
> Subject: Re: [Simple] WGLC: Event Filtering
> 
> 
> Khartabil Hisham (Nokia-TP-MSW/Helsinki) wrote:
> > 
> >>From: Miguel Garcia [mailto:[email-masked]]
> >>Sent: 07.July.2004 17:16
> >>To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> >>Cc: [email-masked]
> >>Subject: Re: [Simple] WGLC: Event Filtering
> >>
> >>
> >>Khartabil Hisham (Nokia-TP-MSW/Helsinki) wrote:
> >>
> >>
> >>>Functionality draft issue.
> >>>
> >>
> >>M.G: I think I expressed myself wrong, because obviously it 
> does not 
> >>make sense that you define a MIME type and in the same 
> >>document you say 
> >>that implementations MUST suppport it, so I agree with you. 
> >>But I think 
> >>the text I am looking for is something that indicates that when an 
> >>implementation encodes a Filter Criteria document, it MUST set the 
> >>Content-Type header (or whatever protocol) to 
> simple-filter+xml. Then 
> >>the functionality draft can say that implementations MUST 
> >>support filter 
> >>criteria documents.
> > 
> > 
> > We don't want to dictate how a filter arrives at a server 
> or what protocol is used to upload such filters. Content-type 
> header gives the false impression that this XML document is 
> only used with SUBSCRIBE requests. A filter can be uploaded 
> using some other means than SIP SUBSCRIBE.
> > 
> 
> Hisham, as you know, a Content-Type header is not SIP-specific. It is 
> available for SIP, HTTP, e-mail, etc. This header just describes the 
> type of body, irrespective the protocol used to transfer the 
> contents. 
> So even if you use HTTP or MSRP (crazy, I know it, just a 
> hypothetical 
> example) to transfer a filter criteria document, still you 
> will need to 
> populate the Content-Type header with a simple-filter+xml.
> 
> As a consequence, I believe the filter format document should 
> state that 
> whatever is the protocol you use to transfer the contents, 
> the MIME type 
> is set to simple-filter+xml, so is the Content-Type header.

I could be manually configuring those filters and not use any transport protocol. But Ok, I will add the following:

Any transport protocol that is used to carry the filters MUST identify the payload as MIME type "simple-filter+xml", if the transport protocol carries such information (for example: a Content-Type header).

Regards,
Hisham

> Regards,

---

From: [email-masked]
Date: Tue, 13 Jul 2004 10:42:23 +0300

There are very few days left for the WGLC of these drafts. Please send your comments a.s.a.p. I've had good comments for the filter-format draft but would appreciate some more comments for filter-funct.

Thanks,
Hisham

> From: ext Robert Sparks [mailto:[email-masked]]
> Sent: 30.June.2004 18:07
> To: [email-masked]
> Subject: WGLC: Event Filtering
> 
>

---

From: "Mary Barnes" <[email-masked]>
Date: Tue, 13 Jul 2004 22:10:47 -0400

I do have a few comments, mostly editorial/nits, but there is one general
concern about the computational burden on the server that's generating these
event filtered notifications, as I think that's not been very thoroughly
addressed (except in the security section) and I think it needs to be
highlighted upfront in these documents. 

Mary  
----------------------------------------------------------------------

I'll start with my comments on filter-funct.  

- Update the document to the new template per the updated guidelines
reflecting new IPR policies per RFCs:
http://www.ietf.org/ietf/1id-guidelines.txt

- Abstract. Is not particularly informative.  I don't think the 1st
paragraph is necessary at all as it only talks about things not related to
this document.  I would remove that and update the 2nd paragraph by changing
from:
"  This document describes the operations a subscriber performs in order
   to define filtering rules, how to handle responses to subscriptions
   carrying filtering rules, and how to handle notifications with
   filtering rules applied to them.  The document also describes how the
   notifier behaves when receiving such filtering rules and how a
   notification is constructed."

To something like: 
"  This document describes the operations a subscriber performs in order
   to define filtering rules associated with event notification information.

   The handling of responses to subscriptions
   carrying filtering rules and the handling of notifications with
   filtering rules applied to them is described.  The document also
describes 
   how the notifier behaves when receiving such 
   filtering rules and how a notification is constructed."

- Section 7. Certainly, limiting the number of occurrences to 20 would help
limit the DoS attacks, however, it seems that the computational intensity of
these filters in general should really be highlighted much earlier in the
document. I would think this would be useful in the introduction in the 2nd
paragraph where the applicability of filtering relative to specific devices
is discussed.  It may well be a good idea to limit this spec, to systems
that must support such devices, due to the computational intensity. Per my
next comment, this is an engineering tradeoff, so it's not just a security
issue, it's a system capacity and performance issue (for the entity handling
the filters) 

- Section 7. <Duplicate comment for filter-funct> Related to the previous
comment, I also think that 20 is rather arbitrary and it would seem that 20
could certainly be a good default recommendation, but that systems need some
engineereing to determine the optimum value.  Do you all have concrete
implementation experience that might help shed some light on why 20 is a
good number?  Perhaps, this has been discussed and I just missed it.  But,
this would be useful information for folks to have.  I would think it's
possible that implementations could have problems at lower levels or could
have it set higher with no problem.  Thus, more guidance in adjusting that
number would be helpful. 

Now, comments on Filter-format, most of which are very similar to the
previous comments for filter-funct. I had a few other comments marked on my
hardcopy, but I think those have already been brought up:

- Update the document to the new template per the updated guidelines
reflecting new IPR policies per RFCs:
http://www.ietf.org/ietf/1id-guidelines.txt

- Abstract. Is not particularly informative.  I don't think the 1st
paragraph is necessary at all as it only talks about things not related to
this document.  I don't find the 2nd paragraph helps much either.  I would
suggest replacing the 1st paragraph for the abstract with the 1st 2
paragraphs from section 2, with the recommended rewording suggested below,
leaving the current 2nd paragraph as a 3rd paragraph or final sentences of
the abstract. 

- Section 2. I would suggest clarifying the first paragraph by augmenting
the first paragraph by the following change from:
"  The filtering mechanism is expected to be particularly valuable to
   users of mobile wireless access devices."  

To: 
"  The filtering mechanism is expected to be particularly valuable and
primarily applicable to users of mobile wireless access devices."  

- Section 2. Related to the next comment on section 7, I think the following
should be added at the end of that 2nd paragraph: 
" However, implementors need to be aware of the computational burden on the
source of the event notification.  This is discussed further in section 7."
  
- Section 7. <Duplicate comment for filter-funct>Certainly, limiting the
number of occurrences to 20 would help limit the DoS attacks, however, it
seems that the computational intensity of these filters in general should
really be highlighted much earlier in the document. I would think this would
be useful in the introduction in the 2nd paragraph where the applicability
of filtering relative to specific devices is discussed.  It may well be a
good idea to limit this spec, to systems that must support such devices, due
to the computational intensity. Per my next comment, this is an engineering
tradeoff, so it's not just a security issue, it's a system capacity and
performance issue (for the entity handling the filters) 

- Section 7. <Duplicate comment for filter-funct> Related to the previous
comment, I also think that 20 is rather arbitrary and it would seem that 20
could certainly be a good default recommendation, but that systems need some
engineereing to determine the optimum value.  Do you all have concrete
implementation experience that might help shed some light on why 20 is a
good number?  Perhaps, this has been discussed and I just missed it.  But,
this would be useful information for folks to have.  I would think it's
possible that implementations could have problems at lower levels or could
have it set higher with no problem.  Thus, more guidance in adjusting that
number would be helpful. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, July 13, 2004 2:42 AM
To: [email-masked]; [email-masked]
Subject: [Simple] RE: WGLC: Event Filtering

There are very few days left for the WGLC of these drafts. Please send your
comments a.s.a.p. I've had good comments for the filter-format draft but
would appreciate some more comments for filter-funct.

Thanks,
Hisham

---

From: [email-masked]
Date: Wed, 14 Jul 2004 12:00:39 +0300

Hi Mary,

Thanks for your time and comments. Responses inline...

> From: Khartabil Hisham (Nokia-TP-MSW/Helsinki) 
> Sent: 14.July.2004 11:31
> Subject: FW: [Simple] RE: WGLC: Event Filtering
> 
> 
> 
> From: ext Mary Barnes [mailto:[email-masked]]
> Sent: 14.July.2004 05:11
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); [email-masked]
> Cc: [email-masked]
> Subject: RE: [Simple] RE: WGLC: Event Filtering
> 
> 
> I do have a few comments, mostly editorial/nits, but there is 
> one general concern about the computational burden on the 
> server that's generating these event filtered notifications, 
> as I think that's not been very thoroughly addressed (except 
> in the security section) and I think it needs to be 
> - Update the document to the new template per the updated 
> guidelines reflecting new IPR policies per RFCs: 

Done.

> - Abstract. Is not particularly informative.  I don't think 
> the 1st paragraph is necessary at all as it only talks about 
> things not related to this document.  I would remove that and 
> update the 2nd paragraph by changing from:
>    filtering rules applied to them is described.  The 
> document also describes 

Done.

> - Section 7. Certainly, limiting the number of occurrences to 
> 20 would help limit the DoS attacks, however, it seems that 
> the computational intensity of these filters in general 
> should really be highlighted much earlier in the document. I 
> would think this would be useful in the introduction in the 
> 2nd paragraph where the applicability of filtering relative 
> to specific devices is discussed.  It may well be a good idea 
> to limit this spec, to systems that must support such 
> devices, due to the computational intensity. Per my next 
> comment, this is an engineering tradeoff, so it's not just a 
> security issue, it's a system capacity and performance issue 
> (for the entity handling the filters) 

I agree with you, but I struggled to write some meaningful text. Can you provide me with text? I would really appreciate it.

> - Section 7. <Duplicate comment for filter-funct> Related to 
> the previous comment, I also think that 20 is rather 
> arbitrary and it would seem that 20 could certainly be a good 
> default recommendation, but that systems need some 
> engineereing to determine the optimum value.  Do you all have 
> concrete implementation experience that might help shed some 
> light on why 20 is a good number?  Perhaps, this has been 
> discussed and I just missed it.  But, this would be useful 
> information for folks to have.  I would think it's possible 
> that implementations could have problems at lower levels or 
> could have it set higher with no problem.  Thus, more 
> guidance in adjusting that number would be helpful. 

The number was not according to any implementation experience, but was rather according to guesstimates I made using the presence document as a guide.  It is very difficult for a client to estimate the processing power of the server that is generating those notifications and therefore we must recommend a number for the client to follow. Having said that, you are right that some servers might be able to handle more than the recommended number enabling the client to set more filters.

> 
> 
> Now, comments on Filter-format, most of which are very 
> similar to the previous comments for filter-funct. I had a 
> few other comments marked on my hardcopy, but I think those 
> have already been brought up:
> - Update the document to the new template per the updated 
> guidelines reflecting new IPR policies per RFCs: 

Done.

> - Abstract. Is not particularly informative.  I don't think 
> the 1st paragraph is necessary at all as it only talks about 
> things not related to this document.  I don't find the 2nd 
> paragraph helps much either.  I would suggest replacing the 
> 1st paragraph for the abstract with the 1st 2 paragraphs from 
> section 2, with the recommended rewording suggested below, 
> leaving the current 2nd paragraph as a 3rd paragraph or final 
> sentences of the abstract. 

The abstract now reads:

"Filtering is a mechanism for defining the preferred content to be delivered and for specifying the rules for when the content should be delivered. In order to enable this, a format is needed to enable the subscriber to choose when notifications are to be sent to it and what they are to contain. This document presents a solution in the form of an XML document format.

The filtering mechanism is expected to be particularly valuable and primarily applicable to users of mobile wireless access devices."

> - Section 2. I would suggest clarifying the first paragraph 
> by augmenting the first paragraph by the following change from:
> "  The filtering mechanism is expected to be particularly 
> valuable and       primarily applicable to users of mobile 
> wireless access devices."  

Done.

> - Section 2. Related to the next comment on section 7, I 
> think the following should be added at the end of that 2nd paragraph: 
> " However, implementors need to be aware of the computational 
> burden on the source of the event notification.  This is 
> discussed further in section 7."

Done.

>   
> - Section 7. <Duplicate comment for filter-funct>Certainly, 
> limiting the number of occurrences to 20 would help limit the 
> DoS attacks, however, it seems that the computational 
> intensity of these filters in general should really be 
> highlighted much earlier in the document. I would think this 
> would be useful in the introduction in the 2nd paragraph 
> where the applicability of filtering relative to specific 
> devices is discussed.  It may well be a good idea to limit 
> this spec, to systems that must support such devices, due to 
> the computational intensity. Per my next comment, this is an 
> engineering tradeoff, so it's not just a security issue, it's 
> a system capacity and performance issue (for the entity 
> handling the filters) 
> - Section 7. <Duplicate comment for filter-funct> Related to 
> the previous comment, I also think that 20 is rather 
> arbitrary and it would seem that 20 could certainly be a good 
> default recommendation, but that systems need some 
> engineereing to determine the optimum value.  Do you all have 
> concrete implementation experience that might help shed some 
> light on why 20 is a good number?  Perhaps, this has been 
> discussed and I just missed it.  But, this would be useful 
> information for folks to have.  I would think it's possible 
> that implementations could have problems at lower levels or 
> could have it set higher with no problem.  Thus, more 
> guidance in adjusting that number would be helpful. 

As above.

Thanks,
Hisham

> There are very few days left for the WGLC of these drafts. 
> Please send your comments a.s.a.p. I've had good comments for 
> the filter-format draft but would appreciate some more 
> comments for filter-funct.
> Thanks, 
> Hisham

---

From: "Mary Barnes" <[email-masked]>
Date: Wed, 14 Jul 2004 09:30:57 -0400

Hisham,

I've some suggestions for the wording below [MB]:

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, July 14, 2004 4:01 AM
To: Barnes, Mary [NGC:B601:EXCH]
Cc: [email-masked]
Subject: RE: [Simple] RE: WGLC: Event Filtering

Hi Mary,

Done.

Done.

> (for the entity handling the filters) 

I agree with you, but I struggled to write some meaningful text. Can you
provide me with text? I would really appreciate it.

> guidance in adjusting that number would be helpful. 

The number was not according to any implementation experience, but was
rather according to guesstimates I made using the presence document as a
guide.  It is very difficult for a client to estimate the processing power
of the server that is generating those notifications and therefore we must
recommend a number for the client to follow. Having said that, you are right
that some servers might be able to handle more than the recommended number
enabling the client to set more filters.

[MB] So, perhaps, the simplest thing is to make it a bit more explicit that
this number is a bit arbitrary and YMMV.  I would suggest changing the
wording in the last sentence of this section from:
"  To counter this, the server SHOULD only
   allow filters with no more than about 20 occurrences of the <what>,
   <changed>, <added> and <removed> elements."
To:
"  To counter this, the server MUST establish a limit on the number of  
   occurrences of the <what>,
   <changed>, <added> and <removed> elements allowed in the filters.  
   A default limit of 20 is RECOMMENDED, however, servers MAY raise or lower

   the limit depending upon their specific engineered capacity. "

[MB] I think the MUST is important in that first sentence as that's what
satisfies the security requirement to limit the DOS attack.  

Done.

The abstract now reads:

"Filtering is a mechanism for defining the preferred content to be delivered
and for specifying the rules for when the content should be delivered. In
order to enable this, a format is needed to enable the subscriber to choose
when notifications are to be sent to it and what they are to contain. This
document presents a solution in the form of an XML document format.

The filtering mechanism is expected to be particularly valuable and
primarily applicable to users of mobile wireless access devices."

Done.

Done.

As above.

Thanks,
Hisham

---

From: [email-masked]
Date: Wed, 14 Jul 2004 16:49:04 +0300

-----Original Message-----
From: ext Mary Barnes [mailto:[email-masked]]
Sent: 14.July.2004 16:31
To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
Cc: [email-masked]
Subject: RE: [Simple] RE: WGLC: Event Filtering

Hisham, 

-----Original Message----- 
From: [email-masked] [ mailto:[email-masked]] 
Sent: Wednesday, July 14, 2004 4:01 AM 
To: Barnes, Mary [NGC:B601:EXCH] 
Cc: [email-masked] 
Subject: RE: [Simple] RE: WGLC: Event Filtering 

Hi Mary, 

> From: ext Mary Barnes [ mailto:[email-masked]] 
> Sent: 14.July.2004 05:11 

Done. 

Done. 

[MB] So, perhaps, the simplest thing is to make it a bit more explicit that this number is a bit arbitrary and YMMV.  I would suggest changing the wording in the last sentence of this section from:

[MB] I think the MUST is important in that first sentence as that's what satisfies the security requirement to limit the DOS attack.   

Ok done. I also added text to the introduction as you suggested for the format draft:

"However, implementers need to be aware of the computational burden on the source of the event notification. This is discussed further in <xref target="security"/>."

Thanks again,

Hisham