Documents: draft-ietf-simple-filter-format-03.txt and draft-ietf-simple-event-filter-funct-03.txt Trigger: IETF Last Call, November 2004 Reviewer: Elwyn Davies AD: Ted Hardie Review Date (amended): 11 January 2004 Intended status: Proposed Standard Summary: After discussion of my original Last Call review of the format draft with the authors it appears that this draft should be considered together with the associated 'functionality' draft draft-ietf-simple-event-filter-funct-03.txt. Even after extensive discussion with the authors to try to ensure that I was not misunderstanding the work, I believe there are still a number of technical issues which need to be resolved before either document can progress. In my opinion the documents need further revision within the WG before consideration by the IESG. Additionally, it has become clear that there are significant inconsistencies between the two drafts. I therefore recommend a DISCUSS related to the inconsistencies and technical issues if the documents are brought to the IESG without further modification. Review: The format draft has now been re-reviewed in parallel with draft-ietf-simple-event-filter-funct-03, and various points raised with the authors. In my view the points raised in my original review (28 November) have not all been adequately refuted and it has become clear that the two drafts are inconsistent in several ways. Overall I am not convinced that separating the functionality draft from the format draft actually helps. If size is a consideration, there is considerable overlap between the examples in the two documents and these in total represent at least a quarter of the total page count, so that a combined document would be considerably less than the sum of its parts. Likewise there is overlap in the Security considerations. It would also make it easier to sort out the consistency issues. In general the format document seems well written and is clear as to its purpose and usefulness. I was less happy with the functionality draft: some of the language is convoluted (especially around the issue of the resources to which particular filters apply) and the interaction with predecessor documents (SIP base - RFC3261, unfiltered event handling - RFC 3265) is not as clear as it might be . I believe a further round of review will be needed, both on account of the technical issues noted below and the inconsistencies between the two documents. In my view the general area AD should post a DISCUSS on these matters for both documents. In my opinion the following technical points need to be resolved: With regards to draft-ietf-simple-filter-format-03.txt: 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. I think the intention is to keep an image of the (complete) package data at each time a NOTIFY is sent for a particular subscriber, with the image being connected to the subscriber. There is a corner case when the first SUBSCRIBE is made for a subscriber: presumably a notional previous XML doc has to be created at this point based on current values but this is not explained - this should be stated if so. I also believe it should be stated whether this would always result in a NOTIFY immediately because values will have changed from the non-value they had before or whether this does not result in a NOTIFY because there isn't really a change. 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: Need for 'id' attribute for filters: ================================================= The id attribute is specified as needing to be unique within a . It is not all clear what the point of the filter id is given that only one filter can be active for a given URI or domain at any one time (give or take the possibility that sub-components may have different filters applicable to the subset, if I understand correctly). This seems to indicate that the id is not very useful. It is possible that this is related to the id in the Event header of the SUBSCRIBE message which is supposed to be returned with NOTIFY responses, but I see no specification requiring that the filter id is passed back with the resulting notifications. Section 3.4: Need/Desirability of and elements in updates: =========================================================================== As specified, *every* MUST have either a or a element. Is this either necessary or desirable when an element is later removed, enabled or disabled? What is the meaning if the / 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. ====================================================== With regards to draft-ietf-simple-event-filter-funct-03.txt: Sections 3.3.3, 4.2, and 5.2.2: Functionality of enable/disable not defined =========================================================================== These sections do not address the enable attribute provided with each filter. Section 3.3.3: Need for filter id ================================= As discussed for Section 3.4 of the format draft, the need for an id with a filter is unclear. Also it is not clear what is its interaction with the id in the event header associated with the SUBSCRIBE dialog. Since there is only one filter at a time associated with a given resource URI, why is this id needed? Unlike the event header id it is not apparently sent back as part of the NOTIFY responses. Section 5.3: Possibility of incompatibilities between available ACCEPT formats and filter output: ============================================================================== Not being a deep expert, I am unsure if there is possibility that the very specific information implied by the filter outputs here are potentially incompatible with some or all of the formats that might be specified in the ACCEPT header. If that was conceivable, the behavior should be specified. ========================================================== Other issues: draft-ietf-simple-filter-format-03.txt: - 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 - The language around matching of URIs is slightly different from the similar language in the functionality draft (nothing about domains in the functionality draft). - Section 3.6.1.4: I think I know what is meant by 'MUST match the 'by' type of decimal' but there should be a better way of expressing this. - 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. - Section 10.2: Arguably Ref [15] is normative. - The authors should run the idnits tool: It identifies a number of minor layout issues (4 residual uses of TAB and some double spaces). - There are some additional language/editorial nits - Section 2, para 4: s/using the XML/using an XML/, s/criteria is/criteria are/ - Section 3.2, para 2: s/criteria is/criteria are/ - Section 3.5: s/additive. I.e./additive, i.e.,/ - Section 3.5.1, para 2: s/but may /but MAY / (debateable) - Section 3.5.2, para 3: s/reveresed/reversed/ - Section 7: s/flitered/filtered/ draft-ietf-simple-event-filter-funct-03.txt: - Conventionally, Section 1 is always the Introduction, and the conventions paragraph follows on. - Section 2: The caveats at the end of the section (everything after 'is described in [5].' In the last three paragraphs) do not belong in the intro but should be placed in the appropriate sub-sections of sections 3,4 and 5. - Section 3.3, paras 3 and 4: Para 4 should be before para 3. Para 3 is ambiguous: s/No content in the body of a SUBSCRIBE indicates to the notifier that no filter is being requested/ If the SUBSCRIBE message does not contain a body of type 'application/simple-filtering+xml' and the server receiving is capable of message filtering as described in this document. The server should behave as described in [3], i.e. the notifier.../ [This still isn't really right as the whole para is too convoluted]. - Section 3.3.1: This is one point where the separation of format and function is really a problem: This document really needs a summary of the filter specification here. - The authors should run the idnits tool - Editorial/language nits: - Section 3.3.2,para 1 (at end):s/[2]./[2])./ - Section 4: s/Resource List Server/Resource List Server(RLS)/ - Section 5.3.1: s/fliter/filter/ - Section 7: s/flitered/filtered/