Document: draft-ietf-simple-filter-format-03.txt
Trigger: IETF Last Call, November 2004
Reviewer: Elwyn Davies
AD: Ted Hardie
Review Date: 28 November 2004

Intended status: Proposed Standard

Summary: There appear to be a number of technical issues which need to
be resolved before this document can progress.  In my opinion the
document needs a further revision within the WG before consideration
by the IESG.

Review: In general the document seems well written and is clear as to
its purpose and usefulness.  There are a number of minor points of
English which I will communicate to the editor separately as they do
not fundamentally affect the document and I believe a further round of
review will be needed.

In my opinion the following technical points need to be resolved:

Sections 3.6: Initial state for 'previous XML document':
========================================================

Comparisons are specified with respect to the 'previous XML document'
sent as a result of the filter specification.  There is no
specification of what this document should be when the filter is first
created (e.g. assume that a notional change occurs when the filter is
created – either force sending of a document or create a notional
'previous XML document' that would have been sent).

Section 3.6: Interaction of changes and filter enable/disable:
==============================================================

Related to the previous point, there is no discussion of whether a
notification should be sent if a change has occurred during a period
when a filter is disabled and subsequently re-enabled.  Similarly, if
a filter is created in the disabled state, is the initial state
recorded at the point of creation or when the filter is later enabled.
If the latter, then should a new initial state and document send occur
whenever the filter is enabled.

Section 3.4: Scope of 'id' attribute for filters:
=================================================

The id attribute is specified as needing to be unique within a
<filter-set>.  However, it does not appear that the <filter-set> is
itself identified: If I understand correctly (and I am not an expert
here), multiple <filter-set>s could be sent for a given namespace and
(optionally) package.  Unless the id is unique across all
<filter-set>s applicable to the same namespace/package, it is not
clear that later remove or enable/disable requests could be correctly
applied.

Section 3.4: Need/Desirability of <what> and <trigger> elements in
updates:
===========================================================================

As specified, *every* <filter> MUST have either a <what> or a
<trigger> element.  Is this either necessary or desirable when an
element is later enabled or disabled? What is the meaning if the
<what>/<trigger> elements are present but *different* from the
originals (should the specification be changed, the request ignored as
an error or the request actioned ignoring the modified
specifications)?  (An example of this usage would help). In practice
the XML schema in Section 6 does not enforce the need for at least one
of the two elements: If possible the words in 3.4 and the schema
should be synchronised.  Although it would be rather overkill, ABNF
for the whole filter-set element might help and should be able to
clarify the possible cases.

Other issues:
- Use of 'when' in Abstract and Introduction: The use of 'when' brings
  the idea of time into the reader's mind.  In the specification time
  is not especially relevant – what is actually discussed is
  triggering or causation.  I would suggest that 'cause' is used
  instead of 'when' because the user will have no control over the
  time when the cause triggers the sending of a document.
- Conventionally, Section 1 is always the Introduction, and the
  conventions paragraph follows on.
- Title of Section 3: The use of 'SIMPLE filter' (as opposed to
  simple-filter which is used everywhere else will not have any
  rationale once the SIMPLE WG is closed and the document becomes an
  RFC.
- Section 2: The term 'package' has a specific meaning here but is not
  defined or a pointer to a relevant reference given.
- Section 3.1: Examples of relevant transport protocols might help
- I have not checked (using any kind of compiler/checker tool) that
  the schema and examples are well-formed: This should be done.
- Section 7: A reference for SIP S/MIME is desirable.
- Section 8: Should be phrased as explicit requests to IANA.
- The authors should run the idnits tool: It identifies a number of
  minor layout issues (4 residual uses of TAB and some double spaces).