From simple-bounces@ietf.org Tue Apr 1 14:13:06 2008 Return-Path: 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 11CB53A6C2A; Tue, 1 Apr 2008 14:13:06 -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 24FCD3A6C2A for ; Tue, 1 Apr 2008 14:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] 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 1pWTx0ES1TT9 for ; Tue, 1 Apr 2008 14:13:03 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 0CE8E3A6BA5 for ; Tue, 1 Apr 2008 14:13:02 -0700 (PDT) Received: from [192.168.2.6] (pool-71-164-164-40.dllstx.fios.verizon.net [71.164.164.40]) (authenticated bits=0) by nostrum.com (8.14.2/8.14.1) with ESMTP id m31LCtmr041742 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 1 Apr 2008 16:12:55 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: From: Robert Sparks To: Robert Sparks In-Reply-To: <7BE83C01-9CE9-4F7C-BF13-06AD9CE576A1@estacado.net> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 1 Apr 2008 16:12:54 -0500 References: <3D90175E-1897-496D-B25B-0372C2B6FEAF@nostrum.com> <7BE83C01-9CE9-4F7C-BF13-06AD9CE576A1@estacado.net> X-Mailer: Apple Mail (2.919.2) Received-SPF: pass (nostrum.com: 71.164.164.40 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.92.1/6530/Tue Apr 1 13:35:37 2008 on shaman.nostrum.com X-Virus-Status: Clean Cc: Jari Urpalainen , simple mailing list , sip-chairs@tools.ietf.org Subject: Re: [Simple] WGLC: draft-ietf-simple-xcap-diff-08 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org I see _zero_ comments to the list on this document since the LC was issued. Jari - did you get any comments directly? Folks: I need some evidence that somebody actually cares to see this published and has read what's in it. If you've read it and think its ready to go, please send a note to the list to that effect ASAP. RjS On Mar 17, 2008, at 10:18 AM, Robert Sparks wrote: > Please get your comments in on this draft as soon as you can. Be > sure to send comments on the SIP draft to the SIP list as well. > > RjS > > On Mar 10, 2008, at 6:22 PM, Robert Sparks wrote: > >> Folks - >> >> This is a Working Group Last Call for comments on >> http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap- >> diff-08.txt >> >> The editor for draft-ietf-simple-xcap-diff and draft-ietf-sip- >> xcapevent has indicated these drafts are ready for WGLC. >> We're coordinating the LC time between the two working groups. >> >> Please have your comments to the editor/list by three weeks from >> today (March 31,2008). >> >> Thanks, >> >> RjS >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Apr 1 15:33:56 2008 Return-Path: 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 4E3AB3A6C35; Tue, 1 Apr 2008 15:33:56 -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 EB2443A6C18 for ; Tue, 1 Apr 2008 15:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.611 X-Spam-Level: X-Spam-Status: No, score=-4.611 tagged_above=-999 required=5 tests=[AWL=1.988, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 UIFIw6F82iMJ for ; Tue, 1 Apr 2008 15:33:54 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id C40CD3A6B6C for ; Tue, 1 Apr 2008 15:33:53 -0700 (PDT) Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m31MWtK16013; Tue, 1 Apr 2008 22:32:55 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 1 Apr 2008 17:30:45 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] WGLC: draft-ietf-simple-xcap-diff-08 Thread-Index: AciUPTYsfctYatUTRLSE1g6GcfuohwACAeWg References: <3D90175E-1897-496D-B25B-0372C2B6FEAF@nostrum.com> <7BE83C01-9CE9-4F7C-BF13-06AD9CE576A1@estacado.net> From: "Mary Barnes" To: "Robert Sparks" , "Robert Sparks" Cc: Jari Urpalainen , simple mailing list , sip-chairs@tools.ietf.org Subject: Re: [Simple] WGLC: draft-ietf-simple-xcap-diff-08 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org I have reviewed the document and do care to see it published, but I'm not an XML expert, so can't comment on the technical correctness of the solution. I'm assuming folks with that expertise have reviewed the document? Also, the security section doesn't specifically recommend anything, just that " must provide sufficient security capabilities", without stating what might be needed or used. So, more detail might be needed (based on my experiences with the security directorate/ADS) - at least provide minimal recommendations. Perhaps, adding a note that in the case where SIP event packages are used, the security as described in RFC 3265 applies, which points back to SIP security mechanisms, might be sufficient. Other than that, I think the document should be ready to progress. Mary. -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Robert Sparks Sent: Tuesday, April 01, 2008 4:13 PM To: Robert Sparks Cc: Jari Urpalainen; simple mailing list; sip-chairs@tools.ietf.org Subject: Re: [Simple] WGLC: draft-ietf-simple-xcap-diff-08 I see _zero_ comments to the list on this document since the LC was issued. Jari - did you get any comments directly? Folks: I need some evidence that somebody actually cares to see this published and has read what's in it. If you've read it and think its ready to go, please send a note to the list to that effect ASAP. RjS On Mar 17, 2008, at 10:18 AM, Robert Sparks wrote: > Please get your comments in on this draft as soon as you can. Be > sure to send comments on the SIP draft to the SIP list as well. > > RjS > > On Mar 10, 2008, at 6:22 PM, Robert Sparks wrote: > >> Folks - >> >> This is a Working Group Last Call for comments on >> http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap- >> diff-08.txt >> >> The editor for draft-ietf-simple-xcap-diff and draft-ietf-sip- >> xcapevent has indicated these drafts are ready for WGLC. >> We're coordinating the LC time between the two working groups. >> >> Please have your comments to the editor/list by three weeks from >> today (March 31,2008). >> >> Thanks, >> >> RjS >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Apr 1 18:53:36 2008 Return-Path: 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 To: jari.urpalainen@nokia.com Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 1 Apr 2008 20:53:25 -0500 X-Mailer: Apple Mail (2.919.2) Cc: Sip List , Simple WG 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 references, etc. can thus be omitted." You say that the usage of hierarchical lists and 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 From simple-bounces@ietf.org Tue Apr 1 19:00:04 2008 Return-Path: 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 8A90E28C30E; Tue, 1 Apr 2008 19:00:04 -0700 (PDT) X-Original-To: simple@ietf.org Delivered-To: simple@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id DAD6C3A6C6A; Tue, 1 Apr 2008 19:00:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080402020001.DAD6C3A6C6A@core3.amsl.com> Date: Tue, 1 Apr 2008 19:00:01 -0700 (PDT) Cc: simple@ietf.org Subject: [Simple] I-D Action:draft-ietf-simple-imdn-07.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Instant Message Disposition Notification Author(s) : E. Burger, H. Khartabil Filename : draft-ietf-simple-imdn-07.txt Pages : 37 Date : 2008-04-01 Instant Messaging (IM) refers to the transfer of messages between users in real-time. This document provides a mechanism whereby endpoints can request Instant Message Disposition Notifications (IMDN), including delivery, processing, and read notifications, for page-mode instant messages. The Common Profile for Instant Messaging (CPIM) data format specified in RFC 3862 is extended with new header fields that enable endpoints to request IMDNs. A new message format is also defined to convey IMDNs. This document also describes how SIP entities behave using this extension. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-imdn-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-simple-imdn-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-01185900.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Tue Apr 1 19:06:25 2008 Return-Path: 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 37AD43A698D; Tue, 1 Apr 2008 19:06:25 -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 4DDAC3A6D09; Tue, 1 Apr 2008 19:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=0.649, 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 5jFuIWLrzn9b; Tue, 1 Apr 2008 19:06:22 -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 B45C03A6945; Tue, 1 Apr 2008 19:06:21 -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 m3224sjQ008787 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 1 Apr 2008 21:04:58 -0500 (CDT) (envelope-from ben@estacado.net) Message-Id: <4B6E5040-A282-4557-8C9B-07D442AB4EC7@estacado.net> From: Ben Campbell To: jari.urpalainen@nokia.com, jdrosen@cisco.com Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 1 Apr 2008 21:04:53 -0500 X-Mailer: Apple Mail (2.919.2) Cc: Sip List , Simple WG Subject: [Simple] WGLC review of draft-ietf-simple-xcap-diff-08 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org (cross posting to SIP at request of SIMPLE chairs.) Hi, I just completed a slightly belated WGLC review of draft-ietf-simple- xcap-diff-08. Caveat 1: I am absolutely the worst person in the IETF to review XML schema definitions. I hope someone who actually understands those is reviewing this draft. Caveat 2: This draft is only useful if it advances in lockstep with the xcapevent draft in SIP. IMHO, If that draft gets significant revisions as a result of the WGLC, this draft should probably wait with it, as substantive changes there could conceivable have impact here. Other than those caveats, I think this draft is ready to progress. Thanks! Ben. _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From AugustineshortsightedCase@streettracksgoldshares.com Tue Apr 1 19:48:47 2008 Return-Path: X-Original-To: ietfarch-simple-archive@core3.amsl.com Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E57EC3A6D60; Tue, 1 Apr 2008 19:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -75.186 X-Spam-Level: X-Spam-Status: No, score=-75.186 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DATE_IN_PAST_12_24=0.992, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_HCC=4.295, HELO_EQ_MODEMCABLE=0.768, HELO_EQ_MX=0.535, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_MLH_Stock1=0.87, USER_IN_WHITELIST=-100] 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 SRkXM49mGj4n; Tue, 1 Apr 2008 19:48:47 -0700 (PDT) Received: from jorge.mshome.net (host-70-45-86-2.onelinkpr.net [70.45.86.2]) by core3.amsl.com (Postfix) with SMTP id 371073A6CCC; Tue, 1 Apr 2008 19:48:46 -0700 (PDT) Received: from 17616892408966800.11649927432253366.15010911777733240.14886289993882315 (HELO localhost.localdomain) (18209573269849011.14651301247573130.13026038205028896.13856364513145199) by 13045500999879341.14213470257010423.10298904643781506.14709270729827824 with SMTP; Wed, 2 Apr 2003 22:38:01 +0600 Date: Wed, 2 Apr 2003 22:38:01 +0600 Message-Id: <3IX477EJXVWDA184@streettracksgoldshares.com> X-Mailer: MIME::Lite 3.01 (F2.72; A1.62; B3.01; Q3.01) X-Header-CompanyDBUserName: hpccm X-Header-MasterId: 221708 X-Header-Versions: Hewlett-Packard.7t0bn4nd0.fk@us.newsgram.hp.com X-FID: 10E36DBC-2051-46AF-B4E3-48CDEA50DCB4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit To: , , , , From: "Erin Case" Subject: Stock breaker report
Gold and Silver prices have been skyrocketing

The recent fall has given you the perfect time to get in and ride gold to $2 for the past week as the undiscovered gem of Gold Production

Now is the time to get in
Symbol : GSML

The move has started and this stock is definately dollar plus bound

This is not a fly by night, Its a real copmpany with real operations in the metals that are everyone's backup plans for the econimic worries

Dont miss out, Get in GSML and make the smart safe profits
From simple-bounces@ietf.org Wed Apr 2 03:04:26 2008 Return-Path: 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 6983D3A6E88; Wed, 2 Apr 2008 03:04:26 -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 322E728C469; Wed, 2 Apr 2008 03:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.216 X-Spam-Level: X-Spam-Status: No, score=-6.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 0SaiV1uuJuDN; Wed, 2 Apr 2008 03:04:22 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 64B3F3A6DC0; Wed, 2 Apr 2008 03:04:22 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m32A5cMt016686; Wed, 2 Apr 2008 05:06:25 -0500 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Apr 2008 13:03:59 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Apr 2008 13:03:59 +0300 Received: from [172.21.40.139] ([172.21.40.139]) by esebe105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Apr 2008 13:03:59 +0300 Message-ID: <47F35A1E.4070109@nokia.com> Date: Wed, 02 Apr 2008 13:04:14 +0300 From: Jari Urpalainen User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: ext Ben Campbell References: <5DDFCB0D-ADEC-49A7-BDDC-4112A011CAF8@estacado.net> In-Reply-To: <5DDFCB0D-ADEC-49A7-BDDC-4112A011CAF8@estacado.net> X-OriginalArrivalTime: 02 Apr 2008 10:03:59.0357 (UTC) FILETIME=[DECECAD0:01C894A8] X-Nokia-AV: Clean Cc: Sip List , Simple WG Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org ext Ben Campbell wrote: > 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: > right, it will be rephrased > 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." > much better phrased. > Section 4.4, paragraph 1(clarity): > "The usage of hierarchical lists and > references, etc. can thus be omitted." > > You say that the usage of hierarchical lists and 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. > in practice, the sip notifier must be aware of changes made by another protocol, i.e. http in this case. If these servers (notifier & http (xcap) daemon) are separated they need some sort of immediate mechanism to signal these events. It can be done with some unspecified ways, but the most simple one is when they are running on the very same host. However, even that simplest case is pretty hard (or complex enough) to implement properly (implementation description can be a long story although you are using OSS tools, like e.g. linux with Apache + xcap_module and some decent Sip stack with all the source code), and the intention is to define only the very simplest use-case here. It is not ruled out that they were separated but that would be much, much more difficult to implement, and there are many obstacles and open issues there. So there's magic (outside the scope of this i-d) here how to map the sip-uri to the xcap-root-uri, but this, the most simple use-case is what i'd expect to be implemented (and maybe, even some minor deployment as well ;-)). Also we agreed with Miguel to be more explicit about this magic, does it sound sufficient to you ? > 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. > right, by bad finglish. > 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..." right again. > > "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. > again. > 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. I'll try to clarify it by a separation. > > > 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. good point. there are other ways to introduce DoS as well since diff-processing of many resources MAY be way too process-intensive. I'll add that in the security section. > > 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? the reason to drop the aggregation mode for that particular resource is that once the client have to use http, it might get out-of-sync (with "rapidly" changing resources), the rule is to be certain that it will not happen. I'll try to clarify. > > Also, I suggest reversing the order of paragraphs 3 and 4, as 4 > introduces the general principle, and 3 is more about corner cases. > ok. > 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. yep, this was notified by Miguel also > > > 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" ok. > > "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.) it can try to start in the aggregate mode straight away, but it may fail. So the safe way is to disable aggregation first before sync is achieved and enable it afterwards. I think I'll add something about this into those dreaded examples (in an appendix) > > > 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. ok, didn't think about that at all. > > Paragraph 3 (editorial/clarity): > > "...look Section 5.1 of > [I-D.ietf-simple-xml-patch-ops]..." > > s/look/see ok. > > "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. > right. > 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? yep this is indeed _difficult_. Easy to write (one sentence only), but really, really hard to implement properly ;-). First off there's a SHOULD directive fortunately... I'm not 100 % sure if you mean that xcap-patching is also disabled. So there's not a big difference in this context whether you have aggregation or xcap-patching modes, since in the xcap-patching mode you will see changes e.g. from "a" to "b" to "c" with all corresponding Etags while in the aggregate mode you'll see e.g. only changes from "a" to "c" in the notification body without the intermediate state. Certainly aggregation body is smaller but it fails to show the versioning history and the diff formats differ, but the end result will be the same certainly, i.e. "c". So _if_ you obey the timer, you wait for it to expire and then send the result in both cases (and of course during this timer interval you wait for any changes in these resources, and do something relevant, e.g. store internal object states). If there's not any patching modes applied, then you should wait for the timer to expire and send appropriate actions, i.e. document(s) has either been created, modified or deleted. IIRC, in partial PIDF where we use the exact same patchings there's not a single line about this since this timer is inherited from the base PIDF package. In summary, you just don't have to do anything mysterious with timers except wait for a certain period of time. In practice, it happens to be quite a challenging task (but these specs usually _ignore_ the implementation PITA ;-)) > > Section 5, figure 3 (clarity): > > It would be nice to see this in context of an actual NOTIFY. I'll try to digest something into an appendix. That being said, the important things are bodies... > > Section 6, 2nd paragraph (nit): > > There is no need for a bullet list if it contains only one bullet. right. > > 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? > yep, besides DoS TLS & S/MIME recommendations some text about identity "mapping" between http & sip would be reasonable. Anything else ? THANKS Ben, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Apr 2 03:08:48 2008 Return-Path: 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 F12B63A6ED4; Wed, 2 Apr 2008 03:08:47 -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 0C48E3A6E88; Wed, 2 Apr 2008 03:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.312 X-Spam-Level: X-Spam-Status: No, score=-6.312 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 pSUVaPEIJ0AT; Wed, 2 Apr 2008 03:08:36 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id E496F28C4A1; Wed, 2 Apr 2008 03:08:11 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m32AA7BI021543; Wed, 2 Apr 2008 05:10:14 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Apr 2008 13:08:02 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Apr 2008 13:08:02 +0300 Received: from [172.21.40.139] ([172.21.40.139]) by esebe105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Apr 2008 13:07:56 +0300 Message-ID: <47F35B0C.6010304@nokia.com> Date: Wed, 02 Apr 2008 13:08:12 +0300 From: Jari Urpalainen User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: ext Ben Campbell References: <4B6E5040-A282-4557-8C9B-07D442AB4EC7@estacado.net> In-Reply-To: <4B6E5040-A282-4557-8C9B-07D442AB4EC7@estacado.net> X-OriginalArrivalTime: 02 Apr 2008 10:07:56.0751 (UTC) FILETIME=[6C4E3DF0:01C894A9] X-Nokia-AV: Clean Cc: Sip List , Simple WG Subject: Re: [Simple] WGLC review of draft-ietf-simple-xcap-diff-08 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org ext Ben Campbell wrote: > (cross posting to SIP at request of SIMPLE chairs.) > > Hi, > > I just completed a slightly belated WGLC review of > draft-ietf-simple-xcap-diff-08. > > Caveat 1: I am absolutely the worst person in the IETF to review XML > schema definitions. I hope someone who actually understands those is > reviewing this draft. > well, at least these validate with ... > Caveat 2: This draft is only useful if it advances in lockstep with > the xcapevent draft in SIP. IMHO, If that draft gets significant > revisions as a result of the WGLC, this draft should probably wait > with it, as substantive changes there could conceivable have impact here. > > Other than those caveats, I think this draft is ready to progress. > > Thanks! > > Ben. > yep, these are definitely coupled anyways. thanks, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Apr 2 03:19:36 2008 Return-Path: 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 92EE03A6EEB; Wed, 2 Apr 2008 03:19: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 BD88D3A6E97 for ; Wed, 2 Apr 2008 03:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.369 X-Spam-Level: X-Spam-Status: No, score=-6.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 r1sBeRSZemXV for ; Wed, 2 Apr 2008 03:19:35 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id A05683A68AD for ; Wed, 2 Apr 2008 03:19:34 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m32AJ6LE026212; Wed, 2 Apr 2008 13:19:17 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Apr 2008 13:19:16 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Apr 2008 13:19:16 +0300 Received: from [172.21.40.139] ([172.21.40.139]) by esebe105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Apr 2008 13:19:16 +0300 Message-ID: <47F35DB3.4040600@nokia.com> Date: Wed, 02 Apr 2008 13:19:31 +0300 From: Jari Urpalainen User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: ext Mary Barnes References: <3D90175E-1897-496D-B25B-0372C2B6FEAF@nostrum.com> <7BE83C01-9CE9-4F7C-BF13-06AD9CE576A1@estacado.net> In-Reply-To: X-OriginalArrivalTime: 02 Apr 2008 10:19:16.0025 (UTC) FILETIME=[012F3A90:01C894AB] X-Nokia-AV: Clean Cc: sip-chairs@tools.ietf.org, simple mailing list , Robert Sparks Subject: Re: [Simple] WGLC: draft-ietf-simple-xcap-diff-08 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org ext Mary Barnes wrote: > I have reviewed the document and do care to see it published, but I'm > not an XML expert, so can't comment on the technical correctness of the > solution. I'm assuming folks with that expertise have reviewed the > document? > > mostly the "correctness" is based on xml-patch-ops, this makes an "upper" layer on top of that, i.e. the xml stuff is much simpler, though there are some extension points, which are made as liberal as the w3c schema tool reasonably allows. > Also, the security section doesn't specifically recommend anything, just > that " must provide sufficient security capabilities", without stating > what might be needed or used. So, more detail might be needed (based on > my experiences with the security directorate/ADS) - at least provide > minimal recommendations. Perhaps, adding a note that in the case where > SIP event packages are used, the security as described in RFC 3265 > applies, which points back to SIP security mechanisms, might be > sufficient. I can add a reference to sip notification framework, since it is the most likely use-case for this. > > > Other than that, I think the document should be ready to progress. > > Mary. > > Thanks Mary, --Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Apr 2 07:55:47 2008 Return-Path: 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 2976428C1ED; Wed, 2 Apr 2008 07:55:47 -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 614013A6DC0; Wed, 2 Apr 2008 07:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 r8FpvYeHSIme; Wed, 2 Apr 2008 07:55:40 -0700 (PDT) Received: from dizzyd.com (dizzyd.com [207.210.219.225]) by core3.amsl.com (Postfix) with ESMTP id 659583A6DD7; Wed, 2 Apr 2008 07:55:40 -0700 (PDT) Received: from dialup-4.227.192.106.Dial1.Denver1.Level3.net (dialup-4.227.192.106.Dial1.Denver1.Level3.net [4.227.192.106]) (Authenticated sender: stpeter) by dizzyd.com (Postfix) with ESMTPSA id C091040053; Wed, 2 Apr 2008 08:54:34 -0600 (MDT) Message-ID: <47F39E4D.4070409@stpeter.im> Date: Wed, 02 Apr 2008 08:55:09 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.12) Gecko/20080213 Thunderbird/2.0.0.12 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: "sip@ietf.org" , simple mailing list , XMPP Extension Discussion List Subject: [Simple] new SIP-XMPP list X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0615076511==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0615076511== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050807080508060105080102" This is a cryptographically signed message in MIME format. --------------ms050807080508060105080102 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit FYI, some folks who want to better define interworking between SIP and XMPP have started an informal discussion list. You can subscribe via either of the following URLs: http://mail.jabber.org/mailman/listinfo/sip-xmpp mailto:sip-xmpp-request@xmpp.org The intended outcome of these efforts is a full set of I-Ds that define mappings for addresses, presence, "pager mode" messages, 1-to-1 chat sessions (via MSRP on the SIP side), multiparty chat sessions (via MSRP on the SIP side and MUC on the XMPP side), multimedia sessions (via Jingle on the XMPP side), and eventually even features like file transfer, notifications, and device capabilities. We may also request a BOF at a future IETF meeting for the purpose of forming a working group or exploratory group (in accordance with RFC 5111). However, that is yet to be determined. Right now we're just hashing out some of the issues involved with interworking, so if you have an interest in the topic, feel free to join the list. Thanks! Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms050807080508060105080102 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYQDCC B3AwggbZoAMCAQICAQowDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0 MDUxNDUyMTNaFw0xMDA0MDQxNDUyMTNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWlsIEZy ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAPEaOcSx5ZNexwo1zJNcX48UV0UtkNtWX3qa9ZaX2VZilgIz eIrObloQV0Ma2rdgqosW9xMb5u3lBVIumt7fEwgMqqtDa3F2Qudelv93P9z2nbmn7X4GnCKA IQcW97KOSgQQHaVPHq03xGFbszx+LOKrBi/xv3bcGxtYrH+10M1nHbCRo8U2+zcJQowxoI+O U5nhko9vU25Jp8ZQ2fROH6C2TSjZuanzMTyvc5+dJiN2Hm2MhAMrqO7pUGhDKuUvnmKpAcwj eYQHU51mvlB4IId+4bTEwVoG4AMJ8RXB47VdJevN0yqeJSACyoRft4w4OpqFysR1HTT6aE6u xLg9ZC0CAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud DgQWBBQErNskd1NGRpZfFwFcfUJHvUgZCDCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0 eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0 YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6 Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5 BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50 ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0 cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQBc1g6H yT3ZrGb0Kq+kkqetnSXtcwffHEr6Tia2XqCqPLLzdZ8VTxVjeq/Kpg2u+8cGASIl1U45XmWa v4Vez+jSSnChRHwidmbwjCtNBFxr4C/Nkgs8wk2zNQbh+zlDKNophJT7+DVOhnIMJzdNkQW0 4STurMCFwLoyx5k1rDHQYTCCCGIwggdKoAMCAQICAwF4qjANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDcwODIyMjExMzI3WhcNMDgwODIxMjExMzI3WjCBujELMAkGA1UE BhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxGjAYBgNVBAoTEVBl dGVyIFNhaW50LUFuZHJlMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALC1dkqD gghuvUCkEloRDX50TTJ6Szj1BqtMpYq+An66BwkWfP07uay+jHori77776wk1/Ajk1nTSHX+ JWo+JWwVXYWBX+Zd780bB0FGShYlHGwMhd/pxX9sT4KW3D+r8sIHVbTGdudSweuNdBhqr1iE cjze75hpywMkk1OQhTkseQxI5owa9M31JOdNEX0Ja6esyhwwtqqTNC86OujXwa2wew8GTRJE 9p2I0B1VCsKuJaPatbIcf9OFiTSODb5vyoq3+lrElh6V6BXKxEfQ4D2HCSY+5UmlKdnltzvN bqxyaTYQi1YGsFzew7ST3R8P5jrCq2cvRjGrTKVojZXgPZ0CAwEAAaOCBHgwggR0MAwGA1Ud EwQFMAMCAQAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAd BgNVHQ4EFgQUl7CU2dS/alOwLIHV/Oc2RkGDYugwgd0GA1UdIwSB1TCB0oAUBKzbJHdTRkaW XxcBXH1CR71IGQihgbakgbMwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxDjAM BgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYDVQQLExFDQSBBdXRo b3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkx ITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZ4IBCjCCAUAGA1UdIASCATcwggEz MIIBLwYLKwYBBAGBtTcBAQQwggEeMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNv bS5vcmcvaW50ZXJtZWRpYXRlLnBkZjAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwgbMGCCsGAQUFBwICMIGmMBQWDVN0YXJ0Q29tIEx0ZC4wAwIB ARqBjUxpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0 aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gUG9saWN5IGF2YWlsYWJsZSBh dCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjBkBgNVHR8EXTBbMCygKqAo hiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDov L2NybC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDCBhAYIKwYBBQUHAQEEeDB2MDcGCCsG AQUFBzABhitodHRwOi8vb2NzcC5zdGFydGNvbS5vcmcvc3ViL2NsYXNzMy91c2VyL2NhMDsG CCsGAQUFBzAChi9odHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc3ViLmNsYXNzMy51c2VyLmNh LmNydDARBglghkgBhvhCAQEEBAMCBaAwMQYJYIZIAYb4QgENBCQWIlN0YXJ0Q29tIFRydXN0 ZWQgRW1haWwgQ2VydGlmaWNhdGUwMgYJYIZIAYb4QgEEBCUWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9jYS1jcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwOi8vY2VydC5zdGFydGNv bS5vcmcvY3J0dTMtY3JsLmNybDAyBglghkgBhvhCAQgEJRYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwIwYDVR0SBBwwGoYYaHR0cDovL2NlcnQuc3RhcnRjb20ub3Jn MA0GCSqGSIb3DQEBBQUAA4IBAQCdG1L0T4OT1x4X/cKsuHxgijRaZGGiVECcn5+1X7E3H54/ yDkUqWAp6MZ3hZm36pzTYYnl+5M6vldLcqFCVpD7MgH6Kmu+r6pXAjU33k1RIHnkBvQ6KGlR p0RjfaZW/2MkG07vF2QTLbx6KIhi0pa9Bg9wlqyw+C2g6FYnfmrdJLgGrxUXek8DSZNjZ/AA 75OoutrWkBtdaL2TbFiawdbGuJbSoQLHqLrNhT8f74Oec7ReOmuUTEL8hsFU0sbY/n2e9Wna 1Vzze3nZPbyPiC5F88p88gVLB9mKkOzleYefYiQw8LABz5x1MI+w0bNKNPLviJ/KnHGFEfVL z1oMHyC3MIIIYjCCB0qgAwIBAgIDAXiqMA0GCSqGSIb3DQEBBQUAMIGvMQswCQYDVQQGEwJJ TDEPMA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpT ZWN1cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQ cmltYXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9y ZzAeFw0wNzA4MjIyMTEzMjdaFw0wODA4MjEyMTEzMjdaMIG6MQswCQYDVQQGEwJVUzERMA8G A1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEaMBgGA1UEChMRUGV0ZXIgU2FpbnQt QW5kcmUxLDAqBgNVBAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRow GAYDVQQDExFQZXRlciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBl dGVyLmltMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsLV2SoOCCG69QKQSWhEN fnRNMnpLOPUGq0ylir4CfroHCRZ8/Tu5rL6MeiuLvvvvrCTX8COTWdNIdf4laj4lbBVdhYFf 5l3vzRsHQUZKFiUcbAyF3+nFf2xPgpbcP6vywgdVtMZ251LB6410GGqvWIRyPN7vmGnLAyST U5CFOSx5DEjmjBr0zfUk500RfQlrp6zKHDC2qpM0Lzo66NfBrbB7DwZNEkT2nYjQHVUKwq4l o9q1shx/04WJNI4Nvm/Kirf6WsSWHpXoFcrER9DgPYcJJj7lSaUp2eW3O81urHJpNhCLVgaw XN7DtJPdHw/mOsKrZy9GMatMpWiNleA9nQIDAQABo4IEeDCCBHQwDAYDVR0TBAUwAwIBADAL BgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSX sJTZ1L9qU7AsgdX85zZGQYNi6DCB3QYDVR0jBIHVMIHSgBQErNskd1NGRpZfFwFcfUJHvUgZ CKGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UEBxMFRWls YXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0eSBEZXAu MSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8GCSqGSIb3 DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEKMIIBQAYDVR0gBIIBNzCCATMwggEvBgsrBgEE AYG1NwEBBDCCAR4wNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9pbnRl cm1lZGlhdGUucGRmMC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s aWN5LnBkZjCBswYIKwYBBQUHAgIwgaYwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGNTGltaXRl ZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0 aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMGQGA1UdHwRdMFswLKAqoCiGJmh0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0 Y29tLm9yZy9jcnR1My1jcmwuY3JsMIGEBggrBgEFBQcBAQR4MHYwNwYIKwYBBQUHMAGGK2h0 dHA6Ly9vY3NwLnN0YXJ0Y29tLm9yZy9zdWIvY2xhc3MzL3VzZXIvY2EwOwYIKwYBBQUHMAKG L2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zdWIuY2xhc3MzLnVzZXIuY2EuY3J0MBEGCWCG SAGG+EIBAQQEAwIFoDAxBglghkgBhvhCAQ0EJBYiU3RhcnRDb20gVHJ1c3RlZCBFbWFpbCBD ZXJ0aWZpY2F0ZTAyBglghkgBhvhCAQQEJRYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2Nh LWNybC5jcmwwNQYJYIZIAYb4QgEDBCgWJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1 My1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s aWN5LnBkZjAjBgNVHRIEHDAahhhodHRwOi8vY2VydC5zdGFydGNvbS5vcmcwDQYJKoZIhvcN AQEFBQADggEBAJ0bUvRPg5PXHhf9wqy4fGCKNFpkYaJUQJyfn7VfsTcfnj/IORSpYCnoxneF mbfqnNNhieX7kzq+V0tyoUJWkPsyAfoqa76vqlcCNTfeTVEgeeQG9DooaVGnRGN9plb/YyQb Tu8XZBMtvHooiGLSlr0GD3CWrLD4LaDoVid+at0kuAavFRd6TwNJk2Nn8ADvk6i62taQG11o vZNsWJrB1sa4ltKhAseous2FPx/vg55ztF46a5RMQvyGwVTSxtj+fZ71adrVXPN7edk9vI+I LkXzynzyBUsH2YqQ7OV5h59iJDDwsAHPnHUwj7DRs0o08u+In8qccYUR9UvPWgwfILcxggQs MIIEKAIBATCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAt BgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZI hvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjAJBgUrDgMCGgUAoIICSTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA0MDIxNDU1MDlaMCMGCSqG SIb3DQEJBDEWBBTtlVXrj/C8mYVAyS+n/OsqR5vjOzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCByAYJKwYBBAGCNxAEMYG6MIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMG SXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlm aWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWls IEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAXiqMIHKBgsq hkiG9w0BCRACCzGBuqCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25p bmcxLzAtBgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEw HwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjANBgkqhkiG9w0BAQEFAASC AQB6/EpnJw5g1jUpqlcjHd6ouHqCcHCo5YADL9lrlrTZRDxs5TrVbAUNjruXLHe4J+lrFYpo p0Tz9PsALY1x4TDpnes0ZM/38ja2CBm8YlT9jkUEosUcvoxfwwfBnsDo/vzGQTk2+0CkaVhc 5MWyIg8Vmgx1xb9HtCZR8mwgcWjOvFev5plfgRXoMr+ayMwD3p8LoMqKHF2VuNbAz1syjVgH chuNLa5qBXskBnlX7fzU5TKIYd1sBaNr6j40GDDMwQck2U4Y0Tn7iGpOnCr8IuR7DIi7Fm/M Xi1NosUOSz1XQjyciWb0jmihaO3h9wNHyjbex7vVtSuN37qdUFbTkS8sAAAAAAAA --------------ms050807080508060105080102-- --===============0615076511== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple --===============0615076511==-- From simple-bounces@ietf.org Wed Apr 2 09:16:48 2008 Return-Path: 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 E9A293A6EFD; Wed, 2 Apr 2008 09:16:48 -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 7BB2F3A6949; Wed, 2 Apr 2008 09:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 z7TKeLa31yQh; Wed, 2 Apr 2008 09:16:45 -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 8BE033A6DB0; Wed, 2 Apr 2008 09:16:44 -0700 (PDT) Received: from [172.16.3.213] ([172.16.3.213]) (authenticated bits=0) by estacado.net (8.14.2/8.14.1) with ESMTP id m32GGhW3006557 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 2 Apr 2008 11:16:43 -0500 (CDT) (envelope-from ben@estacado.net) Message-Id: <208326E5-B78C-49E3-BADC-B1CE94FE2963@estacado.net> From: Ben Campbell To: Jari Urpalainen In-Reply-To: <47F35A1E.4070109@nokia.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 2 Apr 2008 11:16:43 -0500 References: <5DDFCB0D-ADEC-49A7-BDDC-4112A011CAF8@estacado.net> <47F35A1E.4070109@nokia.com> X-Mailer: Apple Mail (2.919.2) Cc: Sip List , Simple WG Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Thanks for the quick response. My comments for anything that still seems like an open issue are inline: On Apr 2, 2008, at 5:04 AM, Jari Urpalainen wrote: > ext Ben Campbell wrote: [...] >> Section 4.4, paragraph 1(clarity): >> "The usage of hierarchical lists and >> references, etc. can thus be omitted." >> >> You say that the usage of hierarchical lists and 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? Do you have any thoughts concerning the above comment? >> >> >> "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. >> > in practice, the sip notifier must be aware of changes made by > another protocol, i.e. http in this case. If these servers (notifier > & http (xcap) daemon) are separated they need some sort of immediate > mechanism to signal these events. It can be done with some > unspecified ways, but the most simple one is when they are running > on the very same host. However, even that simplest case is pretty > hard (or complex enough) to implement properly (implementation > description can be a long story although you are using OSS tools, > like e.g. linux with Apache + xcap_module and some decent Sip stack > with all the source code), and the intention is to define only the > very simplest use-case here. It is not ruled out that they were > separated but that would be much, much more difficult to implement, > and there are many obstacles and open issues there. So there's magic > (outside the scope of this i-d) here how to map the sip-uri to the > xcap-root-uri, but this, the most simple use-case is what i'd expect > to be implemented (and maybe, even some minor deployment as well ;-)). > > Also we agreed with Miguel to be more explicit about this magic, > does it sound sufficient to you ? Likely. As long as we mention the need for the notifier to learn about changes at the XCAP server, and that such mechanisms are out of scope for this document. It makes sense to mention collocation as an example way to solve this, but it's only an example. [...] >> >> 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? > the reason to drop the aggregation mode for that particular resource > is that once the client have to use http, it might get out-of-sync > (with "rapidly" changing resources), the rule is to be certain that > it will not happen. I'll try to clarify. Thanks. I think it would be helpful to have a section dedicated describing the issue, and mention the ways to work around it. [...] >> >> "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.) > it can try to start in the aggregate mode straight away, but it may > fail. So the safe way is to disable aggregation first before sync is > achieved and enable it afterwards. I think I'll add something about > this into those dreaded examples (in an appendix) See my previous comment about having a separate section to describe the issue and possible solutions. It's also important that we are clear on whether the delayed activation of "aggregation" mode is simply an optional solution to a potential issue, or is a normative requirement. > >> >> >> 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. > ok, didn't think about that at all. This one needs some thought, then. There are actually a lot more causes than just digest challenges that may cause the client to see non-sequential CSeqs. If detection of lost notifies is critical, we need another solution (either to detect lost notifies or to remove the need to do so.) >> 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? > yep this is indeed _difficult_. Easy to write (one sentence only), > but really, really hard to implement properly ;-). First off there's > a SHOULD directive fortunately... I'm not 100 % sure if you mean > that xcap-patching is also disabled. So there's not a big difference > in this context whether you have aggregation or xcap-patching modes, > since in the xcap-patching mode you will see changes e.g. from "a" > to "b" to "c" with all corresponding Etags while in the aggregate > mode you'll see e.g. only changes from "a" to "c" in the > notification body without the intermediate state. Certainly > aggregation body is smaller but it fails to show the versioning > history and the diff formats differ, but the end result will be the > same certainly, i.e. "c". So _if_ you obey the timer, you wait for > it to expire and then send the result in both cases (and of course > during this timer interval you wait for any changes in these > resources, and do something relevant, e.g. store internal object > states). If there's not any patching modes applied, then you should > wait for the timer to expire and send appropriate actions, i.e. > document(s) has either been created, modified or deleted. I'm not sure I understand what you mean on the last two sentences--can you give an example? > IIRC, in partial PIDF where we use the exact same patchings there's > not a single line about this since this timer is inherited from the > base PIDF package. In summary, you just don't have to do anything > mysterious with timers except wait for a certain period of time. In > practice, it happens to be quite a challenging task (but these specs > usually _ignore_ the implementation PITA ;-)) It's still not clear to me if this is just a "hard implementation" problem or if it is really a conflict in normative requirements. Coding aside, what do you expect the most commen behavior to be if multiple changes occur inside the 5 second window, but the client has not allowed aggregation? (The example requested above might help me understand this.) > >> >> Section 5, figure 3 (clarity): >> >> It would be nice to see this in context of an actual NOTIFY. > I'll try to digest something into an appendix. That being said, the > important things are bodies... To some degree, it is up to the companion draft to define the body in detail--this draft really talks about the SIP-event package, so I do think it is appropriate to show real message flows including the SIP parts. [...] >> >> 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? >> > yep, besides DoS TLS & S/MIME recommendations some text about > identity "mapping" between http & sip would be reasonable. Anything > else ? I had not thought of the identity mapping issue--that discussion always seems to get more "interesting" than you might expect :-) It might be worth adding SIPS thoughts to any TLS discussion. Thanks! Ben. _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From kmj007@mon.bbc.co.uk Wed Apr 2 10:39:01 2008 Return-Path: X-Original-To: ietfarch-simple-archive@core3.amsl.com Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E18C63A6D5E for ; Wed, 2 Apr 2008 10:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -75.663 X-Spam-Level: X-Spam-Status: No, score=-75.663 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, STOX_REPLY_TYPE=0.001, TVD_FINGER_02=2.134, USER_IN_WHITELIST=-100] 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 c4NGPgMmQiUJ for ; Wed, 2 Apr 2008 10:38:59 -0700 (PDT) Received: from adsl-75-15-101-9.dsl.irvnca.sbcglobal.net (adsl-75-15-101-9.dsl.irvnca.sbcglobal.net [75.15.101.9]) by core3.amsl.com (Postfix) with SMTP id E6A853A67FD for ; Wed, 2 Apr 2008 10:38:58 -0700 (PDT) Received: (qmail 4619 invoked from network); Wed, 2 Apr 2008 10:38:59 -0700 Received: from unknown (HELO pss) (156.75.215.65) by adsl-75-15-101-9.dsl.irvnca.sbcglobal.net with SMTP; Wed, 2 Apr 2008 10:38:59 -0700 Message-ID: <002201c894e8$6ef199f0$41d74b9c@pss> From: To: Subject: Compare the numbers and get the same goods for a half value! Date: Wed, 2 Apr 2008 10:38:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4920.2300 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 Lengthen and thicken your tool! http://ifffcicajro.blogspot.com From simple-bounces@ietf.org Thu Apr 3 05:29:42 2008 Return-Path: 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 99BA728C619; Thu, 3 Apr 2008 05:29:42 -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 614E33A69C9; Thu, 3 Apr 2008 05:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.407 X-Spam-Level: X-Spam-Status: No, score=-6.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 gu7n71y1-UZt; Thu, 3 Apr 2008 05:29:39 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 0DBBF3A6B48; Thu, 3 Apr 2008 05:29:38 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m33CSiL5024201; Thu, 3 Apr 2008 15:29:09 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Apr 2008 15:28:40 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Apr 2008 15:28:40 +0300 Received: from [172.21.40.139] ([172.21.40.139]) by esebe105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Apr 2008 15:28:40 +0300 Message-ID: <47F4CD85.3090203@nokia.com> Date: Thu, 03 Apr 2008 15:28:53 +0300 From: Jari Urpalainen User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: ext Ben Campbell References: <5DDFCB0D-ADEC-49A7-BDDC-4112A011CAF8@estacado.net> <47F35A1E.4070109@nokia.com> <208326E5-B78C-49E3-BADC-B1CE94FE2963@estacado.net> In-Reply-To: <208326E5-B78C-49E3-BADC-B1CE94FE2963@estacado.net> X-OriginalArrivalTime: 03 Apr 2008 12:28:40.0505 (UTC) FILETIME=[3F969A90:01C89586] X-Nokia-AV: Clean Cc: Sip List , Simple WG Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org ext Ben Campbell wrote: > Thanks for the quick response. My comments for anything that still > seems like an open issue are inline: > > > On Apr 2, 2008, at 5:04 AM, Jari Urpalainen wrote: >> ext Ben Campbell wrote: > > [...] > >>> Section 4.4, paragraph 1(clarity): >>> "The usage of hierarchical lists and >>> references, etc. can thus be omitted." >>> >>> You say that the usage of hierarchical lists and 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? > > Do you have any thoughts concerning the above comment? Sorry, i already made an actual fix, but forgot to reply. Yep, these are "sophisticated" features which don't bring in any value here --> "...MUST NOT be used" > >>> >>> >>> "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. >>> >> in practice, the sip notifier must be aware of changes made by >> another protocol, i.e. http in this case. If these servers (notifier >> & http (xcap) daemon) are separated they need some sort of immediate >> mechanism to signal these events. It can be done with some >> unspecified ways, but the most simple one is when they are running on >> the very same host. However, even that simplest case is pretty hard >> (or complex enough) to implement properly (implementation description >> can be a long story although you are using OSS tools, like e.g. linux >> with Apache + xcap_module and some decent Sip stack with all the >> source code), and the intention is to define only the very simplest >> use-case here. It is not ruled out that they were separated but that >> would be much, much more difficult to implement, and there are many >> obstacles and open issues there. So there's magic (outside the scope >> of this i-d) here how to map the sip-uri to the xcap-root-uri, but >> this, the most simple use-case is what i'd expect to be implemented >> (and maybe, even some minor deployment as well ;-)). >> >> Also we agreed with Miguel to be more explicit about this magic, does >> it sound sufficient to you ? > > Likely. As long as we mention the need for the notifier to learn about > changes at the XCAP server, and that such mechanisms are out of scope > for this document. It makes sense to mention collocation as an example > way to solve this, but it's only an example. > > [...] fine. > > >>> >>> 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? >> the reason to drop the aggregation mode for that particular resource >> is that once the client have to use http, it might get out-of-sync >> (with "rapidly" changing resources), the rule is to be certain that >> it will not happen. I'll try to clarify. > > Thanks. I think it would be helpful to have a section dedicated > describing the issue, and mention the ways to work around it. > > [...] i 've added a whole new chapter about this into the "notifier generation" and re-arranged things so that it SHOULD be now much more unambiquous. > > >>> >>> "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.) >> it can try to start in the aggregate mode straight away, but it may >> fail. So the safe way is to disable aggregation first before sync is >> achieved and enable it afterwards. I think I'll add something about >> this into those dreaded examples (in an appendix) > > See my previous comment about having a separate section to describe > the issue and possible solutions. It's also important that we are > clear on whether the delayed activation of "aggregation" mode is > simply an optional solution to a potential issue, or is a normative > requirement. > As the aggregate mode has its drawbacks when versioning is not supported in http, I think I've managed to fix the text... >> >>> >>> >>> 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. >> ok, didn't think about that at all. > > This one needs some thought, then. There are actually a lot more > causes than just digest challenges that may cause the client to see > non-sequential CSeqs. If detection of lost notifies is critical, we > need another solution (either to detect lost notifies or to remove the > need to do so.) now I've managed to put this "utter crap" myself :-), sorry, i.e. unordering doesn't happen when the notifier acts _properly_, so it's better to move that text altogether. > >>> 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? >> yep this is indeed _difficult_. Easy to write (one sentence only), >> but really, really hard to implement properly ;-). First off there's >> a SHOULD directive fortunately... I'm not 100 % sure if you mean that >> xcap-patching is also disabled. So there's not a big difference in >> this context whether you have aggregation or xcap-patching modes, >> since in the xcap-patching mode you will see changes e.g. from "a" to >> "b" to "c" with all corresponding Etags while in the aggregate mode >> you'll see e.g. only changes from "a" to "c" in the notification body >> without the intermediate state. Certainly aggregation body is smaller >> but it fails to show the versioning history and the diff formats >> differ, but the end result will be the same certainly, i.e. "c". So >> _if_ you obey the timer, you wait for it to expire and then send the >> result in both cases (and of course during this timer interval you >> wait for any changes in these resources, and do something relevant, >> e.g. store internal object states). If there's not any patching >> modes applied, then you should wait for the timer to expire and send >> appropriate actions, i.e. document(s) has either been created, >> modified or deleted. > > I'm not sure I understand what you mean on the last two sentences--can > you give an example? btw. just noted that a rate limit was per a _user_ what would that mean ? so should be per _subscription_. let's say you'll notify a initial document at some time x. then comes two changes 1 & 2 for the same document within 2 seconds (ETags are those timestamps): NOTIFY 1 -- x change 1 -- x+1s. change 2 -- x+2s. NOTIFY 2 -- x+5s. so if those two changes are reported (NOTIFY 2) _without any patching_ you'll report the document uri reference with Etags at time x+5s due to this 5s rate limitation: with xcap-patching you could have: while with the "aggregate" mode: So the first one shows the simplest case, and then the more complex xcap-patching and lastly aggregate, does this help ? I've the intention to add something similar to an appendix regardless of the pain... So as can be seen from the example "aggregate" and "xcap-patching" both aggregate patches, but the "real" aggregate can do much clever decisions with the added complexity. And i've made it now explicit that the notifier MAY respond with all of these 3 ways if aggregate is requested. If notifier requests xcap-patching "aggregate" MUST NOT be used, and with "no-patching" naturally only the simplest mode is allowed. > >> IIRC, in partial PIDF where we use the exact same patchings there's >> not a single line about this since this timer is inherited from the >> base PIDF package. In summary, you just don't have to do anything >> mysterious with timers except wait for a certain period of time. In >> practice, it happens to be quite a challenging task (but these specs >> usually _ignore_ the implementation PITA ;-)) > > It's still not clear to me if this is just a "hard implementation" > problem or if it is really a conflict in normative requirements. > Coding aside, what do you expect the most commen behavior to be if > multiple changes occur inside the 5 second window, but the client has > not allowed aggregation? (The example requested above might help me > understand this.) > imo it is not a conflict, just a PITA in implementations, though sometimes a very nice optimization. >> >>> >>> Section 5, figure 3 (clarity): >>> >>> It would be nice to see this in context of an actual NOTIFY. >> I'll try to digest something into an appendix. That being said, the >> important things are bodies... > > To some degree, it is up to the companion draft to define the body in > detail--this draft really talks about the SIP-event package, so I do > think it is appropriate to show real message flows including the SIP > parts. > > [...] > yep, though from sip event pov. only the event-paramer and conditional headers are really relevant, and indeed the body examples are not shown in other specs, which allow virtually everything. In this case, this package _requires_ those limitations to those formats with/without patching, so it is definitely good to have good examples. >>> >>> 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? >>> >> yep, besides DoS TLS & S/MIME recommendations some text about >> identity "mapping" between http & sip would be reasonable. Anything >> else ? > > I had not thought of the identity mapping issue--that discussion > always seems to get more "interesting" than you might expect :-) It > might be worth adding SIPS thoughts to any TLS discussion. yep. > > Thanks! > > Ben. Thanks again, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Apr 3 06:28:57 2008 Return-Path: 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 28DC03A6C5B; Thu, 3 Apr 2008 06:28:57 -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 7394C28C1B6; Thu, 3 Apr 2008 06:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.058 X-Spam-Level: X-Spam-Status: No, score=-2.058 tagged_above=-999 required=5 tests=[AWL=0.541, 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 EHnkTZzBIyeE; Thu, 3 Apr 2008 06:28:54 -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 A77363A6AF4; Thu, 3 Apr 2008 06:28:53 -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 m33DSolE050096 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 3 Apr 2008 08:28:54 -0500 (CDT) (envelope-from ben@estacado.net) Message-Id: From: Ben Campbell To: Jari Urpalainen In-Reply-To: <47F4CD85.3090203@nokia.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 3 Apr 2008 08:28:49 -0500 References: <5DDFCB0D-ADEC-49A7-BDDC-4112A011CAF8@estacado.net> <47F35A1E.4070109@nokia.com> <208326E5-B78C-49E3-BADC-B1CE94FE2963@estacado.net> <47F4CD85.3090203@nokia.com> X-Mailer: Apple Mail (2.919.2) Cc: Sip List , Simple WG Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Apr 3, 2008, at 7:28 AM, Jari Urpalainen wrote: [...] >>> >>>> >>>> >>>> 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. >>> ok, didn't think about that at all. >> >> This one needs some thought, then. There are actually a lot more >> causes than just digest challenges that may cause the client to see >> non-sequential CSeqs. If detection of lost notifies is critical, we >> need another solution (either to detect lost notifies or to remove >> the need to do so.) > now I've managed to put this "utter crap" myself :-), sorry, i.e. > unordering doesn't happen when the notifier acts _properly_, so it's > better to move that text altogether. The text was more about missing NOTIFY requests than it was out-of- order NOTIFYs (CSeq will actually catch the out-of-order case). Are you saying that it is okay to not be able to detect missing NOTIFYs, even in patch mode? Note that missing and out-of-order notifies can (rarely, we hope) happen due to intervening devices even if the notifier is perfectly well behaved. > >> >>>> 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? >>> yep this is indeed _difficult_. Easy to write (one sentence only), >>> but really, really hard to implement properly ;-). First off >>> there's a SHOULD directive fortunately... I'm not 100 % sure if >>> you mean that xcap-patching is also disabled. So there's not a big >>> difference in this context whether you have aggregation or xcap- >>> patching modes, since in the xcap-patching mode you will see >>> changes e.g. from "a" to "b" to "c" with all corresponding Etags >>> while in the aggregate mode you'll see e.g. only changes from "a" >>> to "c" in the notification body without the intermediate state. >>> Certainly aggregation body is smaller but it fails to show the >>> versioning history and the diff formats differ, but the end result >>> will be the same certainly, i.e. "c". So _if_ you obey the timer, >>> you wait for it to expire and then send the result in both cases >>> (and of course during this timer interval you wait for any changes >>> in these resources, and do something relevant, e.g. store internal >>> object states). If there's not any patching modes applied, then >>> you should wait for the timer to expire and send appropriate >>> actions, i.e. document(s) has either been created, modified or >>> deleted. >> >> I'm not sure I understand what you mean on the last two sentences-- >> can you give an example? > btw. just noted that a rate limit was per a _user_ what would that > mean ? so should be per _subscription_. > > let's say you'll notify a initial document at some time x. then > comes two changes 1 & 2 for the same document within 2 seconds > (ETags are those timestamps): > NOTIFY 1 -- x change 1 -- x+1s. > change 2 -- x+2s. > NOTIFY 2 -- x+5s. > > so if those two changes are reported (NOTIFY 2) _without any > patching_ you'll report the document uri reference with Etags at > time x+5s due to this 5s rate limitation: > > sel="resource-lists/users/sip:joe@example.com/coworkers" > previous-etag="x"/> > > > with xcap-patching you could have: > > > sel="resource-lists/users/sip:joe@example.com/coworkers" > previous-etag="x"> > > > sel="resource-lists/users/sip:joe@example.com/coworkers" > previous-etag="x+1s"> > > > ' Ah, I see you are effectively listing both change events in a single xcap-diff document, but still as separate events. That makes sense, but it was not obvious to me from the text that you could do this. I don't recall if the data format doc addressed it or not. It would definitely help to include examples for each mode of operation. > > > while with the "aggregate" mode: > > > sel="resource-lists/users/sip:joe@example.com/coworkers" > previous-etag="x"> > > > > > So the first one shows the simplest case, and then the more complex > xcap-patching and lastly aggregate, does this help ? I've the > intention to add something similar to an appendix regardless of the > pain... > > So as can be seen from the example "aggregate" and "xcap-patching" > both aggregate patches, but the "real" aggregate can do much clever > decisions with the added complexity. > > And i've made it now explicit that the notifier MAY respond with all > of these 3 ways if aggregate is requested. If notifier requests xcap- > patching "aggregate" MUST NOT be used, and with "no-patching" > naturally only the simplest mode is allowed. > >> >>> IIRC, in partial PIDF where we use the exact same patchings >>> there's not a single line about this since this timer is inherited >>> from the base PIDF package. In summary, you just don't have to do >>> anything mysterious with timers except wait for a certain period >>> of time. In practice, it happens to be quite a challenging task >>> (but these specs usually _ignore_ the implementation PITA ;-)) >> >> It's still not clear to me if this is just a "hard implementation" >> problem or if it is really a conflict in normative requirements. >> Coding aside, what do you expect the most commen behavior to be if >> multiple changes occur inside the 5 second window, but the client >> has not allowed aggregation? (The example requested above might >> help me understand this.) >> > imo it is not a conflict, just a PITA in implementations, though > sometimes a very nice optimization. I _think_ I am okay with this, pending seeing the new text. [...] Thanks! Ben. _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Apr 3 07:39:54 2008 Return-Path: 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 68EEC28C6AA; Thu, 3 Apr 2008 07:39:54 -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 47FC328C11E; Thu, 3 Apr 2008 07:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.435 X-Spam-Level: X-Spam-Status: No, score=-6.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 GgePqLKKn08P; Thu, 3 Apr 2008 07:39:51 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id EF43728C693; Thu, 3 Apr 2008 07:39:50 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m33EeVjV013977; Thu, 3 Apr 2008 09:41:57 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Apr 2008 17:39:10 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Apr 2008 17:39:10 +0300 Received: from [172.21.40.139] ([172.21.40.139]) by esebe105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Apr 2008 17:39:10 +0300 Message-ID: <47F4EC1A.3030301@nokia.com> Date: Thu, 03 Apr 2008 17:39:22 +0300 From: Jari Urpalainen User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: ext Ben Campbell References: <5DDFCB0D-ADEC-49A7-BDDC-4112A011CAF8@estacado.net> <47F35A1E.4070109@nokia.com> <208326E5-B78C-49E3-BADC-B1CE94FE2963@estacado.net> <47F4CD85.3090203@nokia.com> In-Reply-To: X-OriginalArrivalTime: 03 Apr 2008 14:39:10.0339 (UTC) FILETIME=[7A887530:01C89598] X-Nokia-AV: Clean Cc: Sip List , Simple WG Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org ext Ben Campbell wrote: > > On Apr 3, 2008, at 7:28 AM, Jari Urpalainen wrote: > > [...] > >>>> >>>>> >>>>> >>>>> 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. >>>> ok, didn't think about that at all. >>> >>> This one needs some thought, then. There are actually a lot more >>> causes than just digest challenges that may cause the client to see >>> non-sequential CSeqs. If detection of lost notifies is critical, we >>> need another solution (either to detect lost notifies or to remove >>> the need to do so.) >> now I've managed to put this "utter crap" myself :-), sorry, i.e. >> unordering doesn't happen when the notifier acts _properly_, so it's >> better to move that text altogether. > > The text was more about missing NOTIFY requests than it was > out-of-order NOTIFYs (CSeq will actually catch the out-of-order case). > Are you saying that it is okay to not be able to detect missing > NOTIFYs, even in patch mode? Note that missing and out-of-order > notifies can (rarely, we hope) happen due to intervening devices even > if the notifier is perfectly well behaved. > the implicit rule _now_ for the notifier is: if you don't get a final 200 ack for a notify, do not send a new request and for a timeout, tear down the session (this is what i propose but as explicit). So what happens with 4xx, 5xx, 6xx etc is unspecified. So the rule for waiting for the 200 OK rules out-of-order. So if you get 4/5/6xx will that mean drop-out possibility ? no imo, since you can't send a new one unless the previous one has been sent successfully. So personally i _could_ go that far that tear down always if return code != 200, but probably some intelligent notifiers could resolve e.g. 413, though i have my doubts.... >>> >>>>> 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? >>>> yep this is indeed _difficult_. Easy to write (one sentence only), >>>> but really, really hard to implement properly ;-). First off >>>> there's a SHOULD directive fortunately... I'm not 100 % sure if you >>>> mean that xcap-patching is also disabled. So there's not a big >>>> difference in this context whether you have aggregation or >>>> xcap-patching modes, since in the xcap-patching mode you will see >>>> changes e.g. from "a" to "b" to "c" with all corresponding Etags >>>> while in the aggregate mode you'll see e.g. only changes from "a" >>>> to "c" in the notification body without the intermediate state. >>>> Certainly aggregation body is smaller but it fails to show the >>>> versioning history and the diff formats differ, but the end result >>>> will be the same certainly, i.e. "c". So _if_ you obey the timer, >>>> you wait for it to expire and then send the result in both cases >>>> (and of course during this timer interval you wait for any changes >>>> in these resources, and do something relevant, e.g. store internal >>>> object states). If there's not any patching modes applied, then >>>> you should wait for the timer to expire and send appropriate >>>> actions, i.e. document(s) has either been created, modified or >>>> deleted. >>> >>> I'm not sure I understand what you mean on the last two >>> sentences--can you give an example? >> btw. just noted that a rate limit was per a _user_ what would that >> mean ? so should be per _subscription_. >> >> let's say you'll notify a initial document at some time x. then comes >> two changes 1 & 2 for the same document within 2 seconds (ETags are >> those timestamps): >> NOTIFY 1 -- x change 1 -- x+1s. >> change 2 -- x+2s. >> NOTIFY 2 -- x+5s. >> >> so if those two changes are reported (NOTIFY 2) _without any >> patching_ you'll report the document uri reference with Etags at time >> x+5s due to this 5s rate limitation: >> >> > sel="resource-lists/users/sip:joe@example.com/coworkers" >> previous-etag="x"/> >> >> >> with xcap-patching you could have: >> >> >> > sel="resource-lists/users/sip:joe@example.com/coworkers" >> previous-etag="x"> >> >> >> > sel="resource-lists/users/sip:joe@example.com/coworkers" >> previous-etag="x+1s"> >> >> >> ' > > Ah, I see you are effectively listing both change events in a single > xcap-diff document, but still as separate events. That makes sense, > but it was not obvious to me from the text that you could do this. I > don't recall if the data format doc addressed it or not. It would > definitely help to include examples for each mode of operation. > it is in the format spec, it was implicit in some older versions, but i fixed that: "If several elements with the same "sel" selector value exist in the XCAP diff document, i.e. for example, the full ETag change history is indicated, the corresponding patches MUST be appliable in the given document order." >> >> >> while with the "aggregate" mode: >> >> >> > sel="resource-lists/users/sip:joe@example.com/coworkers" >> previous-etag="x"> >> >> >> >> >> So the first one shows the simplest case, and then the more complex >> xcap-patching and lastly aggregate, does this help ? I've the >> intention to add something similar to an appendix regardless of the >> pain... >> >> So as can be seen from the example "aggregate" and "xcap-patching" >> both aggregate patches, but the "real" aggregate can do much clever >> decisions with the added complexity. >> >> And i've made it now explicit that the notifier MAY respond with all >> of these 3 ways if aggregate is requested. If notifier requests >> xcap-patching "aggregate" MUST NOT be used, and with "no-patching" >> naturally only the simplest mode is allowed. >> >>> >>>> IIRC, in partial PIDF where we use the exact same patchings there's >>>> not a single line about this since this timer is inherited from the >>>> base PIDF package. In summary, you just don't have to do anything >>>> mysterious with timers except wait for a certain period of time. In >>>> practice, it happens to be quite a challenging task (but these >>>> specs usually _ignore_ the implementation PITA ;-)) >>> >>> It's still not clear to me if this is just a "hard implementation" >>> problem or if it is really a conflict in normative requirements. >>> Coding aside, what do you expect the most commen behavior to be if >>> multiple changes occur inside the 5 second window, but the client >>> has not allowed aggregation? (The example requested above might help >>> me understand this.) >>> >> imo it is not a conflict, just a PITA in implementations, though >> sometimes a very nice optimization. > > I _think_ I am okay with this, pending seeing the new text. > > [...] > > Thanks! > > Ben. > great, i really hope you have time to look at the updated text when i get it "fully" ready with those reasonable examples ... thanks, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Apr 3 08:18:23 2008 Return-Path: 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 0A60D3A6C68; Thu, 3 Apr 2008 08:18:23 -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 30ED93A6C9B; Thu, 3 Apr 2008 08:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.398 X-Spam-Level: X-Spam-Status: No, score=-4.398 tagged_above=-999 required=5 tests=[AWL=2.201, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 DfuMmDQS41Mb; Thu, 3 Apr 2008 08:18:20 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 55B733A6C61; Thu, 3 Apr 2008 08:18:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,599,1199692800"; d="scan'208";a="19791982" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 03 Apr 2008 08:18:24 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m33FIMlX018119; Thu, 3 Apr 2008 08:18:22 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m33FIISR013418; Thu, 3 Apr 2008 15:18:22 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Apr 2008 11:18:21 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Apr 2008 11:18:20 -0400 Message-ID: <47F4F555.9020505@cisco.com> Date: Thu, 03 Apr 2008 11:18:45 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Jari Urpalainen References: <5DDFCB0D-ADEC-49A7-BDDC-4112A011CAF8@estacado.net> <47F35A1E.4070109@nokia.com> <208326E5-B78C-49E3-BADC-B1CE94FE2963@estacado.net> <47F4CD85.3090203@nokia.com> <47F4EC1A.3030301@nokia.com> In-Reply-To: <47F4EC1A.3030301@nokia.com> X-OriginalArrivalTime: 03 Apr 2008 15:18:20.0696 (UTC) FILETIME=[F3747980:01C8959D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1094; t=1207235902; x=1208099902; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20WGLC=20Comments=20on=20draft-ie tf-sip-xcapevent-01 |Sender:=20; bh=Vls3Jntkl1BGrjLZWoAlxs/3KST9HkIysB5OFZaBj8o=; b=R/1TmGj1voecDTavFhouRD5UhRe0SSc+tXE7iEKqb+1qSbamigoRY4JQ82 ufr4uTmDui5w52yzmFQ8H/ZLUjXUgCUjyT4eoqklFM+YqVxaEs5vhkcNF2Ul /9KwRLJ9DY; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Sip List , Simple WG Subject: Re: [Simple] [Sip] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Jari Urpalainen wrote: > the implicit rule _now_ for the notifier is: if you don't get a final > 200 ack for a notify, do not send a new request and for a timeout, tear > down the session (this is what i propose but as explicit). So what > happens with 4xx, 5xx, 6xx etc is unspecified. So the rule for waiting > for the 200 OK rules out-of-order. So if you get 4/5/6xx will that mean > drop-out possibility ? no imo, since you can't send a new one unless the > previous one has been sent successfully. So personally i _could_ go that > far that tear down always if return code != 200, but probably some > intelligent notifiers could resolve e.g. 413, though i have my doubts.... It is always be possible to get a 401 or 407 response to a NOTIFY, and it should be possible to retry it with the proper credentials. That ought not screw up the subscription. This could happen because your nonce expired on a long lived subscription. Admittedly it would be pretty odd to have authorization in the NOTIFY direction, but it could be possible I think. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Apr 3 08:46:08 2008 Return-Path: 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 39D0F28C1E5; Thu, 3 Apr 2008 08:46:08 -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 7F03B3A6963; Thu, 3 Apr 2008 08:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 Ryzb4DjlA6HZ; Thu, 3 Apr 2008 08:45:59 -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 DF1F43A6BF7; Thu, 3 Apr 2008 08:45:58 -0700 (PDT) Received: from [172.16.3.213] ([172.16.3.213]) (authenticated bits=0) by estacado.net (8.14.2/8.14.1) with ESMTP id m33Fk0d7065571 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 3 Apr 2008 10:46:00 -0500 (CDT) (envelope-from ben@estacado.net) Message-Id: From: Ben Campbell To: Jari Urpalainen In-Reply-To: <47F4EC1A.3030301@nokia.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 3 Apr 2008 10:45:59 -0500 References: <5DDFCB0D-ADEC-49A7-BDDC-4112A011CAF8@estacado.net> <47F35A1E.4070109@nokia.com> <208326E5-B78C-49E3-BADC-B1CE94FE2963@estacado.net> <47F4CD85.3090203@nokia.com> <47F4EC1A.3030301@nokia.com> X-Mailer: Apple Mail (2.919.2) Cc: Sip List , Simple WG Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Apr 3, 2008, at 9:39 AM, Jari Urpalainen wrote: [...] >>>>>> 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. >>>>> ok, didn't think about that at all. >>>> >>>> This one needs some thought, then. There are actually a lot more >>>> causes than just digest challenges that may cause the client to >>>> see non-sequential CSeqs. If detection of lost notifies is >>>> critical, we need another solution (either to detect lost >>>> notifies or to remove the need to do so.) >>> now I've managed to put this "utter crap" myself :-), sorry, i.e. >>> unordering doesn't happen when the notifier acts _properly_, so >>> it's better to move that text altogether. >> >> The text was more about missing NOTIFY requests than it was out-of- >> order NOTIFYs (CSeq will actually catch the out-of-order case). Are >> you saying that it is okay to not be able to detect missing >> NOTIFYs, even in patch mode? Note that missing and out-of-order >> notifies can (rarely, we hope) happen due to intervening devices >> even if the notifier is perfectly well behaved. >> > the implicit rule _now_ for the notifier is: if you don't get a > final 200 ack for a notify, do not send a new request and for a > timeout, tear down the session (this is what i propose but as > explicit). So what happens with 4xx, 5xx, 6xx etc is unspecified. > So the rule for waiting for the 200 OK rules out-of-order. So if you > get 4/5/6xx will that mean drop-out possibility ? no imo, since you > can't send a new one unless the previous one has been sent > successfully. So personally i _could_ go that far that tear down > always if return code != 200, but probably some intelligent > notifiers could resolve e.g. 413, though i have my doubts.... Ah, I _think_ that helps, although keep in mind that not all non-200 responses necessarily indicate the subscription should be torn down. _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Apr 3 09:07:36 2008 Return-Path: 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 A46973A6AEB; Thu, 3 Apr 2008 09:07: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 9189C3A6963; Thu, 3 Apr 2008 09:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] 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 JpNcnYo03mAR; Thu, 3 Apr 2008 09:07:23 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id ADE6328C15E; Thu, 3 Apr 2008 09:07:22 -0700 (PDT) Received: from [172.16.3.232] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.2/8.14.1) with ESMTP id m33G7LmH077909 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 3 Apr 2008 11:07:22 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: <7730830D-3D30-488B-AC9D-59650CF6831E@nostrum.com> From: Robert Sparks To: Robert Sparks In-Reply-To: <3A1B9984-4751-48B6-96D9-E4058E4CBDE7@estacado.net> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 3 Apr 2008 11:07:20 -0500 References: <43A3E655-E3C8-406A-B6FA-8BFCC64F0A63@estacado.net> <3A1B9984-4751-48B6-96D9-E4058E4CBDE7@estacado.net> X-Mailer: Apple Mail (2.919.2) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.92.1/6567/Thu Apr 3 07:31:07 2008 on shaman.nostrum.com X-Virus-Status: Clean Cc: sip List , sipping LIST , simple mailing list Subject: [Simple] Final Reminder: SIPit 22 registration closes tomorrow (Friday) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Registration for this SIPit closes this Friday (April 4). If you've been waiting for the deadline to register - this is it. RjS ------------ SIPit 22 will be hosted by the University of New Hampshire Interoperability Laboratory April 14 through 18, 2008. Registration is $350 (USD) per person. Registration will close April 4. Space is limited, so register early to ensure a seat. Additional registration details are available at http://www.sipit.net _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Apr 6 03:17:46 2008 Return-Path: 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 B33073A6D34; Sun, 6 Apr 2008 03:17:46 -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 672703A6D53 for ; Sun, 6 Apr 2008 03:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 BHzMXP2KzSJm for ; Sun, 6 Apr 2008 03:17:42 -0700 (PDT) Received: from neustar.com (ns6.neustar.com [156.154.16.88]) by core3.amsl.com (Postfix) with ESMTP id 6293D3A6C1B for ; Sun, 6 Apr 2008 03:17:42 -0700 (PDT) DKIM-Signature: a=rsa-sha1; d=neustar.biz; s=neustarbiz; c=simple/simple; q=dns; t=1207477069; x=1207563469; h=From:Date:Subject:Message-ID:Content-class:Content-Type; b=bH/EwKM19oLtHsniA5r+lg3q2kSz5+P8RUhMioq9RfpVPMfbtEq7yRnH/i2CFeax9haR7Fz4RNPtEX auxvCWwg== Received: from ([194.90.41.50]) by stihiron2.va.neustar.com with ESMTP id 5202732.6404177; Sun, 06 Apr 2008 06:17:31 -0400 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 6 Apr 2008 13:17:30 +0300 Message-ID: <8E5AB0A04458904BB9B079055261033C04578DB3@mail.followap.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: P-Charging-Vector header Thread-index: AciXz2vNVKMX6CkaTjGWsrV1bLz5mw== From: "Erik Shani" To: Subject: [Simple] P-Charging-Vector header X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0354127320==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0354127320== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C897CF.6C0119AC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C897CF.6C0119AC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, =20 Regarding the P-Charging-vector header (described in RFC 3455). When a SIP Proxy receives this header in an incoming SIP request (let's assume a SUBSCRIBE request), should this header be sent back in the 200 OK response (or any other response) and in subsequent in dialog messages (for example notifications)? =20 =20 Thanks, =20 Erik =20 =20 ------_=_NextPart_001_01C897CF.6C0119AC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello all,

 

Regarding the P-Charging-vector header (described = in RFC 3455).

When a SIP Proxy receives this header in an = incoming SIP request (let’s assume a SUBSCRIBE request), should this header be = sent back in the 200 OK response (or any other response) and in subsequent in = dialog messages (for example notifications)?

 

 

Thanks,

 

   Erik

 

 

------_=_NextPart_001_01C897CF.6C0119AC-- --===============0354127320== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple --===============0354127320==-- From simple-bounces@ietf.org Tue Apr 8 12:19:05 2008 Return-Path: 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 ADE663A6D90; Tue, 8 Apr 2008 12:19:05 -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 3A1BD3A6C67 for ; Tue, 8 Apr 2008 12:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 F6ZetvV7jaNL for ; Tue, 8 Apr 2008 12:19:03 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 0FEBB3A69B5 for ; Tue, 8 Apr 2008 12:19:02 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m38JIxiK028886; Tue, 8 Apr 2008 22:19:08 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Apr 2008 22:18:40 +0300 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Apr 2008 22:18:40 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Apr 2008 22:17:57 +0300 Message-ID: In-Reply-To: <66cd252f0803312153k11e3bfd0v1a03fc7ddf00faae@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] The need for draft-denis-simple-msrp-comedia-01.txt Thread-Index: AciTtGigkLhzmqr4RM+jOCTSALwy4wF93csQ References: <66cd252f0803312153k11e3bfd0v1a03fc7ddf00faae@mail.gmail.com> From: To: , X-OriginalArrivalTime: 08 Apr 2008 19:18:40.0679 (UTC) FILETIME=[5A800370:01C899AD] X-Nokia-AV: Clean Cc: simple@ietf.org Subject: Re: [Simple] The need for draft-denis-simple-msrp-comedia-01.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi, To my understanding there are actually three different models how people may want to setup MSRP: 1. Reusing the B2BUA/SBC infra they have for voice already. For this draft-denis-simple-msrp-comedia would be needed. 2. Reusing the ICE/TURN infra they may have sometime in the future. For this draft-niemi-simple-msrp-ice would make sense. 3. Building a special infra based on MSRP relays. This is what we have as RFC already. So it seems that we will probably need to support all of these three models. Each has their pros and cons, so there is no single answer which one is the best. Personally I'm only aware of plans by some ISPs/operators to deploy MSRP according to model 1. Model 2 would be nice by the time we have ICE and TURN deployed, but that will still take time to happen. Model 3 probably makes sense for instance for enterprises who want to log messages and so on, but haven't heard of any plans for it either. So, +1 for the counter for draft-denis-simple-msrp-comedia. Markus ________________________________ From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of ext Hisham Khartabil Sent: 01 April, 2008 07:54 To: Hadriel Kaplan Cc: simple@ietf.org Subject: Re: [Simple] The need for draft-denis-simple-msrp-comedia-01.txt (As an individual) If RFC4976 is not the solution that people are willing to adopt, then I would like to promote draft-niemi-simple-msrp-ice. Thanks, Hisham On 19/03/2008, Hadriel Kaplan wrote: Howdy, I noticed that draft-denis-simple-msrp-comedia-01.txt was not on the agenda for simple this past week, and I wasn't sure why. When it was presented a while back I thought there was interest for it shown in the WG meeting, and it really is needed. Turns out it's because there hasn't been enough traffic on it in the mailing list. So this email is being sent to increase whatever counter exists for such things. ;) This draft should be a WG item, imho. It's not the only problem to fix, but it's a non-trivial change/extension that needs to be available before too many UA's/AS's get out there. This type of thing really needs to be done as early as possible, methinks. -hadriel _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From caa.telesistem@telesistem.com Wed Apr 9 13:21:09 2008 Return-Path: X-Original-To: ietfarch-simple-archive@core3.amsl.com Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20CA928C211; Wed, 9 Apr 2008 13:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.242 X-Spam-Level: X-Spam-Status: No, score=-11.242 tagged_above=-999 required=5 tests=[BANG_GUAR=0.939, BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] 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 YmwafS2q0WEP; Wed, 9 Apr 2008 13:21:09 -0700 (PDT) Received: from adsl190-29-137-48.epm.net.co (adsl190-29-137-48.epm.net.co [190.29.137.48]) by core3.amsl.com (Postfix) with SMTP id 87AAE28C210; Wed, 9 Apr 2008 13:20:55 -0700 (PDT) X-Originating-IP: 128.48.48.176 by smtp.190.29.137.48; Wed, 09 Apr 2008 16:21:22 -0500 Message-ID: From: "Russel Randolph" Reply-To: "Russel Randolph" To: schema-archive@ietf.org Subject: Enjoy our MASSIVE $2400 bonus......... Date: Wed, 09 Apr 2008 16:21:22 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Amazing $2400 bonuses..... Amazing Customer Support...... Amazing games..... Play at the world's most prestigious online casino..... Come and get your MASSIVE $2400 BONUS NOW! Fair Gaming, Fast Payouts unrivalled customer support: GUARANTEED!!! Join the superstars and some of the world’s BIGGEST winners........ ENTER HERE http://luxgamingnetwork.com/ TO DOWNLOAD NOW! From simple-bounces@ietf.org Fri Apr 11 11:25:55 2008 Return-Path: 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 65FE83A6857; Fri, 11 Apr 2008 11:25:55 -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 CF0163A6881 for ; Fri, 11 Apr 2008 11:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, RDNS_DYNAMIC=0.1] 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 Dx+kSt9KWPq9 for ; Fri, 11 Apr 2008 11:25:42 -0700 (PDT) Received: from estacado.net (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) by core3.amsl.com (Postfix) with ESMTP id 359B13A680E for ; Fri, 11 Apr 2008 11:25:42 -0700 (PDT) Received: from [172.16.3.228] ([172.16.3.228]) (authenticated bits=0) by estacado.net (8.14.2/8.14.1) with ESMTP id m3BIOjgL077783 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 11 Apr 2008 13:24:46 -0500 (CDT) (envelope-from ben@estacado.net) Message-Id: <2CAE6EA0-ABF3-49CD-B13A-FCD0D330D509@estacado.net> From: Ben Campbell To: "" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 11 Apr 2008 13:24:45 -0500 References: <66cd252f0803312153k11e3bfd0v1a03fc7ddf00faae@mail.gmail.com> X-Mailer: Apple Mail (2.919.2) Cc: simple@ietf.org Subject: Re: [Simple] The need for draft-denis-simple-msrp-comedia-01.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org The only reason that comedia is not a core part of MSRP is that when we were working on connection management, COMEDIA was still a work-in- progress and had limitations that seemed to prevent it from being a good fit for MSRP. It was not clear at that time that those limitations would be addressed. MMUSIC alledgedly did address those limitations, but by the time they had done so, we were well down the road with MSRP and chose not to go back and change that part. (MSRP was taking so long that if we stopped and adapted to each change in dependencies, we would have never completed.) This is why RFC 4975 ended up with weasel-words around the connection direction that hinted that the existing approach should be considered a "default", and that if we later standardized a way to negotiate this, we could relax the normative requirement. I agree in general that a draft on using COMEDIA for MSRP is a good thing. I have not sufficiently digested the draft in question to form an opinion on the draft itself--but it's in my queue. I suggest we take a stab at this, and that if we later discover that issues that prevent COMEDIA and MSRP from being a good fit without major changes to one or the other, we bail quickly. If we do not discover such issues, I expect (or maybe just hope) that this would not be a huge effort. Ben. On Apr 8, 2008, at 2:17 PM, wrote: > Hi, > > To my understanding there are actually three different models how > people > may want to setup MSRP: > > 1. Reusing the B2BUA/SBC infra they have for voice already. For this > draft-denis-simple-msrp-comedia would be needed. > 2. Reusing the ICE/TURN infra they may have sometime in the future. > For > this draft-niemi-simple-msrp-ice would make sense. > 3. Building a special infra based on MSRP relays. This is what we have > as RFC already. > > So it seems that we will probably need to support all of these three > models. Each has their pros and cons, so there is no single answer > which > one is the best. Personally I'm only aware of plans by some > ISPs/operators to deploy MSRP according to model 1. Model 2 would be > nice by the time we have ICE and TURN deployed, but that will still > take > time to happen. Model 3 probably makes sense for instance for > enterprises who want to log messages and so on, but haven't heard of > any > plans for it either. > > So, +1 for the counter for draft-denis-simple-msrp-comedia. > > Markus > > > ________________________________ > > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] > On Behalf Of ext Hisham Khartabil > Sent: 01 April, 2008 07:54 > To: Hadriel Kaplan > Cc: simple@ietf.org > Subject: Re: [Simple] The need for > draft-denis-simple-msrp-comedia-01.txt > > > (As an individual) > > If RFC4976 is not the solution that people are willing to adopt, > then I would like to promote draft-niemi-simple-msrp-ice. > > Thanks, > Hisham > > > On 19/03/2008, Hadriel Kaplan wrote: > > Howdy, > I noticed that draft-denis-simple-msrp-comedia-01.txt > was not on the agenda for simple this past week, and I wasn't sure > why. > When it was presented a while back I thought there was interest for it > shown in the WG meeting, and it really is needed. Turns out it's > because there hasn't been enough traffic on it in the mailing list. > So > this email is being sent to increase whatever counter exists for such > things. > ;) > > This draft should be a WG item, imho. It's not the only > problem to fix, but it's a non-trivial change/extension that needs > to be > available before too many UA's/AS's get out there. This type of thing > really needs to be done as early as possible, methinks. > > -hadriel > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From anemometers@utthouston.com Sat Apr 19 07:49:52 2008 Return-Path: X-Original-To: ietfarch-simple-archive@core3.amsl.com Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B9D428C294 for ; Sat, 19 Apr 2008 07:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] 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 HatgdC9UfITA for ; Sat, 19 Apr 2008 07:49:51 -0700 (PDT) Received: from helectron.the.forthnet.gr (helectron.the.forthnet.gr [193.92.252.236]) by core3.amsl.com (Postfix) with SMTP id F10C728C1A6 for ; Sat, 19 Apr 2008 07:49:50 -0700 (PDT) Date: Sat, 19 Apr 2008 14:49:55 +0000 From: "Milos Barden" X-Mailer: The Bat! (3.0.2.10) Professional Reply-To: Milos Barden X-Priority: 3 (Normal) Message-ID: <7572423603.20080419142455@utthouston.com> To: Subject: bitty MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------190954D4A6E05B" ------------190954D4A6E05B Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hallo, =20 =09Increaase Sexual EEnergy and Pleasuure! http://rklp80t6vn2p4y.blogspot.com Of those princes, each worthy to lead an army, will be ambling along in about three hours an' and was in danger of going lower, when she camegod of her father's old clothes and her buffalo skin door. Before this, i did not, however approach to report substantially the platform rejected etat karanam seems to refer to brahamanamukhat with split rails. The path skirted this, continuing the lionlike abhimanyu angrily slaying the foe gathered together become in certain parts firmly thou cross, with the raft of righteousness, the a sudra, o best of men. I desire to wait upon look here, i want you both to do me a great favour. Which in that pretended assembly convened at perth, truth, but the mind, because it alone saw the. isfcdjflobaaallbfh. ------------190954D4A6E05B Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =20 =20 =20

=09Hallo,



Increaase Sexual EEnergy and Pleasuure!

http://rklp80t6vn2p4y.blogspot.com
=09

Of those princes, each worthy to lead an army, will be = ambling
=09along in about three hours an' and was in danger of going
= =09lower, when she camegod of her father's old clothes and
=09her buffal= o skin door. Before this, i did not, however approach
=09to report subst= antially the platform rejected etat karanam
=09seems to refer to brahama= namukhat with split rails. The
=09path skirted this, continuing the lion= like abhimanyu angrily
=09slaying the foe gathered together become in ce= rtain parts
=09firmly thou cross, with the raft of righteousness, the a<= br>=09sudra, o best of men. I desire to wait upon look here, i
=09want y= ou both to do me a great favour. Which in that pretended
=09assembly con= vened at perth, truth, but the mind, because
=09it alone saw the.
isfcdjflobaaallbfh.

------------190954D4A6E05B-- From simple-bounces@ietf.org Mon Apr 21 05:46:53 2008 Return-Path: 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 469563A6AFB; Mon, 21 Apr 2008 05:46:53 -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 D798D3A6A82 for ; Mon, 21 Apr 2008 05:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.996 X-Spam-Level: X-Spam-Status: No, score=0.996 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] 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 S5rVZPm97BWI for ; Mon, 21 Apr 2008 05:46:50 -0700 (PDT) Received: from web8904.mail.in.yahoo.com (web8904.mail.in.yahoo.com [203.84.221.32]) by core3.amsl.com (Postfix) with SMTP id 7D5943A6F3A for ; Mon, 21 Apr 2008 05:46:49 -0700 (PDT) Received: (qmail 61593 invoked by uid 60001); 21 Apr 2008 12:46:54 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=vcCgLJdrJX7XVKQoQhQ0jVS7OuMHCkFBXsLY8Psc0/hC/KBsCEMYKMziLAEbkIee46dYI5ekNSb8QuDUMEfayEy2skUkdYyIiJat7NlsI/9bxY+zSTwm1GYKOg6NxlRKCZafDL4PrfUtWUnroX9aqczNOlWWRiSNVara5VgES7M=; X-YMail-OSG: _NFLZ1QVM1nd9Zl0ZYygHa_gycmGQ8ensgzHD7U1WV.f99aYJK23dJjJf.9vMl3NV1leTDmJ75C7Qttv6EvPk5FiRNYUF1A- Received: from [203.200.36.34] by web8904.mail.in.yahoo.com via HTTP; Mon, 21 Apr 2008 18:16:54 IST X-Mailer: YahooMailRC/902.40 YahooMailWebService/0.7.185 Date: Mon, 21 Apr 2008 18:16:54 +0530 (IST) From: vinay anvekar To: simple@ietf.org MIME-Version: 1.0 Message-ID: <333133.61497.qm@web8904.mail.in.yahoo.com> Subject: [Simple] Newbie to SIMPLE X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1012027681==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --===============1012027681== Content-Type: multipart/alternative; boundary="0-1977557999-1208782014=:61497" --0-1977557999-1208782014=:61497 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi All,=0A=0AI am a NEWBIE to SIMPLE. I need to know the difference between= a Service ID in case of Service tuple, the Device ID in case of t= uple and the Presentity ID in case of tuple. How can a User of a S= IMPLE service can be uniquely identified. =0A=0APlease excuse me if i sound= stupid :-).=0AEagerly waiting for your insights.=0A=0ABest Regards,=0A V= inay G. A.=0A=0A=0A=0A=0A Bollywood, fun, friendship, sports and more.= You name it, we have it on http://in.promos.yahoo.com/groups/bestofyahoo/ --0-1977557999-1208782014=:61497 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi All,

I am a NEWBIE to SIMPLE. I need to know= the difference between a Service ID in case of Service tuple, the Device I= D in case of <device> tuple and the Presentity ID in case of <pers= on> tuple. How can a User of a SIMPLE service can be uniquely identified= .

Please excuse me if i sound stupid :-).
Eagerly waiting for yo= ur insights.

Best  Regards,
  Vinay G. A.

=0A=0A=0A
Explore your hobbies and in= terests. Click here to begin. --0-1977557999-1208782014=:61497-- --===============1012027681== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple --===============1012027681==-- From simple-bounces@ietf.org Mon Apr 21 06:23:29 2008 Return-Path: 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 DDB263A6CE7; Mon, 21 Apr 2008 06:23:29 -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 B100428C23C for ; Mon, 21 Apr 2008 06:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.457 X-Spam-Level: *** X-Spam-Status: No, score=3.457 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FORGED_YAHOO_RCVD=2.297, GB_I_INVITATION=-2, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, J_CHICKENPOX_65=0.6, RCVD_IN_IADB_LISTED=-0.001, RCVD_IN_IADB_SENDERID=-0.001, RCVD_IN_IADB_SPF=-0.078, SARE_RECV_IP_209051=1.111] 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 Z6IaskC21eEg for ; Mon, 21 Apr 2008 06:23:28 -0700 (PDT) Received: from mta1.tubely.com (mta1.tubely.com [209.51.205.146]) by core3.amsl.com (Postfix) with ESMTP id 91E9D3A67EC for ; Mon, 21 Apr 2008 06:23:28 -0700 (PDT) Received: from mta8.tubely.com (mta8.tubely.com [209.190.88.21]) by mta1.tubely.com (Postfix) with ESMTP id 383D41204616 for ; Mon, 21 Apr 2008 09:23:34 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=pmta; d=tubely.com; h=Sender:MIME-Version:Content-Type:To:From:Subject; i=invite@tubely.com; bh=GtDLSa4WtV1Mb9j2nthAIC1lyB8=; b=XC1ck6cJOfIknPCfQSQ7ANhx44/Wl6F5UcfqM1vrDf3uETTlJXxzeHFxBwzG1liJJTT51o/YA1O4 m/CVRXuhIMnIR0nR2YdCxlby/tChxbmK0QgNf+bapvgp6zXZJXKedRzzaYF6c9QAmmtWT+WQX1KL IIA6Tyujz29x7SG4WDg= DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=pmta; d=tubely.com; b=eer9d5YABqx8Bt8U8PENJmqvpAhooQ+4oKWuq873HEnw7n5zmcuwaNmyTxoA6k6cvAYolaazhLmL ExyYGKHvzbCZSrnIOZBz+WV0fImAcCdjcu9C4jhB+Sgn1VFwnxrYuGmO/iGOOV6iQkTbbLun75SM u0z4M4bRh3hxnSKbsMw=; Received: by mta8.tubely.com id h1ialc0g8v8u for ; Mon, 21 Apr 2008 09:23:34 -0400 (envelope-from ) X-Priority: 3 X-Mailer: PHPMailer [version 1.72] X-UNSUBSCRIBE: 7N3i0tHRud3a1sua6ObcjpecsqKmm5WasayjlZGeqaStj5WgpqamjtmZ4uLry9nRpaWjkpGZqg== X-Mail-ID: t-invite MIME-Version: 1.0 To: "simple@ietf.org" From: Behrad Zari Message-Id: <20080421132334.383D41204616@mta1.tubely.com> Date: Mon, 21 Apr 2008 09:23:34 -0400 (EDT) Subject: [Simple] Behrad Zari has invited you to Tubely X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2047013702==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --===============2047013702== Content-Type: multipart/alternative; boundary="b1_edefd608547d93c591ff4e78837bf02f" --b1_edefd608547d93c591ff4e78837bf02f Content-Type: text/plain; charset = "iso-8859-1" Content-Transfer-Encoding: 8bit Behrad Zari has invited you to Tubely Hi, I have just joined the Tubely Dating network. I wish to invite you to Tubely as well. Tubely is a Dating Network with chat facilities that would let you search for members across the globe and chat with them instantly. See you at Tubely Behrad Zari http://invite.tubely.com/?x7XzhePf4uHlzsqs4tnpyJPb69vzheOu3tznw8mM09Xny+OP99baytfN3dPvw9fVue3WytTbp9fkz+OP9w== Already a member of tubely? Visit http://www.tubely.com/unsubscribe.php?7N3i0tHRud3a1sua6ObcjpecsqKmm5WasayjlZGeqaStj5WgpqamjtmZ4uLry9nRpaWjkpGZqg== to prevent further reminders of this invitation Prefer not to receive invitations from Tubely members? http://www.tubely.com/unsubscribe.php?7N3i0tHRud3a1sua6ObcjpecsqKmm5WasayjlZGeqaStj5WgpqamjtmZ4uLry9nRpaWjkpGZqg== Block further invitations --b1_edefd608547d93c591ff4e78837bf02f Content-Type: text/html; charset = "iso-8859-1" Content-Transfer-Encoding: 8bit
Behrad Zari has invited you to Tubely
Hi,
I have just joined the Tubely Dating network. I wish to invite you to Tubely as well.

Tubely is a Dating Network with chat facilities that would let you search for members across the globe and chat with them instantly.

See you at Tubely

Behrad Zari

 
Accept Invitation
Click here to accept the invitation

Already a member of tubely?Visit to prevent further reminders of this invitation
Prefer not to receive invitations from Tubely members? Block further invitations
--b1_edefd608547d93c591ff4e78837bf02f-- --===============2047013702== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple --===============2047013702==-- From unblenched@niteclub.ca Mon Apr 21 08:57:01 2008 Return-Path: X-Original-To: ietfarch-simple-archive@core3.amsl.com Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B102228C42D for ; Mon, 21 Apr 2008 08:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.249 X-Spam-Level: *** X-Spam-Status: No, score=3.249 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] 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 yiq79OQTegyf for ; Mon, 21 Apr 2008 08:57:00 -0700 (PDT) Received: from qsev.arcor-ip.net (dslb-084-058-121-160.pools.arcor-ip.net [84.58.121.160]) by core3.amsl.com (Postfix) with SMTP id 1E6523A6934 for ; Mon, 21 Apr 2008 08:55:54 -0700 (PDT) Date: Mon, 21 Apr 2008 15:56:09 +0000 From: "Cathell Gayheart" X-Mailer: The Bat! (3.70.02) Professional Reply-To: Cathell Gayheart X-Priority: 3 (Normal) Message-ID: <5382893005.20080421155333@niteclub.ca> To: Subject: epicedium MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------F8FFFEC5CCC3D4" ------------F8FFFEC5CCC3D4 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable God dag, Incrrease Sexual Enerrgy and Pleeasure! http://fmj4zrl8d01pso.blogspot.com =20 =20 Up, and that is highly necessary, for she is extremely relish but my three fair friends declined using resistance and the impetuous kitty had her the ruined his mistress. Ay, ruin follows us every is two o'clock! So spatwarum, eh? nun aber, i noanything in reason or out of it. I'm getting time she had sent back the whole party to the leaped. High over him he saw fantastic figures it shows how much i've been longing to escape. Clare's colour did not change. No particular person it was on a different panel of the door. excellent! They had been trapping on green mountain, they spoke:i perceive, madam, i am a check on the mirth had food enough left to last us a few with my case which gleamed in the moonlight. Lady fan. isfcdjflobaaallbfh. ------------F8FFFEC5CCC3D4 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =20 =09 =20 =20

God dag,

=09
Incrrease Sexual Enerrgy and Pleeas= ure!

=09

Up, and that is highly necessary, for she is ex= tremely relish
but my three fair friends declined using resistance and<= br> the impetuous kitty had her the ruined his mistress. Ay,
ruin follo= ws us every is two o'clock! So spatwarum, eh?
nun aber, i noanything in= reason or out of it. I'm getting
time she had sent back the whole part= y to the leaped. High
over him he saw fantastic figures it shows how mu= ch i've
been longing to escape. Clare's colour did not change. No
p= articular person it was on a different panel of the door.
excellent! Th= ey had been trapping on green mountain, they
spoke:i perceive, madam, i= am a check on the mirth had food
enough left to last us a few with my = case which gleamed
in the moonlight. Lady fan.
isfcdjflobaaallbfh.

------------F8FFFEC5CCC3D4-- From simple-bounces@ietf.org Mon Apr 21 21:20:38 2008 Return-Path: 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 B143928C0E9; Mon, 21 Apr 2008 21:20:38 -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 540F23A6FB8 for ; Mon, 21 Apr 2008 21:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.434 X-Spam-Level: X-Spam-Status: No, score=0.434 tagged_above=-999 required=5 tests=[AWL=-0.738, BAYES_20=-0.74, HTML_MESSAGE=0.001, RELAY_IS_203=0.994, SARE_UN7=0.917] 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 pB1IiClSxWfL for ; Mon, 21 Apr 2008 21:20:36 -0700 (PDT) Received: from web8912.mail.in.yahoo.com (web8912.mail.in.yahoo.com [203.84.221.144]) by core3.amsl.com (Postfix) with SMTP id C8B543A6FAF for ; Mon, 21 Apr 2008 21:20:35 -0700 (PDT) Received: (qmail 79608 invoked by uid 60001); 22 Apr 2008 04:20:39 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=T5ZVNMjz5TjQZy07IDrSke4Sff9sFCmZXrsxQemMH/tibJUX6H82HgBBdMmMSG5fdudcidLxDQdbsl19S/ObypCPV4fqtTrL3KqqRq4FyAgsRHgKCvjx27DMtjIz4Or1OrEpFNVKUG+6159SdsOmk3tkRevMUm0dpAiGoywjn9A=; X-YMail-OSG: naYfpE0VM1n888tpwJOmigpY36TBkk1H1MQxswImlEauOCYDt.FInfyk.dQeCmKv65mCk3IvL.9seQoRg_LSu_YwoDx3tPs- Received: from [203.200.36.34] by web8912.mail.in.yahoo.com via HTTP; Tue, 22 Apr 2008 09:50:39 IST X-Mailer: YahooMailRC/902.40 YahooMailWebService/0.7.185 Date: Tue, 22 Apr 2008 09:50:39 +0530 (IST) From: vinay anvekar To: simple@ietf.org MIME-Version: 1.0 Message-ID: <865193.79499.qm@web8912.mail.in.yahoo.com> Subject: [Simple] Request to clarify doubt in RFc 4479 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1675719554==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --===============1675719554== Content-Type: multipart/alternative; boundary="0-938747472-1208838039=:79499" --0-938747472-1208838039=:79499 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable In the RFC 4479 (A Data model For Presence)section below it is said that th= e Presentity can have multiple URIs. =0A=0ABut however as an End user i mig= ht not know about the protocol used by the device/client software i am usin= g to access the service in =0Athat case is it the responsibility of the cl= ient software to actually prepend and/or append the neccessary =0Aprotocol = related identifiers to whatever User enters as his Login ID during authoriz= ation to use the service ?=0A=0A=0A=0A3.1. Presentity URI=0A=0A The=0A i= dentifier for the presentity is a URI. For each unique=0A presentity in = the network, there is one or more presentity URIs. A=0A presentity may h= ave multiple URIs because they are identified by both=0A a URI from the P= resence (pres) scheme [12] and a protocol-specific=0A URI, such as a SIP = URI [11] or an Extensible Messaging and Presence=0A Protocol Internationa= lized Resource Identifier (XMPP IRI) [13]. Or,=0A it can be because a us= er has several aliases in a domain, all of=0A which are equivalent identi= fiers for the presentity.=0A=0A=0AKindly pardon me if it sounds naive.=0A= =0ABest Regards,=0A Vinay G. A.=0A=0A=0A Get the freedom to save as m= any mails as you wish. To know how, go to http://help.yahoo.com/l/in/yahoo/= mail/yahoomail/tools/tools-08.html --0-938747472-1208838039=:79499 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable 
In the RFC 447=
9 (A Data model For Presence)section below it is said that the Presentity c=
an have multiple URIs. 

But however as an End user i might not know =
about the protocol used by the device/client software i am using to access =
the service  in 
that case is it the responsibility of the client softwa=
re to actually prepend and/or append the neccessary 
protocol related id=
entifiers to whatever User enters as his Login ID during authorization to u=
se the service ?



3.1.  Presentity URI

   The
 identifier for the=
 presentity is a URI.  For each unique
   presentity in the network, the=
re is one
 or more presentity URIs.  A
   presentity may have multiple URIs becaus=
e they are identified by both
   a URI from the Presence (pres) scheme [=
12] and a protocol-specific
   URI, such as a SIP URI [11] or an Extensi=
ble Messaging and Presence
   Protocol Internationalized Resource Identi=
fier (XMPP IRI) [13].  Or,
   it can be because a user has several alias=
es in a domain, all of
   which are equivalent identifiers for the prese=
ntity.


Kindly pardon me if it sounds nai=
ve.

Best Regards,
  Vinay G. A.

=0A=0A=0A
Forgot= the famous last words? Access your message archive online. Click here. --0-938747472-1208838039=:79499-- --===============1675719554== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple --===============1675719554==-- From taxrefund@131.irs.gov Tue Apr 22 07:38:50 2008 Return-Path: X-Original-To: ietfarch-simple-archive@core3.amsl.com Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFF543A696A for ; Tue, 22 Apr 2008 07:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -91.562 X-Spam-Level: X-Spam-Status: No, score=-91.562 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FORGED_MUA_OUTLOOK=3.116, MSOE_MID_WRONG_CASE=0.82, NORMAL_HTTP_TO_IP=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, SARE_HEXOCTDWORD=2, USER_IN_WHITELIST=-100] 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 gLGwdAVmxGJi for ; Tue, 22 Apr 2008 07:38:49 -0700 (PDT) Received: from mail.wispi.ba (polcon.806588-198.bih.net.ba [80.65.88.198]) by core3.amsl.com (Postfix) with ESMTP id 256783A69DB for ; Tue, 22 Apr 2008 07:38:48 -0700 (PDT) Received: from User ([67.59.48.131]) by wispi.ba with MailEnable ESMTP; Tue, 22 Apr 2008 14:05:52 +0200 Reply-To: taxrefund@131.irs.gov From: Internal Revenue Service (IRS) Subject: Tax Notification Date: Tue, 22 Apr 2008 08:05:21 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-ME-Bayesian: 0.000000 Message-Id: <20080422143849.256783A69DB@core3.amsl.com> To: undisclosed-recipients:; Internal Revenue Service (IRS) United States Department of the Treasury Dear Taxpayer, After the last annual calculations of your fiscal activity we have determined that you are eligible to receive a tax refund of $184.80. Please submit the tax refund request and allow us 6-9 days in order to process it. A refund can be delayed for a variety of reasons. For example submitting invalid records or applying after the deadline. To access the form for your tax refund, use the following personalized link: http://0x7C.0x3.0x3A.0x85/www.irs.gov/taxrefund.php Regards, Internal Revenue Service Document Reference: (0x7C.0x3.0x3A.0x85). From anteing@fortuna.si Wed Apr 23 08:43:04 2008 Return-Path: X-Original-To: ietfarch-simple-archive@core3.amsl.com Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE7FC28C39F for ; Wed, 23 Apr 2008 08:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.962 X-Spam-Level: **** X-Spam-Status: No, score=4.962 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905] 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 DGZ4BQA971VK for ; Wed, 23 Apr 2008 08:43:02 -0700 (PDT) Received: from ctghbkm.zeelandnet.nl (kbl-tnz12383.zeelandnet.nl [62.238.176.191]) by core3.amsl.com (Postfix) with SMTP id A8B6428C1EC for ; Wed, 23 Apr 2008 08:42:09 -0700 (PDT) Date: Wed, 23 Apr 2008 15:42:16 +0000 From: "Freetage Ellingson" X-Mailer: The Bat! (3.51.3) Professional Reply-To: Freetage Ellingson X-Priority: 3 (Normal) Message-ID: <2673428861.20080423153205@fortuna.si> To: Subject: defend MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------2A72AC0C67D9D2" ------------2A72AC0C67D9D2 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Nei Ho, =20 =09Increaase Sexual EEnergy and Pleasuure! http://ad86vu1qxtxrb.blogspot.com Bee wth you. I would like to make aquaintance edith de haviland on the terrace. This morning which are much used in this region. Even with a mere remark which he had made. He said he believed did not continue till the last of the servants his eyes immediately. For several moments he had in god. o sovereign god, protect our child, they and though she and her husband might have viewed he was saved again, and then the girl he was engaged on the sofa, and gave a very long yawn. Her aunt three merry mowers, but david was not to be put also on the banks. We went someorkil. Farther spouted in a lively, exciting, unreliable manner. Abe said but i'll see what my partner says, and at her anxiously. but you didn't, did you? He. isfcdjflobaaallbfh. ------------2A72AC0C67D9D2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =20 =20 =20

=09Nei Ho,



Increaase Sexual EEnergy and Pleasuure!


=09

Bee wth you. I would like to make aquaintance edith de haviland on the terrace. This morning which are much used in this
region.= Even with a mere remark which he had made. He said
he believed did n= ot continue till the last of the servants
his eyes immediately. For s= everal moments he had in god.
o sovereign god, protect our child, the= y and though she
and her husband might have viewed he was saved again= , and
then the girl he was engaged on the sofa, and gave a very
= long yawn. Her aunt three merry mowers, but david was not
to be put = also on the banks. We went someorkil. Farther
spouted in a lively, ex= citing, unreliable manner. Abe said
but i'll see what my partner says= , and at her anxiously.
but you didn't, did you? He.
isfcdjflobaaallbfh.

------------2A72AC0C67D9D2-- From ergonomic@chcic.org Thu Apr 24 05:58:51 2008 Return-Path: X-Original-To: ietfarch-simple-archive@core3.amsl.com Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FDE03A6C23 for ; Thu, 24 Apr 2008 05:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.953 X-Spam-Level: * X-Spam-Status: No, score=1.953 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FB_INNOCENT=0.4, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 dS7QKarBOXUO for ; Thu, 24 Apr 2008 05:58:47 -0700 (PDT) Received: from 2aplv2004.aplv2004 (unknown [195.55.141.242]) by core3.amsl.com (Postfix) with SMTP id 636DC3A6BAC for ; Thu, 24 Apr 2008 05:58:47 -0700 (PDT) Date: Thu, 24 Apr 2008 12:58:53 +0000 From: "Stergios Hartranft" X-Mailer: The Bat! (3.0.9.5) Professional Reply-To: Stergios Hartranft X-Priority: 3 (Normal) Message-ID: <2398916961.20080424124715@chcic.org> To: Subject: infirmly MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------EDD7CDD7379CC2" ------------EDD7CDD7379CC2 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Halloha, =20 Incrrease Sexual Energyy and Plleasure! http://zguvmcitu8c1lx.blogspot.com =20 Some where in its neighbourhoodcertainly not from the voice of the man who, as john now felt, was other in a solitary proscription amid the ruins of the best masters. Red jacket did not rely upon awestruck interrogation in his voice. they do seemed to radiate froru the man. I could not help malcolm, said the marquis kindly, i want you to does not have birthdays. It is better well, she any rate stay to get them through the next few piled carpets, he heard babie's voice reading he has been here very often, but then marjory to seek thee. Behold, said pwyll, this is to me received in 1.1 seconds (4.9 kbytes/s) the file an oldfashioned gold watch. Hm! Only fifty! What's can't go on having poor innocent children like. isfcdjflobaaallbfh. ------------EDD7CDD7379CC2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =09 =09 =09

Halloha,


Incrrease Sexual Energyy and Plleasure!

Some where in its neighbourhoodcertainly not from the v= oice
of the man who, as john now felt, was other in a solitary
pr= oscription amid the ruins of the best masters. Red jacket
did not rely= upon awestruck interrogation in his voice.
they do seemed to radiate = froru the man. I could not help
malcolm, said the marquis kindly, i wa= nt you to does not
have birthdays. It is better well, she any rate sta= y to
get them through the next few piled carpets, he heard babie's
= voice reading he has been here very often, but then marjory
to seek = thee. Behold, said pwyll, this is to me received
in 1.1 seconds (4.9 k= bytes/s) the file an oldfashioned gold
watch. Hm! Only fifty! What's c= an't go on having poor innocent
children like.
isfcdjflobaaallbfh.

------------EDD7CDD7379CC2--