[Simple] WGLC Comments on draft-ietf-sip-xcapevent-01
Ben Campbell <ben@estacado.net> Wed, 02 April 2008 01:53 UTC
Return-Path: <simple-bounces@ietf.org>
X-Original-To: simple-archive@megatron.ietf.org
Delivered-To: ietfarch-simple-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0EA53A69F4; Tue, 1 Apr 2008 18:53:36 -0700 (PDT)
X-Original-To: simple@core3.amsl.com
Delivered-To: simple@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D14243A6945; Tue, 1 Apr 2008 18:53:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.788
X-Spam-Level:
X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=0.811, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vszwBI922c2x; Tue, 1 Apr 2008 18:53:33 -0700 (PDT)
Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 0E0BA3A69F4; Tue, 1 Apr 2008 18:53:32 -0700 (PDT)
Received: from [10.0.1.193] (adsl-68-94-18-109.dsl.rcsntx.swbell.net [68.94.18.109]) (authenticated bits=0) by estacado.net (8.14.2/8.14.1) with ESMTP id m321rPYl007541 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 1 Apr 2008 20:53:30 -0500 (CDT) (envelope-from ben@estacado.net)
Message-Id: <5DDFCB0D-ADEC-49A7-BDDC-4112A011CAF8@estacado.net>
From: Ben Campbell <ben@estacado.net>
To: jari.urpalainen@nokia.com
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Tue, 01 Apr 2008 20:53:25 -0500
X-Mailer: Apple Mail (2.919.2)
Cc: Sip List <sip@ietf.org>, Simple WG <simple@ietf.org>
Subject: [Simple] WGLC Comments on draft-ietf-sip-xcapevent-01
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions <simple.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/simple>, <mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/simple>, <mailto:simple-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org
Hi, I have reviewed draft-ietf-sip-xcapevent-01 for WGLC, and have some comments. Apologies in advance for getting this in late. General: While I do not have many major technical concerns, I think the presentation could use some work. I share Miguel's concern that the organization of section 4.1 needs work. More specifics below: Specific Comments: Section 4.1 Paragraph 2 (editorial): "Once these nodes will be created, the notification bodies will indicate their content." I find this sentence confusing. I suggest something like "If this node is later created, the notification body will indicate its content." Section 4.4, paragraph 1(clarity): "The usage of hierarchical lists and <entry> references, etc. can thus be omitted." You say that the usage of hierarchical lists and <entry> references can be omitted. Are they actually being forbidden in this context, or do you just mean to say that they are optional? If features of the resource list format are forbidden, then this draft needs normative language saying explicitly what is not to be used. If you just mean to say that they are optional, what are the interoperability issues if one device chooses to use them but the peer does not understand them? "As it is anticipated that the XCAP server will be collocated with the SIP notifier, the subscriber MAY use relative XCAP URIs." Is it the authors' intention to require this collocation? That seems to be an architectural consequence of allowing relative URIs, unless we assert that if an implementation is architected differently, it is up to the implementation to be able to dereference relative URIs. Paragraph 2(editorial): "If no Accept header is specified to a SUBSCRIBE request, the NOTIFY messages will also contain bodies in this MIME type." I am confused by the word "also" in this context--does this imply that the body in this MIME type is in addition to some other body? I think you just mean to say that the default is xcap-diff+xml if the Accept header is ommitted, but the wording is confusing. Section 4.7, first paragraph(clarity): "Once there are superfluous resource selections in the requested URI list, the notifier SHOULD NOT provide overlapping similar responses for these resources." The sentence is confusing. "Once there are..." implies that there _will_ eventually be superfuous resource selections. I think you mean to say "If there are..." "Only the resources where the authenticated user has read privilege, will be included in the XCAP-Diff format." That seems like a normative statement that needs normative language. The last half of the paragraph is hard to follow, as it intermingles three distinct ideas each worthy of its own paragraph. That is, 1) Subscriber must have read permissions to see things, 2) Subscriptions to elements that don't exist yet are still kept in case the element is created in the future, and 3) What happens if the subscriber switches event parameters in a re-subscribe. Also, have we thought about the performance and DoS implications of requiring the notifier to keep subscription state for elements that may or may not exist at some point in the future? I'm not saying there is a problem, but it raises a warning flag to me. I'm willing to believe it is okay, but it might be worth some text explaining that. Paragraph 3 (clarity): I'm not sure what the MUST applies to here--are you saying that the server MUST check for the condition you list as an example, or simply that, if the notifier chooses not to send XML-Patch-Ops patches for reasons of local policy, it MUST fall back to xcap-patching mode? Also, I suggest reversing the order of paragraphs 3 and 4, as 4 introduces the general principle, and 3 is more about corner cases. Paragraph 5 (clarity): "RFC 3265 [RFC3265] proposes utilization of a "version" attribute information to state deltas in chapter 4.4. Partial-PIDF-Notify [I-D.ietf-simple-partial-notify] requires that notifiers will not send a new request to the same dialog unless a successful response (200 OK) has been received for the last request. The latter applies also to this "xcap-diff" event package." This is confusing--you mention the version attribute but don't seem to indicate its use here. Why mention it at all, except maybe in a paragraph explaining why it wasn't chosen? OTOH, you do require the partial-pidf-notify approach--this needs some normative language, unless it is elsewhere and I missed it. section 4.8, paragraph 1 (editorial/clarity): " However, once all atomic XCAP modifications are indicated with both previous and new ETags of each resource, it is easy to chain the modification list for a document and possibly omit some of the patches based on the received ETag (with HTTP) of a document." s/"once all"/"since all" "After that the subscriber MAY send a re-subscription to start the diff "aggregation" on the server." Does this mean to imply the subscriber cannot start out with aggregation turned on? (I think this may be another case of presenting the edge case without presenting the primary use case first.) Paragraph 2: (substantive) You cannot safely use non-sequential CSeq to detect missing NOTIFY requests. For example, if the NOTIFY request is challenged by an intervening proxy, the subscriber will see non-sequential CSeq values. It may be unusual for NOTIFY to get challenged, but unless we forbid it, then we cannot depend on CSeq for this purpose. Paragraph 3 (editorial/clarity): "...look Section 5.1 of [I-D.ietf-simple-xml-patch-ops]..." s/look/see "It is hardly reasonable to signal this error to the notifier even if the error exists in the notifier process." I think there is an implication here that should be stated explicitly, that is, the subscriber does not send a non-2XX response to a NOTIFY because of an inability to apply the patch. Section 4.10 (substantive) It's not clear to me how this interacts with the "aggregation" mechanism. In particular, if the notifier has more than one change in the 5 second window, but the subscriber did not allow aggregation, how is it handled? Section 5, figure 3 (clarity): It would be nice to see this in context of an actual NOTIFY. Section 6, 2nd paragraph (nit): There is no need for a bullet list if it contains only one bullet. Section 7, Security Considerations (substantive) I think we need more here. What sort of authentication is adequate (particularly for authenticating the notifier.) Does the potential sensitive content create any need for privacy and integrity protection beyond that generically needed for SIP-Events? _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple
- [Simple] WGLC Comments on draft-ietf-sip-xcapeven… Ben Campbell
- Re: [Simple] WGLC Comments on draft-ietf-sip-xcap… Jari Urpalainen
- Re: [Simple] WGLC Comments on draft-ietf-sip-xcap… Ben Campbell
- Re: [Simple] WGLC Comments on draft-ietf-sip-xcap… Jari Urpalainen
- Re: [Simple] WGLC Comments on draft-ietf-sip-xcap… Ben Campbell
- Re: [Simple] WGLC Comments on draft-ietf-sip-xcap… Jari Urpalainen
- Re: [Simple] [Sip] WGLC Comments on draft-ietf-si… Paul Kyzivat
- Re: [Simple] WGLC Comments on draft-ietf-sip-xcap… Ben Campbell