From simple-bounces@ietf.org Sun Jul 02 14:21:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fx6Za-00085d-Av; Sun, 02 Jul 2006 14:21:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fx6ZY-00083t-2R for simple@ietf.org; Sun, 02 Jul 2006 14:21:32 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fx6ZW-00088X-RA for simple@ietf.org; Sun, 02 Jul 2006 14:21:32 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 02 Jul 2006 11:21:32 -0700 X-IronPort-AV: i="4.06,199,1149490800"; d="scan'208"; a="302616635:sNHT31073700" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id k62ILUDn023140; Sun, 2 Jul 2006 11:21:30 -0700 Received: from [192.168.1.2] (sjc-vpn6-311.cisco.com [10.21.121.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k62ILTcL001946; Sun, 2 Jul 2006 11:21:29 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8D8DC628-F387-4E0C-8883-EEE5983B3EF0@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Sun, 2 Jul 2006 11:21:26 -0700 To: Peter Saint-Andre , Avshalom Houri , Joe Hildebrand X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=117; t=1151864490; x=1152728490; c=relaxed/simple; s=sjdkim7001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:draft-siantandre-smpp-simple-07; X=v=3Dcisco.com=3B=20h=3DuBqcHxypeSZ3Tfdwswrlb3RF5xw=3D; b=VScfeNiNDwcrbdl5spgqw9lm1i4nR4Of+xjXkMoZhkMC95CIz2bQKj14i3/gKQUywpRdAWpw NocT5s6DgALM0CFJ2DpaJvKgaFgmlBx6zkcjC0ncQfse0vDMECYEtlls; Authentication-Results: sj-dkim-7.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Cc: simple@ietf.org Subject: [Simple] draft-siantandre-smpp-simple-07 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org This draft looks good - I could not find any relevant comments to send other than I like it :-) Thanks, Cullen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 03 18:21:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxWmh-0007OG-IT; Mon, 03 Jul 2006 18:20:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxWmg-0007Nw-Ro; Mon, 03 Jul 2006 18:20:50 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxWmf-0002dw-LA; Mon, 03 Jul 2006 18:20:50 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Jul 2006 17:20:47 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Mon, 03 Jul 2006 17:20:46 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Jul 2006 17:20:45 -0500 Message-ID: From: "Thomson, Martin" To: "Ted Hardie" , , Date: Mon, 3 Jul 2006 17:20:03 -0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 03 Jul 2006 22:20:45.0985 (UTC) FILETIME=[EE0CA910:01C69EEE] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: Content-class: urn:content-classes:message Thread-Topic: [Geopriv] Proposed Resolution to thedraft-ietf-geopriv-common-policy issue. Thread-Index: AcacfVQU9MwikSwORc+7rLNIU6Y3NACcWDlQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: hartmans@mit.edu, phoffman@isc.org Subject: [Simple] RE: [Geopriv] Proposed Resolution to thedraft-ietf-geopriv-common-policy issue. X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 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="===============0766063791==" Errors-To: simple-bounces@ietf.org --===============0766063791== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message Ny4xLjMgbmVlZHMgdG8gYmUgcmVudW1iZXJlZCBhcyB3ZWxsOyB5b3Ugc2hvdyBpdCBhcyAxLCAz LCA0Og0KDQo+IE5FVzoNCj4gDQo+ICAgIDEuICBUcmFuc2xhdGUgcGVyY2VudC1lbmNvZGluZyBm b3IgZWl0aGVyIHN0cmluZy4NCj4gDQo+ICAgIDMuICBDb252ZXJ0IGJvdGggZG9tYWluIHN0cmlu Z3MgdXNpbmcgdGhlIHRvQVNDSUkgb3BlcmF0aW9uIGRlc2NyaWJlZA0KPiAgICAgICAgaW4gUkZD IDM0OTAgWzJdLg0KPiANCj4gICAgNC4gIENvbXBhcmUgdGhlIHR3byBkb21haW4gc3RyaW5ncyBm b3IgQVNDSUkgZXF1YWxpdHksIGZvciBlYWNoDQo+ICAgICAgICBsYWJlbC4gIElmIHRoZSBzdHJp bmcgY29tcGFyaXNvbiBmb3IgZWFjaCBsYWJlbCBpbmRpY2F0ZXMNCj4gICAgICAgIGVxdWFsaXR5 LCB0aGUgY29tcGFyaXNvbiBzdWNjZWVkcy4gIE90aGVyd2lzZSwgdGhlIGRvbWFpbnMgYXJlDQo+ ICAgICAgICBub3QgZXF1YWwuDQo+IA0KPiAgICBJZiB0aGUgY29udmVyc2lvbiBmYWlscyBpbiBz dGVwICgyKSwgdGhlIGRvbWFpbnMgYXJlIG5vdCBlcXVhbC4NCj4gDQoNClRoYW5rcywNCk1hcnRp bg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlzIG1lc3NhZ2Ug aXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBtYXkNCmNvbnRhaW4gcHJp dmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0aW9uLiAg DQpJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyDQppbW1lZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbC4gIEFueSB1bmF1dGhvcml6 ZWQgdXNlIG9mDQp0aGlzIGVtYWlsIGlzIHByb2hpYml0ZWQuDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NClttZjJd --===============0766063791== 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://www1.ietf.org/mailman/listinfo/simple --===============0766063791==-- From simple-bounces@ietf.org Wed Jul 05 21:45:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyIvY-0001g2-8I; Wed, 05 Jul 2006 21:45:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyIvX-0001fx-Ad for simple@ietf.org; Wed, 05 Jul 2006 21:45:11 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyIvV-0007k8-TF for simple@ietf.org; Wed, 05 Jul 2006 21:45:11 -0400 Received: from [172.17.2.251] (dsl001-129-070.dfw1.dsl.speakeasy.net [72.1.129.70]) (authenticated bits=0) by nostrum.com (8.13.6/8.13.6) with ESMTP id k661hqsD036253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Jul 2006 20:43:53 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <44AC6AC9.4040907@nostrum.com> Date: Wed, 05 Jul 2006 20:43:37 -0500 From: Adam Roach User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Peter Saint-Andre Subject: Re: [Simple] "last call" on SIMPLE-XMPP interworking I-D References: <448610BB.5000707@jabber.org> In-Reply-To: <448610BB.5000707@jabber.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 72.1.129.70 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: xmppwg@jabber.org, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org I have a few relatively broad comments on the draft. 1. MIME Types The document omits a discussion of MIME types. In particular, I think you'll find that many (or most) SIMPLE implementations use something slightly more sophisticated than text/plain for instant messaging (text/html, for example, seems quite popular). I'm not familiar with how XMPP handles rich message content, although RFC 3921 hints at the ability to embed XHTML message bodies in elements. I would suggest that the mapping document would be far more helpful if it contained a brief discussion of at least the mapping from SIMPLE messages with text/html bodies and XHTML content in XMPP messages. As far as I know, the only complete answer for other MIME types in general is the use of RFC 3923. The document should probably either explicitly rule non-text MIME types out of scope or mention RFC 3923 as a solution for non-text MIME types. 2. Infinite Message Amplification If I read section 4.2 correctly: when the gateway receives an XMPP stanza with type='subscribe', the gateway is responsible from that moment until the subscriber sends a stanza with type='unsubscribe' (which may never happen) for maintaining not just the record of the subscription, but an actual live subscription -- complete with SUBSCRIBE refreshes -- to the SIP entity. Is that right? This seems to be a Really Bad Thing, both from a general scalability perspective (maintaining live SIP subscriptions for entities that are offline) and from a security perspective (one message in, infinite messages out makes for a mighty fine traffic amplifier). Unfortunately, I don't have any suggestions here, although the bare minimum that the draft needs to do is detail these properties more prominently -- including some discussion in the Security Considerations around the infinite-message amplification properties proposed by the document. To be clear about the danger here, I'll outline a potential attack. I learn that example.net is running an XMPP/SIP gateway to serve their SIP users. I learn the identity of _one_ SIP user in their domain. Then, I open up a TCP connection to their gateway, and introduce myself as a jabber server. I pretend that I have four thousand users who are interested in the presence state of the one SIP user I know about in their domain. To do so, I send out four thousand requests, each from a unique user; I pace these out with about a one second gap between each. Now I'm done. I spent a little over an hour sending XMPP subscription requests; in response, I have increased the load on the victim SIP server by a little more than one TPS from now until the heat death of the universe. If I do it again, I double that additional load. And, of course, if I blasted the requests out as fast as possible for a day or two, the devastation would be complete. 3. Subscription Permission Indication The receipt of a 200-class response to a SUBSCRIBE message means that the SUBSCRIBE message has been received. It does not mean that permission to subscribe to the resource has been granted. The only way to know that permission to subscribe to the resource has been granted is the receipt of a NOTIFY message with a "Subscription-State:" header field of "active". Based on the text in section 6.2 of RFC 3921, I believe that XMPP uses with a type of 'subscribed' to indicate that permission has been granted. The mapping document suggests mapping the 200-class response to a stanza of 'subscribed'. This is a semantic mismatch. The stanza should be withheld until a NOTIFY arrives with a Subscription-State of "active." Similarly, if a NOTIFY arrives that contains a Subscription-State of "terminated" with a reason code of "rejected" or "noresource", the gateway should send a stanza. Any other NOTIFYs -- that is, other Subscription-States and/or other reason codes shouldn't trigger a stanza at all, since they don't have implications about whether subscription permission has been granted. /a Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > (Cross-posted to the SIMPLE and XMPP lists.) > > Because draft-saintandre-xmpp-simple appears to have reached stability, > it seems appropriate to request an unofficial last call on this document > (which has perhaps the longest title in IETF history). > > The I-D is available here: > > http://www.ietf.org/internet-drafts/draft-saintandre-xmpp-simple-07.txt > > http://www.xmpp.org/drafts/draft-saintandre-xmpp-simple-07.html > > Please note that this I-D seeks to define only basic presence and > messaging interoperability between SIMPLE and XMPP systems. Use cases > such as extended presence, chat and multi-party messaging, and file > transfer are not covered by this specification, but may be discussed in > future I-Ds. > > Feedback may be sent directly to me, to all three authors, or to either > or both of the lists. > > Thanks! > > Peter > > - -- > Peter Saint-Andre > Jabber Software Foundation > http://www.jabber.org/people/stpeter.shtml > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.1 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFEhhC6NF1RSzyt3NURAtjJAJ9LW+cttgPCKwK8ViYP5KEagn5qegCdFtR+ > cx34mhV520JK9Diwvw3wdaY= > =s8TL > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------ > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 06 13:48:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyXxM-0000bL-Uj; Thu, 06 Jul 2006 13:48:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyXxL-0000bG-Gw for simple@ietf.org; Thu, 06 Jul 2006 13:48:03 -0400 Received: from corp-fw-main.jabber.com ([207.182.164.14] helo=wrk187.corp.jabber.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyXxI-0008Bs-N7 for simple@ietf.org; Thu, 06 Jul 2006 13:48:03 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by wrk187.corp.jabber.com (Postfix) with ESMTP id EFD574FC306; Thu, 6 Jul 2006 11:48:05 -0600 (MDT) Message-ID: <44AD4CD5.2000001@jabber.org> Date: Thu, 06 Jul 2006 11:48:05 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.4) Gecko/20060530 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Adam Roach Subject: Re: [Simple] "last call" on SIMPLE-XMPP interworking I-D References: <448610BB.5000707@jabber.org> <44AC6AC9.4040907@nostrum.com> In-Reply-To: <44AC6AC9.4040907@nostrum.com> X-Enigmail-Version: 0.94.0.0 Jabber-ID: stpeter@jabber.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd Cc: xmppwg@jabber.org, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 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="===============1865280319==" Errors-To: simple-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1865280319== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040206020907050009000503" This is a cryptographically signed message in MIME format. --------------ms040206020907050009000503 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Adam, thanks for the feedback. Comments inline. Adam Roach wrote: > I have a few relatively broad comments on the draft. > > 1. MIME Types > > The document omits a discussion of MIME types. In particular, I > think you'll find that many (or most) SIMPLE implementations use > something slightly more sophisticated than text/plain for instant > messaging (text/html, for example, seems quite popular). Yes, I was talking with an implementor recently and realized that the draft needs to discuss handling of various MIME types. It would be helpful to know which types are in broad use, since my understanding is that any MIME type is allowed. > I'm not familiar with how XMPP handles rich message content, > although RFC 3921 hints at the ability to embed XHTML message bodies > in elements. We've defined an XHTML 1.0 Integration Set for HTML message bodies: http://www.jabber.org/jeps/jep-0071.html > I would suggest that the mapping document would be far more helpful > if it contained a brief discussion of at least the mapping from > SIMPLE messages with text/html bodies and XHTML content in XMPP > messages. Agreed. > As far as I know, the only complete answer for other MIME types in > general is the use of RFC 3923. The document should probably either > explicitly rule non-text MIME types out of scope or mention RFC 3923 > as a solution for non-text MIME types. For now, I think it would be best to specify that implementations MUST handle text/plain, SHOULD handle text/html (text to follow), and MAY handle other MIME types (leaving the handling of other types up to the implementation). > 2. Infinite Message Amplification > > If I read section 4.2 correctly: when the gateway receives an XMPP > stanza with type='subscribe', the gateway is responsible > from that moment until the subscriber sends a stanza > with type='unsubscribe' (which may never happen) for maintaining not > just the record of the subscription, but an actual live subscription > -- complete with SUBSCRIBE refreshes -- to the SIP entity. > > Is that right? I think that the gateway is responsible for maintaining the live subscription only if the request has been approved by the SIP user, not if the XMPP user has only sent a subscribe without receiving approval. If the text in the I-D is not clear on that point, I'll fix it. > This seems to be a Really Bad Thing, both from a general scalability > perspective (maintaining live SIP subscriptions for entities that > are offline) That concern could be addressed by specifying that a gateway must not maintain the live subscription on the SIP side for XMPP entities that are offline, which seems appropriate. > and from a security perspective (one message in, > infinite messages out makes for a mighty fine traffic amplifier). > > Unfortunately, I don't have any suggestions here, although the bare > minimum that the draft needs to do is detail these properties more > prominently -- including some discussion in the Security > Considerations around the infinite-message amplification properties > proposed by the document. > > To be clear about the danger here, I'll outline a potential attack. > I learn that example.net is running an XMPP/SIP gateway to serve > their SIP users. I learn the identity of _one_ SIP user in their > domain. Then, I open up a TCP connection to their gateway, and > introduce myself as a jabber server. I pretend that I have four > thousand users who are interested in the presence state of the one > SIP user I know about in their domain. To do so, I send out four > thousand requests, each from a unique user; I pace these > out with about a one second gap between each. Now I'm done. I spent > a little over an hour sending XMPP subscription requests; in > response, I have increased the load on the victim SIP server by a > little more than one TPS from now until the heat death of the > universe. If I do it again, I double that additional load. And, of > course, if I blasted the requests out as fast as possible for a day > or two, the devastation would be complete. I agree that this attack is bad. But it's not clear to me how this attack is different from a similar attack waged by one SIP presence server against another SIP presence server. For example, I learn that example.net is running a SIP presence server and I learn the identity of one SIP user in that domain (hapless_user@example.net). I set up a rogue SIP presence server at evil.example.com and I pretend that I have four thousand users who are interested in the availability of the hapless user. I send a SIP SUBSCRIBE refresh once a minute for each of my four thousand fake users. Thereby, I have seriously increased the load on the victim SIP presence server at example.net. Unless I'm missing something, this seems to be a problem with rogue servers, not with the protocol mapping (except for the caveats above about unapproved subscriptions and offline users). > 3. Subscription Permission Indication > > The receipt of a 200-class response to a SUBSCRIBE message means > that the SUBSCRIBE message has been received. It does not mean that > permission to subscribe to the resource has been granted. The only > way to know that permission to subscribe to the resource has been > granted is the receipt of a NOTIFY message with a > "Subscription-State:" header field of "active". > > Based on the text in section 6.2 of RFC 3921, I believe that XMPP > uses with a type of 'subscribed' to indicate that > permission has been granted. That's right. > The mapping document suggests mapping the 200-class response to a > stanza of 'subscribed'. This is a semantic mismatch. The > stanza should be withheld until a > NOTIFY arrives with a Subscription-State of "active." Similarly, if > a NOTIFY arrives that contains a Subscription-State of "terminated" > with a reason code of "rejected" or "noresource", the gateway should > send a stanza. Any other NOTIFYs -- > that is, other Subscription-States and/or other reason codes > shouldn't trigger a stanza at all, since they don't have > implications about whether subscription permission has been granted. Thanks, I'll correct that. Furthermore, I've received feedback off-list that it would be helpful for this document to specify a mapping of various error and status codes, so I'll add that to the next version, as well. Peter > Peter Saint-Andre wrote: > (Cross-posted to the SIMPLE and XMPP lists.) > > Because draft-saintandre-xmpp-simple appears to have reached stability, > it seems appropriate to request an unofficial last call on this document > (which has perhaps the longest title in IETF history). > > The I-D is available here: > > http://www.ietf.org/internet-drafts/draft-saintandre-xmpp-simple-07.txt > > http://www.xmpp.org/drafts/draft-saintandre-xmpp-simple-07.html > > Please note that this I-D seeks to define only basic presence and > messaging interoperability between SIMPLE and XMPP systems. Use cases > such as extended presence, chat and multi-party messaging, and file > transfer are not covered by this specification, but may be discussed in > future I-Ds. > > Feedback may be sent directly to me, to all three authors, or to either > or both of the lists. > > Thanks! > > Peter > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFErUzUNF1RSzyt3NURAjeuAKClyu5rmgqT8MTjWbklBpx+nRaomwCeLPy4 RFMShF6c94amCTdRTMjTOSM= =s/2C -----END PGP SIGNATURE----- --------------ms040206020907050009000503 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKdDCC BTYwggMeoAMCAQICAwGUqzANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEw MjUyMjM4NDhaFw0wNjEwMjUyMjM4NDhaMGoxHTAbBgNVBAMTFEouIFBldGVyIFNhaW50LUFu ZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQGphYmJlci5vcmcxJjAkBgkqhkiG9w0BCQEW F2oucGV0ZXJAc2FpbnQtYW5kcmUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEA1IwvV3ywawrPfb66pLs0KqIj5QKXYQ45EUlTzKp6iHeCQzd+Kr8AOO21dcs/s0VcQqno mVHDuqp0B+53Dp6Re66yc1x89U3HFFWw/HfLuAzbngoD9PmmSLaJsXGfO0PyXQPB5GVJfVnb RW0qfbZ7l278DATqilmBqGOvoDaJks/XjRvq7tt/0mPWlmWOplw/Nlniy0o6GlbwMnLLgNfM UG30nhWZj70qW5NZyPTjDQAeYw6LxFieXIk9+6gCc84d2j3VTBglPFe0JkUmdVDXdcFyvU7N UZWmWdMzvCu9tD3nb+6CipKATjYPQNRxMFGcfnP7HxeFLTBYoy8BHL33wQIDAQABo4HVMIHS MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZp Y2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMDIGCCsG AQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzA2BgNVHREE LzAtgRJzdHBldGVyQGphYmJlci5vcmeBF2oucGV0ZXJAc2FpbnQtYW5kcmUuY29tMA0GCSqG SIb3DQEBBAUAA4ICAQAV/ddHlibIhbnXGnEs1HUglGX5xCIZRW6g8jpCOKIgguVvjHFdvhyl O67VqjAXMCYKsWfI6Sfu6YyoDtSJpq8yWa/83nEq6aMOWtC6N2I9PINAojZelq97W6tHYrrJ L6ql6QnS0ubtlWJEcKZoVglMZ+gmqGeuKGmoT25Lz7pslxN7/HXBiRqFaHh/gBqFSy0AGLQA NvDsUx1VnYORRT3E+y1p1L82FgWKXHOLBZyaz2Eoi3CCroIA7JxhfQV+NNtVxhxmUyWj821c DHc1DLp3B9W4hW4PYdfn8Hdzepwug2dYovjyFYEU2kekC38iD9/VuuLK9Z4C66FD1uqCAFfd 1NRl1LzVIMVml991Ejmeju3h5WvdfFMAteDQjmfGgqB9CFPIM3MPKM/Ir3GeaoQ8OV55U1zy 2N5hkHEJdFeNIvg4AE+up7EKkMTdTuXWlYfAG2Tb8ToBrWFqYCUdxorhWM1q2TXrmCMXmsoH FPW7OIjaNyHykBoU3ZArm8I61UeGcvbtzf4AbDqXLvBjdup7oJofAWqY/2ZsWwmo8m7XqoYn BCZ/QOcPiZ+OwlhkXzh+qpk4ZBsy5FEFwt9rQQoyQJpaIwF1CFKuPzH3kl/2EJY0GjOtLGCO GMc3fAsxqV6YffveN18M4OYhLOkYay1QcgwJ81DSYvHs/2N5NjD4rDCCBTYwggMeoAMCAQIC AwGUqzANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRw Oi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkx ITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEwMjUyMjM4NDhaFw0w NjEwMjUyMjM4NDhaMGoxHTAbBgNVBAMTFEouIFBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZI hvcNAQkBFhJzdHBldGVyQGphYmJlci5vcmcxJjAkBgkqhkiG9w0BCQEWF2oucGV0ZXJAc2Fp bnQtYW5kcmUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1IwvV3ywawrP fb66pLs0KqIj5QKXYQ45EUlTzKp6iHeCQzd+Kr8AOO21dcs/s0VcQqnomVHDuqp0B+53Dp6R e66yc1x89U3HFFWw/HfLuAzbngoD9PmmSLaJsXGfO0PyXQPB5GVJfVnbRW0qfbZ7l278DATq ilmBqGOvoDaJks/XjRvq7tt/0mPWlmWOplw/Nlniy0o6GlbwMnLLgNfMUG30nhWZj70qW5NZ yPTjDQAeYw6LxFieXIk9+6gCc84d2j3VTBglPFe0JkUmdVDXdcFyvU7NUZWmWdMzvCu9tD3n b+6CipKATjYPQNRxMFGcfnP7HxeFLTBYoy8BHL33wQIDAQABo4HVMIHSMAwGA1UdEwEB/wQC MAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJF RSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMDIGCCsGAQUFBwEBBCYwJDAi BggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzA2BgNVHREELzAtgRJzdHBldGVy QGphYmJlci5vcmeBF2oucGV0ZXJAc2FpbnQtYW5kcmUuY29tMA0GCSqGSIb3DQEBBAUAA4IC AQAV/ddHlibIhbnXGnEs1HUglGX5xCIZRW6g8jpCOKIgguVvjHFdvhylO67VqjAXMCYKsWfI 6Sfu6YyoDtSJpq8yWa/83nEq6aMOWtC6N2I9PINAojZelq97W6tHYrrJL6ql6QnS0ubtlWJE cKZoVglMZ+gmqGeuKGmoT25Lz7pslxN7/HXBiRqFaHh/gBqFSy0AGLQANvDsUx1VnYORRT3E +y1p1L82FgWKXHOLBZyaz2Eoi3CCroIA7JxhfQV+NNtVxhxmUyWj821cDHc1DLp3B9W4hW4P Ydfn8Hdzepwug2dYovjyFYEU2kekC38iD9/VuuLK9Z4C66FD1uqCAFfd1NRl1LzVIMVml991 Ejmeju3h5WvdfFMAteDQjmfGgqB9CFPIM3MPKM/Ir3GeaoQ8OV55U1zy2N5hkHEJdFeNIvg4 AE+up7EKkMTdTuXWlYfAG2Tb8ToBrWFqYCUdxorhWM1q2TXrmCMXmsoHFPW7OIjaNyHykBoU 3ZArm8I61UeGcvbtzf4AbDqXLvBjdup7oJofAWqY/2ZsWwmo8m7XqoYnBCZ/QOcPiZ+Owlhk Xzh+qpk4ZBsy5FEFwt9rQQoyQJpaIwF1CFKuPzH3kl/2EJY0GjOtLGCOGMc3fAsxqV6Yffve N18M4OYhLOkYay1QcgwJ81DSYvHs/2N5NjD4rDGCA4cwggODAgEBMIGAMHkxEDAOBgNVBAoT B1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0Eg Q2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQu b3JnAgMBlKswCQYFKw4DAhoFAKCCAdswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDYwNzA2MTc0ODA1WjAjBgkqhkiG9w0BCQQxFgQUU7kErP2n3Gud6DLI EjnukyJzudEwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAw DQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgZEGCSsGAQQBgjcQBDGB gzCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5v cmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEW EnN1cHBvcnRAY2FjZXJ0Lm9yZwIDAZSrMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYD VQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMT GUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2Fj ZXJ0Lm9yZwIDAZSrMA0GCSqGSIb3DQEBAQUABIIBAKrxm5b0EjRi0YgubLpfvyS0lN1+Bck5 boUg/XYvPSzem1aRf95fC0E+A1EDxmGlE+TfiymB3vPZO0AJtHnNwq0mFhqLyexpcpeBApyP 6NULuSnEbAIDnJ+p5g99EtmXEMRsMh3/j0Me4MaDeYsvWL70fuf0WbVw/c9/ybmtulsFeNaT f6Jx0gHl4moBLf9aS1JM0FlP7hx6RtnecGT6Cmjclo3vTF1454gP0rbSHevbf4eA0mFUwLeb 8JDUuXYUArE1Nq6v2nL1Z9fvuemUcAo5l3mPhOF6QPZLyjF55eGH8Ia0qzvseZXtrsyiaPAp f7X5nNPpwiseOmCO8yntydcAAAAAAAA= --------------ms040206020907050009000503-- --===============1865280319== 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://www1.ietf.org/mailman/listinfo/simple --===============1865280319==-- From simple-bounces@ietf.org Thu Jul 06 20:48:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyeVk-0001FX-R8; Thu, 06 Jul 2006 20:48:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyeVj-0001FN-JJ for simple@ietf.org; Thu, 06 Jul 2006 20:47:59 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyeVi-0001YP-4V for simple@ietf.org; Thu, 06 Jul 2006 20:47:59 -0400 Received: from [172.17.2.251] ([172.17.2.251]) (authenticated bits=0) by vicuna.estacado.net (8.13.6/8.13.4) with ESMTP id k670kg1g093654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Jul 2006 19:46:42 -0500 (CDT) (envelope-from adam@estacado.net) Message-ID: <44ADAEE2.8000601@estacado.net> Date: Thu, 06 Jul 2006 19:46:26 -0500 From: Adam Roach User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Peter Saint-Andre Subject: Re: [Simple] "last call" on SIMPLE-XMPP interworking I-D References: <448610BB.5000707@jabber.org> <44AC6AC9.4040907@nostrum.com> <44AD4CD5.2000001@jabber.org> In-Reply-To: <44AD4CD5.2000001@jabber.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: xmppwg@jabber.org, Adam Roach , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Peter Saint-Andre wrote: > I think that the gateway is responsible for maintaining the live > subscription only if the request has been approved by the SIP user, not > if the XMPP user has only sent a subscribe without receiving approval. I suspect you don't quite understand the way subscribers learn about presence authorization in SIP. Generally, if I subscribe to you and I'm not yet explicitly authorized (but also not explicitly barred), the subscription needs to hang around in a "pending" state until the authorization question is answered (or the subscriber gives up). If the subscription isn't maintained, there's no way for the gateway to ever know that permission has been granted. >> To be clear about the danger here, I'll outline a potential attack. >> I learn that example.net is running an XMPP/SIP gateway to serve >> their SIP users. I learn the identity of _one_ SIP user in their >> domain. Then, I open up a TCP connection to their gateway, and >> introduce myself as a jabber server. I pretend that I have four >> thousand users who are interested in the presence state of the one >> SIP user I know about in their domain. To do so, I send out four >> thousand requests, each from a unique user; I pace these >> out with about a one second gap between each. Now I'm done. I spent >> a little over an hour sending XMPP subscription requests; in >> response, I have increased the load on the victim SIP server by a >> little more than one TPS from now until the heat death of the >> universe. If I do it again, I double that additional load. And, of >> course, if I blasted the requests out as fast as possible for a day >> or two, the devastation would be complete. >> > > I agree that this attack is bad. But it's not clear to me how this > attack is different from a similar attack waged by one SIP presence > server against another SIP presence server. For example, I learn that > example.net is running a SIP presence server and I learn the identity of > one SIP user in that domain (hapless_user@example.net). I set up a rogue > SIP presence server at evil.example.com and I pretend that I have four > thousand users who are interested in the availability of the hapless > user. I send a SIP SUBSCRIBE refresh once a minute for each of my four > thousand fake users. Thereby, I have seriously increased the load on the > victim SIP presence server at example.net. Unless I'm missing something, > this seems to be a problem with rogue servers, not with the protocol > mapping (except for the caveats above about unapproved subscriptions and > offline users). > The difference is that the rogue SIP server -- the attacker -- needs to continue to generate traffic in the scenario you describe. For every SUBSCRIBE that the attacker wants to hit example.net, the attacker must send one message. For example, if I'm attacking a SIP server using SIP, the best I can generally do (modulo some known attacks that we're working to fix) is send 3600 messages and cause the victim server to process 3600 messages. This represents no amplification. In the attack I describe above, an attacker can send 3600 messages, and cause the victim server (and their gateway) to process 3600 messages *every* *hour* until the sun expands to engulf the earth's orbit. This represents nearly infinite amplification. The difference isn't that subtle. In one case, each message sent by the attacker causes the victim network to handle one message. In the other, each message sent by the attacker causes the victim network to handle approximately 4.4 x 10^13 messages. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 06 23:33:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyh52-0005xI-Ft; Thu, 06 Jul 2006 23:32:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyh51-0005xA-Bp for simple@ietf.org; Thu, 06 Jul 2006 23:32:35 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyerI-00049a-JN for simple@ietf.org; Thu, 06 Jul 2006 21:10:16 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FyeWh-0007gU-93 for simple@ietf.org; Thu, 06 Jul 2006 20:49:00 -0400 Received: from [172.17.2.251] (dsl001-129-070.dfw1.dsl.speakeasy.net [72.1.129.70]) (authenticated bits=0) by nostrum.com (8.13.6/8.13.6) with ESMTP id k670lWG7029623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Jul 2006 19:47:32 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <44ADAF14.9040602@nostrum.com> Date: Thu, 06 Jul 2006 19:47:16 -0500 From: Adam Roach User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 CC: simple@ietf.org Subject: Re: [Simple] "last call" on SIMPLE-XMPP interworking I-D References: <448610BB.5000707@jabber.org> <44AC6AC9.4040907@nostrum.com> <44AD4CD5.2000001@jabber.org> In-Reply-To: <44AD4CD5.2000001@jabber.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 72.1.129.70 is authenticated by a trusted mechanism) X-Spam-Score: -2.2 (--) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Peter Saint-Andre wrote: > I think that the gateway is responsible for maintaining the live > subscription only if the request has been approved by the SIP user, not > if the XMPP user has only sent a subscribe without receiving approval. I suspect you don't quite understand the way subscribers learn about presence authorization in SIP. Generally, if I subscribe to you and I'm not yet explicitly authorized (but also not explicitly barred), the subscription needs to hang around in a "pending" state until the authorization question is answered (or the subscriber gives up). If the subscription isn't maintained, there's no way for the gateway to ever know that permission has been granted. >> To be clear about the danger here, I'll outline a potential attack. >> I learn that example.net is running an XMPP/SIP gateway to serve >> their SIP users. I learn the identity of _one_ SIP user in their >> domain. Then, I open up a TCP connection to their gateway, and >> introduce myself as a jabber server. I pretend that I have four >> thousand users who are interested in the presence state of the one >> SIP user I know about in their domain. To do so, I send out four >> thousand requests, each from a unique user; I pace these >> out with about a one second gap between each. Now I'm done. I spent >> a little over an hour sending XMPP subscription requests; in >> response, I have increased the load on the victim SIP server by a >> little more than one TPS from now until the heat death of the >> universe. If I do it again, I double that additional load. And, of >> course, if I blasted the requests out as fast as possible for a day >> or two, the devastation would be complete. >> > > I agree that this attack is bad. But it's not clear to me how this > attack is different from a similar attack waged by one SIP presence > server against another SIP presence server. For example, I learn that > example.net is running a SIP presence server and I learn the identity of > one SIP user in that domain (hapless_user@example.net). I set up a rogue > SIP presence server at evil.example.com and I pretend that I have four > thousand users who are interested in the availability of the hapless > user. I send a SIP SUBSCRIBE refresh once a minute for each of my four > thousand fake users. Thereby, I have seriously increased the load on the > victim SIP presence server at example.net. Unless I'm missing something, > this seems to be a problem with rogue servers, not with the protocol > mapping (except for the caveats above about unapproved subscriptions and > offline users). > The difference is that the rogue SIP server -- the attacker -- needs to continue to generate traffic in the scenario you describe. For every SUBSCRIBE that the attacker wants to hit example.net, the attacker must send one message. For example, if I'm attacking a SIP server using SIP, the best I can generally do (modulo some known attacks that we're working to fix) is send 3600 messages and cause the victim server to process 3600 messages. This represents no amplification. In the attack I describe above, an attacker can send 3600 messages, and cause the victim server (and their gateway) to process 3600 messages *every* *hour* until the sun expands to engulf the earth's orbit. This represents nearly infinite amplification. The difference isn't that subtle. In one case, each message sent by the attacker causes the victim network to handle one message. In the other, each message sent by the attacker causes the victim network to handle approximately 4.4 x 10^13 messages. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 07 04:01:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FylGk-0003BJ-Nt; Fri, 07 Jul 2006 04:00:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxYH5-0000aJ-0f; Mon, 03 Jul 2006 19:56:19 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxYH3-000565-K2; Mon, 03 Jul 2006 19:56:18 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k63NuHM9028459; Mon, 3 Jul 2006 16:56:17 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k63NuH4l028458; Mon, 3 Jul 2006 16:56:17 -0700 Date: Mon, 3 Jul 2006 16:56:17 -0700 Message-Id: <200607032356.k63NuH4l028458@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 X-Mailman-Approved-At: Fri, 07 Jul 2006 04:00:56 -0400 Cc: simple@ietf.org, rfc-editor@rfc-editor.org Subject: [Simple] RFC 4480 on RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4480 Title: RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF) Author: H. Schulzrinne, V. Gurbani, P. Kyzivat, J. Rosenberg Status: Standards Track Date: July 2006 Mailbox: hgs+simple@cs.columbia.edu, vkg@lucent.com, pkyzivat@cisco.com, jdrosen@cisco.com Pages: 37 Characters: 74026 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-simple-rpid-10.txt URL: http://www.rfc-editor.org/rfc/rfc4480.txt The Presence Information Data Format (PIDF) defines a basic format for representing presence information for a presentity. This format defines a textual note, an indication of availability (open or closed) and a Uniform Resource Identifier (URI) for communication. The Rich Presence Information Data format (RPID) described here is an extension that adds optional elements to the Presence Information Data Format (PIDF). These extensions provide additional information about the presentity and its contacts. The information is designed so that much of it can be derived automatically, e.g., from calendar files or user activity. This extension includes information about what the person is doing, a grouping identifier for a tuple, when a service or device was last used, the type of place a person is in, what media communications might remain private, the relationship of a service tuple to another presentity, the person's mood, the time zone it is located in, the type of service it offers, an icon reflecting the presentity's status, and the overall role of the presentity. These extensions include presence information for persons, services (tuples), and devices. [STANDARDS TRACK] This document is a product of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for From simple-bounces@ietf.org Fri Jul 07 04:01:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FylGk-0003BJ-Nt; Fri, 07 Jul 2006 04:00:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxYH5-0000aJ-0f; Mon, 03 Jul 2006 19:56:19 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxYH3-000565-K2; Mon, 03 Jul 2006 19:56:18 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k63NuHM9028459; Mon, 3 Jul 2006 16:56:17 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k63NuH4l028458; Mon, 3 Jul 2006 16:56:17 -0700 Date: Mon, 3 Jul 2006 16:56:17 -0700 Message-Id: <200607032356.k63NuH4l028458@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 X-Mailman-Approved-At: Fri, 07 Jul 2006 04:00:56 -0400 Cc: simple@ietf.org, rfc-editor@rfc-editor.org Subject: [Simple] RFC 4480 on RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4480 Title: RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF) Author: H. Schulzrinne, V. Gurbani, P. Kyzivat, J. Rosenberg Status: Standards Track Date: July 2006 Mailbox: hgs+simple@cs.columbia.edu, vkg@lucent.com, pkyzivat@cisco.com, jdrosen@cisco.com Pages: 37 Characters: 74026 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-simple-rpid-10.txt URL: http://www.rfc-editor.org/rfc/rfc4480.txt The Presence Information Data Format (PIDF) defines a basic format for representing presence information for a presentity. This format defines a textual note, an indication of availability (open or closed) and a Uniform Resource Identifier (URI) for communication. The Rich Presence Information Data format (RPID) described here is an extension that adds optional elements to the Presence Information Data Format (PIDF). These extensions provide additional information about the presentity and its contacts. The information is designed so that much of it can be derived automatically, e.g., from calendar files or user activity. This extension includes information about what the person is doing, a grouping identifier for a tuple, when a service or device was last used, the type of place a person is in, what media communications might remain private, the relationship of a service tuple to another presentity, the person's mood, the time zone it is located in, the type of service it offers, an icon reflecting the presentity's status, and the overall role of the presentity. These extensions include presence information for persons, services (tuples), and devices. [STANDARDS TRACK] This document is a product of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 07 04:01:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FylGl-0003Ca-Bn; Fri, 07 Jul 2006 04:00:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxZsT-0001My-NU; Mon, 03 Jul 2006 21:39:01 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxYWb-00063J-CO; Mon, 03 Jul 2006 20:12:21 -0400 Received: from nit.isi.edu ([128.9.160.116]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FxYGW-00032x-QN; Mon, 03 Jul 2006 19:55:46 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k63NtfPB028454; Mon, 3 Jul 2006 16:55:41 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k63Ntfi5028453; Mon, 3 Jul 2006 16:55:41 -0700 Date: Mon, 3 Jul 2006 16:55:41 -0700 Message-Id: <200607032355.k63Ntfi5028453@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -17.6 (-----------------) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 X-Mailman-Approved-At: Fri, 07 Jul 2006 04:00:56 -0400 Cc: simple@ietf.org, rfc-editor@rfc-editor.org Subject: [Simple] RFC 4481 on Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4481 Title: Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals Author: H. Schulzrinne Status: Standards Track Date: July 2006 Mailbox: hgs+simple@cs.columbia.edu Pages: 9 Characters: 15549 Updates/Obsoletes/SeeAlso: None I-D Tag: draftimprovements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 07 04:01:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FylGl-0003Ca-Bn; Fri, 07 Jul 2006 04:00:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxZsT-0001My-NU; Mon, 03 Jul 2006 21:39:01 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxYWb-00063J-CO; Mon, 03 Jul 2006 20:12:21 -0400 Received: from nit.isi.edu ([128.9.160.116]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FxYGW-00032x-QN; Mon, 03 Jul 2006 19:55:46 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k63NtfPB028454; Mon, 3 Jul 2006 16:55:41 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k63Ntfi5028453; Mon, 3 Jul 2006 16:55:41 -0700 Date: Mon, 3 Jul 2006 16:55:41 -0700 Message-Id: <200607032355.k63Ntfi5028453@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -17.6 (-----------------) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 X-Mailman-Approved-At: Fri, 07 Jul 2006 04:00:56 -0400 Cc: simple@ietf.org, rfc-editor@rfc-editor.org Subject: [Simple] RFC 4481 on Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4481 Title: Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals Author: H. Schulzrinne Status: Standards Track Date: July 2006 Mailbox: hgs+simple@cs.columbia.edu Pages: 9 Characters: 15549 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-simple-future-05.txt URL: http://www.rfc-editor.org/rfc/rfc4481.txt The Presence Information Data Format (PIDF) defines a basic XML format for presenting presence information for a presentity. This document extends PIDF, adding a timed status extension ( element) that allows a presentity to declare its status for a time interval fully in the future or the past. [STANDARDS TRACK] This document is a product of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple -ietf-simple-future-05.txt URL: http://www.rfc-editor.org/rfc/rfc4481.txt The Presence Information Data Format (PIDF) defines a basic XML format for presenting presence information for a presentity. This document extends PIDF, adding a timed status extension ( element) that allows a presentity to declare its status for a time interval fully in the future or the past. [STANDARDS TRACK] This document is a product of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 07 04:01:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FylGk-0003Ag-5g; Fri, 07 Jul 2006 04:00:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxYFp-00087r-MK; Mon, 03 Jul 2006 19:55:01 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxYFo-0004uK-0I; Mon, 03 Jul 2006 19:55:01 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k63NsxkH028445; Mon, 3 Jul 2006 16:54:59 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k63Nsxv8028444; Mon, 3 Jul 2006 16:54:59 -0700 Date: Mon, 3 Jul 2006 16:54:59 -0700 Message-Id: <200607032354.k63Nsxv8028444@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 X-Mailman-Approved-At: Fri, 07 Jul 2006 04:00:56 -0400 Cc: simple@ietf.org, rfc-editor@rfc-editor.org Subject: [Simple] RFC 4482 on CIPID: Contact Information for the Presence Information Data Format X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4482 Title: CIPID: Contact Information for the Presence Information Data Format Author: H. Schulzrinne Status: Standards Track Date: July 2006 Mailbox: hgs+simple@cs.columbia.edu Pages: 11 Characters: 22157 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-simple-cipid-07.txt URL: http://www.rfc-editor.org/rfc/rfc4482.txt The Presence Information Data Format (PIDF) defines a basic XML format for presenting presence information for a presentity. The Contact Information for the Presence Information Data format (CIPID) is an extension that adds elements to PIDF that provide additional contact information about a presentity and its contacts, including references to address book entries and icons. [STANDARDS TRACK] This document is a product of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 07 04:01:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FylGj-0003Aa-QJ; Fri, 07 Jul 2006 04:00:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxYF9-0007ab-V6; Mon, 03 Jul 2006 19:54:19 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxYF8-0004pu-IZ; Mon, 03 Jul 2006 19:54:19 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k63NsIdb028440; Mon, 3 Jul 2006 16:54:18 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k63NsIuf028439; Mon, 3 Jul 2006 16:54:18 -0700 Date: Mon, 3 Jul 2006 16:54:18 -0700 Message-Id: <200607032354.k63NsIuf028439@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 X-Mailman-Approved-At: Fri, 07 Jul 2006 04:00:56 -0400 Cc: simple@ietf.org, rfc-editor@rfc-editor.org Subject: [Simple] RFC 4479 on A Data Model for Presence X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4479 Title: A Data Model for Presence Author: J. Rosenberg Status: Standards Track Date: July 2006 Mailbox: jdrosen@cisco.com Pages: 35 Characters: 88399 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-simple-presence-data-model-07.txt URL: http://www.rfc-editor.org/rfc/rfc4479.txt This document defines the underlying presence data model used by Session Initiation Protocol (SIP) for Instant Messaging and Presence Leveraging Extensions (SIMPLE) presence agents. The data model provides guidance on how to map various communications systems into presence documents in a consistent fashion. [STANDARDS TRACK] This document is a product of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 07 06:54:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FynyN-0006jk-Dq; Fri, 07 Jul 2006 06:54:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FynyM-0006jf-6r for simple@ietf.org; Fri, 07 Jul 2006 06:54:10 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fymkk-0007YD-Ab for simple@ietf.org; Fri, 07 Jul 2006 05:36:02 -0400 Received: from mtagate6.de.ibm.com ([195.212.29.155]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fymc7-0007sN-JL for simple@ietf.org; Fri, 07 Jul 2006 05:27:09 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.13.6/8.13.6) with ESMTP id k679R6es121214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 7 Jul 2006 09:27:06 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k679Tqkf085356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Jul 2006 11:29:52 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k679R50o029630 for ; Fri, 7 Jul 2006 11:27:05 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k679R55P029625; Fri, 7 Jul 2006 11:27:05 +0200 To: Peter Saint-Andre , simple@ietf.org, adam@nostrum.com Subject: Fw: [Simple] "last call" on SIMPLE-XMPP interworking I-D MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 From: Avshalom Houri Message-ID: Date: Fri, 7 Jul 2006 12:29:49 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.1HF123 | April 14, 2006) at 07/07/2006 12:29:51, Serialize complete at 07/07/2006 12:29:51 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: -2.4 (--) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Adam, The attach that your are describing is inherent to the way that subscriptions are handled in XMPP and in SIP. In XMPP the subscriptions are long lived while in SIP there are (in a lot of cases redundant) resubscriptions. The same attack that your are describing can happen also between two XMPP servers where the attacker deploys an XMPP server and subscribes to users on another XMPP server. Even in SIP, the need of having resubsscribes in SIP does not make a real difference to the attacker since as long as there is a living TCP connection there is no problem in sending those refreshes. The TCP connection itself will have to send keep alives every two hours is there is no other traffic. I do not believe that there are mechanisms other then identity and secure provisioning that will prevent these kinds of attacks. --Avshalom Everything will become a commodity except for human attention (Udi Shapiro) ----- Forwarded by Avshalom Houri/Haifa/IBM on 07/07/2006 12:12 ----- Adam Roach 07/07/2006 03:47 To cc simple@ietf.org Subject Re: [Simple] "last call" on SIMPLE-XMPP interworking I-D Peter Saint-Andre wrote: > I think that the gateway is responsible for maintaining the live > subscription only if the request has been approved by the SIP user, not > if the XMPP user has only sent a subscribe without receiving approval. I suspect you don't quite understand the way subscribers learn about presence authorization in SIP. Generally, if I subscribe to you and I'm not yet explicitly authorized (but also not explicitly barred), the subscription needs to hang around in a "pending" state until the authorization question is answered (or the subscriber gives up). If the subscription isn't maintained, there's no way for the gateway to ever know that permission has been granted. >> To be clear about the danger here, I'll outline a potential attack. >> I learn that example.net is running an XMPP/SIP gateway to serve >> their SIP users. I learn the identity of _one_ SIP user in their >> domain. Then, I open up a TCP connection to their gateway, and >> introduce myself as a jabber server. I pretend that I have four >> thousand users who are interested in the presence state of the one >> SIP user I know about in their domain. To do so, I send out four >> thousand requests, each from a unique user; I pace these >> out with about a one second gap between each. Now I'm done. I spent >> a little over an hour sending XMPP subscription requests; in >> response, I have increased the load on the victim SIP server by a >> little more than one TPS from now until the heat death of the >> universe. If I do it again, I double that additional load. And, of >> course, if I blasted the requests out as fast as possible for a day >> or two, the devastation would be complete. >> > > I agree that this attack is bad. But it's not clear to me how this > attack is different from a similar attack waged by one SIP presence > server against another SIP presence server. For example, I learn that > example.net is running a SIP presence server and I learn the identity of > one SIP user in that domain (hapless_user@example.net). I set up a rogue > SIP presence server at evil.example.com and I pretend that I have four > thousand users who are interested in the availability of the hapless > user. I send a SIP SUBSCRIBE refresh once a minute for each of my four > thousand fake users. Thereby, I have seriously increased the load on the > victim SIP presence server at example.net. Unless I'm missing something, > this seems to be a problem with rogue servers, not with the protocol > mapping (except for the caveats above about unapproved subscriptions and > offline users). > The difference is that the rogue SIP server -- the attacker -- needs to continue to generate traffic in the scenario you describe. For every SUBSCRIBE that the attacker wants to hit example.net, the attacker must send one message. For example, if I'm attacking a SIP server using SIP, the best I can generally do (modulo some known attacks that we're working to fix) is send 3600 messages and cause the victim server to process 3600 messages. This represents no amplification. In the attack I describe above, an attacker can send 3600 messages, and cause the victim server (and their gateway) to process 3600 messages *every* *hour* until the sun expands to engulf the earth's orbit. This represents nearly infinite amplification. The difference isn't that subtle. In one case, each message sent by the attacker causes the victim network to handle one message. In the other, each message sent by the attacker causes the victim network to handle approximately 4.4 x 10^13 messages. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 07 08:05:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyp4x-0002c2-BG; Fri, 07 Jul 2006 08:05:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyp4w-0002bx-L6 for simple@ietf.org; Fri, 07 Jul 2006 08:05:02 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fyp4u-0006iS-15 for simple@ietf.org; Fri, 07 Jul 2006 08:05:02 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k67C2prC030878; Fri, 7 Jul 2006 15:04:43 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Jul 2006 15:03:38 +0300 Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Jul 2006 15:03:38 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] I-D ACTION:draft-ietf-simple-imdn-00.txt Date: Fri, 7 Jul 2006 15:03:37 +0300 Message-ID: <58357EDC7884E24BAD684C1B2D91F96D0380009D@trebe101.NOE.Nokia.com> In-Reply-To: <7ae2a04a1f6086cb7f1a1439490e9483@telio.no> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] I-D ACTION:draft-ietf-simple-imdn-00.txt Thread-Index: AcaPs5hDxPBsep50QhmdFmoTDTsWIASA/yrA From: To: , X-OriginalArrivalTime: 07 Jul 2006 12:03:38.0167 (UTC) FILETIME=[61670470:01C6A1BD] X-Spam-Score: 0.2 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi, I read the draft, and have a couple of comments as follows:=20 - it is said in section 5/ 2nd paragraph that "In this case, the intermediary MUST add a CPIM Original-To header to the CPIM message populating it with the address of the sender.". Shouldn't the header field rather be populated with the address of the original recipient (which is basically the address of the intermediary as well as the address of the entity forwarding the message)? If there are several intermediaries, is the Original-To header set by the first one? - 9.1.4. : it is said that this carries the URI of the final recipient. Shouldn't this be the URI of the recipient in the originated IM? - 10.2. (Intermediary behaviour): it is said for the read notification that the intermediary forwards it. Shouldn't similar text be written for "positive-delivery" notifications (generated by an endpoint)? - 10.2. If the intermediary generates the IMDN then also other quidelines should be given than only how the is populated, e.g. reference to the subsection 4.2.1. BR, Eva=20 >-----Original Message----- >From: ext Hisham Khartabil [mailto:hisham.khartabil@telio.no]=20 >Sent: 14 June, 2006 16:06 >To: 'simple@ietf.org' WG >Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-imdn-00.txt=20 > >This version of the Instant Messaging Disposition Notification draft=20 >represents consensus from the design team (with very few open issues).=20 >The authors would appreciate some review and comments before the next=20 >IETF meeting in Montreal in order to allow us to properly discuss any=20 >open issues that are raised. > >Thanks, >Hisham > >On May 31, 2006, at 12:50 AM, Internet-Drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts=20 >> directories. >> This draft is a work item of the SIP for Instant Messaging and=20 >> Presence Leveraging Extensions Working Group of the IETF. >> >> Title : Instant Message Disposition Notification >> Author(s) : E. Burger, H. Khartabil >> Filename : draft-ietf-simple-imdn-00.txt >> Pages : 27 >> Date : 2006-5-30 >> =09 >> Instant Messaging (IM) refers to the transfer of messages between >> users in real-time. >> >> This document extends Message/CPIM message format to enable endpoints >> to request, create and send IM Disposition Notifications (IMDN), >> including delivery and read notifications, for page-mode as well as >> session mode instant messages. This document also describes how SIP >> and MSRP entities behave using this extension. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-simple-imdn-00.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in=20 >the body of=20 >> the message. >> You can also visit=20 >https://www1.ietf.org/mailman/listinfo/I-D-announce >> to change your subscription settings. >> >> >> Internet-Drafts are also available by anonymous FTP. Login with the=20 >> username >> "anonymous" and a password of your e-mail address. After logging in, >> type "cd internet-drafts" and then >> "get draft-ietf-simple-imdn-00.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-ietf-simple-imdn-00.txt". >> =09 >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant=20 >mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> =09 >> =09 >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> Content-Type: text/plain >> Content-ID: <2006-5-30162236.I-D@ietf.org> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 07 09:41:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyqae-00008g-1M; Fri, 07 Jul 2006 09:41:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyqac-000085-K3 for simple@ietf.org; Fri, 07 Jul 2006 09:41:50 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fyqac-0001wd-HG for simple@ietf.org; Fri, 07 Jul 2006 09:41:50 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FyqX3-0003oA-Bo for simple@ietf.org; Fri, 07 Jul 2006 09:38:10 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k67DZirc029050; Fri, 7 Jul 2006 16:37:10 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Jul 2006 16:29:04 +0300 Received: from [172.21.34.132] ([172.21.34.132]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 7 Jul 2006 16:29:04 +0300 Message-ID: <44AE619F.1000900@nokia.com> Date: Fri, 07 Jul 2006 16:29:03 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Hisham Khartabil , Eric Burger Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2006 13:29:04.0727 (UTC) FILETIME=[5111FE70:01C6A1C9] X-Spam-Score: -2.4 (--) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Cc: "'simple@ietf.org'" Subject: [Simple] Comments to draft-ietf-simple-imdn-00.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi: Here are some comments to the IMDN draft. 1) I think the draft is desperately looking for a terminology section within Section 2. I think we ought to define the following terms (this my understanding): IM or Instant Message: a SIP or MSRP message that contains a message/cpim body IMDN: a SIP or MSRP message that contains an IMDN document IMDN document: an XML document that complies with the Schema of Section 9.3 message/cpim body: a document that complies with RFC 3862. It can also contain the extensions defined in this document. So, notice that we have definitions of SIP/MSRP carrying either a regular IM or an IMDN. We have a name for the XML part of the IMDN, and a name for the document part of a regular IM. Don't know if this fits with your intention, I hope so. Then please stick to the terminology: avoid terms like 'Message/CPIM IM'. 2) In Section 3, Overview, I am missing an overview description of the Aggregation feature. 3) Make sure that it is always spelled out if you are referring to the Content-Type header in SIP or MSRP, or the Content-Type header that goes into the message/cpim body 4) The text in Section 4.1 reads: In this extension, the Message/CPIM IM MAY contain a Message-ID header field if an IMDN is requested. The Message-ID field is populated with a value that is unique in space and time. This header field enables the message sender to match any notifications with their corresponding IMs. This header need not be present if the instant message sender is not requesting any IMDNs or if no state of any kind is kept for an IM. First, I don't know what "In this extension" means... I guess it should be "Implementations according with this specification..." Then I think we should encourage implementations to include a Message-ID header whenever they are requesting IMDN, even when they do not keep state... It may help when debugging, for example. 5) Section 4.1, third paragraph: there seems to be a repetition for the justification of the timestamp: It is therefore necessary to add a time stamp in the IM to indicate when it was sent in order to enable the human user to correlate the IM with the IMDN. This time stamp is returned in the IMDN in order to enable the user to correlate the IM with the IMDN at the human level. 6) I would suggest renaming Section 4.1 as "Requesting Disposition Notifications". 7) Section 4.2. I am missing to put a context to IMDNs. Specifically, the text should answer to the question: "is the IMDN XML stuff inserted as SIP/MSRP payload or as message/cpim payload?. So I would start this section with some text along these lines (according to the suggested terminology in my first bullet point). "An IMDN is a SIP or MSRP message that contains a message/cpim body whose payload is an IMDN document compliant with the XML schema of Section 9.3." 8) The last paragraph in Section 4.2 starts speaking about the "Really-From" header like if the reader were familiar with it, but this is the first occurrence of this header. So I would suggest to add a couple of sentence that describes what this header is all about right before this paragraph. 9) The titles in Sections 4.2 and 4.3 are very similar... With the terminology suggestion I made in my first bullet point, Section 4.3 will become "Constructing an IMDN document". 10) Sections 4.2.1 and 4.2.2 should describe how to populate all the elements of the IMDN XML document, but they are not described. Instead, The Content-Disposition header is described, but that one falls into Section 4.2, not 4.2.1. 11) Section 4.2.2 reads: There are situations where the recipient user agent cannot determine if or when the message has been read. The recipient user agent in this case generates a read notification with a value of "error" to indicate an internal error by the server. If the status is unknown, why don't you choose "unknown" as the value, rather than "error"? 12) Is '"aggregate" a parameter of the whole header field or a parameter of a value. I think of the latter, the text first says the former, and then indicates that the latter can be done.... Take a look at the following sentences included in the first paragraph in Section 4.3: The endpoint does so by adding the Disposition-Notification header field parameter "aggregate". So the above clearly says that 'aggregate' is a parameter of the whole header, not of the individual values. But the text then reads: For example, a IM sender can request delivery notification to be aggregated but read reports to be sent individually. For example: Disposition-Notification: positive-delivery;aggregate, read So I believe the example is correct, and the first sentence should read: The endpoint does so by adding a parameter "aggregate" close to the value of the Disposition-Notification header that requires aggregation. The "aggregate" parameter affects each value independently. 13) In Section 4.4 I found the term "Requesting endpoint". Perhaps it is good to include it in the definitions, I guess it is not the "sender". 14) Section 5, second paragraph, I guess the 'may' is really a 'MAY': An intermediary that forwards an IM may change the recipient address... 15) I found a bit weird a paragraph in Section 5 that speaks about procedures that an intermediary can do when it does not support this specification. So, if the intermediary does not support the specification, it will not insert any "Really-From" header either. This is the text I am referring to: An intermediary MAY choose to remain on the path of IMDNs for a specific IM. It can do so by adding a CPIM Really-From header field as the top Really-From header and populating it with its own address. This works well with intermediaries that don't support this extension in that IMDNs would therefore traverse directly from receiver to sender or to intermediaries that do support the extension. 16) I hate the names of these headers "Really-From", "Really-To". I would suggest something more meaningful, for examlpe "Reply-Via" and "Via", respectively. 17) I don't understand this text in Section 9.1.4, looks like a contradiction that the contains the URI of the final recipient rather than that of the original recipient. The element is optional and carries the URI of the final recipient. 18) Section 9.2, first paragraph reads: The SIP [9] MESSAGE request [10] or the MSRP SEND request [11] that is used to carry the IMDN that also carries payload type information MUST identify the payload as MIME type "message/imdn+xml" in the Content- Type header field. Ouch, didn't we say that the IMDN document goes into message/cpim body? At least the examples in 4.2.1 and 4.2.2 indicate it that way. Also the above text contradicts most of the text around Section 10.1 NITS: - Missing full stop at the end of the paragraph in Section 3.1. - s/Recipient/recipient - s/content-type/Content-Type (or is true that the message/cpim header is typically spelled as Content-type? RFC 3862 spells it like that...) - Extra space in before the DateTime header at the end of Section 4.1 - The examples in 4.2.1 and 4.2.2 show a couple of identities in the and elements, but they do not look like URIs, since they don't contain a URI scheme. I guess they should be prepended with "im:" - The first paragraph in Section 4.3 contains twice "it does so". Can we please spell out what is "so", because it may be misleading when you have previously said that there are two options to do something. - Extra ";" at the end of elements in the titles of Sections 9.1.3, 9.1.4, and 9.1.5. /Miguel -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 07 12:10:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FysuU-00006h-Qd; Fri, 07 Jul 2006 12:10:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FysuU-00006c-6v for simple@ietf.org; Fri, 07 Jul 2006 12:10:30 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FysuT-0002Zs-Ql for simple@ietf.org; Fri, 07 Jul 2006 12:10:30 -0400 Received: from [192.168.0.102] (ppp-70-249-144-63.dsl.rcsntx.swbell.net [70.249.144.63]) (authenticated bits=0) by nostrum.com (8.13.6/8.13.6) with ESMTP id k67G9BmI095185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Jul 2006 11:09:12 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <44AE872E.3080902@nostrum.com> Date: Fri, 07 Jul 2006 11:09:18 -0500 From: Adam Roach User-Agent: Thunderbird 1.5.0.4 (X11/20060614) MIME-Version: 1.0 To: Avshalom Houri Subject: Re: Fw: [Simple] "last call" on SIMPLE-XMPP interworking I-D References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.144.63 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Avshalom Houri wrote: > Adam, > > The attach that your are describing is inherent to the way > that subscriptions are handled in XMPP and in SIP. > In XMPP the subscriptions are long lived while in SIP there are > (in a lot of cases redundant) resubscriptions. > I understand the difficulty, which is why the solution to the problem is non-obvious to me. However, I think it would be dangerous and irresponsible of the IETF to publish as an RFC a document that describes behavior that is effectively a pre-canned zombie attack. I was hoping that someone with a better knowledge of XMPP than I would be able to hop in and say something like, "Oh, yeah, you're right. We can solve this by making the subscribing system do a commensurate amount of work. The gateway does this by sending a stanza to the subscriber every time it is about to send a SIP SUBSCRIBE refresh on that subscriber's behalf. RFC WXYZ requires the {client,server} to respond to the stanza with a response. As long as the gateway requires a / exchange with the subscribing XMPP {client,server} for each SIP SUBSCRIBE refresh, then we're requiring any potential attacker to do the work on the same order of magnitude as the gateway, which thwarts the amplification attack you describe." There might be a solution along these lines, and there may not be. There may be other approaches that would work. Engineering these solutions will require more XMPP knowledge than I possess. > Even in SIP, the need of having resubsscribes in SIP does not make a real > difference to the attacker since as long as there is a living TCP > connection there is no problem in sending those refreshes. > The TCP connection itself will have to send keep alives every two hours > is there is no other traffic. > Let me bound the time-frame that I am talking about a little bit more. Let's consider a single day. Assume the presence subscriptions are refreshed every hour. Further, assume the attacker is sending messages out at a leisurely 2.7 messages per second -- or 10,000 an hour. +----------+ +----------+ +--------------+ | XMPP |______| Victim | | Victim | | Attacker | A | XMPP/SIP |-----| SIP Presence | +----------+ | Gateway | B | Server | +----------+ +--------------+ In the first hour of the attack, the XMPP attacker sends 10,000 presence requests across link A. The source of these requests are imaginary users 1 through 10,000. As a reaction, the gateway sends 10,000 presence requests across link B. So far, so good. The first hour looks just like it would if the gateway were a SIP proxy. At the beginning of the second hour, the gateway sends a refresh to the presence server on behalf of imaginary user #1, since his hour is up. At the same time, the attacker has sent a subscription request from imaginary user #10,001, so the XMPP/SIP gateway sends a subscribe for that user as well. About a third of a second later, a the gateway will send a similar set of subscribes for imaginary users #2 (refresh) and #10,002 (new subscription). At the end of the second hour, the attacker has sent a total of 20,000 messages (10,000 the first hour, 10,000 the second hour). The gateway has sent a total of 30,000 (10,000 the first hour, and 20,000 the second hour). In the third hour, the attacker sends 10,000 messages for imaginary users 20,000 through 29,999. The gateway sends 10,000 corresponding messages, plus 20,000 refreshes for imaginary users #1 through #19,999. By the 24th hour, the attacker has sent a total of 240,000 messages. In reaction, he has caused a total of 3,000,000 SUBSCRIBE messages to flow between the victim gateway and the victim server. That's better than a 12:1 amplification. Not bad at all. Keep in mind: if the attacker decided to stop at this point, the victim system would continue to process 5.7 million messages a day because of the attack. Now, let's consider slightly longer time frames. If the attacker decided to go on with the attack, then at the end of the second day, the attacker would have sent 480,000 messages in total, while causing the victim system to process 11.7 million messages total (24:1 amplification). By day 3, the numbers are 720,000 and 26.2 million, respectively (36:1 amplification). By the end of a week, the attacker will have sent 1.4 million messages, while managing to induce the victim system to process 104.4 million (74:1 amplification). And again, even if the attack stops at this point, the victim system would continue to process 34.5 million messages a day without any further effort from the attacker ever again. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Jul 09 23:30:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzmT6-0005sQ-J3; Sun, 09 Jul 2006 23:29:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzmT4-0005sL-OX for simple@ietf.org; Sun, 09 Jul 2006 23:29:54 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzmT3-0000lj-CH for simple@ietf.org; Sun, 09 Jul 2006 23:29:54 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 09 Jul 2006 20:29:53 -0700 X-IronPort-AV: i="4.06,221,1149490800"; d="scan'208"; a="1836723195:sNHT31590408" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k6A3TqCV016819 for ; Sun, 9 Jul 2006 20:29:52 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k6A3Tq46023868 for ; Sun, 9 Jul 2006 20:29:52 -0700 (PDT) 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.211); Sun, 9 Jul 2006 23:29:52 -0400 Received: from [142.131.134.111] ([10.86.242.24]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 9 Jul 2006 23:29:51 -0400 Message-ID: <44B18A4D.7050709@cisco.com> Date: Sun, 09 Jul 2006 18:59:25 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jul 2006 03:29:51.0793 (UTC) FILETIME=[1AB0E210:01C6A3D1] DKIM-Signature: a=rsa-sha1; q=dns; l=3212; t=1152502192; x=1153366192; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:comments=20on=20draft-schulzrinne-simple-composition=20policy; X=v=3Dcisco.com=3B=20h=3Dr1lU9L/KohwgfCckaTZENHsbJ5Q=3D; b=q57Be5dsqC2r2ZpBgVxFA9WNDtZSJKKEGTLvWCcrt4X6/J5E9URiN9yK0dTX/BK3mcTyxval 8DYUrvtP31PJLLt3QnCNOSHMNsosKCWRcl/ZkqCfxxlCAGQdct2kMNb5; Authentication-Results: sj-dkim-5.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Subject: [Simple] comments on draft-schulzrinne-simple-composition policy X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org * On the topic of overlap with presence-processing-model, I think there is overlap principally between section 4.2.2 of presence processing model (which specifies concepts for composition) and this document. The specification of an actual composition format is clearly not overlapping with presence processing model. If we do decide to move forward with both documents, I'd suggest combining the high level concepts from simple-composiiton-policy into presence-processing-model, and then composition-policy would specify detailed mechanisms and the policy format. * Clearly a big question is whether composition policy is per-watcher or not. This document assumes its not, and presence-processing-model assumes it can be. * the document assumes that the sources of presence composition are all presence documents. But, if you look at other sip event packages, almost every one of them are useful sources of presence data, on which derivation would be a useful operation. I think the model needs to support derivation of presence from non-presence XML sources * scope is another huge question here (we had similar issues with RPID). Do we know what we really need to specify in terms of composition policies at this time? It would be good to have some requirements from actual deployments * another big question we need to ask is whether we really expect composition policies to be pluggable like this, or whether they are simply a set of hard-coded functions built into a presence server. In the latter case, we don't need to specify a language per se; guidance on the types of things that might be done would be more appropriate Some minor comments: * section 2 enumerates different types of presence data. However, it wasn't clear to me that this particular taxonomy was either exhaustive or the right set. For example, where in this taxonomy would information from an IP PBX on whether the user is in a call be? > Composition involves adding or removing information from a set of > sources, and this may be done at a tuple or element granularity. > Some of the steps operate at one granularity or another. While any > of the operations may be done on any tuple type, some operations may > be more likely performed on certain types. This information is nit: the table talks about , and . These are not types of tuples. I thin the paragraph about should say "on any data component". Data component is defined in the presence data model. Generally this problem happens in many places. Sometimes the document uses tuple to mean one of , or and sometimes it means just . * the document claims that you can't have conflicts for service or device information, but it really wasnt clear why this is true Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 10 08:29:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzust-0008MA-Ib; Mon, 10 Jul 2006 08:29:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzuss-0008M5-Ni for simple@ietf.org; Mon, 10 Jul 2006 08:29:06 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzusr-0001ue-By for simple@ietf.org; Mon, 10 Jul 2006 08:29:06 -0400 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 14:28:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Jul 2006 14:28:52 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-aoki-simple-interdomain-bcp-01.txt Thread-Index: AcakHICdPQ7r/tScStCGb7i7lhX1MQ== From: "MARJOU Xavier RD-MAPS-LAN" To: X-OriginalArrivalTime: 10 Jul 2006 12:28:55.0867 (UTC) FILETIME=[6942E8B0:01C6A41C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: simple@ietf.org Subject: [Simple] Comments on draft-aoki-simple-interdomain-bcp-01.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi, In section 6.2, there's a SDP body in the 200 of OPTIONS. Is it a mistake or is it done or purpose? In section 6.3.2, interim "IM sessions" solutions merit more details, especially about the way there are negotiated with SDP. Xavier _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 10 10:59:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzxEM-0005qm-Eo; Mon, 10 Jul 2006 10:59:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzxEK-0005ku-9S for simple@ietf.org; Mon, 10 Jul 2006 10:59:24 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzxEI-0003dX-RM for simple@ietf.org; Mon, 10 Jul 2006 10:59:24 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6ADxLhN026829 for ; Mon, 10 Jul 2006 16:59:22 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 17:59:21 +0300 Received: from esebe106.NOE.Nokia.com ([172.21.143.51]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 17:59:21 +0300 Received: from 10.241.58.185 ([10.241.58.185]) by esebe106.NOE.Nokia.com ([172.21.143.51]) with Microsoft Exchange Server HTTP-DAV ; Mon, 10 Jul 2006 14:59:21 +0000 Received: from macbuster by ESEBE106.noe.nokia.com; 10 Jul 2006 10:59:21 -0400 From: Aki Niemi To: "'simple@ietf.org'" Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Nokia-NRC/Helsinki Date: Mon, 10 Jul 2006 10:59:21 -0400 Message-Id: <1152543561.13403.6.camel@macbuster.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-OriginalArrivalTime: 10 Jul 2006 14:59:21.0823 (UTC) FILETIME=[6D267EF0:01C6A431] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Simple] Updated simple-chat draft X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi, We've updated the simple-chat draft, taking into account the feedback from and since the last IETF meeting. The controversial stuff should now be all gone. A link for your convenience: http://www.ietf.org/internet-drafts/draft-niemi-simple-chat-05.txt -- Aki Niemi Nokia Research Center _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 10 13:12:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzzIk-0005bO-Gk; Mon, 10 Jul 2006 13:12:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzzIi-0005bD-UL for simple@ietf.org; Mon, 10 Jul 2006 13:12:04 -0400 Received: from papaya.cc.columbia.edu ([128.59.29.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzzIh-0004eJ-Jz for simple@ietf.org; Mon, 10 Jul 2006 13:12:04 -0400 Received: from papaya.cc.columbia.edu (localhost [127.0.0.1]) by papaya.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k6AHC0uV016538; Mon, 10 Jul 2006 13:12:00 -0400 (EDT) Received: from localhost (rs2194@localhost) by papaya.cc.columbia.edu (8.13.7/8.12.3/Submit) with ESMTP id k6AHC0sx016535; Mon, 10 Jul 2006 13:12:00 -0400 (EDT) X-Authentication-Warning: papaya.cc.columbia.edu: rs2194 owned process doing -bs Date: Mon, 10 Jul 2006 13:12:00 -0400 (EDT) From: Ron Shacham To: Jonathan Rosenberg Subject: Re: [Simple] comments on draft-schulzrinne-simple-composition policy In-Reply-To: <44B18A4D.7050709@cisco.com> Message-ID: References: <44B18A4D.7050709@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.5 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: shacham@cs.columbia.edu, simple@ietf.org, hgs@cs.columbia.edu X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Jonathan, Thanks for your helpful comments. Please see responses inline. Regards, Ron On Sun, 9 Jul 2006, Jonathan Rosenberg wrote: > * On the topic of overlap with presence-processing-model, I think there is > overlap principally between section 4.2.2 of presence processing model (which > specifies concepts for composition) and this document. The specification of > an actual composition format is clearly not overlapping with presence > processing model. If we do decide to move forward with both documents, I'd > suggest combining the high level concepts from simple-composiiton-policy into > presence-processing-model, and then composition-policy would specify detailed > mechanisms and the policy format. > > * Clearly a big question is whether composition policy is per-watcher or not. > This document assumes its not, and presence-processing-model assumes it can > be. >From the processing-model draft, it appears that this is limited to a case like "polite block". We agree that in such a case, there would be a special policy, although in general different composition policies do not seem useful. Are you thinking of other use cases? We haven't specified a specific way to do polite blocking; maybe this doesn't have to be done through "composition", but rather a separate document that is shown to the polite blocked watchers, since the view is probably static anyway (eg. a single service whose basic status is closed) > > * the document assumes that the sources of presence composition are all > presence documents. But, if you look at other sip event packages, almost > every one of them are useful sources of presence data, on which derivation > would be a useful operation. I think the model needs to support derivation of > presence from non-presence XML sources This is a good suggestion. You discuss 'dialog-info' and 'reg' in the draft. I think that maybe 'message-summary' and 'conference' could have useful applications as well. Would the conversion of other notification data to presence data be more appropriately handled by the server, without the user specifying it? Once the data is represented as presence, it is easier for the composition policy document to reference and manipulate it. In general, we need to clarify what will be done through "hard-coding" as you mention, and what should be specified by the user in an XML composition policy document. > > * scope is another huge question here (we had similar issues with RPID). Do > we know what we really need to specify in terms of composition policies at > this time? It would be good to have some requirements from actual deployments > > * another big question we need to ask is whether we really expect composition > policies to be pluggable like this, or whether they are simply a set of > hard-coded functions built into a presence server. In the latter case, we > don't need to specify a language per se; guidance on the types of things that > might be done would be more appropriate > > > > Some minor comments: > > > * section 2 enumerates different types of presence data. However, it > wasn't clear to me that this particular taxonomy was either exhaustive > or the right set. For example, where in this taxonomy would information > from an IP PBX on whether the user is in a call be? > >> Composition involves adding or removing information from a set of >> sources, and this may be done at a tuple or element granularity. >> Some of the steps operate at one granularity or another. While any >> of the operations may be done on any tuple type, some operations may >> be more likely performed on certain types. This information is > > nit: the table talks about , and . These are not > types of tuples. I thin the paragraph about should say "on any data > component". Data component is defined in the presence data model. Okay, we have been using bad terminology, and we'll fix that. > > Generally this problem happens in many places. Sometimes the document uses > tuple to mean one of , or and sometimes it means > just . > > * the document claims that you can't have conflicts for service or device > information, but it really wasnt clear why this is true In general, we consider multiple service instances to be different representations of the same service, so they do not conflict. The example in your draft of overriding service info by publishing another service with the same service URI clearly doesn't assume this. Would overriding work by using the same instance ID? Are there other examples where services (or devices) conflict? > > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 10 18:15:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G042X-0008Qe-JB; Mon, 10 Jul 2006 18:15:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G042W-0008QZ-DP for simple@ietf.org; Mon, 10 Jul 2006 18:15:40 -0400 Received: from c3po.aoltw.net ([64.236.137.25] helo=mcom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G042Q-000503-Ul for simple@ietf.org; Mon, 10 Jul 2006 18:15:40 -0400 Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by mcom.com (8.10.0/8.10.0) with ESMTP id k6AMFNW16843 for ; Mon, 10 Jul 2006 15:15:28 -0700 (PDT) Received: from [192.168.1.93] ([10.180.190.176]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id J27KHM03.B0N; Mon, 10 Jul 2006 15:15:22 -0700 Message-ID: <44B2D173.2010202@aol.net> Date: Mon, 10 Jul 2006 15:15:15 -0700 From: Edwin Aoki User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.2) Gecko/20060405 SeaMonkey/1.0.1 MIME-Version: 1.0 To: MARJOU Xavier RD-MAPS-LAN References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: simple@ietf.org Subject: [Simple] Re: Comments on draft-aoki-simple-interdomain-bcp-01.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Xavier, Thank you for your comments. MARJOU Xavier RD-MAPS-LAN wrote: > Hi, > > In section 6.2, there's a SDP body in the 200 of OPTIONS. Is it a > mistake or is it done or purpose? > > The SDP body is there on purpose, but it doesn't have any specific relevance to the example. Presumably, the SDP exists to communicate information about the media types that the server supports independent of whether it supports the page-mode IM (specified by having MESSAGE in the Allow) field. > In section 6.3.2, interim "IM sessions" solutions merit more details, > especially about the way there are negotiated with SDP. > > Earlier versions of the related draft-levin-simple-interdomain-reqs-03.txt (now expired) had additional detail on how to specify an interim session mode IM dialog, but the general consensus in this WG was that we should not be encouraging the use of sessions-based IM dialogs outside of MSRP. As it stands, this section exists to convey that there are IM systems that have implemented session based IM before MSRP was standardized, and that they signal and negotiate this capability through SDP. Cheers, -Edwin > Xavier > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jul 11 02:31:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0BmW-0004z0-9U; Tue, 11 Jul 2006 02:31:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0BVS-0003HF-6f for simple@ietf.org; Tue, 11 Jul 2006 02:14:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G098d-0004ci-CI for simple@ietf.org; Mon, 10 Jul 2006 23:42:19 -0400 Received: from [67.70.246.244] (helo=roundabout.local) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G08y4-0001WT-V4 for simple@ietf.org; Mon, 10 Jul 2006 23:31:31 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by roundabout.local (Postfix) with ESMTP id A35144FD95B; Mon, 10 Jul 2006 21:31:23 -0600 (MDT) Message-ID: <44B31B7C.1050506@jabber.org> Date: Mon, 10 Jul 2006 21:31:08 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.4) Gecko/20060530 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Adam Roach Subject: Re: Fw: [Simple] "last call" on SIMPLE-XMPP interworking I-D References: <44AE872E.3080902@nostrum.com> In-Reply-To: <44AE872E.3080902@nostrum.com> X-Enigmail-Version: 0.94.0.0 Jabber-ID: stpeter@jabber.org X-Spam-Score: -2.6 (--) X-Scan-Signature: 025f8c5000216988bfe31585db759250 Cc: xmppwg@jabber.org, Avshalom Houri , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 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="===============1563633208==" Errors-To: simple-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1563633208== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010109010600060305050108" This is a cryptographically signed message in MIME format. --------------ms010109010600060305050108 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Adam Roach wrote: > Avshalom Houri wrote: >> Adam, >> >> The attach that your are describing is inherent to the way >> that subscriptions are handled in XMPP and in SIP. >> In XMPP the subscriptions are long lived while in SIP there are >> (in a lot of cases redundant) resubscriptions. >> > > I understand the difficulty, which is why the solution to the problem is > non-obvious to me. However, I think it would be dangerous and > irresponsible of the IETF to publish as an RFC a document that describes > behavior that is effectively a pre-canned zombie attack. > > I was hoping that someone with a better knowledge of XMPP than I would > be able to hop in and say something like, "Oh, yeah, you're right. We > can solve this by making the subscribing system do a commensurate amount > of work. The gateway does this by sending a stanza to the > subscriber every time it is about to send a SIP SUBSCRIBE refresh on > that subscriber's behalf. RFC WXYZ requires the {client,server} to > respond to the stanza with a response. As long as the > gateway requires a / exchange with the subscribing XMPP > {client,server} for each SIP SUBSCRIBE refresh, then we're requiring any > potential attacker to do the work on the same order of magnitude as the > gateway, which thwarts the amplification attack you describe." But XMPP doesn't require that level of work (subscriptions are long-lived), so it doesn't have protocol semantics for what you describe. > There might be a solution along these lines, and there may not be. There > may be other approaches that would work. Engineering these solutions > will require more XMPP knowledge than I possess. Engineering those solutions would require extensions to XMPP, which would be optional since they're not part of the core spec, at which point the potential attacker could simply ignore them. One could attempt to say that any entity that registers with a gateway must support the extensions (i.e., a gateway MUST require support for these extensions on the part of a registering client), but there would be ways around that, too (e.g., lie when you register). >> Even in SIP, the need of having resubsscribes in SIP does not make a real >> difference to the attacker since as long as there is a living TCP >> connection there is no problem in sending those refreshes. >> The TCP connection itself will have to send keep alives every two hours >> is there is no other traffic. >> > > Let me bound the time-frame that I am talking about a little bit more. > Let's consider a single day. Assume the presence subscriptions are > refreshed every hour. Further, assume the attacker is sending messages > out at a leisurely 2.7 messages per second -- or 10,000 an hour. > > +----------+ +----------+ +--------------+ > | XMPP |______| Victim | | Victim | > | Attacker | A | XMPP/SIP |-----| SIP Presence | > +----------+ | Gateway | B | Server | > +----------+ +--------------+ > > In the first hour of the attack, the XMPP attacker sends 10,000 presence > requests across link A. The source of these requests are imaginary users > 1 through 10,000. As a reaction, the gateway sends 10,000 presence > requests across link B. > > So far, so good. The first hour looks just like it would if the gateway > were a SIP proxy. > > At the beginning of the second hour, the gateway sends a refresh to the > presence server on behalf of imaginary user #1, since his hour is up. At > the same time, the attacker has sent a subscription request from > imaginary user #10,001, so the XMPP/SIP gateway sends a subscribe for > that user as well. About a third of a second later, a the gateway will > send a similar set of subscribes for imaginary users #2 (refresh) and > #10,002 (new subscription). > > At the end of the second hour, the attacker has sent a total of 20,000 > messages (10,000 the first hour, 10,000 the second hour). The gateway > has sent a total of 30,000 (10,000 the first hour, and 20,000 the second > hour). > > In the third hour, the attacker sends 10,000 messages for imaginary > users 20,000 through 29,999. The gateway sends 10,000 corresponding > messages, plus 20,000 refreshes for imaginary users #1 through #19,999. > > By the 24th hour, the attacker has sent a total of 240,000 messages. In > reaction, he has caused a total of 3,000,000 SUBSCRIBE messages to flow > between the victim gateway and the victim server. That's better than a > 12:1 amplification. Not bad at all. > > Keep in mind: if the attacker decided to stop at this point, the victim > system would continue to process 5.7 million messages a day because of > the attack. > > Now, let's consider slightly longer time frames. > > If the attacker decided to go on with the attack, then at the end of the > second day, the attacker would have sent 480,000 messages in total, > while causing the victim system to process 11.7 million messages total > (24:1 amplification). > > By day 3, the numbers are 720,000 and 26.2 million, respectively (36:1 > amplification). > > By the end of a week, the attacker will have sent 1.4 million messages, > while managing to induce the victim system to process 104.4 million > (74:1 amplification). And again, even if the attack stops at this point, > the victim system would continue to process 34.5 million messages a day > without any further effort from the attacker ever again. That's all very nice, but it doesn't solve the problem. What do you see as the nature of the attack? Is this a denial of service attack that is made easier via amplification? Or is amplification its own type of attack? As far as I can see right now, there are two ways to solve this problem using existing protocol semantics: 1. Honor the long-lived subscriptions from XMPP but instruct gateway deployments that they must treat multiple subscriptions from the same IP or domain with caution, set configurable limits to the number of subscriptions they will accept, etc. 2. Honor the short-lived subscriptions from SIP and send unsubscribes to the XMPP entities whenever the subscription is about to time out, thus forcing the XMPP entity to resubscribe. Option #2 would force the behavior you are hoping for, since it would put an equal burden on the XMPP entities as on the SIP presence server, thus preventing the amplification effect. Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml --------------ms010109010600060305050108 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYVDCC B3AwggbZoAMCAQICAQkwDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0 MDUxNDUxMDNaFw0xMDA0MDQxNDUxMDNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVtYWlsIEZy ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAOOY75tn3YhiCOsNXQn9/4WfpNrX8HLIUlBTLrGtMINvcYJ0 3Nlr9kJyOF5Z8g+2G9Zg+zN8iWGBEpl37bgjYdea3q0AaO9uyZOMLa0rztjFeo7Uw8AjdDmW kaJQU1c6q9OoieOT6Tf4MvHMGqtbnaOL3Xvz4o6XnH+Ek9h8zPgYgiUw2tIF0ueLayTGiInH dWM5eYMoz7OnVlUeIurDweT4C9V1TtwplnhWZ7bilcuN4w3/8hndqryqqflbCMlLZWn+1uaT 21d12cdpjBOaqtg6hqiTY4S4+wVAmGrAiOPQ3Z574gljhUKf5ehz7p9xtsb+mjvM1I4yPP8/ vjKZoRUCAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud DgQWBBS4Zr17owi6irSy+USIcU+li0GzUTCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0 eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0 YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6 Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5 BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50 ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0 cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQDss9KK Fx/bCifYjAQTmBtRoHFsdR5ZQ1nlagXKoyJ+IwmdGdiYqAKeaDfjT6bTXHfQvK8kp5xSoz0I PcpSwztY7UKtylgJwplu1q6vjj4BGB621sD60qzirAhLSqxmpBgjl8HMMMoiM28DCLsshihl g7wG7Oi/rPIuR8dawiaDejCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STGCBCwwggQoAgEBMIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UE CBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2Vy dGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVt YWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAOhwMAkG BSsOAwIaBQCgggJJMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTA2MDcxMTAzMzEwOFowIwYJKoZIhvcNAQkEMRYEFCaSioWtvxFJZtkVpPfo59gMXfFGMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHIBgkrBgEEAYI3EAQxgbowgbcwga8xCzAJ BgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAh BgNVBAsTGlNlY3VyZSBDZXJ0aWZpY2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBD bGFzcyAyIFByaW1hcnkgRW1haWwgRnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3Rh cnRjb20ub3JnAgMA6HAwgcoGCyqGSIb3DQEJEAILMYG6oIG3MIGvMQswCQYDVQQGEwJJTDEP MA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1 cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwID AOhwMA0GCSqGSIb3DQEBAQUABIIBAFN4pOzzV2vis2sLJ1mjxq6gDBhbSklLScYk28D2I2PS c/WthLZ2LGHBZp80MS4MIPi/hXNg/O9k0TDgnn6zH5An/YsU3DWFM7J5HCPsBxd0KgugE3+8 XS80Lvhc183ucuQZpMUtZjJcOH/joox3nkzNiMIH9mVw8wougREli81s2LWRpEeiRw2+uZF8 JTC4TJaW60KSfPmg4jzUh3VOIu+rrCZKc3xprIWHUVJLfzNjU0CbOqGI0EYC/cBHum0dDbfH fCro6TlOx60/ilH7u2sVfWNPnQ62KR6UtU42z6KZyfdySsHiCC+xP5avhVhRO7d+SICsow7A +1ygnSwraScAAAAAAAA= --------------ms010109010600060305050108-- --===============1563633208== 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://www1.ietf.org/mailman/listinfo/simple --===============1563633208==-- From simple-bounces@ietf.org Tue Jul 11 14:14:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0MkZ-0006wE-Gb; Tue, 11 Jul 2006 14:14:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0MkY-0006w9-O2 for simple@ietf.org; Tue, 11 Jul 2006 14:14:22 -0400 Received: from [2001:5c0:8fff:fffe::4c49] (helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0MkW-0002Ob-L2 for simple@ietf.org; Tue, 11 Jul 2006 14:14:22 -0400 Received: from [132.219.24.178] (h18b2-net84db.lab.risq.net [132.219.24.178] (may be forged)) (authenticated bits=0) by nostrum.com (8.13.6/8.13.6) with ESMTP id k6BIEDFE065870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Jul 2006 13:14:15 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <44B3EA74.1040104@nostrum.com> Date: Tue, 11 Jul 2006 14:14:12 -0400 From: Adam Roach User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Peter Saint-Andre Subject: Re: Fw: [Simple] "last call" on SIMPLE-XMPP interworking I-D References: <44AE872E.3080902@nostrum.com> <44B31B7C.1050506@jabber.org> In-Reply-To: <44B31B7C.1050506@jabber.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Received-SPF: pass (nostrum.com: 132.219.24.178 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Avshalom Houri , xmppwg@jabber.org, Adam Roach , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Peter Saint-Andre wrote: > Adam Roach wrote: > =20 >> I was hoping that someone with a better knowledge of XMPP than I would= >> be able to hop in and say something like, "Oh, yeah, you're right. We >> can solve this by making the subscribing system do a commensurate amou= nt >> of work. The gateway does this by sending a stanza to the >> subscriber every time it is about to send a SIP SUBSCRIBE refresh on >> that subscriber's behalf. RFC WXYZ requires the {client,server} to >> respond to the stanza with a response. As long as the >> gateway requires a / exchange with the subscribing XMPP >> {client,server} for each SIP SUBSCRIBE refresh, then we're requiring a= ny >> potential attacker to do the work on the same order of magnitude as th= e >> gateway, which thwarts the amplification attack you describe." >> =20 > > But XMPP doesn't require that level of work (subscriptions are > long-lived), so it doesn't have protocol semantics for what you describ= e. > =20 Okay, let's try this again. I was hoping that someone who knows more about XMPP than I -- say, one of= the XMPP RFC authors -- would be sufficiently familiar with the XMPP pro= tocol to hop in with something like: "Oh, yeah, you're right. We can solv= e this by making the subscribing system do a commensurate amount of work.= The gateway does this by sending an stanza to the sub= scriber's XMPP server every time it is about to send a SIP SUBSCRIBE refr= esh on that subscriber's behalf. RFC 3920, section 9.2.3, bullet #3, requ= ires (at a MUST strength) the server to respond to the = stanza with an or stanza. As l= ong as the gateway requires an exchange with the subscribing user's= XMPP server for each SIP SUBSCRIBE refresh, then we're requiring any pot= ential attacker to do the work on the same order of magnitude as the gate= way, which thwarts the amplification attack you describe." /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jul 11 14:59:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0NRr-0002Ck-3n; Tue, 11 Jul 2006 14:59:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0NRp-0002Cf-Jz for simple@ietf.org; Tue, 11 Jul 2006 14:59:05 -0400 Received: from [132.219.31.121] (helo=h1f79-net84db.lab.risq.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0NRo-0004rN-3f for simple@ietf.org; Tue, 11 Jul 2006 14:59:05 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by h1f79-net84db.lab.risq.net (Postfix) with ESMTP id 88F3B4FDE56; Tue, 11 Jul 2006 12:59:13 -0600 (MDT) Message-ID: <44B3F501.7060104@jabber.org> Date: Tue, 11 Jul 2006 12:59:13 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.4) Gecko/20060530 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Adam Roach Subject: Re: Fw: [Simple] "last call" on SIMPLE-XMPP interworking I-D References: <44AE872E.3080902@nostrum.com> <44B31B7C.1050506@jabber.org> <44B3EA74.1040104@nostrum.com> In-Reply-To: <44B3EA74.1040104@nostrum.com> X-Enigmail-Version: 0.94.0.0 Jabber-ID: stpeter@jabber.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: xmppwg@jabber.org, Avshalom Houri , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 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="===============2046675633==" Errors-To: simple-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============2046675633== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070004090302000307080701" This is a cryptographically signed message in MIME format. --------------ms070004090302000307080701 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Adam Roach wrote: > Peter Saint-Andre wrote: >> Adam Roach wrote: >> >>> I was hoping that someone with a better knowledge of XMPP than I would >>> be able to hop in and say something like, "Oh, yeah, you're right. We >>> can solve this by making the subscribing system do a commensurate amount >>> of work. The gateway does this by sending a stanza to the >>> subscriber every time it is about to send a SIP SUBSCRIBE refresh on >>> that subscriber's behalf. RFC WXYZ requires the {client,server} to >>> respond to the stanza with a response. As long as the >>> gateway requires a / exchange with the subscribing XMPP >>> {client,server} for each SIP SUBSCRIBE refresh, then we're requiring any >>> potential attacker to do the work on the same order of magnitude as the >>> gateway, which thwarts the amplification attack you describe." >>> >> >> But XMPP doesn't require that level of work (subscriptions are >> long-lived), so it doesn't have protocol semantics for what you describe. >> > > Okay, let's try this again. > > I was hoping that someone who knows more about XMPP than I -- say, one > of the XMPP RFC authors -- would be sufficiently familiar with the XMPP > protocol to hop in with something like: "Oh, yeah, you're right. We can > solve this by making the subscribing system do a commensurate amount of > work. The gateway does this by sending an stanza to the > subscriber's XMPP server every time it is about to send a SIP SUBSCRIBE > refresh on that subscriber's behalf. RFC 3920, section 9.2.3, bullet #3, > requires (at a MUST strength) the server to respond to the type='get'/> stanza with an or > stanza. As long as the gateway requires an exchange with the > subscribing user's XMPP server for each SIP SUBSCRIBE refresh, then > we're requiring any potential attacker to do the work on the same order > of magnitude as the gateway, which thwarts the amplification attack you > describe." I'm saying that XMPP does have what you want, but in order to enforce that, on the XMPP end of the wormhole the gateway would need to mimic short-lived SIP subscription semantics rather than long-lived XMPP subscription semantics. Peter --------------ms070004090302000307080701 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYVDCC B3AwggbZoAMCAQICAQkwDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0 MDUxNDUxMDNaFw0xMDA0MDQxNDUxMDNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVtYWlsIEZy ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAOOY75tn3YhiCOsNXQn9/4WfpNrX8HLIUlBTLrGtMINvcYJ0 3Nlr9kJyOF5Z8g+2G9Zg+zN8iWGBEpl37bgjYdea3q0AaO9uyZOMLa0rztjFeo7Uw8AjdDmW kaJQU1c6q9OoieOT6Tf4MvHMGqtbnaOL3Xvz4o6XnH+Ek9h8zPgYgiUw2tIF0ueLayTGiInH dWM5eYMoz7OnVlUeIurDweT4C9V1TtwplnhWZ7bilcuN4w3/8hndqryqqflbCMlLZWn+1uaT 21d12cdpjBOaqtg6hqiTY4S4+wVAmGrAiOPQ3Z574gljhUKf5ehz7p9xtsb+mjvM1I4yPP8/ vjKZoRUCAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud DgQWBBS4Zr17owi6irSy+USIcU+li0GzUTCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0 eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0 YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6 Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5 BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50 ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0 cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQDss9KK Fx/bCifYjAQTmBtRoHFsdR5ZQ1nlagXKoyJ+IwmdGdiYqAKeaDfjT6bTXHfQvK8kp5xSoz0I PcpSwztY7UKtylgJwplu1q6vjj4BGB621sD60qzirAhLSqxmpBgjl8HMMMoiM28DCLsshihl g7wG7Oi/rPIuR8dawiaDejCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STGCBCwwggQoAgEBMIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UE CBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2Vy dGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVt YWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAOhwMAkG BSsOAwIaBQCgggJJMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTA2MDcxMTE4NTkxM1owIwYJKoZIhvcNAQkEMRYEFJ3jRanA/bwsKY0I6n48vZFU7KbxMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHIBgkrBgEEAYI3EAQxgbowgbcwga8xCzAJ BgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAh BgNVBAsTGlNlY3VyZSBDZXJ0aWZpY2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBD bGFzcyAyIFByaW1hcnkgRW1haWwgRnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3Rh cnRjb20ub3JnAgMA6HAwgcoGCyqGSIb3DQEJEAILMYG6oIG3MIGvMQswCQYDVQQGEwJJTDEP MA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1 cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwID AOhwMA0GCSqGSIb3DQEBAQUABIIBAKYm38lxSYzQbZL33grCP12k938NenpP0i/0gHVElYj+ r4Fv2SAAxeO6KclfigK1uVVBU9sZ1w4lQRZt3MvOk3SAQIDbHSgAV1npp6SA/0+5oVAiK8k3 JJUk8ivbpBwo767U4C2zXt+ZqRL3lchgCTn3iRepkDyhM98CW/ZZ6693lZBWKy+euUr3Jh1U JsVJpeoMcSjmFKKI5EuHrkh7dFWjlxd/fGevdnZPsIWE/okxCRcDNm+2U9PaCjfIuquT7tLO is1z0/toRaYGrfLjv2OidthfHbNkhwiYR/HejTVD5jtk4w2ZR7Hk6dLUN2sa8eLmX+X7keIl ILEUj+7XHq4AAAAAAAA= --------------ms070004090302000307080701-- --===============2046675633== 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://www1.ietf.org/mailman/listinfo/simple --===============2046675633==-- From simple-bounces@ietf.org Tue Jul 11 15:26:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Nsf-0003th-Vj; Tue, 11 Jul 2006 15:26:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Nse-0003tb-Nz for simple@ietf.org; Tue, 11 Jul 2006 15:26:48 -0400 Received: from [2001:5c0:8fff:fffe::4c3d] (helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0Nsb-00075J-N1 for simple@ietf.org; Tue, 11 Jul 2006 15:26:48 -0400 Received: from [132.219.24.178] (h18b2-net84db.lab.risq.net [132.219.24.178] (may be forged)) (authenticated bits=0) by vicuna.estacado.net (8.13.6/8.13.4) with ESMTP id k6BJQaLb038711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Jul 2006 14:26:40 -0500 (CDT) (envelope-from adam@estacado.net) Message-ID: <44B3FB6A.70502@estacado.net> Date: Tue, 11 Jul 2006 15:26:34 -0400 From: Adam Roach User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Peter Saint-Andre Subject: Re: Fw: [Simple] "last call" on SIMPLE-XMPP interworking I-D References: <44AE872E.3080902@nostrum.com> <44B31B7C.1050506@jabber.org> <44B3EA74.1040104@nostrum.com> <44B3F501.7060104@jabber.org> In-Reply-To: <44B3F501.7060104@jabber.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Avshalom Houri , xmppwg@jabber.org, Adam Roach , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Peter Saint-Andre wrote: > I'm saying that XMPP does have what you want, but in order to enforce > that, on the XMPP end of the wormhole the gateway would need to mimic > short-lived SIP subscription semantics rather than long-lived XMPP > subscription semantics. > Okay; let's do that, then. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jul 11 15:47:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0OCA-0006xY-3j; Tue, 11 Jul 2006 15:46:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0OC8-0006xI-Ir for simple@ietf.org; Tue, 11 Jul 2006 15:46:56 -0400 Received: from [132.219.31.121] (helo=h1f79-net84db.lab.risq.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0OC5-0001LB-Tz for simple@ietf.org; Tue, 11 Jul 2006 15:46:56 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by h1f79-net84db.lab.risq.net (Postfix) with ESMTP id CB7E54FDF7C; Tue, 11 Jul 2006 13:47:00 -0600 (MDT) Message-ID: <44B40034.2030400@jabber.org> Date: Tue, 11 Jul 2006 13:47:00 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.4) Gecko/20060530 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Adam Roach Subject: Re: Fw: [Simple] "last call" on SIMPLE-XMPP interworking I-D References: <44AE872E.3080902@nostrum.com> <44B31B7C.1050506@jabber.org> <44B3EA74.1040104@nostrum.com> <44B3F501.7060104@jabber.org> <44B3FB6A.70502@estacado.net> In-Reply-To: <44B3FB6A.70502@estacado.net> X-Enigmail-Version: 0.94.0.0 Jabber-ID: stpeter@jabber.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: Avshalom Houri , xmppwg@jabber.org, Adam Roach , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 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="===============0272147976==" Errors-To: simple-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0272147976== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010603040302070203010701" This is a cryptographically signed message in MIME format. --------------ms010603040302070203010701 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Adam Roach wrote: > Peter Saint-Andre wrote: >> I'm saying that XMPP does have what you want, but in order to enforce >> that, on the XMPP end of the wormhole the gateway would need to mimic >> short-lived SIP subscription semantics rather than long-lived XMPP >> subscription semantics. >> > > Okay; let's do that, then. Would you prefer it to be a (1) a MUST or (2) a SHOULD with a proviso in all caps saying that if you decide to be nice to XMPP clients at the deployment level then you open up a possible amplification attack (see the security considerations) and be aware that SIP presence servers might not refuse to talk with you blah blah blah? Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml --------------ms010603040302070203010701 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYVDCC B3AwggbZoAMCAQICAQkwDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0 MDUxNDUxMDNaFw0xMDA0MDQxNDUxMDNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVtYWlsIEZy ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAOOY75tn3YhiCOsNXQn9/4WfpNrX8HLIUlBTLrGtMINvcYJ0 3Nlr9kJyOF5Z8g+2G9Zg+zN8iWGBEpl37bgjYdea3q0AaO9uyZOMLa0rztjFeo7Uw8AjdDmW kaJQU1c6q9OoieOT6Tf4MvHMGqtbnaOL3Xvz4o6XnH+Ek9h8zPgYgiUw2tIF0ueLayTGiInH dWM5eYMoz7OnVlUeIurDweT4C9V1TtwplnhWZ7bilcuN4w3/8hndqryqqflbCMlLZWn+1uaT 21d12cdpjBOaqtg6hqiTY4S4+wVAmGrAiOPQ3Z574gljhUKf5ehz7p9xtsb+mjvM1I4yPP8/ vjKZoRUCAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud DgQWBBS4Zr17owi6irSy+USIcU+li0GzUTCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0 eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0 YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6 Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5 BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50 ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0 cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQDss9KK Fx/bCifYjAQTmBtRoHFsdR5ZQ1nlagXKoyJ+IwmdGdiYqAKeaDfjT6bTXHfQvK8kp5xSoz0I PcpSwztY7UKtylgJwplu1q6vjj4BGB621sD60qzirAhLSqxmpBgjl8HMMMoiM28DCLsshihl g7wG7Oi/rPIuR8dawiaDejCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STGCBCwwggQoAgEBMIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UE CBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2Vy dGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVt YWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAOhwMAkG BSsOAwIaBQCgggJJMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTA2MDcxMTE5NDcwMFowIwYJKoZIhvcNAQkEMRYEFL9kxNHoOLR0tcIxe9v3jOEPGYxyMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHIBgkrBgEEAYI3EAQxgbowgbcwga8xCzAJ BgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAh BgNVBAsTGlNlY3VyZSBDZXJ0aWZpY2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBD bGFzcyAyIFByaW1hcnkgRW1haWwgRnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3Rh cnRjb20ub3JnAgMA6HAwgcoGCyqGSIb3DQEJEAILMYG6oIG3MIGvMQswCQYDVQQGEwJJTDEP MA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1 cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwID AOhwMA0GCSqGSIb3DQEBAQUABIIBAF2Am6gZskPnfgpijY84T2GnebJqM11569/foYUvc6q3 mziPVQ15NyuOOvL7RnyCz0+bQxD1gSNp61l7VxWkqkNJ5HW6tRq6XRDRLuLRebnw9VZfW57t GoDaLZUbW0IKJGQTfhW2IEbzUH0BsITxAgnMrtiNFOcjNhjwxJQuxtMtfRNyjRkSfupS86A2 b0cMjPrqJA6MK6C8luydqMI+Bygjb2jZxkOo+6otS6bzcrHi8iF94p+1JF+CQ2pHvW5Es5fY zX0yKbN0BwbDeUZkY1bHyt0KpPyl4fVcnuVS2Az7F4qpwd8T8rMFq2IEJ77oeMFCeDOvH9ur FMwCuK1E/GcAAAAAAAA= --------------ms010603040302070203010701-- --===============0272147976== 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://www1.ietf.org/mailman/listinfo/simple --===============0272147976==-- From simple-bounces@ietf.org Tue Jul 11 16:21:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0OjG-0005gu-4e; Tue, 11 Jul 2006 16:21:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0OjE-0005gp-7x for simple@ietf.org; Tue, 11 Jul 2006 16:21:08 -0400 Received: from [132.219.31.121] (helo=h1f79-net84db.lab.risq.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0OjC-0007rs-Ra for simple@ietf.org; Tue, 11 Jul 2006 16:21:08 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by h1f79-net84db.lab.risq.net (Postfix) with ESMTP id 840FB4FE040; Tue, 11 Jul 2006 14:21:15 -0600 (MDT) Message-ID: <44B4083A.8090107@jabber.org> Date: Tue, 11 Jul 2006 14:21:14 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.4) Gecko/20060530 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Adam Roach Subject: Re: Fw: [Simple] "last call" on SIMPLE-XMPP interworking I-D References: <44AE872E.3080902@nostrum.com> <44B31B7C.1050506@jabber.org> <44B3EA74.1040104@nostrum.com> <44B3F501.7060104@jabber.org> <44B3FB6A.70502@estacado.net> <44B40034.2030400@jabber.org> <44B40517.3060709@nostrum.com> In-Reply-To: <44B40517.3060709@nostrum.com> X-Enigmail-Version: 0.94.0.0 Jabber-ID: stpeter@jabber.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: xmppwg@jabber.org, Avshalom Houri , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 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="===============0210506209==" Errors-To: simple-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0210506209== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040608000308070209010700" This is a cryptographically signed message in MIME format. --------------ms040608000308070209010700 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Adam Roach wrote: > Peter Saint-Andre wrote: >> Would you prefer it to be a (1) a MUST or (2) a SHOULD with a proviso in >> all caps saying that if you decide to be nice to XMPP clients at the >> deployment level then you open up a possible amplification attack (see >> the security considerations) and be aware that SIP presence servers >> might not refuse to talk with you blah blah blah? >> > > I would be surprised if (2) has any chance of passing IESG muster. > > Personally, I'm uncomfortable with (2), and see (1) as the only > responsible path forward. You're probably right, I'll update the draft accordingly in the next version. Just wanted to be sure that we were in agreement about the requirements language. Peter --------------ms040608000308070209010700 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYVDCC B3AwggbZoAMCAQICAQkwDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0 MDUxNDUxMDNaFw0xMDA0MDQxNDUxMDNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVtYWlsIEZy ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAOOY75tn3YhiCOsNXQn9/4WfpNrX8HLIUlBTLrGtMINvcYJ0 3Nlr9kJyOF5Z8g+2G9Zg+zN8iWGBEpl37bgjYdea3q0AaO9uyZOMLa0rztjFeo7Uw8AjdDmW kaJQU1c6q9OoieOT6Tf4MvHMGqtbnaOL3Xvz4o6XnH+Ek9h8zPgYgiUw2tIF0ueLayTGiInH dWM5eYMoz7OnVlUeIurDweT4C9V1TtwplnhWZ7bilcuN4w3/8hndqryqqflbCMlLZWn+1uaT 21d12cdpjBOaqtg6hqiTY4S4+wVAmGrAiOPQ3Z574gljhUKf5ehz7p9xtsb+mjvM1I4yPP8/ vjKZoRUCAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud DgQWBBS4Zr17owi6irSy+USIcU+li0GzUTCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0 eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0 YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6 Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5 BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50 ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0 cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQDss9KK Fx/bCifYjAQTmBtRoHFsdR5ZQ1nlagXKoyJ+IwmdGdiYqAKeaDfjT6bTXHfQvK8kp5xSoz0I PcpSwztY7UKtylgJwplu1q6vjj4BGB621sD60qzirAhLSqxmpBgjl8HMMMoiM28DCLsshihl g7wG7Oi/rPIuR8dawiaDejCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STGCBCwwggQoAgEBMIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UE CBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2Vy dGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVt YWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAOhwMAkG BSsOAwIaBQCgggJJMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTA2MDcxMTIwMjExNFowIwYJKoZIhvcNAQkEMRYEFLbtX4+ZYUNHXjKoSzjDMIaxtlNLMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHIBgkrBgEEAYI3EAQxgbowgbcwga8xCzAJ BgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAh BgNVBAsTGlNlY3VyZSBDZXJ0aWZpY2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBD bGFzcyAyIFByaW1hcnkgRW1haWwgRnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3Rh cnRjb20ub3JnAgMA6HAwgcoGCyqGSIb3DQEJEAILMYG6oIG3MIGvMQswCQYDVQQGEwJJTDEP MA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1 cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwID AOhwMA0GCSqGSIb3DQEBAQUABIIBAHoYhydZsnICe+44Ctuql+E8pdRCmF6afMceUtXSRjT2 nfX9AklBLdsH+87p4+w0St3v9J7wlS1EzEJ7/xEM6VLfasHvzAfjKLD4HmaQxkqLthXtqcsM 0o0W6JoUA+Bsb/1off7Lx0huepDR3MDyylO/ziq3Rg3Hxv4v8fISZwK/iJ3VsWDMrCRAObSD kb7YLo5PILm+FcSWs3WHBf2mUHLQOpq5kV4SKE7zBm76wHk89LtJYR4gg99EdS3N9kaToSOj 063sBfwyw6ZZTKYBdi9gv1t4FwB7zyMCxlQPTnytI2zn09KGg5VhvJy/Dfewhp8HvstjCKBN PwVCYFEXGqsAAAAAAAA= --------------ms040608000308070209010700-- --===============0210506209== 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://www1.ietf.org/mailman/listinfo/simple --===============0210506209==-- From simple-bounces@ietf.org Tue Jul 11 16:31:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Ot7-0006VQ-VV; Tue, 11 Jul 2006 16:31:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Ot6-0006VJ-8N for simple@ietf.org; Tue, 11 Jul 2006 16:31:20 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0Ot4-0000UH-NN for simple@ietf.org; Tue, 11 Jul 2006 16:31:20 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 266326E0001 for ; Tue, 11 Jul 2006 22:31:18 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Jul 2006 22:31:17 +0200 Received: from eseldmw101.eemea.ericsson.se ([136.225.228.103]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Jul 2006 22:31:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Jul 2006 22:31:16 +0200 Message-ID: <61D8D34BB13CFE408D154529C120E07936B18E@eseldmw101.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: continuation of draft-rosenberg-simple-presence-processing-model Thread-Index: AcalJA69U6ZIffEURPG1bKHZqId6SAAAuKsw From: "Atle Monrad \(GR/ETO\)" To: X-OriginalArrivalTime: 11 Jul 2006 20:31:17.0836 (UTC) FILETIME=[F66EA8C0:01C6A528] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 1.1 (+) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Simple] continuation of draft-rosenberg-simple-presence-processing-model X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hello My 2 cents on the topic 3gpp got this draft on its dependency list due to a reminder in the presence spec as result of the split of simple-presence-data-model. I have not seen any real requirements of this within 3gpp, and to me we can safley assume that 3gpp can live without draft-rosenberg-simple-presence-processing-model.=20 3gpp can imho adjust the presence spec on the topic without any problems. /atle Atle Monrad Business Unit Mobile Platforms Ericsson Norway ETO/GR/TG Phone: +47 372 93 040 Mobile: +47 454 10 665 Mail: atle.monrad@ericsson.com Web: www.ericsson.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jul 11 17:55:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0QCv-00038w-Ud; Tue, 11 Jul 2006 17:55:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0QCu-00038o-QR for simple@ietf.org; Tue, 11 Jul 2006 17:55:52 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0OyT-0000h1-Vf for simple@ietf.org; Tue, 11 Jul 2006 16:36:54 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G0OWZ-0003as-M2 for simple@ietf.org; Tue, 11 Jul 2006 16:08:05 -0400 Received: from [132.219.24.178] (h18b2-net84db.lab.risq.net [132.219.24.178] (may be forged)) (authenticated bits=0) by nostrum.com (8.13.6/8.13.6) with ESMTP id k6BK7r1b074403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Jul 2006 15:07:54 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <44B40517.3060709@nostrum.com> Date: Tue, 11 Jul 2006 16:07:51 -0400 From: Adam Roach User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Peter Saint-Andre Subject: Re: Fw: [Simple] "last call" on SIMPLE-XMPP interworking I-D References: <44AE872E.3080902@nostrum.com> <44B31B7C.1050506@jabber.org> <44B3EA74.1040104@nostrum.com> <44B3F501.7060104@jabber.org> <44B3FB6A.70502@estacado.net> <44B40034.2030400@jabber.org> In-Reply-To: <44B40034.2030400@jabber.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 132.219.24.178 is authenticated by a trusted mechanism) X-Spam-Score: -2.6 (--) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Avshalom Houri , xmppwg@jabber.org, Adam Roach , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Peter Saint-Andre wrote: > Would you prefer it to be a (1) a MUST or (2) a SHOULD with a proviso in > all caps saying that if you decide to be nice to XMPP clients at the > deployment level then you open up a possible amplification attack (see > the security considerations) and be aware that SIP presence servers > might not refuse to talk with you blah blah blah? > I would be surprised if (2) has any chance of passing IESG muster. Personally, I'm uncomfortable with (2), and see (1) as the only responsible path forward. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From admin@001f.com Wed Jul 12 01:03:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0WsO-0007V7-0A for simple-archive@lists.ietf.org; Wed, 12 Jul 2006 01:03:08 -0400 Received: from [220.75.62.115] (helo=samsung-mbrdr91) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0WsL-0006II-V5 for simple-archive@lists.ietf.org; Wed, 12 Jul 2006 01:03:07 -0400 Date: Wed, 12 Jul 2006 05:03:06 -0540 From: "Elva Whitehead" X-Mailer: The Bat! (v3.0.1 RC7) Home Reply-To: "Elva Whitehead" X-Priority: 3 (Normal) Message-ID: <57030478.20060712050306@001f.com> To: simple-archive@lists.ietf.org Subject: Z5K MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 move around. There it was, the pussycat, shiny new and clean, the copper Break the chains of your thought, and you break the chains of your body, hankies and an orchestra. and one day they will see what you see. Forgive them, and help them to From simple-bounces@ietf.org Wed Jul 12 02:52:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0YZn-0004mE-8C; Wed, 12 Jul 2006 02:52:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0YZl-0004m4-Ry for simple@ietf.org; Wed, 12 Jul 2006 02:52:01 -0400 Received: from datnt07.tieto.com ([194.110.47.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0YZj-0008C1-6K for simple@ietf.org; Wed, 12 Jul 2006 02:52:01 -0400 Received: from camaro.eu.tieto.com ([192.176.143.43]) by datnt07.tieto.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Jul 2006 09:51:28 +0300 Received: from carrera.eu.tieto.com ([192.176.158.112]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Jul 2006 08:51:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] "last call" on SIMPLE-XMPP interworking I-D Date: Wed, 12 Jul 2006 08:51:51 +0200 Message-ID: <3ACC9A25264A684F82C71840111F979801E39AC0@carrera.eu.tieto.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] "last call" on SIMPLE-XMPP interworking I-D Thread-Index: AcagnfoZARFE6kMSREmrxdErTtncRwE4Iywg From: To: , X-OriginalArrivalTime: 12 Jul 2006 06:51:54.0752 (UTC) FILETIME=[A95D2000:01C6A57F] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: xmppwg@jabber.org, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hello,=20 I have one question not directly related to the interworking, but to one comment from Adam: >3. Subscription Permission Indication > > The receipt of a 200-class response to a SUBSCRIBE message means > that the SUBSCRIBE message has been received. It does not mean that > permission to subscribe to the resource has been granted. The only > way to know that permission to subscribe to the resource has been > granted is the receipt of a NOTIFY message with a > "Subscription-State:" header field of "active". >From rfc3265, 3.1.6.1 Initial SUBSCRIBE Transaction Processing: ... If the notifier is able to immediately determine that it understands the event package, that the authenticated subscriber is authorized to subscribe, and that there are no other barriers to creating the subscription, it creates the subscription and a dialog (if necessary), and returns a "200 OK" response (unless doing so would reveal authorization policy in an undesirable fashion; see section 5.2.). If the notifier cannot immediately create the subscription (e.g., it needs to wait for user input for authorization, or is acting for another node which is not currently reachable), or wishes to mask authorization policy, it will return a "202 Accepted" response. This response indicates that the request has been received and understood, but does not necessarily imply that the subscription has been authorized yet. ... >From the above, it seems to me that 200 OK to SUBSCIBE means that the permission has been granted. Or am I wrong? Thanks,=20 Silvestr Peknik TietoEnator _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From 64h28g5o@mail.ru Wed Jul 12 14:33:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0jWf-0006rD-1E for simple-archive@lists.ietf.org; Wed, 12 Jul 2006 14:33:33 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0jV4-0001ck-FE for simple-archive@lists.ietf.org; Wed, 12 Jul 2006 14:31:55 -0400 Received: from [196.207.251.79] (helo=mail.0451.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G0jJb-00007p-9v for simple-archive@lists.ietf.org; Wed, 12 Jul 2006 14:20:03 -0400 Message-ID: <662161c806046yy29wmfg2t4s1i3rmxnvmcmh4qv1vj1@mxs.mail.ru> Date: Wed, 12 Jul 2006 18:20:08 -0060 From: "Joanna Beltran" To: simple-archive@lists.ietf.org Subject: NMH MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam: Not detected X-Spam-Score: 2.0 (++) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 I didn't understand what was happening to me, but I just couldn't make stable of science fiction talent ever seen, he would throw out challenges to showed them to another sergeant, who handed us special outfits. Now they are schoolboy, that a college student published the coordinates, but that for From simple-bounces@ietf.org Wed Jul 12 14:58:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0juX-0004mY-VW; Wed, 12 Jul 2006 14:58:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0juX-0004im-13 for simple@ietf.org; Wed, 12 Jul 2006 14:58:13 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0g5o-0000aL-EM for simple@ietf.org; Wed, 12 Jul 2006 10:53:36 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G0fuj-0005rH-Vj for simple@ietf.org; Wed, 12 Jul 2006 10:42:11 -0400 Received: from [132.219.16.186] (h10ba-net84db.lab.risq.net [132.219.16.186] (may be forged)) (authenticated bits=0) by nostrum.com (8.13.6/8.13.6) with ESMTP id k6CEg2ox051432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Jul 2006 09:42:04 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <44B50A38.7040307@nostrum.com> Date: Wed, 12 Jul 2006 10:42:00 -0400 From: Adam Roach User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Silvestr.Peknik@tietoenator.com Subject: SUBSCRIBE Responses (was Re: [Simple] "last call" on SIMPLE-XMPP interworking I-D) References: <3ACC9A25264A684F82C71840111F979801E39AC0@carrera.eu.tieto.com> In-Reply-To: <3ACC9A25264A684F82C71840111F979801E39AC0@carrera.eu.tieto.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 132.219.16.186 is authenticated by a trusted mechanism) X-Spam-Score: -2.6 (--) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Silvestr.Peknik@tietoenator.com wrote: > Hello, > > I have one question not directly related to the interworking, but to one > comment from Adam: > > >> 3. Subscription Permission Indication >> >> The receipt of a 200-class response to a SUBSCRIBE message means >> that the SUBSCRIBE message has been received. It does not mean that >> permission to subscribe to the resource has been granted. The only >> way to know that permission to subscribe to the resource has been >> granted is the receipt of a NOTIFY message with a >> "Subscription-State:" header field of "active". >> > > >From rfc3265, 3.1.6.1 Initial SUBSCRIBE Transaction Processing: > ... > If the notifier is able to immediately determine that it understands > the event package, that the authenticated subscriber is authorized to > subscribe, and that there are no other barriers to creating the > subscription, it creates the subscription and a dialog (if > necessary), and returns a "200 OK" response (unless doing so would > reveal authorization policy in an undesirable fashion; see section > 5.2.). > > If the notifier cannot immediately create the subscription (e.g., it > needs to wait for user input for authorization, or is acting for > another node which is not currently reachable), or wishes to mask > authorization policy, it will return a "202 Accepted" response. This > response indicates that the request has been received and understood, > but does not necessarily imply that the subscription has been > authorized yet. > ... > > >From the above, it seems to me that 200 OK to SUBSCIBE means that the > permission has been granted. Or am I wrong? > You are correct. A 200 response, as specified, generally should indicate that permission has been granted. That cannot be inferred from all 200-class responses. Some confusion has arisen in the time since 3265 was published regarding handling of 200-class responses that are neither 200 nor 202. Per 3261, these should be treated at 200s; however, this can't always be a valid assumption. In practice, I've noted that many, many implementations get the 200/202 distinction wrong. On the other hand, it's *always* safe to assume an active subscription upon receipt of a NOTIFY with an active subscription state. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 12 16:08:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0l0E-0000i9-0x; Wed, 12 Jul 2006 16:08:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0l01-0008KS-0u; Wed, 12 Jul 2006 16:07:57 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0kzz-0002Qh-PB; Wed, 12 Jul 2006 16:07:56 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k6CJo2QC030767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Jul 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G0kig-0000vJ-7W; Wed, 12 Jul 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 12 Jul 2006 15:50:02 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-message-sessions-15.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 : The Message Session Relay Protocol Author(s) : B. Campbell, et al. Filename : draft-ietf-simple-message-sessions-15.txt Pages : 59 Date : 2006-7-12 This document describes the Message Session Relay Protocol, a protocol for transmitting a series of related instant messages in the context of a session. Message sessions are treated like any other media stream when set up via a rendezvous or session creation protocol such as the Session Initiation Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-message-sessions-15.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-message-sessions-15.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-message-sessions-15.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-7-12112357.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-message-sessions-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-message-sessions-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-7-12112357.I-D@ietf.org> --OtherAccess-- --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://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Thu Jul 13 09:22:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G118j-0005bM-EE; Thu, 13 Jul 2006 09:22:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G118i-0005bC-2u for simple@ietf.org; Thu, 13 Jul 2006 09:22:00 -0400 Received: from [2001:5c0:8fff:fffe::4c49] (helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G118e-0003j1-Fw for simple@ietf.org; Thu, 13 Jul 2006 09:22:00 -0400 Received: from [132.219.30.170] (h1eaa-net84db.lab.risq.net [132.219.30.170] (may be forged)) (authenticated bits=0) by nostrum.com (8.13.6/8.13.6) with ESMTP id k6DD6TR0042496 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 13 Jul 2006 08:06:41 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <44B50A38.7040307@nostrum.com> References: <3ACC9A25264A684F82C71840111F979801E39AC0@carrera.eu.tieto.com> <44B50A38.7040307@nostrum.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: SUBSCRIBE Responses (was Re: [Simple] "last call" on SIMPLE-XMPP interworking I-D) Date: Thu, 13 Jul 2006 09:06:14 -0400 To: Adam Roach X-Mailer: Apple Mail (2.752.2) Received-SPF: pass (nostrum.com: 132.219.30.170 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org > > You are correct. A 200 response, as specified, generally should > indicate that permission has been granted. That cannot be inferred > from all 200-class responses. Some confusion has arisen in the time > since 3265 was published regarding handling of 200-class responses > that are neither 200 nor 202. Per 3261, these should be treated at > 200s; however, this can't always be a valid assumption. > > In practice, I've noted that many, many implementations get the > 200/202 distinction wrong. > > On the other hand, it's *always* safe to assume an active > subscription upon receipt of a NOTIFY with an active subscription > state. To reinforce this: Using the initial notify is always safer - to the point that I would gladly accept deprecation of 202 and go back to just 200. 1) If you fork, you're only going to get one of the branches' 2xx back. You'll have to look at the NOTIFYs anyhow to know which legs are active 2) The initial notify(s) are quite likely to beat the 2xx to the subscribe back anyhow. RjS > /a > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 13 11:09:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12oi-0004mh-Of; Thu, 13 Jul 2006 11:09:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12oc-0004Qk-3R for simple@ietf.org; Thu, 13 Jul 2006 11:09:22 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G12gi-0008Ag-4B for simple@ietf.org; Thu, 13 Jul 2006 11:01:14 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 61A546E0002 for ; Thu, 13 Jul 2006 17:01:09 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Jul 2006 17:01:08 +0200 Received: from eseldmw101.eemea.ericsson.se ([136.225.228.103]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Jul 2006 17:01:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: [Simple] continuation of draft-ietf-simple-pres-policy-caps-01 & draft-ietf-simple-common-policy-caps-01 Date: Thu, 13 Jul 2006 17:01:07 +0200 Message-ID: <61D8D34BB13CFE408D154529C120E07936B28C@eseldmw101.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] continuation of draft-ietf-simple-pres-policy-caps-01 & draft-ietf-simple-common-policy-caps-01 Thread-Index: AcalJA69U6ZIffEURPG1bKHZqId6SAAAuKswAFjXZWA= From: "Atle Monrad \(GR/ETO\)" To: X-OriginalArrivalTime: 13 Jul 2006 15:01:08.0950 (UTC) FILETIME=[2C3E0760:01C6A68D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hello The conclusion on the drafts draft-ietf-simple-pres-policy-caps-01 and draft-ietf-simple-common-policy-caps-01 discussed at the SIMPLE session on Tuesday was not completely clear to me. >From a 3gpp point of view, it is my opinion that these drafts can be discontinued. I am not aware of any particular requirements that makes these drafts needed. On the contrary, I think it would be beneficial to get the specifications ready and get some deployment experience without having too complicated mechanisms. If these drafts are terminated, I am confident that we can do our part in 3gpp aswell by removing any reference to the drafts.=20 IMHO, please don't use the fact that the drafts are currently referenced by 3gpp as a reason to continute the work. /atle Atle Monrad Business Unit Mobile Platforms Ericsson Norway ETO/GR/TG Phone: +47 372 93 040 Mobile: +47 454 10 665 Mail: atle.monrad@ericsson.com Web: www.ericsson.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 14 07:35:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Lwo-0003mZ-1H; Fri, 14 Jul 2006 07:35:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Lwm-0003mR-Mh for simple@ietf.org; Fri, 14 Jul 2006 07:35:04 -0400 Received: from datnt07.tieto.com ([194.110.47.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1Lwl-0001rQ-0T for simple@ietf.org; Fri, 14 Jul 2006 07:35:04 -0400 Received: from camaro.eu.tieto.com ([192.176.143.43]) by datnt07.tieto.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Jul 2006 14:34:34 +0300 Received: from carrera.eu.tieto.com ([192.176.158.112]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Jul 2006 13:35:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Jul 2006 13:34:56 +0200 Message-ID: <3ACC9A25264A684F82C71840111F979801E77A02@carrera.eu.tieto.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: presence event package - generation of notify requests Thread-Index: AcanOYhGX7xZxftpQqerMt2KirjLmg== From: To: X-OriginalArrivalTime: 14 Jul 2006 11:35:00.0686 (UTC) FILETIME=[8A9876E0:01C6A739] X-Spam-Score: 0.2 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Roman.Bosak@tietoenator.com Subject: [Simple] presence event package - generation of notify requests X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hello,=20 I would like to get some clarification about notifications. In RFC3856 par. 6.7. Notifier Generation of NOTIFY Requests ... A PA MAY send a NOTIFY at any time. Typically, it will send one when the state of the presentity changes. The NOTIFY request MAY contain a body indicating the state of the presentity. The times at which the NOTIFY is sent for a particular subscriber, and the contents of the body within that notification, are subject to any rules specified by the authorization policy that governs the subscription. ... If PA does not deliver the notification at all, is it still valid behavior?=20 The situation I have in mind:=20 There is rate control mechanism and then filtering mechanism on the PA (rate control is applied first due to implementation decision). A resource is subscribed. The state of the resource changes quickly from A to B (notification N1 is generated) and then back to A (N2). Lets say that N1 is caught by rate control. N2 arrives and replaces N1 in the rate control. N2 is passed to filtering and is discarded because the client is not interested in changes from B to A (but it is interested in changes from A to B).=20 In my opinion this behavior is not valid because the subscriber can miss the information it seeks, but the specification is not very specific on this. What is your opinion? Thank you Silvestr Peknik Software Specialist TietoEnator _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 14 17:00:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Um7-00038t-9d; Fri, 14 Jul 2006 17:00:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Um5-00038E-OF; Fri, 14 Jul 2006 17:00:37 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1Tsh-00048T-6S; Fri, 14 Jul 2006 16:03:23 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=willow.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G1Tfm-0003NT-2z; Fri, 14 Jul 2006 15:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k6EJo1QC032701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 14 Jul 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G1Tfl-0000AZ-F0; Fri, 14 Jul 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 14 Jul 2006 15:50:01 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-msrp-relays-08.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 : Relay Extensions for the Message Sessions Relay Protocol (MSRP) Author(s) : C. Jennings, et al. Filename : draft-ietf-simple-msrp-relays-08.txt Pages : 35 Date : 2006-7-14 Two separate models for conveying instant messages have been defined. Page-mode messages stand alone and are not part of a SIP (Session Initiation Protocol) session, whereas Session-mode messages are set up as part of a session using the SIP protocol. MSRP (Message Session Relay Protocol) is a protocol for near real-time, peer-to- peer exchanges of binary content without intermediaries, which is designed to be signaled using a separate rendezvous protocol such as SIP. This document introduces the notion of message relay intermediaries to MSRP and describes the extensions necessary to use them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-msrp-relays-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-msrp-relays-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-msrp-relays-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-7-14135721.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-msrp-relays-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-msrp-relays-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-7-14135721.I-D@ietf.org> --OtherAccess-- --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://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Fri Jul 14 22:26:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Zr8-0004H5-Rj; Fri, 14 Jul 2006 22:26:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Zr6-0004GL-Cx for simple@ietf.org; Fri, 14 Jul 2006 22:26:08 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1Zbd-0005ZN-Pu for simple@ietf.org; Fri, 14 Jul 2006 22:10:12 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 14 Jul 2006 19:10:09 -0700 X-IronPort-AV: i="4.06,245,1149490800"; d="scan'208"; a="1838816721:sNHT28675768" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6F2A6pH031563; Fri, 14 Jul 2006 19:10:06 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k6F2A5HS004549; Fri, 14 Jul 2006 19:10:06 -0700 (PDT) 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); Fri, 14 Jul 2006 22:10:05 -0400 Received: from [192.168.1.100] ([10.86.243.31]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Jul 2006 22:10:05 -0400 Message-ID: <44B84E7C.2050704@cisco.com> Date: Fri, 14 Jul 2006 22:10:04 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Atle Monrad (GR/ETO)" Subject: Re: [Simple] continuation of draft-ietf-simple-pres-policy-caps-01 & draft-ietf-simple-common-policy-caps-01 References: <61D8D34BB13CFE408D154529C120E07936B28C@eseldmw101.eemea.ericsson.se> In-Reply-To: <61D8D34BB13CFE408D154529C120E07936B28C@eseldmw101.eemea.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jul 2006 02:10:05.0391 (UTC) FILETIME=[C9D6A5F0:01C6A7B3] DKIM-Signature: a=rsa-sha1; q=dns; l=1611; t=1152929406; x=1153793406; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Simple]=20continuation=20of=20draft-ietf-simple-pres-policy-cap s-01=0A=20&=09draft-ietf-simple-common-policy-caps-01; X=v=3Dcisco.com=3B=20h=3DPLZq1GQv93cYayuNL1O3Sj5eZw8=3D; b=lxLl4BF+/HEc3F4Sqv9/uLw6ErXy3WOvuW1JEgN3rvprVKME+BaxS3zWgOZ5+zDqhzRDldwl t9MyJlw+QjCWq54IzFRu7v0HQ7fad+cJmenMYlfjBDhz2xwKC0x9qx5Q; Authentication-Results: sj-dkim-6.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org I think the conclusion was in fact to not continue them. -Jonathan R. Atle Monrad (GR/ETO) wrote: > Hello > > The conclusion on the drafts draft-ietf-simple-pres-policy-caps-01 and > draft-ietf-simple-common-policy-caps-01 discussed at the SIMPLE session > on Tuesday was not completely clear to me. > >>From a 3gpp point of view, it is my opinion that these drafts can be > discontinued. I am not aware of any particular requirements that makes > these drafts needed. On the contrary, I think it would be beneficial to > get the specifications ready and get some deployment experience without > having too complicated mechanisms. > > If these drafts are terminated, I am confident that we can do our part > in 3gpp aswell by removing any reference to the drafts. > > IMHO, please don't use the fact that the drafts are currently referenced > by 3gpp as a reason to continute the work. > > /atle > > > > Atle Monrad > Business Unit Mobile Platforms > > Ericsson Norway > ETO/GR/TG > Phone: +47 372 93 040 > Mobile: +47 454 10 665 > Mail: atle.monrad@ericsson.com > Web: www.ericsson.com > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Jul 15 19:26:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1tX5-0007s6-Hf; Sat, 15 Jul 2006 19:26:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1tX4-0007s1-3R for simple@ietf.org; Sat, 15 Jul 2006 19:26:46 -0400 Received: from [2001:5c0:8fff:fffe::4c49] (helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1tX0-00046k-Tz for simple@ietf.org; Sat, 15 Jul 2006 19:26:46 -0400 Received: from [192.168.1.102] (cpe-66-25-19-139.houston.res.rr.com [66.25.19.139]) (authenticated bits=0) by nostrum.com (8.13.6/8.13.6) with ESMTP id k6FNQcPS076934 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Sat, 15 Jul 2006 18:26:39 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <0CA26A2B-02A6-45CF-B4BA-AF6916C253E3@nostrum.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: simple@ietf.org From: Robert Sparks Date: Sat, 15 Jul 2006 19:26:38 -0400 X-Mailer: Apple Mail (2.752.2) Received-SPF: pass (nostrum.com: 66.25.19.139 is authenticated by a trusted mechanism) X-Spam-Score: 1.8 (+) X-Scan-Signature: 8ea98b4531a0f62d9b5bec3f8f731859 Subject: [Simple] Draft minutes: SIMPLE at IETF66 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Please reply with any edits/corrections/needed clarifications to these minutes ASAP. Thanks, RjS ---------- IETF66 - SIMPLE - Minutes 11Jul2006 - Tuesday Afternoon II Summary: - Report: Publication has been requested for patch-ops and presence-rules. Revised documents have been requested for prescaps-ext and the partial-* documents before requesting their publication. - There was consensus in the room to abandon the effort to standardize composition at this time. We will verify that any dangling dependencies this creates in other SDOs can be rectified. We will capture what we do know about composition as part of the annotated overview work. - There was consensus in the room to not pursue the presence policy capabilities work at this time. - Aki's "chat" draft has been simplified based on feedback from IETF65. The list will be polled for whether to pick up work as described in the current document after this meeting. - The IMDN draft is very close to last-callable. Please review it if you have not already done so. - The room showed interest in refining the presence scaling and performance analysis document targeting an Informational RFC - The remaining milestones in the proposed new charter text were reveiwed and several were deleted (based on the above decisions). The xcap-package milestone currently remains but may turn into a hand-off to SIPPING as part of the config-framework. - Feedback is requested on draft-garcia-simple-presence-dictionary and draft-saintandre-xmpp-simple ---------------------------------------- RAW NOTES: DEAN WILLIS ---------------------------------------- SIMPLE Session 1 July 11,2006 Chairs: Robert Sparks, Hisham Khartabil Recorded by: Dean Willis Topic: Agenda and Status by Chairs Slides presented: http://www3.ietf.org/proceedings/06jul/slides/simple-0.ppt Agenda reviewed and accepted Chairs request review of simple-chat and draft-garcia-simple-presence. Topic: Presence Policy Capabilities by Jonathan Rosenberg Slides presented: http://www3.ietf.org/proceedings/06jul/slides/simple-0.ppt Documented reviewed by author using slides. Noted by HGS: Overall SIMPLE system is far from simple. We should look at each item, especially those for which we have no deployment experience, and ask if the complexity added outweighs the benefits, or if there might be harm or the encouragement of a non-compliant implementation on the server side. The proposed approach may be over this threshold. Response: it is clear that some vendors will want to do their own authorization policies. This is however an interesting point for discussion. Question: It seems that separation of the web app from the presence server might be able to eliminate any special extension requirements, but that is debatable. Noted that the common policy documents have some extension capability, but it might not be implemented in a useful (or the right way). Poll: Would you implement this? (only a few). Noted: We need to come up with a common starting point here. If we don't, we'll degenerate to the least common denominator of OMA or other profiles. Noted: There's a lot of complexity in the user interface to deal with variations in capabilities. Noted: One point in this design was to eliminate dependence on specific vendor implementations. We need the ability to convey something that goes beyond the base presence document that we have today. Counterproposal: new presence rule sets could be put in separate namespaces Poll by chairs: If you feel there is a compelling need to pursue and standardize this mechanism now: Strongly opposed. Possible problem: Do any other SDOs refer to this thing? We need to follow up on list and via liaison to verify this. Topic: Presence Processing Model and Composition by Jonathan Rosenberg Slides presented: http://www3.ietf.org/proceedings/06jul/slides/simple-2.ppt Problem statement reviewed. Proposed that we don't really need this right now. Comment: Two problems people report with SIMPLE are: 1) Too much bandwidth consumed, 2) Don't know how to do composition. But we don't really know what we need to do about this yet. Comment: Interoperability is an industrywide issue that has to be resolved sometime. Comment: OMA has gone ahead with a declaration that they need normative composition policy. We need some kind of statement about this. Response: In the absence of use cases, how do they know they need it? Comment: We already have an example here. We either really care which way the composition works, in which case we should spec it, or not? Response: I've always viewed that there should be a great deal of flexibility in the way that composition might be done. Do we need a spec that says "This is exactly how composition works" or should we wait and see a couple of working approaches before we standardize it? Comment: We've done too few "overview" documents that give people a clear sense of how pieces fit together. This document has a lot of information that is useful here. Perhaps we could mine stuff out of here and put it into the architecture document. But we probably do NOT need an RFC that specifies a fixed processing model. Comment: this is the document beyond which people need to start thinking. Chair comment: We will mine this thing for useful material but not pursue normative descriptions from this document. Report back: 3GPP references processing model and composition. Topic: Composition led by Henning Schulzrinne Slides presented http://www3.ietf.org/proceedings/06jul/slides/simple-3.ppt Problem background reviewed. Discussion: This is a good thing to figure out, but we don't have a current need in the industry to do this. We should simply allow vendors to figure out their own composition policies. Proposed that we put this aside along with the presence processing model. Noted that all the commercial things have very simple composition policies today. Conclusion: academic work may continue, but SIMPLE will not address. Off-agenda process sidebar Process commentary: We seem to be changing our model to "has market need" vs "is interesting and useful". For example, do we want to delay work on SPIT until somebody asks for it? Or are we just in a document-shooting mood? AD response: Let's not go out of our way to find new work. Comment: There are some things, like SPIT, where we want to plan ahead. Other things we need to wait until we understand the problem before attacking it. Topic: SIMPLE Advanced IM Requirements Slides presented: http://www3.ietf.org/proceedings/06jul/slides/simple-4.ppt led by Markus Isomaki Open question: Are there any things beyond the four ideas described in the slides, that we want to work on? Four open issues related to IMDN given, and one open issue on SIP MESSAGE max-size. Discussion on message size ensued. It may be easier to send a message in the reverse direction saying "your message was too large" than to develop an automable response. Chair comment: This document is a scratchpad to help us keep from forgetting stuff. We don't intend to publish it. Question: Are there any other SDOs that we need to check with as we wrap up? Noted that the work of niemi-simple-chat is still needed by OMA, even though it's now in XCON. Topic: IMDN by Hisham Khartabil Slides presented http://www3.ietf.org/proceedings/06jul/slides/simple-5.ppt Question: Are you describing exactly when one sends or does not send IMDN, or is it left to server choice. (there's a SHOULD in the doc). Repsonse: it's usage, not implementation. Requested that this be clarified as to its guidance. Question: Should there be a message ID in the delivery report? Discussion indicated that it should be included, because somebody might care. Open Issue 1: use of "require" mechanism to require rejection of message if IMDN not supported? Consensus to withdraw this requirement. Open Issue 2: Readdressing of requests in forwarding. Does this break end-to-end encryption? Noted that if it were encrypted, the intermediary can either read the message and pass it on, or not read it at all and cannot process it. Of course, it could be signed, which would probably break and needs list discussion. This also needs careful security review. Question: What is the expectation for notifications sent to a list? Do we get an IMDN for each recipient, or just one for the aggregator? Response that that's in the list aggregator stuff, and is outside the scope of this draft. Topic: Interdomain Scaling Problem by Avshalom Houri Slides presented: http://www3.ietf.org/proceedings/06jul/slides/simple-6.ppt Question: Is this verbosity unavoidable? Also, are there other models, used by other systems, that are substantially more efficient? For example, we have subscription refresh traffic that others might not. Also, is it useful that we have hundreds of watchees per user? So what are underlying casues versus operational assumptions? Comment: This is great work. We probably need to consider "how much better could we do" as a next step. It should be possible to produce a best- case model. This should account for things like shared views. We should keep working on this, model the mechanisms, and move forward. Comment: we need more analysis before requirements. That said, would like to assure that we cover privacy and security explicitly in the work. Question: do we have real numbers on watchers and watchees? There are probably real world cases with lots. One such case (DoD) was pointed out. Topic: Interdomain Practices by Avshalom Houris Slides presented: http://www3.ietf.org/proceedings/06jul/slides/simple-7.ppt Responses requested: Doe we need to publish this as a BCP? IS this the right info? Anybody else want to contribute? Comment: This seems to be worth doing. It would be good to get additional operational experience. Question: Do you issue this right away, or wait until there are specs to fold in? Topic: XMPP-SIMPLE Interworking Review requested by chairs. Topic: Rechartering by chairs slides presented Comment: xcap and config are definitely swirled up. August is not achievable. Also need to delete advanced messaging requirements and need to talk about changing working groups on some drafts. Presence composition milestone can also be deleted. Comment: Can we possibly conclude on optimization and scalability issues by July 2007? Does that work happen here or elsewhere? There may be items that come out of the discussion with SPEERMINT that we need to account for in our milestones. Discussion of milestones continued. There does seem to be interest in the optimization/scaling problem statement draft. Proposed: take the optimization document on with the intent to produce an informational document. Poll: If you think we should expend WG cycles refining the optimization problem statement document into an informational RFC that would be refined by SIMPLE: Noted mild positive response. ---------------------------------------- RAW NOTES: BRIAN STUCKER ---------------------------------------- SIMPLE Agenda Bash Intro/Administrivia/Agenda Bashing * Updates : getting closer to being done, lots in the RFC Editor's Queue. * Draft-niemi-simple-chat-05 o All controversial issues removed o Adopt as a WG item? o Will be asking on the list if this is something to pursue as a group. People need to read it and get opinionated. * Draft-garcia-simple-presence-dictionary-00 o Sigcomp dictionary for presence. o Needed by OMA o If interested in it, email miguel.an.garcia@nokia.com Policy caps Johnathan Rosenberg * Problem Statement: o Possible variation across providers in sets of authorization policies that are available. + Subsets of what is defined in presence-rules + Provider-proprietary "macros" like "high privacy" and "low privacy" o Assumption that clients create authorization documents and upload them to the server. o So- how does client know what kind of authorization policies can be placed in its document? * Basic approach o Common Policy Capabilities + Defines a policy capabilities document mirroring common policy. + , , and , , o Presence Policy Capabilites + Declarations for support for each? o Do we need this? + Not needed if # Clients use web applications or any servier- side applications to generate authorization policies # Clients are matched to a particular provider and are hard coded with their capabilities # Client/Server interfaces remain proprietary for control of authorization policies + (Discussion at Microphone) # Henning Schulzrenne: Concern is that overall simple system is far from simple. We should look at any particular item and see that given we have no deployment experience, to see if thigns we add are adding complexity or harm versus help. * Increases complexity.. now have to deal with combinations. * Encourages non compliant implementations at the server. * Both seem like things we don't want to do. * When we did the implementation, the student working on it has not complained that any one of these tags is so much harder than others. * At a loss as to if this is simply implementation laziness rather than policy. * If we want to do policy then we should only do thigns we're worried about. # Jonathan Rosenberg: * There is an issue if there are totally proprietary extensions from the server. * I want to get rid of this, I think they're more complicated than they are worth. * It is fair to say that there are places that will want to do their own authentication policy. * Counter-argument if you have a non compliant server, just match it with a non-compliant client. # Hannes: * Common policy framework. * If the client uses web applications to do authorization then we don't need this. # Jonathan Rosenberg: Not true. It's still needed. # Hannes: * If we extend existing documents with new capabilities, that doesn't mean that current documents are wrong. * In common policy, it's not possible to omit certain tags. # Jonathan Rosenberg: Poll of the room, raise your hand if you already have a SIMPLE implementation. (few hands) # Eric: * If we don't come up with a common starting point, then other standards orgs will. * Doesn't matter if you're customizing with a service provide if you don't have a general framework. # Jonathan Rosenberg: How does the client use the information it gets in XML for authorization, not clear. # Henning: * If I spend a lot of time trying to build a client that does common policy, and someone comes along and rips a bunch out of the XML, then I've wasted my time. * Discourage random subset implementations (RFC minus tags I didn't like). * Have the ability to convey something that goes beyond base documents, and then we can talk about the model we want. # Jonathan Rosenberg: * Counter-proposal: If you're not worried about implementing a subset, then put those elements in a separate namespace if it's supported. * (Henning agrees) # Robert Sparks (Chair) * Hum vote: o If you feel there is a compelling need to pursue and standardize this right now, then hum: (Result: NO HUM) o If you believe that we should not take this on right now, then hum: (Result: LOUD HUM) # Keith Drage: * You can't take it off the charter, it's already on the charter. * 3GPP at one point did refer to these items. # Robert Sparks (Chair): We'll take it to the list to make sure no one is left in a lurch. Presence-processing * Problem Statement o No agreement yet on + How composition on privacy filterin relate + Wht it means to do composition + How to override presence data + How to set various fields in a PUBLISH request o Solution: + Define a presence server processing model * Basic Content o Client Processing + Reporting + Over-riding o Presence server processing + Subscription processing + Document processing # Collection # Composition # Privacy filtering # Watcher filtering # Post-processing composition o (Do you combine tuples if they wind up looking the same after an operation is taken upon them, etc.) * Issues Yet to address o What is presence federation o Derivation of presence from non-presence sources + Registration states + Dialog states o How lying and polite blocking are modeled and controlled o Union compositor concept o Pres vs. SIP URI o Telephony features impacting presence states * Questions o Do we need this? o Is this higher or lower priority than other work? o Is there an implementation problem that's not covered yet? o There's problems that are more important, it's a theoretical problems. + Markus: There's not enough understanding as to what needs to be done here. I don't think we should do this right now because we have no requirements. + Avshalom Hauri: # There is value in this as an informational item. + Keith Drage: # We need a statement around if things are being done wrong currently before we try to correct it. + Jonathan Rosenberg: # If OMA needs a statement on how this should work, then maybe they're too premature to spec it out as well. + Paul Kyzviat: # The composition policy that Henning was talking about is not consistent with the model (it's not per subscriber). # Either this is useful now, or it's not useful because we have a real practical implementation. # We can go either way, so we need to make some decisions about how we care about composition being done. + Jonathan Rosenberg: # Fallout is that you might want to specify a composition language. # Do we need a spec to allow developers to build a compositor without having to think. + Henning: # Is the document something like that useful? # Is it more useful to expand on some items on the previous slide? # Are we oversubscribed? # It's hard for new people to get a sense around how this all works, which makes this document useful as a good way to see how everything works. Informational, not normative. + Robert Sparks (Chair): Are there elements that we can mine out of this that are useful. + Henning: # There are different points of the complexity spectrum that different people will implement, so there's no one way to do it. Don't try to be overly prescriptive. + Jonathan Rosenberg: # Once you bring it in, then it brings work. + Henning: # Don't do controversial bits, just do the parts that are already resolved. + Jonathan Rosenberg: # It's a fair bit of work. + Hisham (at microphone): # In my opinion this is a trial and error thing to do with code to figure out what we need. We need implementation experience to figure out what we need to focus upon. + Jonathan Rosenberg: # There are some market requirements behind this that I think are potentially valuable. + Keith Drage: # What we need is a document that says this is what you need to start thinking about, that they can't just go blindly implementing things. + Jonathan Rosenberg: # The market will weed out stupid implementations that have no value. + Robert Sparks (Chair): # Find the things that are useful (likely a small amount of text). # If we find tidbits that are useful as a future warning, then put it into a draft. # Don't have enough real-world experience to do protocol element work. # The essence is that we're mine this thing for issues that we can use in a Hitchhiker's Guide type material to be captured. # We're not going to let it all fall through the cracks so it actually guides the implementers away from land- mines we've already identified. When we know what our future issues are, update it then. + Cullen Jennings: # HHG is an annotated history of how we got here. + Robert Sparks (Chair): # We need something that ties everything together, but less than an architecture document. + Andrew Allen # 3GPP does refer to policy caps as a shell, they're only desirable and not critical path. Composing Presence Information * Motivation for Composition o Different sources of information that need to be merged that's not just a union. + Remove stale information + Remove contradictory info + Remove redundant info + Generate new, inferred presence information + Represent information in a useful way * Steps of Composition o Discarding stale and redundant info o Derivation of new presence info o Remove any conflicts o Merge tuples * Discarding o Clsoed contacts o Old contacts o Unreferenced * Deriving presence info * Provide additional information o Device may not support certain extension and so cannot publish that information o Users may not always express presence info manually, and there are many assocaitioans that can be auomatically made o Uasge examples: on the phone, driving, etc. * Derivation of presence * Static presence info o Example: my home pc is in a certain location - include location even though it isn't published by the PC o A rule can be defined for this: + devideID =.. =>content o Alternatively, use a static presence document. * Conflict resolution o Allows the compositor to remove inaccurate info o Must first detect information conflict, then choose how to resolve it o Usage exmpales: * Detecting infor conflict o Some info conflict can be easily detect + Place-is + Privact + Location ino o For other information, conflict is less clear + Activitiy could be on-the-phone away and appointment + Place-type could be outside and stadium * Big questions o User-specified rules or guidelines? o Per-presentity or per-watcher? + For rule language, per presentity seems sufficient # Establish "truth" + More complicated tailoring probably reuires a programming language. o JR: + I think this is a good thing. o Henning: + For now, recommendation is to do union composition? o JR: + No, vendors and providers will control composition logic. This is the current reality. + Put this proposal aside along with presence processing. o Cullen Jennings: + Compositors are pretty simple today. SIMPLE Advanced IM Requirements (Markus Isomaki) * Background and Purpose o The current draft is a revision of draft-rosenberg-simle- messagnig-requirements-01 o That draft drew requirements e.g. from draft-niemi- simple-im-iwreless-reqs-02, which tried to capture 3GPP/IMS related IM. * Scope of the requirements o IM disposition notifications o Is-composing o Conent capabilities o Page-mode groups o Multiparty MSRP related reqs (including "private" messaging, nicknames) currently missing. o Anything else SIMPLE should be working on related to IM? * Specific Open Issues Related to IMDN o IMDN and intermediaries o IMDN in session-mode messaging o REQ-DISNOT-11/12/13, REQ-COMP-14. * Open Issue related to SIP Message max-size indication o REQ-CONTENT-2: A 413 response MUST be capable of infication the max size. o (Microphone) + Henning: In practice I think we'll get two values for this # One is infinity. # The other is a lower value. + JR: SMS gateway + Henning: # Ok, agreed, SMS gateway is an example. # We use a set mechanism that is not specific to message. + Markus: # I don't think that's apropos with this proposal, someone else can deal with that. + JR: # What would an automata do with this? # Just send a message back in the opposite direction that says "Too big". # (JR/Henning agree) * Next Steps o Are we conering all the areas we should work on relate to IM capabilities. o Should we specifically ask input from OMA? o Resolve the IMDN related open issues in order to get the draft on the correct track. o Resolve the SIP MESSAGE maximum size issue o (Microphone) + Henning: I'm always for capturing requirements. Do we need an RFC or simply a WG consensus that we can use for a scratchpad. + Robert Sparks (Chair): It's a scratch pad. + Markus: Agree, scratchpad. + Robert Sparks (Chair): Go read this, and get opinionated on what we really need to take on. + Dean Willis: OMA wants SIMPLE chat. + Robert Sparks(Chair): They want things that have moved to XCON. IMDN (Hisham Khartabil/Eric Burger) * Changes o Combines two I-Ds. o IMDN- Instant Message Disposition Notification o Endpoints may send positive delivery notifications and should send negative delivery notifications if requested to. o (mic) + Henning: # Are you describing exactly when a server sends or not or is it implementation choice? # Getting frustrated as if these SHOULDs are operational or design guidelines? + Ben Campbell: # I think it went to a SHOULD was due to a lack of information, not optional implementation. o Status changed from sip style to strings "success" instead of "200". o Added really-from and really-to headers + Really-from indicates previous hop (intermediary) in order to send the IMDN + Really-from headers converted to Really-to headers in IMDNs. + Aggregation text was added. # People, please read it and give feedback. o Message-ID not mandated but needed if sender keeps state (sent items box) + If you don't keep state for the message you've sent then there's no point in getting a notification because you don't care. + IMDN is a message as well, so it needs Message-ID. + (mic) # Eric Burger: * Also realize that message-id which comes from the email world is for a lot of debugging, etc. * You may not care about message-id, but other intermediaries might. # Ben Campbell: * Message-ID is not there if IMDN is not requested. # Hisham: * Eric just convinced me message-id is needed in all messages and IMDNs when IMDNs are requested. * Open issues o Do we want to allow the sender to invoke the "required" mechanism to tell the recipient to please just reject the message if it does not support IMDN? + Hisham votes no. o Rejecting the IM based on this will reveal such private information abut the recipient to the sender. o Opinions? o (mic) + Ben Campbell: # I agree no for complexity reasons, and we get little value. + Eric Burger: # We can silently ignore it, or we don't mean requires when someone says require? + Ben Campbell: # Don't address it. # However, CPIM allows you to do it arbitrarily. Someone could construct it that way. I don't think we should suggest it though. + Eric/Hisham/Robert Sparks/Ben - It's out (agreed). o An intermediary that forwards an IM may change the recipient address in the CPIM to header field when forwarding (for example, aURI-List server change the recipient address from its own to the address of the final recipient of that message). In this case, the intermediary MUST add a CPIM original-to header to the CPIM message. o Is this a problem for end-to-end encryption? If so, how to go through GWs? + Ben Campbell: It's not a problem. + Miguel Garcia: Exploders already have the key, not a problem. + Aki Neimi: It could be signed. + Robert Sparks (Chair): Probably worth list discussion (around signing). Take it to the list. This is going to WGLC soon. o Hisham: I think these are solvable in the next couple of weeks so the charter is achievable. SIMPLE Problem Statement (Avshalom Houri) * Deployment experience of SIMPLE based systems shows scalability issues with respect to number of messages * Number of messages in several typical deployments * Two categories of optimizations were considered: o Dialog saving optimizations: event-list or uri-list that collapse number of subscriptions o Notification optimizations: subnot-etags by Aki Miemi which suppresses non necessary notifies. * Computation o Described in detail in the draft o Input parameters + Subscription lifetime + Presence state change/hour + Subscription refresh interval/hour + Total federated presentities per watcher + Number of dialogs per watcher (optimization dependent) + Number of watchers in each domain. * Widely distributed inter-domain mode. o Users of each domain are not usually subscribed to presence within the domain o For example small public servers o Numbers used o Subscription lifetime : 8 hours o Presence state changes per hour : 3 o Subscription is refreshed every hour o Total watched presentities : 20 o Number of watchers in each domain -20k o Number of dialogs per watcher : 20 (non-optimized), 1 (optimized) o Not optimized: 70.4M messages per hour, 2444/sec. o Optimized: 39.36M message per hour, 1300/sec. * Other models o Simple case : t wo domains connecting o Associated inter-domain : enterprise servers. Assuming it is the same as widely distributed inter-domain with respect to traffic between domains o Very large network peering : e.e. consumer IM networks. o Intra domain peering * Summary o The numbers presented are only between two domains, when more domains are connected the number of messages will be multiplied o Although current optimizations can reduce the traffic by up to 50%, the traffic is still very high o Conservative numbers were used, in real life numbers may be even higher. * Conclusions o Further work I SIMPLE WG is needed in order to have beeter optimizations o Initial set of requirement is included in the draft. + Linear scaling + Minimal state + Must be able to scale to millions of concurrent users + MUST support a very high level of watcher/ presentity intersections in various intersection models o (mic) + Henning: I don't think inter-domain is important. + Avshalom: You could do more optimizations in intra- domain. + Henning: # Is this unavoidable? # Are there other models other systems do that are more efficient? Others have hard state models, for instance. # Is the user model that we're going to have going to be linear and useful? : I think it does not. # Most information is not very interesting in the notifications. + JR: # I like the work and thank you for quantifying it. # Next step is to figure out how much better can we do than what we're doing today. # What is the best that is possible to do and how close do we get? # Shared information has the potential to reduce the amount of messaging. # Presence systems remain stubbornly proprietary. SIMPLE is good for inter-connect. # We should continue working on this. + Ben Campbell: # May need more analysis before talking about requirements. # Need to cover security and privacy. + Aki Neimi: # Should continue. + Miguel Garcia: # Presence dictionary should be part of the discussion. + Dean Willis: # DoD has requirements for thousands of watchers. * Purpose of this Draft o Provide a catalog of high-level BCPs derived from experience in operating large enterprise and consumer IM communities o Two categories of recommendations in this draft. + A recommended minimum profile for SIMPLE implementations to satisfy expectations of "real world" users. + Techniques that can assist in scalability. * Next Steps o Does the WG see utility in documenting this kind of information? o Is this the right information to cover? o Are there others with operational experience to contribute? o (mic) + Jon Peterson (as participant); # I think this is good, we need more people with operational experience. + JR: # I think it's interesting to do. # Is this the end document or start document? + Avshalom: # I'm not sure myself. Robert Sparks (Chair) : Go take a look at draft XMPP/SIMPLE draft, and give Peter comments. Rechartering (Robert Sparks, as Chair) * If you don't like the rechartering steps, comment on the list soon. * Submission of mechanism for presence composition, messaging requirements goes away from today's conversation. * Dates need to be real. o (mic) o JR: + XCAP event package Config package draft is swirled up. Package and format packages are likely to be put together and punted over to SIPPING. o Robert Sparks: + So this could go either way, and not August. o JR: + Yes. o Robert Sparks (Chair): + XCAP milestone dates will change or it needs to change working groups. Needs discussion. + Anything from the advanced messaging reuirements scratchpad will discover stuff to be finished by this year. We don't know what those are yet, when we do we'll replace it. o Ben Campbell: + Will optimizations/scalability delay finishing up the work group? o Jon Peterson (as Area Director): + There's some discussion in Speermint that will cover Avshalom potentially. + AD's want Speermint to be a tactical WG and not pollute it, so we don't want to move things wholesale. + Recommendation would be to continue to investigate work here. o Ben Campbell: + First draft is not just domain naming. o Jon Peterson: + Speermint as it is currently cast is not centered on SIP or SIMPLE, but on conventions in the interdomain context. Protocol work gets pushed off to the appropriate WG (e.g. here). o Avshalom: + Problem statement is not currently a milestone? o Robert Sparks (as Chair): + Not at the moment, but it can go through the review process. o Jon Peterson (as AD): + No need to be fussy, if there's a strong feeling in the room we can add it now on a hum. o Robert Sparks (as Chair): + Room seems interested. o Ben Campbell: + Add milestones as we come up with them seems appropriate. o JR: + I think problem statement has persistent value long after you are done. BCP seems fuzzy though. + Propose: take on problem statement for information document. o Jon Peterson (as AD): + Speermint is a good place for it, and given that we don't have it there now, it's ok to have it here. o Robert Sparks (as Chair): + If you think that we should expend working group cycles refining the problem statement document into an informational document (HUM): Hum vote is yes. + (Meeting Close) _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 17 10:12:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2Tpu-0007gp-Vo; Mon, 17 Jul 2006 10:12:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2Tpt-0007gk-GM for simple@ietf.org; Mon, 17 Jul 2006 10:12:37 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2Tps-0001CE-5K for simple@ietf.org; Mon, 17 Jul 2006 10:12:37 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 17 Jul 2006 07:12:36 -0700 X-IronPort-AV: i="4.06,251,1149490800"; d="scan'208"; a="306181516:sNHT26313636" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6HECZRa022924; Mon, 17 Jul 2006 07:12:35 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k6HECFHq027069; Mon, 17 Jul 2006 07:12:34 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Jul 2006 10:12:29 -0400 Received: from [192.168.1.100] ([10.86.240.252]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Jul 2006 10:12:29 -0400 Message-ID: <44BB9ACC.8000607@cisco.com> Date: Mon, 17 Jul 2006 10:12:28 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Silvestr.Peknik@tietoenator.com Subject: Re: [Simple] presence event package - generation of notify requests References: <3ACC9A25264A684F82C71840111F979801E77A02@carrera.eu.tieto.com> In-Reply-To: <3ACC9A25264A684F82C71840111F979801E77A02@carrera.eu.tieto.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jul 2006 14:12:29.0143 (UTC) FILETIME=[098DD670:01C6A9AB] DKIM-Signature: a=rsa-sha1; q=dns; l=2174; t=1153145555; x=1154009555; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Simple]=20presence=20event=20package=20-=20generation=20of=20no tify=20requests; X=v=3Dcisco.com=3B=20h=3Dg3eyKA5hbMd5SLmCm9hxrkb+Bu4=3D; b=k9EHRZlCl7b6yf6V8Hljeg4/8IY+Sw4lOSWopQye5e7bmKDpPx4k1BQx+Kp/OtNNp7FFPuN7 k5ZsoOy1wJYIXUdPBQTcH8DpWk3BatttuiIWoLXo5KLA+JIrVqQEFw5p; Authentication-Results: sj-dkim-6.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: simple@ietf.org, Roman.Bosak@tietoenator.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org inline. Silvestr.Peknik@tietoenator.com wrote: > Hello, > > I would like to get some clarification about notifications. > > In RFC3856 par. 6.7. Notifier Generation of NOTIFY Requests > > ... > A PA MAY send a NOTIFY at any time. Typically, it will send one when > the state of the presentity changes. The NOTIFY request MAY contain > a body indicating the state of the presentity. The times at which > the NOTIFY is sent for a particular subscriber, and the contents of > the body within that notification, are subject to any rules specified > by the authorization policy that governs the subscription. > ... > > If PA does not deliver the notification at all, is it still valid > behavior? Generally speaking, of course. If privacy filters are on, no notifications might ever be generated in some use cases. > > The situation I have in mind: > There is rate control mechanism and then filtering mechanism on the PA > (rate control is applied first due to implementation decision). A > resource is subscribed. The state of the resource changes quickly from A > to B (notification N1 is generated) and then back to A (N2). Lets say > that N1 is caught by rate control. N2 arrives and replaces N1 in the > rate control. N2 is passed to filtering and is discarded because the > client is not interested in changes from B to A (but it is interested in > changes from A to B). > > In my opinion this behavior is not valid because the subscriber can miss > the information it seeks, but the specification is not very specific on > this. What is your opinion? Rate limiting causes loss of information. If you do it, you run the risk of losing things that might be interesting. You cannot have it both ways (rate limit notifications and never miss useful data.) -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 17 16:55:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2a7r-0006vM-8Q; Mon, 17 Jul 2006 16:55:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2a7p-0006u2-R8; Mon, 17 Jul 2006 16:55:33 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2Zcp-00063H-6G; Mon, 17 Jul 2006 16:23:31 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G2ZUj-0007Y2-4G; Mon, 17 Jul 2006 16:15:11 -0400 Received: from [172.17.2.252] (dsl001-129-070.dfw1.dsl.speakeasy.net [72.1.129.70]) (authenticated bits=0) by nostrum.com (8.13.6/8.13.6) with ESMTP id k6HK7vnw054765 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 17 Jul 2006 15:07:58 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Date: Mon, 17 Jul 2006 15:07:56 -0500 To: IETF SIP List , sipping , simple@ietf.org, sip-implementors@cs.columbia.edu X-Mailer: Apple Mail (2.752.2) Received-SPF: pass (nostrum.com: 72.1.129.70 is authenticated by a trusted mechanism) X-Spam-Score: -1.5 (-) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [Simple] Registration for SIPit 19 is open X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: RjS@sipit.net List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Registration for SIPit 19. This SIPit will take place at the University of New Hampshire InterOperability Laboratory October 16-20. Space is limited to 120 participants, so register early. Registration will close September 29. For more information, and to register, see http://www.sipit.net RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jul 18 10:57:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2r0o-00033N-5v; Tue, 18 Jul 2006 10:57:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2r0m-00033F-UX for simple@ietf.org; Tue, 18 Jul 2006 10:57:24 -0400 Received: from corp-fw-main.jabber.com ([207.182.164.14] helo=wrk187.corp.jabber.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2r0j-00054Z-3u for simple@ietf.org; Tue, 18 Jul 2006 10:57:24 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by wrk187.corp.jabber.com (Postfix) with ESMTP id B7C7B505AD3; Tue, 18 Jul 2006 08:57:21 -0600 (MDT) Message-ID: <44BC53F8.30205@jabber.org> Date: Mon, 17 Jul 2006 21:22:32 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.4) Gecko/20060530 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Adam Roach Subject: Re: Fw: [Simple] "last call" on SIMPLE-XMPP interworking I-D References: <44AE872E.3080902@nostrum.com> <44B31B7C.1050506@jabber.org> <44B3EA74.1040104@nostrum.com> <44B3F501.7060104@jabber.org> <44B3FB6A.70502@estacado.net> In-Reply-To: <44B3FB6A.70502@estacado.net> X-Enigmail-Version: 0.94.0.0 Jabber-ID: stpeter@jabber.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: xmppwg@jabber.org, Adam Roach , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 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="===============1880329321==" Errors-To: simple-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1880329321== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080000020902020905030706" This is a cryptographically signed message in MIME format. --------------ms080000020902020905030706 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Adam Roach wrote: > Peter Saint-Andre wrote: >> I'm saying that XMPP does have what you want, but in order to enforce >> that, on the XMPP end of the wormhole the gateway would need to mimic >> short-lived SIP subscription semantics rather than long-lived XMPP >> subscription semantics. >> > > Okay; let's do that, then. Does the following proposed text address the concern? *** Note: The XMPP-SIMPLE gateway MUST honor the short-lived subscription semantics of SIP presence subscriptions rather than the long-lived subscription semantics of XMPP presence subscriptions by passing along all subscription renewals (i.e., subsequent SUBSCRIBE requests) from the SIP user to the XMPP user in the form of XMPP presence stanzas of type "unsubscribe", thus forcing the XMPP user to resubscribe to the presence of the SIP user; this helps to avoid possible amplification attacks caused by the mismatch between long-lived XMPP subscriptions and short-lived SIP subscriptions. *** Thanks. Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml --------------ms080000020902020905030706 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYVDCC B3AwggbZoAMCAQICAQkwDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0 MDUxNDUxMDNaFw0xMDA0MDQxNDUxMDNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVtYWlsIEZy ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAOOY75tn3YhiCOsNXQn9/4WfpNrX8HLIUlBTLrGtMINvcYJ0 3Nlr9kJyOF5Z8g+2G9Zg+zN8iWGBEpl37bgjYdea3q0AaO9uyZOMLa0rztjFeo7Uw8AjdDmW kaJQU1c6q9OoieOT6Tf4MvHMGqtbnaOL3Xvz4o6XnH+Ek9h8zPgYgiUw2tIF0ueLayTGiInH dWM5eYMoz7OnVlUeIurDweT4C9V1TtwplnhWZ7bilcuN4w3/8hndqryqqflbCMlLZWn+1uaT 21d12cdpjBOaqtg6hqiTY4S4+wVAmGrAiOPQ3Z574gljhUKf5ehz7p9xtsb+mjvM1I4yPP8/ vjKZoRUCAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud DgQWBBS4Zr17owi6irSy+USIcU+li0GzUTCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0 eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0 YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6 Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5 BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50 ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0 cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQDss9KK Fx/bCifYjAQTmBtRoHFsdR5ZQ1nlagXKoyJ+IwmdGdiYqAKeaDfjT6bTXHfQvK8kp5xSoz0I PcpSwztY7UKtylgJwplu1q6vjj4BGB621sD60qzirAhLSqxmpBgjl8HMMMoiM28DCLsshihl g7wG7Oi/rPIuR8dawiaDejCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STGCBCwwggQoAgEBMIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UE CBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2Vy dGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVt YWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAOhwMAkG BSsOAwIaBQCgggJJMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTA2MDcxODAzMjIzMlowIwYJKoZIhvcNAQkEMRYEFD9v/674Xg6QafbsinNaupCQwfHyMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHIBgkrBgEEAYI3EAQxgbowgbcwga8xCzAJ BgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAh BgNVBAsTGlNlY3VyZSBDZXJ0aWZpY2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBD bGFzcyAyIFByaW1hcnkgRW1haWwgRnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3Rh cnRjb20ub3JnAgMA6HAwgcoGCyqGSIb3DQEJEAILMYG6oIG3MIGvMQswCQYDVQQGEwJJTDEP MA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1 cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwID AOhwMA0GCSqGSIb3DQEBAQUABIIBAEb8lzPcB7yJUTaTsDBu1rFqB4pAQQ5oTmMN2iCVNq8R P0zTtaOjBkdEKK5RyGb2wLlR0A0yhwrOmnG9LREQ9/mN2ZJ+cOHgcn0Ks5phh5c3ksxnsBSO Gj2aUqQTh+xj01fqvUuVwl+OJYzTsZ6MRM9x3few9GCYzCYur7BEHRCk7AA0oVDPiqaixRWZ JULOXSR3nSfLrfgp6Efs7yn9ou+oq5CcvO3/JR84LYiHvpWpVscVBQlArukCKpJ8/bPnH0FQ GD+h5Rg7kjUADxvBde/MjoweV0lRuHbGCspwmQB2rzcrgqaagA98HDTo1RvUxNb2UF4fF+Pi u/m4XyjHcNcAAAAAAAA= --------------ms080000020902020905030706-- --===============1880329321== 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://www1.ietf.org/mailman/listinfo/simple --===============1880329321==-- From simple-bounces@ietf.org Tue Jul 18 11:50:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2rpm-0007Ah-MP; Tue, 18 Jul 2006 11:50:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2rpl-00078w-3C for simple@ietf.org; Tue, 18 Jul 2006 11:50:05 -0400 Received: from tidos.tid.es ([193.145.240.2] helo=correo.tid.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2rpi-0000tf-Oa for simple@ietf.org; Tue, 18 Jul 2006 11:50:05 -0400 Received: from tid (filvit [192.168.48.202]) by tid.hi.inet (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0J2L00IWMVZFDT@tid.hi.inet> for simple@ietf.org; Tue, 18 Jul 2006 17:50:04 +0200 (MEST) Received: from matrix2 (matrix2.hi.inet [10.95.28.131]) by tid.hi.inet (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0J2L00IWIVZFDT@tid.hi.inet> for simple@ietf.org; Tue, 18 Jul 2006 17:50:03 +0200 (MEST) Date: Tue, 18 Jul 2006 17:49:58 +0200 From: =?iso-8859-1?Q?Gustavo_Garc=EDa_Bernardo?= To: simple@ietf.org Message-id: <00fb01c6aa81$d26ab730$831c5f0a@matrix2> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcaqgdIkLcQA+aAPSRm/K8wTEJyQLA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Subject: [Simple] Expressing Privacy Preferences X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 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="===============1690775128==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1690775128== Content-type: multipart/alternative; boundary="Boundary_(ID_YQ0TNSnfmi/Ps3yaKyIYTw)" This is a multi-part message in MIME format. --Boundary_(ID_YQ0TNSnfmi/Ps3yaKyIYTw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Hi all,=20 =20 A question about draft-ietf-geopriv-common-policy-10.txt: =20 Is this framework intended to define derivation rules like: =93If = watcher identity is xxx then add =91away=92 to my presence activities=94 or is = only oriented to define privacy rules like =93If watcher identity is xxx then = hide activities=94? =20 Thanks =20 G. =20 --Boundary_(ID_YQ0TNSnfmi/Ps3yaKyIYTw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT

Hi all,

 

A question about draft-ietf-geopriv-common-policy-10.txt:

 

Is this framework intended to define derivation rules like: “If watcher identity is xxx then add ‘away’ to my presence activities” or is only oriented to define privacy rules like “If watcher identity is xxx then hide activities”?

 

Thanks

 

G.

 

--Boundary_(ID_YQ0TNSnfmi/Ps3yaKyIYTw)-- --===============1690775128== 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://www1.ietf.org/mailman/listinfo/simple --===============1690775128==-- From simple-bounces@ietf.org Wed Jul 19 08:49:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3BUD-0008Ue-12; Wed, 19 Jul 2006 08:49:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3BUB-0008UZ-7x for simple@ietf.org; Wed, 19 Jul 2006 08:49:07 -0400 Received: from mail.tieto.com ([194.110.47.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3BU8-0008Mi-I0 for simple@ietf.org; Wed, 19 Jul 2006 08:49:07 -0400 Received: from camaro.eu.tieto.com ([192.176.143.43]) by mail.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 15:50:16 +0300 Received: from carrera.eu.tieto.com ([192.176.158.112]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 14:49:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Jul 2006 14:48:57 +0200 Message-ID: <3ACC9A25264A684F82C71840111F979801EC5E54@carrera.eu.tieto.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UDP - what if response is bigger than 1500 bytes (ethernet MTU)? Thread-Index: AcarMbN4Ivp2DZ4bScW+zHXrnHyyJw== From: To: X-OriginalArrivalTime: 19 Jul 2006 12:49:00.0590 (UTC) FILETIME=[B50CCCE0:01C6AB31] X-Spam-Score: 0.2 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Milan.Kunc@tietoenator.com Subject: [Simple] UDP - what if response is bigger than 1500 bytes (ethernet MTU)? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hello,=20 Could someone help me with following problem?=20 I am not sure what should be done when the response to SIP request sent over UDP is bigger than 1500 bytes? It can happen e.g. when PUBBLISH request is responded by 415 Unsupported Media Type and Accept, Accept-Encoding and Accept-Language headers are added. Thank you,=20 Silvestr Peknik Extract from RFC3261: 18.1.1 Sending requests: ... If a request is within 200 bytes of the path MTU, or if it is larger than 1300 bytes and the path MTU is unknown, the request MUST be sent using an RFC 2914 [43] congestion controlled transport protocol, such as TCP. If this causes a change in the transport protocol from the one indicated in the top Via, the value in the top Via MUST be changed. This prevents fragmentation of messages over UDP and provides congestion control for larger messages. However, implementations MUST be able to handle messages up to the maximum datagram packet size. For UDP, this size is 65,535 bytes, including IP and UDP headers. The 200 byte "buffer" between the message size and the MTU accommodates the fact that the response in SIP can be larger than the request. This happens due to the addition of Record-Route header field values to the responses to INVITE, for example. With the extra buffer, the response can be about 170 bytes larger than the request, and still not be fragmented on IPv4 (about 30 bytes is consumed by IP/UDP, assuming no IPSec). 1300 is chosen when path MTU is not known, based on the assumption of a 1500 byte Ethernet MTU. ...=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 19 09:31:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3C9D-0004un-UX; Wed, 19 Jul 2006 09:31:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3C9B-0004ty-SL; Wed, 19 Jul 2006 09:31:29 -0400 Received: from smail3.alcatel.fr ([62.23.212.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3C9A-0002S4-AF; Wed, 19 Jul 2006 09:31:29 -0400 Received: from missrv1.nextenso.alcatel.fr (proxy.nextenso.alcatel.fr [139.54.130.250]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id k6JDVLcJ030253; Wed, 19 Jul 2006 15:31:21 +0200 Received: from [139.54.131.75] (nx1075.nextenso.alcatel.fr [139.54.131.75]) by missrv1.nextenso.alcatel.fr (8.13.5/8.12.8) with ESMTP id k6JDVKDG030649; Wed, 19 Jul 2006 15:31:20 +0200 Message-ID: <44BE3426.3050502@alcatel.fr> Date: Wed, 19 Jul 2006 15:31:18 +0200 From: Thomas Froment User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Silvestr.Peknik@tietoenator.com, sip@ietf.org Subject: Re: [Simple] UDP - what if response is bigger than 1500 bytes (ethernet MTU)? References: <3ACC9A25264A684F82C71840111F979801EC5E54@carrera.eu.tieto.com> In-Reply-To: <3ACC9A25264A684F82C71840111F979801EC5E54@carrera.eu.tieto.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Milan.Kunc@tietoenator.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Silvestr.Peknik@tietoenator.com wrote: > Hello, > > Could someone help me with following problem? > > I am not sure what should be done when the response to SIP request sent > over UDP is bigger than 1500 bytes? It can happen e.g. when PUBBLISH > request is responded by 415 Unsupported Media Type and Accept, > Accept-Encoding and Accept-Language headers are added. > This is a good question: I think it was mentionned in last SIP WG IETF meeting that having responses greater than path MTU (-200 bytes) in SIP was not currently well specified. It was an open issue on draft-ietf-sip-hop-limit-diagnostics-03.txt which raises this problem since it leads naturally to send big SIP responses. SIP WG people may probably answer you if something is planned to handle this problem... Thomas > Thank you, > Silvestr Peknik > > Extract from RFC3261: > 18.1.1 Sending requests: > ... > If a request is within 200 bytes of the path MTU, or if it is larger > than 1300 bytes and the path MTU is unknown, the request MUST be sent > using an RFC 2914 [43] congestion controlled transport protocol, such > as TCP. If this causes a change in the transport protocol from the > one indicated in the top Via, the value in the top Via MUST be > changed. This prevents fragmentation of messages over UDP and > provides congestion control for larger messages. However, > implementations MUST be able to handle messages up to the maximum > datagram packet size. For UDP, this size is 65,535 bytes, including > IP and UDP headers. > > The 200 byte "buffer" between the message size and the MTU > accommodates the fact that the response in SIP can be larger than > the request. This happens due to the addition of Record-Route > header field values to the responses to INVITE, for example. With > the extra buffer, the response can be about 170 bytes larger than > the request, and still not be fragmented on IPv4 (about 30 bytes > is consumed by IP/UDP, assuming no IPSec). 1300 is chosen when > path MTU is not known, based on the assumption of a 1500 byte > Ethernet MTU. > ... > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 19 10:59:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3DVu-0005Ka-4y; Wed, 19 Jul 2006 10:59:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3DVs-0005KV-9A for simple@ietf.org; Wed, 19 Jul 2006 10:59:00 -0400 Received: from exchange.jabber.com ([207.182.164.133] helo=ossex1.jabber.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3DVr-0000HZ-0O for simple@ietf.org; Wed, 19 Jul 2006 10:59:00 -0400 Received: from [IPv6:::1] (gatekeeper-int.jabber.com [10.101.0.11]) by ossex1.jabber.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 34X9H66D; Wed, 19 Jul 2006 08:59:29 -0600 In-Reply-To: <44BC53F8.30205@jabber.org> References: <44BC53F8.30205@jabber.org> Mime-Version: 1.0 (Apple Message framework v752.2) Jabber-Id: jhildebrand@corp.jabber.com Message-Id: <2AE988AC-28FD-418F-8826-D96122C4BA23@jabber.com> From: Joe Hildebrand Subject: Re: [Simple] "last call" on SIMPLE-XMPP interworking I-D Date: Wed, 19 Jul 2006 08:58:56 -0600 To: Peter Saint-Andre X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: xmppwg@jabber.org, Adam Roach , Adam Roach , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 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="===============1130658237==" Errors-To: simple-bounces@ietf.org --===============1130658237== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-6-1067761361; protocol="application/pkcs7-signature" --Apple-Mail-6-1067761361 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed stpeter writes: > Note: The XMPP-SIMPLE gateway MUST honor the short-lived subscription > semantics of SIP presence subscriptions rather than the long-lived > subscription semantics of XMPP presence subscriptions by passing along > all subscription renewals (i.e., subsequent SUBSCRIBE requests) > from the > SIP user to the XMPP user in the form of XMPP presence stanzas of type > "unsubscribe", thus forcing the XMPP user to resubscribe to the > presence > of the SIP user; this helps to avoid possible amplification attacks > caused by the mismatch between long-lived XMPP subscriptions and > short-lived SIP subscriptions. Whoa. Really? I can't imagine any of my users being willing to deploy such a system. We can't change the existing clients to handle these transparently, so this means their contacts on the other end of a SIMPLE gateway are going to be continuously disappearing. --Apple-Mail-6-1067761361 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEdzCCBHMw ggJboAMCAQICAwFnvTANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTA4MjUxOTU2NDZaFw0w NjA4MjUxOTU2NDZaMEAxFzAVBgNVBAMTDkpvZSBIaWxkZWJyYW5kMSUwIwYJKoZIhvcNAQkBFhZq aGlsZGVicmFuZEBqYWJiZXIuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCq49BpJX8D ehvNyc0WzQCIau00T/do5DPCoavn3P+IpTyKGXwUzTTdoCNDvj8H6p4xLSUx5M8h3X6sFQ1/fz/j Qn4cUnCnCpPIA1XRTaudpY+Q8XVVK0txU5yOP5nGppMM0KaT7OqclF7bP6dfrD4nJo7I0D3Fl0th yEtnxlE+3QIDAQABo4HAMIG9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5 b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9y ZzAhBgNVHREEGjAYgRZqaGlsZGVicmFuZEBqYWJiZXIuY29tMA0GCSqGSIb3DQEBBAUAA4ICAQA0 rYT+WImu2hfUZBQ4a8Sys/11H2EjB8DqQdI5A7EJtHnQsR6nO2muym2k9fB8FRMf9BIzhsknGOB+ DqBgvqFn+KrFfVnty3zfHwl6ogbogk3eLiezbBtvsfB0pHfKiRos4P7ivzPNLdyNNjG2NF7bwCt9 vvHq2KEsTWX18BjVv5PezK//LngXt6EW4O61+aBGWgRiQ18vM9jAuEATMHMxyeIbCtBSLyv/St86 pB8oOrMYopOCtPKMqmzctIe1evPmro6FuQxvGtyWDd1rRdy40t6LhXEcDqDzsUfvtSOeRAvEf63g C2BQtWaw2jHmoIXigopZVs89ZWUsMkowEl2P7hQ5mffpQEDcfNcfDQ51yjHKfeSuOyFkj5hmnZpO TJMX9Ileo6A5MIdHcKwT6v6h6jfz/mH30XQYB0Wu+2vlPhBITBICubp68YL0BVf7BKFqANjMDfX+ QCGEUcpIzbnFHY+OHFiJFVs/nnYVRzGF8YaX8UFeSla4rYsyiOnyUOLNSKXdR4BM8SsIj2K/9IxL PQHG7xa3yDlQZ/11sPvDTfyEA/D/wDjDzobh/t0hED2og+tTqbno3JXVqY2YQKkiN+tjeD0z7FKf 0UZjg983pAW3wpFFc6PkihG6a2mZ15klMeub+hHhzaERMrXLekFi4Yn66QeksQUnKO2fQIviiTGC ArIwggKuAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2Fj ZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJ ARYSc3VwcG9ydEBjYWNlcnQub3JnAgMBZ70wCQYFKw4DAhoFAKCCAYcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwNzE5MTQ1ODU3WjAjBgkqhkiG9w0BCQQxFgQU YqW6d549eLFf0R+LSWY0YblDZGAwgZEGCSsGAQQBgjcQBDGBgzCBgDB5MRAwDgYDVQQKEwdSb290 IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2ln bmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDAWe9MIGT BgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8v d3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkq hkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDAWe9MA0GCSqGSIb3DQEBAQUABIGAcmFgc/5E aHbpGCKLajnly93m+dTmqWnUGZCJWkmFpPHGytHOde6ML4Xw4inr1bYFTLNOjK3kdImQselSv5vh HudMaWNRFszbU+duXvtSL1Pg/YkY2hGL/yVuQs5q81PW+ZP0lUtYgockCCgu1sNwSgcRXsYEmOew XiLEWxWlDxkAAAAAAAA= --Apple-Mail-6-1067761361-- --===============1130658237== 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://www1.ietf.org/mailman/listinfo/simple --===============1130658237==-- From simple-bounces@ietf.org Wed Jul 19 11:40:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3EAC-0001uY-2T; Wed, 19 Jul 2006 11:40:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3EAA-0001uT-Tq for simple@ietf.org; Wed, 19 Jul 2006 11:40:38 -0400 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3EA8-00044l-Fb for simple@ietf.org; Wed, 19 Jul 2006 11:40:38 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.50) id 1G3EA7-0006v8-Dx; Wed, 19 Jul 2006 15:40:35 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id F1B40498003; Wed, 19 Jul 2006 16:43:12 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25993-09; Wed, 19 Jul 2006 16:43:07 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id C91AF498002; Wed, 19 Jul 2006 16:43:07 +0100 (BST) Date: Wed, 19 Jul 2006 16:40:27 +0100 Subject: Re: [xmppwg] Re: [Simple] "last call" on SIMPLE-XMPP interworking I-D References: <44BC53F8.30205@jabber.org> <2AE988AC-28FD-418F-8826-D96122C4BA23@jabber.com> In-Reply-To: <2AE988AC-28FD-418F-8826-D96122C4BA23@jabber.com> MIME-Version: 1.0 Message-Id: <29267.1153323628.817914@peirce.dave.cridland.net> From: Dave Cridland To: Joe Hildebrand Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Rutherford-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Mailing list of the IETF's XMPP Working Group , Adam Roach , Adam Roach , SIP for Instant Messaging and Presence Leveraging Extensions X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org On Wed Jul 19 15:58:56 2006, Joe Hildebrand wrote: > > stpeter writes: > >> Note: The XMPP-SIMPLE gateway MUST honor the short-lived >> subscription >> semantics of SIP presence subscriptions rather than the long-lived >> subscription semantics of XMPP presence subscriptions by passing >> along >> all subscription renewals (i.e., subsequent SUBSCRIBE requests) >> from the >> SIP user to the XMPP user in the form of XMPP presence stanzas of >> type >> "unsubscribe", thus forcing the XMPP user to resubscribe to the >> presence >> of the SIP user; this helps to avoid possible amplification attacks >> caused by the mismatch between long-lived XMPP subscriptions and >> short-lived SIP subscriptions. > > Whoa. Really? I can't imagine any of my users being willing to > deploy such a system. We can't change the existing clients to > handle these transparently, so this means their contacts on the > other end of a SIMPLE gateway are going to be continuously > disappearing. I agree - if this is really what's needed, XMPP/SIMPLE gatewaying is not going to happen, or else this requirement will be dropped. I suspect that the simplest method is to recommend restricting access to the XMPP side of the XMPP/SIMPLE gateway to a single XMPP domain, and recommending that sensible limits should be put on the number of users allowed to connect to a server from the same address. This, I think, forces such an attack to be done by the attacker finding a bunch of zombie machines creating the users on the XMPP domain (if possible), and performing the subscription. The thing is, why on earth would you bother when you could just flood the SIP presence server directly with your zombie army? Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 19 11:54:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3ENg-00075Q-1o; Wed, 19 Jul 2006 11:54:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3ENe-00075L-3e for simple@ietf.org; Wed, 19 Jul 2006 11:54:34 -0400 Received: from corp-fw-main.jabber.com ([207.182.164.14] helo=wrk187.corp.jabber.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3ENc-0005Dj-Fl for simple@ietf.org; Wed, 19 Jul 2006 11:54:34 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by wrk187.corp.jabber.com (Postfix) with ESMTP id 821A750A513; Wed, 19 Jul 2006 09:54:32 -0600 (MDT) Message-ID: <44BE55B8.8000909@jabber.org> Date: Wed, 19 Jul 2006 09:54:32 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.4) Gecko/20060530 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Dave Cridland Subject: Re: [xmppwg] Re: [Simple] "last call" on SIMPLE-XMPP interworking I-D References: <44BC53F8.30205@jabber.org> <2AE988AC-28FD-418F-8826-D96122C4BA23@jabber.com> <29267.1153323628.817914@peirce.dave.cridland.net> In-Reply-To: <29267.1153323628.817914@peirce.dave.cridland.net> X-Enigmail-Version: 0.94.0.0 Jabber-ID: stpeter@jabber.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Cc: Joe Hildebrand , Mailing list of the IETF's XMPP Working Group , Adam Roach , Adam Roach , SIP for Instant Messaging and Presence Leveraging Extensions X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 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="===============0634444498==" Errors-To: simple-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0634444498== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020104040506060400070702" This is a cryptographically signed message in MIME format. --------------ms020104040506060400070702 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dave Cridland wrote: > On Wed Jul 19 15:58:56 2006, Joe Hildebrand wrote: >> >> stpeter writes: >> >>> Note: The XMPP-SIMPLE gateway MUST honor the short-lived subscription >>> semantics of SIP presence subscriptions rather than the long-lived >>> subscription semantics of XMPP presence subscriptions by passing along >>> all subscription renewals (i.e., subsequent SUBSCRIBE requests) from >>> the >>> SIP user to the XMPP user in the form of XMPP presence stanzas of type >>> "unsubscribe", thus forcing the XMPP user to resubscribe to the >>> presence >>> of the SIP user; this helps to avoid possible amplification attacks >>> caused by the mismatch between long-lived XMPP subscriptions and >>> short-lived SIP subscriptions. >> >> Whoa. Really? I can't imagine any of my users being willing to >> deploy such a system. We can't change the existing clients to handle >> these transparently, so this means their contacts on the other end of >> a SIMPLE gateway are going to be continuously disappearing. > > I agree - if this is really what's needed, XMPP/SIMPLE gatewaying is not > going to happen, or else this requirement will be dropped. > > I suspect that the simplest method is to recommend restricting access to > the XMPP side of the XMPP/SIMPLE gateway to a single XMPP domain, and > recommending that sensible limits should be put on the number of users > allowed to connect to a server from the same address. > > This, I think, forces such an attack to be done by the attacker finding > a bunch of zombie machines creating the users on the XMPP domain (if > possible), and performing the subscription. The thing is, why on earth > would you bother when you could just flood the SIP presence server > directly with your zombie army? Because, according to Adam, the mismatch between SIP presence subscriptions (short-lived) and XMPP presence subscriptions (long-lived) means that the attacker can save some bytes by attacking from the XMPP side of the wormhole rather than from the SIP side, thus presumably making the attack less expensive in terms of bandwidth and processor. Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml --------------ms020104040506060400070702 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYVDCC B3AwggbZoAMCAQICAQkwDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0 MDUxNDUxMDNaFw0xMDA0MDQxNDUxMDNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVtYWlsIEZy ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAOOY75tn3YhiCOsNXQn9/4WfpNrX8HLIUlBTLrGtMINvcYJ0 3Nlr9kJyOF5Z8g+2G9Zg+zN8iWGBEpl37bgjYdea3q0AaO9uyZOMLa0rztjFeo7Uw8AjdDmW kaJQU1c6q9OoieOT6Tf4MvHMGqtbnaOL3Xvz4o6XnH+Ek9h8zPgYgiUw2tIF0ueLayTGiInH dWM5eYMoz7OnVlUeIurDweT4C9V1TtwplnhWZ7bilcuN4w3/8hndqryqqflbCMlLZWn+1uaT 21d12cdpjBOaqtg6hqiTY4S4+wVAmGrAiOPQ3Z574gljhUKf5ehz7p9xtsb+mjvM1I4yPP8/ vjKZoRUCAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud DgQWBBS4Zr17owi6irSy+USIcU+li0GzUTCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0 eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0 YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6 Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5 BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50 ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0 cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQDss9KK Fx/bCifYjAQTmBtRoHFsdR5ZQ1nlagXKoyJ+IwmdGdiYqAKeaDfjT6bTXHfQvK8kp5xSoz0I PcpSwztY7UKtylgJwplu1q6vjj4BGB621sD60qzirAhLSqxmpBgjl8HMMMoiM28DCLsshihl g7wG7Oi/rPIuR8dawiaDejCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STGCBCwwggQoAgEBMIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UE CBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2Vy dGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVt YWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAOhwMAkG BSsOAwIaBQCgggJJMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTA2MDcxOTE1NTQzMlowIwYJKoZIhvcNAQkEMRYEFFy4BUo8o0YT3+ZE0zN/8ehxIuvSMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHIBgkrBgEEAYI3EAQxgbowgbcwga8xCzAJ BgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAh BgNVBAsTGlNlY3VyZSBDZXJ0aWZpY2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBD bGFzcyAyIFByaW1hcnkgRW1haWwgRnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3Rh cnRjb20ub3JnAgMA6HAwgcoGCyqGSIb3DQEJEAILMYG6oIG3MIGvMQswCQYDVQQGEwJJTDEP MA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1 cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwID AOhwMA0GCSqGSIb3DQEBAQUABIIBAIMj9vye7wdj0x7LR5sak1cGOAXA4unbKNRSZF63bpZw /zbxTXt4IR9EE3DnLBB+V24TGw0bIrXwKdIdqk+Qzg62OL1CVDvx/rLsGfwu3ClXMpq6X3Oc JEfgtuNlu+nZK8tL2WzSdQ38NrQD7eyG0n+QnpfsEnabnT0DjtikxM74I5dTi8366kDYLvju TDHwEkBMI8HHlrnqF87llnnBUIXzSlwtLGvntW2a2VooAVhcFm09cetEqDBz17Z7a6hMLSk0 asaFIbFgcxnNV5dJaewpNYHNYvlli7aJyb/M3TZb4N5oEkmbsx7+YCKzodSAfMKC/06Z6RXl xoUygg2wbycAAAAAAAA= --------------ms020104040506060400070702-- --===============0634444498== 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://www1.ietf.org/mailman/listinfo/simple --===============0634444498==-- From simple-bounces@ietf.org Wed Jul 19 12:00:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3ETY-0000D1-KO; Wed, 19 Jul 2006 12:00:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3ETX-0000Cr-NA for simple@ietf.org; Wed, 19 Jul 2006 12:00:39 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3ETV-0006BU-C9 for simple@ietf.org; Wed, 19 Jul 2006 12:00:39 -0400 Received: from [192.168.0.102] (ppp-70-245-142-249.dsl.rcsntx.swbell.net [70.245.142.249]) (authenticated bits=0) by vicuna.estacado.net (8.13.6/8.13.4) with ESMTP id k6JFxLEX055016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jul 2006 10:59:21 -0500 (CDT) (envelope-from adam@estacado.net) Message-ID: <44BE56EF.4030609@estacado.net> Date: Wed, 19 Jul 2006 10:59:43 -0500 From: Adam Roach User-Agent: Thunderbird 1.5.0.4 (X11/20060614) MIME-Version: 1.0 To: Peter Saint-Andre Subject: Re: [Simple] "last call" on SIMPLE-XMPP interworking I-D References: <44BC53F8.30205@jabber.org> <2AE988AC-28FD-418F-8826-D96122C4BA23@jabber.com> <44BE4E31.9010307@jabber.org> In-Reply-To: <44BE4E31.9010307@jabber.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Joe Hildebrand , xmppwg@jabber.org, Adam Roach , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Peter Saint-Andre wrote: > (3) Come up with another solution to the amplification attack scenario > that Adam brought up. > What about the ping-pong that I suggested? I freely admit that I don't know enough about XMPP to predict what problems it may cause, but a casual read of the related RFCs leads me to believe that it is a pain-free solution to the problem with no user impacts. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 19 12:02:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3EUu-0000hS-M1; Wed, 19 Jul 2006 12:02:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3EUt-0000hN-8v for simple@ietf.org; Wed, 19 Jul 2006 12:02:03 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3EUq-0006KA-UD for simple@ietf.org; Wed, 19 Jul 2006 12:02:03 -0400 Received: from [192.168.0.102] (ppp-70-245-142-249.dsl.rcsntx.swbell.net [70.245.142.249]) (authenticated bits=0) by vicuna.estacado.net (8.13.6/8.13.4) with ESMTP id k6JG0jRx055255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jul 2006 11:00:45 -0500 (CDT) (envelope-from adam@estacado.net) Message-ID: <44BE5742.8080806@estacado.net> Date: Wed, 19 Jul 2006 11:01:06 -0500 From: Adam Roach User-Agent: Thunderbird 1.5.0.4 (X11/20060614) MIME-Version: 1.0 To: Mridul Muralidharan Subject: Re: [xmppwg] Re: [Simple] "last call" on SIMPLE-XMPP interworking I-D References: <44BC53F8.30205@jabber.org> <2AE988AC-28FD-418F-8826-D96122C4BA23@jabber.com> <44BE4E31.9010307@jabber.org> <44BE562D.2080400@sun.com> In-Reply-To: <44BE562D.2080400@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Joe Hildebrand , xmppwg@jabber.org, Adam Roach , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Mridul Muralidharan wrote: > > Just to get it clarified , this amplification attack (or similar > behavior) is something that exists currently in the SIP/SIMPLE world , > irrespective of this XMPP gateway , right ? No. The problem arises because of the gateway, and does not exist in its absence. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 19 12:02:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3EVU-0000qV-Eu; Wed, 19 Jul 2006 12:02:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3ESJ-0007ul-Iy for simple@ietf.org; Wed, 19 Jul 2006 11:59:23 -0400 Received: from corp-fw-main.jabber.com ([207.182.164.14] helo=wrk187.corp.jabber.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3ESI-0005zl-3q for simple@ietf.org; Wed, 19 Jul 2006 11:59:23 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by wrk187.corp.jabber.com (Postfix) with ESMTP id DEE1150A516; Wed, 19 Jul 2006 09:59:23 -0600 (MDT) Message-ID: <44BE56DB.6050309@jabber.org> Date: Wed, 19 Jul 2006 09:59:23 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.4) Gecko/20060530 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Mridul Muralidharan Subject: Re: [xmppwg] Re: [Simple] "last call" on SIMPLE-XMPP interworking I-D References: <44BC53F8.30205@jabber.org> <2AE988AC-28FD-418F-8826-D96122C4BA23@jabber.com> <44BE4E31.9010307@jabber.org> <44BE562D.2080400@sun.com> In-Reply-To: <44BE562D.2080400@sun.com> X-Enigmail-Version: 0.94.0.0 Jabber-ID: stpeter@jabber.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: Joe Hildebrand , xmppwg@jabber.org, Adam Roach , Adam Roach , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 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="===============1443082333==" Errors-To: simple-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1443082333== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080505080502090607000401" This is a cryptographically signed message in MIME format. --------------ms080505080502090607000401 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mridul Muralidharan wrote: > Just to get it clarified , this amplification attack (or similar > behavior) is something that exists currently in the SIP/SIMPLE world , > irrespective of this XMPP gateway , right ? > If yes , then is this the right document to solve it in ? If no , > disregard this mail please. Yes, the denial of service attack exists in the SIP/SIMPLE world. Adam's point is that, because SIP subscriptions are short-lived whereas XMPP subscriptions are long-lived, there is an amplification factor here, thus making it easier to launch the denial of service attack from the XMPP side than from the SIP side. Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml --------------ms080505080502090607000401 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYVDCC B3AwggbZoAMCAQICAQkwDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0 MDUxNDUxMDNaFw0xMDA0MDQxNDUxMDNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVtYWlsIEZy ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAOOY75tn3YhiCOsNXQn9/4WfpNrX8HLIUlBTLrGtMINvcYJ0 3Nlr9kJyOF5Z8g+2G9Zg+zN8iWGBEpl37bgjYdea3q0AaO9uyZOMLa0rztjFeo7Uw8AjdDmW kaJQU1c6q9OoieOT6Tf4MvHMGqtbnaOL3Xvz4o6XnH+Ek9h8zPgYgiUw2tIF0ueLayTGiInH dWM5eYMoz7OnVlUeIurDweT4C9V1TtwplnhWZ7bilcuN4w3/8hndqryqqflbCMlLZWn+1uaT 21d12cdpjBOaqtg6hqiTY4S4+wVAmGrAiOPQ3Z574gljhUKf5ehz7p9xtsb+mjvM1I4yPP8/ vjKZoRUCAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud DgQWBBS4Zr17owi6irSy+USIcU+li0GzUTCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0 eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0 YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6 Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5 BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50 ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0 cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQDss9KK Fx/bCifYjAQTmBtRoHFsdR5ZQ1nlagXKoyJ+IwmdGdiYqAKeaDfjT6bTXHfQvK8kp5xSoz0I PcpSwztY7UKtylgJwplu1q6vjj4BGB621sD60qzirAhLSqxmpBgjl8HMMMoiM28DCLsshihl g7wG7Oi/rPIuR8dawiaDejCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STGCBCwwggQoAgEBMIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UE CBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2Vy dGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVt YWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAOhwMAkG BSsOAwIaBQCgggJJMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTA2MDcxOTE1NTkyM1owIwYJKoZIhvcNAQkEMRYEFOKKEGOo6nPMO+NLbhnk1dPp1zU4MFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHIBgkrBgEEAYI3EAQxgbowgbcwga8xCzAJ BgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAh BgNVBAsTGlNlY3VyZSBDZXJ0aWZpY2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBD bGFzcyAyIFByaW1hcnkgRW1haWwgRnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3Rh cnRjb20ub3JnAgMA6HAwgcoGCyqGSIb3DQEJEAILMYG6oIG3MIGvMQswCQYDVQQGEwJJTDEP MA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1 cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwID AOhwMA0GCSqGSIb3DQEBAQUABIIBAKpwJJ0LF9VRs5lQyXkFuC48EJUGao+0ZCPsBrPNhdqP K99hW7soO1FuQ63ZvqfX8JgvCne/apU7H0IVcG8Z3RlHHT8SHhEuhQsti0wmK9JI69yaePuY VwQnCXgD6unKT9yGBT98v8lNI4PveI7C/ikpmj9bvYJRqLCU7Xxn6a2QPMq4v1NtAocEXnIl YsQMd+XJYWkThNl/DC1kSfdXdpOJeuwIBmX9Sl5IXzjK2QEKYcpy/qimDS+5ANnBn5vyEIAp Dot0oaMjfhDNAXCVne1Q948JsiywOZJG8nWtV8CNgwqiHJL6FpPlRQ4TmNH6QS1qOrI6Fuwd Jhxf5NrhYxYAAAAAAAA= --------------ms080505080502090607000401-- --===============1443082333== 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://www1.ietf.org/mailman/listinfo/simple --===============1443082333==-- From simple-bounces@ietf.org Wed Jul 19 12:04:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3EXD-0000w9-AU; Wed, 19 Jul 2006 12:04:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3EXC-0000w3-Dk for simple@ietf.org; Wed, 19 Jul 2006 12:04:26 -0400 Received: from corp-fw-main.jabber.com ([207.182.164.14] helo=wrk187.corp.jabber.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3EXA-0006o6-PZ for simple@ietf.org; Wed, 19 Jul 2006 12:04:26 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by wrk187.corp.jabber.com (Postfix) with ESMTP id 7104A50A51E; Wed, 19 Jul 2006 10:04:26 -0600 (MDT) Message-ID: <44BE580A.3030207@jabber.org> Date: Wed, 19 Jul 2006 10:04:26 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.4) Gecko/20060530 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Adam Roach Subject: Re: [Simple] "last call" on SIMPLE-XMPP interworking I-D References: <44BC53F8.30205@jabber.org> <2AE988AC-28FD-418F-8826-D96122C4BA23@jabber.com> <44BE4E31.9010307@jabber.org> <44BE56EF.4030609@estacado.net> In-Reply-To: <44BE56EF.4030609@estacado.net> X-Enigmail-Version: 0.94.0.0 Jabber-ID: stpeter@jabber.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: Joe Hildebrand , xmppwg@jabber.org, Adam Roach , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 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="===============0553430024==" Errors-To: simple-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0553430024== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060601060600020404010609" This is a cryptographically signed message in MIME format. --------------ms060601060600020404010609 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Adam Roach wrote: > Peter Saint-Andre wrote: >> (3) Come up with another solution to the amplification attack scenario >> that Adam brought up. >> > > What about the ping-pong that I suggested? I freely admit that I > don't know enough about XMPP to predict what problems it may cause, but > a casual read of the related RFCs leads me to believe that it is a > pain-free solution to the problem with no user impacts. The problem is that the payload of the elements will presumably be qualified by a namespace that is yet to be defined (extensibility rocks) and therefore the attacker can simply feign ignorance and reply with a service unavailable error ("sorry, I don't understand that namespace"). Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml --------------ms060601060600020404010609 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYVDCC B3AwggbZoAMCAQICAQkwDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0 MDUxNDUxMDNaFw0xMDA0MDQxNDUxMDNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVtYWlsIEZy ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAOOY75tn3YhiCOsNXQn9/4WfpNrX8HLIUlBTLrGtMINvcYJ0 3Nlr9kJyOF5Z8g+2G9Zg+zN8iWGBEpl37bgjYdea3q0AaO9uyZOMLa0rztjFeo7Uw8AjdDmW kaJQU1c6q9OoieOT6Tf4MvHMGqtbnaOL3Xvz4o6XnH+Ek9h8zPgYgiUw2tIF0ueLayTGiInH dWM5eYMoz7OnVlUeIurDweT4C9V1TtwplnhWZ7bilcuN4w3/8hndqryqqflbCMlLZWn+1uaT 21d12cdpjBOaqtg6hqiTY4S4+wVAmGrAiOPQ3Z574gljhUKf5ehz7p9xtsb+mjvM1I4yPP8/ vjKZoRUCAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud DgQWBBS4Zr17owi6irSy+USIcU+li0GzUTCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0 eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0 YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6 Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5 BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50 ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0 cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQDss9KK Fx/bCifYjAQTmBtRoHFsdR5ZQ1nlagXKoyJ+IwmdGdiYqAKeaDfjT6bTXHfQvK8kp5xSoz0I PcpSwztY7UKtylgJwplu1q6vjj4BGB621sD60qzirAhLSqxmpBgjl8HMMMoiM28DCLsshihl g7wG7Oi/rPIuR8dawiaDejCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STGCBCwwggQoAgEBMIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UE CBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2Vy dGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVt YWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAOhwMAkG BSsOAwIaBQCgggJJMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTA2MDcxOTE2MDQyNlowIwYJKoZIhvcNAQkEMRYEFNx/Ibdc7Wqt5d0PsbXJVGXIZKCyMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHIBgkrBgEEAYI3EAQxgbowgbcwga8xCzAJ BgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAh BgNVBAsTGlNlY3VyZSBDZXJ0aWZpY2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBD bGFzcyAyIFByaW1hcnkgRW1haWwgRnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3Rh cnRjb20ub3JnAgMA6HAwgcoGCyqGSIb3DQEJEAILMYG6oIG3MIGvMQswCQYDVQQGEwJJTDEP MA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1 cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwID AOhwMA0GCSqGSIb3DQEBAQUABIIBACNlCo3qK2i8pq9RH02MOJWQBpbQfU9P9/SJTwK2Lu9S gZXMa0dxv4Vdr5EQCGiey26fv6UoeuuuoD7S47a+BBoyPjnnxrUnCtwU0Hu8LJDiHJzyOLGE G4Q3pW3+8vGRmtUzPOvAzdlixPtwTBJQEpCyouPkZXWc5/xcVQ5LD7YB+ukXk/DNTZb2LzwB GKXL0Ja6jk22xHs5hcFCNZE2bTcFK9BiIeYE7nKt+N2ATkGPtUvk01zi+nJEbC2BVGQXblQ7 UImHhdbuIcsevoOKeGY7kZHK9Fc6xnx6CzA5L3C0F4ctpzgDrAQlCKLKdTdm4mmOR2RmPncv PgGvkZygrVwAAAAAAAA= --------------ms060601060600020404010609-- --===============0553430024== 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://www1.ietf.org/mailman/listinfo/simple --===============0553430024==-- From simple-bounces@ietf.org Wed Jul 19 12:05:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3EY8-00013f-91; Wed, 19 Jul 2006 12:05:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3EY7-00013a-He for simple@ietf.org; Wed, 19 Jul 2006 12:05:23 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3EY6-0006vC-9y for simple@ietf.org; Wed, 19 Jul 2006 12:05:23 -0400 Received: from [192.168.0.102] (ppp-70-245-142-249.dsl.rcsntx.swbell.net [70.245.142.249]) (authenticated bits=0) by nostrum.com (8.13.6/8.13.6) with ESMTP id k6JG45fh021458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jul 2006 11:04:05 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <44BE580B.9040202@nostrum.com> Date: Wed, 19 Jul 2006 11:04:27 -0500 From: Adam Roach User-Agent: Thunderbird 1.5.0.4 (X11/20060614) MIME-Version: 1.0 To: Peter Saint-Andre Subject: Re: [Simple] "last call" on SIMPLE-XMPP interworking I-D References: <44BC53F8.30205@jabber.org> <2AE988AC-28FD-418F-8826-D96122C4BA23@jabber.com> <44BE4E31.9010307@jabber.org> In-Reply-To: <44BE4E31.9010307@jabber.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.245.142.249 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Joe Hildebrand , xmppwg@jabber.org, Adam Roach , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Peter Saint-Andre wrote: > (3) Come up with another solution to the amplification attack scenario > that Adam brought up. > What about the ping-pong that I suggested? I freely admit that I don't know enough about XMPP to predict what problems it may cause, but a casual read of the related RFCs leads me to believe that it is a pain-free solution to the problem with no user impacts. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 19 12:05:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3EYU-0001EQ-V0; Wed, 19 Jul 2006 12:05:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3EYT-0001EL-9N for simple@ietf.org; Wed, 19 Jul 2006 12:05:45 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3EYS-0006wL-1n for simple@ietf.org; Wed, 19 Jul 2006 12:05:45 -0400 Received: from [192.168.0.102] (ppp-70-245-142-249.dsl.rcsntx.swbell.net [70.245.142.249]) (authenticated bits=0) by nostrum.com (8.13.6/8.13.6) with ESMTP id k6JG4Sk2021476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jul 2006 11:04:28 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <44BE5822.8070007@nostrum.com> Date: Wed, 19 Jul 2006 11:04:50 -0500 From: Adam Roach User-Agent: Thunderbird 1.5.0.4 (X11/20060614) MIME-Version: 1.0 To: Mridul Muralidharan Subject: Re: [xmppwg] Re: [Simple] "last call" on SIMPLE-XMPP interworking I-D References: <44BC53F8.30205@jabber.org> <2AE988AC-28FD-418F-8826-D96122C4BA23@jabber.com> <44BE4E31.9010307@jabber.org> <44BE562D.2080400@sun.com> In-Reply-To: <44BE562D.2080400@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.245.142.249 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Joe Hildebrand , xmppwg@jabber.org, Adam Roach , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Mridul Muralidharan wrote: > > Just to get it clarified , this amplification attack (or similar > behavior) is something that exists currently in the SIP/SIMPLE world , > irrespective of this XMPP gateway , right ? No. The problem arises because of the gateway, and does not exist in its absence. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 19 12:06:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3EZe-0001Pr-Fg; Wed, 19 Jul 2006 12:06:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3EZd-0001Pi-BH for simple@ietf.org; Wed, 19 Jul 2006 12:06:57 -0400 Received: from corp-fw-main.jabber.com ([207.182.164.14] helo=wrk187.corp.jabber.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3EZb-0006z2-PD for simple@ietf.org; Wed, 19 Jul 2006 12:06:57 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by wrk187.corp.jabber.com (Postfix) with ESMTP id 9628650A521; Wed, 19 Jul 2006 10:06:57 -0600 (MDT) Message-ID: <44BE58A1.8020105@jabber.org> Date: Wed, 19 Jul 2006 10:06:57 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.4) Gecko/20060530 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Adam Roach Subject: Re: [xmppwg] Re: [Simple] "last call" on SIMPLE-XMPP interworking I-D References: <44BC53F8.30205@jabber.org> <2AE988AC-28FD-418F-8826-D96122C4BA23@jabber.com> <44BE4E31.9010307@jabber.org> <44BE562D.2080400@sun.com> <44BE5742.8080806@estacado.net> In-Reply-To: <44BE5742.8080806@estacado.net> X-Enigmail-Version: 0.94.0.0 Jabber-ID: stpeter@jabber.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: Mridul Muralidharan , Joe Hildebrand , xmppwg@jabber.org, Adam Roach , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 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="===============1668091546==" Errors-To: simple-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1668091546== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080806030908060804060806" This is a cryptographically signed message in MIME format. --------------ms080806030908060804060806 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Adam Roach wrote: > Mridul Muralidharan wrote: >> >> Just to get it clarified , this amplification attack (or similar >> behavior) is something that exists currently in the SIP/SIMPLE world , >> irrespective of this XMPP gateway , right ? > > No. The problem arises because of the gateway, and does not exist in its > absence. IMHO it's eminently possible to launch a denial of service attack on a SIP presence server without involving any gateways, but it is arguably easier (using less bandwidth and processor) through a gateway. Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml --------------ms080806030908060804060806 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYVDCC B3AwggbZoAMCAQICAQkwDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0 MDUxNDUxMDNaFw0xMDA0MDQxNDUxMDNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVtYWlsIEZy ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAOOY75tn3YhiCOsNXQn9/4WfpNrX8HLIUlBTLrGtMINvcYJ0 3Nlr9kJyOF5Z8g+2G9Zg+zN8iWGBEpl37bgjYdea3q0AaO9uyZOMLa0rztjFeo7Uw8AjdDmW kaJQU1c6q9OoieOT6Tf4MvHMGqtbnaOL3Xvz4o6XnH+Ek9h8zPgYgiUw2tIF0ueLayTGiInH dWM5eYMoz7OnVlUeIurDweT4C9V1TtwplnhWZ7bilcuN4w3/8hndqryqqflbCMlLZWn+1uaT 21d12cdpjBOaqtg6hqiTY4S4+wVAmGrAiOPQ3Z574gljhUKf5ehz7p9xtsb+mjvM1I4yPP8/ vjKZoRUCAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud DgQWBBS4Zr17owi6irSy+USIcU+li0GzUTCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0 eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0 YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6 Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5 BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50 ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0 cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQDss9KK Fx/bCifYjAQTmBtRoHFsdR5ZQ1nlagXKoyJ+IwmdGdiYqAKeaDfjT6bTXHfQvK8kp5xSoz0I PcpSwztY7UKtylgJwplu1q6vjj4BGB621sD60qzirAhLSqxmpBgjl8HMMMoiM28DCLsshihl g7wG7Oi/rPIuR8dawiaDejCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STGCBCwwggQoAgEBMIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UE CBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2Vy dGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVt YWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAOhwMAkG BSsOAwIaBQCgggJJMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTA2MDcxOTE2MDY1N1owIwYJKoZIhvcNAQkEMRYEFGoH4m9MZgVoVXvKJgoTlfbcwiR4MFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHIBgkrBgEEAYI3EAQxgbowgbcwga8xCzAJ BgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAh BgNVBAsTGlNlY3VyZSBDZXJ0aWZpY2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBD bGFzcyAyIFByaW1hcnkgRW1haWwgRnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3Rh cnRjb20ub3JnAgMA6HAwgcoGCyqGSIb3DQEJEAILMYG6oIG3MIGvMQswCQYDVQQGEwJJTDEP MA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1 cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwID AOhwMA0GCSqGSIb3DQEBAQUABIIBAGo20/auZWjkkarWU5Svot8/LAX1p3dekRVq70/k0gR5 DECyE02GvtASqKEbsez2HdMGPKE9giP3mGyjmoD961PS6KyRI6UEorpX03DGrOxjM50eAmnI /SLFAemm1tfXhJJNgkUsQqfnNrpSuxu/MB0ofkSZEhdxJDjWBRtK92TZkJjWyuZRPSOwZwHE 8ecM88QPJei++zQasvZnonj3XAidYVRcIu3tBKdSlK0T9bdt626F3erke0ym5z6GqecpAzCj TRXodTzCfNNLH39B2r5XeK9sWrIaA0sGTN0YZiYo5a/ugft+8ra2gYbelVBSSXU2/aFMRCSQ wwG6LrNwSjoAAAAAAAA= --------------ms080806030908060804060806-- --===============1668091546== 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://www1.ietf.org/mailman/listinfo/simple --===============1668091546==-- From simple-bounces@ietf.org Wed Jul 19 12:10:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Ed7-0002Gt-N6; Wed, 19 Jul 2006 12:10:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Ed5-0002FL-R1 for simple@ietf.org; Wed, 19 Jul 2006 12:10:31 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3Ed4-0007z7-2r for simple@ietf.org; Wed, 19 Jul 2006 12:10:31 -0400 Received: from [192.168.0.102] (ppp-70-245-142-249.dsl.rcsntx.swbell.net [70.245.142.249]) (authenticated bits=0) by nostrum.com (8.13.6/8.13.6) with ESMTP id k6JG9Bp5021802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jul 2006 11:09:12 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <44BE593D.3000703@nostrum.com> Date: Wed, 19 Jul 2006 11:09:33 -0500 From: Adam Roach User-Agent: Thunderbird 1.5.0.4 (X11/20060614) MIME-Version: 1.0 To: Peter Saint-Andre Subject: Re: [Simple] "last call" on SIMPLE-XMPP interworking I-D References: <44BC53F8.30205@jabber.org> <2AE988AC-28FD-418F-8826-D96122C4BA23@jabber.com> <44BE4E31.9010307@jabber.org> <44BE56EF.4030609@estacado.net> <44BE580A.3030207@jabber.org> In-Reply-To: <44BE580A.3030207@jabber.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.245.142.249 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Joe Hildebrand , xmppwg@jabber.org, Adam Roach , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Peter Saint-Andre wrote: > The problem is that the payload of the elements will presumably be > qualified by a namespace that is yet to be defined (extensibility rocks) > and therefore the attacker can simply feign ignorance and reply with a > service unavailable error ("sorry, I don't understand that namespace"). > Perfect! That would be absolutely sufficient to thwart the attack. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 19 12:14:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Egu-0003dP-RQ; Wed, 19 Jul 2006 12:14:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Egt-0003d4-04 for simple@ietf.org; Wed, 19 Jul 2006 12:14:27 -0400 Received: from corp-fw-main.jabber.com ([207.182.164.14] helo=wrk187.corp.jabber.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3Egq-0008HU-EW for simple@ietf.org; Wed, 19 Jul 2006 12:14:26 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by wrk187.corp.jabber.com (Postfix) with ESMTP id 3E46350A529; Wed, 19 Jul 2006 10:14:26 -0600 (MDT) Message-ID: <44BE5A61.4090602@jabber.org> Date: Wed, 19 Jul 2006 10:14:25 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.4) Gecko/20060530 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Adam Roach Subject: Re: [xmppwg] Re: [Simple] "last call" on SIMPLE-XMPP interworking I-D References: <44BC53F8.30205@jabber.org> <2AE988AC-28FD-418F-8826-D96122C4BA23@jabber.com> <44BE4E31.9010307@jabber.org> <44BE56EF.4030609@estacado.net> <44BE580A.3030207@jabber.org> <44BE593D.3000703@nostrum.com> In-Reply-To: <44BE593D.3000703@nostrum.com> X-Enigmail-Version: 0.94.0.0 Jabber-ID: stpeter@jabber.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: Joe Hildebrand , xmppwg@jabber.org, Adam Roach , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 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="===============0115010997==" Errors-To: simple-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0115010997== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040804050003020206090708" This is a cryptographically signed message in MIME format. --------------ms040804050003020206090708 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Adam Roach wrote: > Peter Saint-Andre wrote: >> The problem is that the payload of the elements will presumably be >> qualified by a namespace that is yet to be defined (extensibility rocks) >> and therefore the attacker can simply feign ignorance and reply with a >> service unavailable error ("sorry, I don't understand that namespace"). >> > > Perfect! That would be absolutely sufficient to thwart the attack. Well, OK then. :-) BTW, in XMPP semantics, an entity MUST reply to the IQ request (with success or an error). Of course if the entity is an attacker then it could violate the semantics of the XMPP stanza, but there's not much we can do about that (though I suppose in that case the gateway could refuse to communicate with the attacker). Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml --------------ms040804050003020206090708 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYVDCC B3AwggbZoAMCAQICAQkwDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0 MDUxNDUxMDNaFw0xMDA0MDQxNDUxMDNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVtYWlsIEZy ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAOOY75tn3YhiCOsNXQn9/4WfpNrX8HLIUlBTLrGtMINvcYJ0 3Nlr9kJyOF5Z8g+2G9Zg+zN8iWGBEpl37bgjYdea3q0AaO9uyZOMLa0rztjFeo7Uw8AjdDmW kaJQU1c6q9OoieOT6Tf4MvHMGqtbnaOL3Xvz4o6XnH+Ek9h8zPgYgiUw2tIF0ueLayTGiInH dWM5eYMoz7OnVlUeIurDweT4C9V1TtwplnhWZ7bilcuN4w3/8hndqryqqflbCMlLZWn+1uaT 21d12cdpjBOaqtg6hqiTY4S4+wVAmGrAiOPQ3Z574gljhUKf5ehz7p9xtsb+mjvM1I4yPP8/ vjKZoRUCAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud DgQWBBS4Zr17owi6irSy+USIcU+li0GzUTCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0 eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0 YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6 Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5 BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50 ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0 cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQDss9KK Fx/bCifYjAQTmBtRoHFsdR5ZQ1nlagXKoyJ+IwmdGdiYqAKeaDfjT6bTXHfQvK8kp5xSoz0I PcpSwztY7UKtylgJwplu1q6vjj4BGB621sD60qzirAhLSqxmpBgjl8HMMMoiM28DCLsshihl g7wG7Oi/rPIuR8dawiaDejCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STGCBCwwggQoAgEBMIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UE CBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2Vy dGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVt YWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAOhwMAkG BSsOAwIaBQCgggJJMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTA2MDcxOTE2MTQyNVowIwYJKoZIhvcNAQkEMRYEFCFLdRENh+D/nPA1cy1ko+kTD8kOMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHIBgkrBgEEAYI3EAQxgbowgbcwga8xCzAJ BgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAh BgNVBAsTGlNlY3VyZSBDZXJ0aWZpY2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBD bGFzcyAyIFByaW1hcnkgRW1haWwgRnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3Rh cnRjb20ub3JnAgMA6HAwgcoGCyqGSIb3DQEJEAILMYG6oIG3MIGvMQswCQYDVQQGEwJJTDEP MA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1 cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwID AOhwMA0GCSqGSIb3DQEBAQUABIIBACdgAKRwHRcYo5JLIn3QkQU+1dglsD9Dmd/SmzyKuXNG GjgAhUNL6JgZJIwk1dvx1wOAU/lMA+Oq6sajMVmPiDq7g3vTzRtDHT8dokBQMRpYZBy0XqNv fRWmM9J3jCRU0Qg3G4sH3tb7biZarpzBDVMBxDJdqljBe0Fe18+dojiKjsVMbQ/U9a9M2o9q iaB2NoxVp2roXprgI0+08LoFRcwuqqGA49w4Fw4MOMju4I39TFPjqMbnf6SC3GqmaRxEf/hi 5ywLRHA0s8T/bFXozn9og+5sg8l4uOd+m0XLCMXDPtBBPYll44z3PjODrISHv3y3DyHWmb1x 4nSssMQI1eUAAAAAAAA= --------------ms040804050003020206090708-- --===============0115010997== 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://www1.ietf.org/mailman/listinfo/simple --===============0115010997==-- From simple-bounces@ietf.org Wed Jul 19 12:22:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3EoM-0005gH-6q; Wed, 19 Jul 2006 12:22:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3EoK-0005gC-6Z for simple@ietf.org; Wed, 19 Jul 2006 12:22:08 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3EoI-0000hf-OH for simple@ietf.org; Wed, 19 Jul 2006 12:22:08 -0400 Received: from [192.168.0.102] (ppp-70-245-142-249.dsl.rcsntx.swbell.net [70.245.142.249]) (authenticated bits=0) by nostrum.com (8.13.6/8.13.6) with ESMTP id k6JGKoZt022438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jul 2006 11:20:50 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <44BE5BF8.3040303@nostrum.com> Date: Wed, 19 Jul 2006 11:21:12 -0500 From: Adam Roach User-Agent: Thunderbird 1.5.0.4 (X11/20060614) MIME-Version: 1.0 To: Peter Saint-Andre Subject: Re: [xmppwg] Re: [Simple] "last call" on SIMPLE-XMPP interworking I-D References: <44BC53F8.30205@jabber.org> <2AE988AC-28FD-418F-8826-D96122C4BA23@jabber.com> <44BE4E31.9010307@jabber.org> <44BE56EF.4030609@estacado.net> <44BE580A.3030207@jabber.org> <44BE593D.3000703@nostrum.com> <44BE5A61.4090602@jabber.org> In-Reply-To: <44BE5A61.4090602@jabber.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.245.142.249 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Joe Hildebrand , xmppwg@jabber.org, Adam Roach , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Peter Saint-Andre wrote: > Adam Roach wrote: > >> Peter Saint-Andre wrote: >> >>> The problem is that the payload of the elements will presumably be >>> qualified by a namespace that is yet to be defined (extensibility rocks) >>> and therefore the attacker can simply feign ignorance and reply with a >>> service unavailable error ("sorry, I don't understand that namespace"). >>> >>> >> Perfect! That would be absolutely sufficient to thwart the attack. >> > > Well, OK then. :-) > > BTW, in XMPP semantics, an entity MUST reply to the IQ request (with > success or an error). Of course if the entity is an attacker then it > could violate the semantics of the XMPP stanza, but there's not > much we can do about that (though I suppose in that case the gateway > could refuse to communicate with the attacker). > That's the entire point: if the attacker fails to respond to the stanza (i.e. isn't willing to do a commensurate amount of work), then the gateway fails to refresh the subscription. That's what I meant by, "As long as the gateway requires an ***EXCHANGE*** with the subscribing user's XMPP server for each SIP SUBSCRIBE refresh, then we're requiring any potential attacker to do the work on the same order of magnitude as the gateway, which thwarts the amplification attack..." /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 19 12:28:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Eum-0001ol-FS; Wed, 19 Jul 2006 12:28:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Euk-0001ob-PQ for simple@ietf.org; Wed, 19 Jul 2006 12:28:46 -0400 Received: from corp-fw-main.jabber.com ([207.182.164.14] helo=wrk187.corp.jabber.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3Eui-0002Nz-6w for simple@ietf.org; Wed, 19 Jul 2006 12:28:46 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by wrk187.corp.jabber.com (Postfix) with ESMTP id CA6B450A539; Wed, 19 Jul 2006 10:28:45 -0600 (MDT) Message-ID: <44BE5DBD.1060601@jabber.org> Date: Wed, 19 Jul 2006 10:28:45 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.4) Gecko/20060530 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Adam Roach Subject: Re: [xmppwg] Re: [Simple] "last call" on SIMPLE-XMPP interworking I-D References: <44BC53F8.30205@jabber.org> <2AE988AC-28FD-418F-8826-D96122C4BA23@jabber.com> <44BE4E31.9010307@jabber.org> <44BE56EF.4030609@estacado.net> <44BE580A.3030207@jabber.org> <44BE593D.3000703@nostrum.com> <44BE5A61.4090602@jabber.org> <44BE5BF8.3040303@nostrum.com> In-Reply-To: <44BE5BF8.3040303@nostrum.com> X-Enigmail-Version: 0.94.0.0 Jabber-ID: stpeter@jabber.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: Joe Hildebrand , xmppwg@jabber.org, Adam Roach , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 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="===============1307410177==" Errors-To: simple-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1307410177== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070505010201030806080007" This is a cryptographically signed message in MIME format. --------------ms070505010201030806080007 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Adam Roach wrote: > Peter Saint-Andre wrote: >> Adam Roach wrote: >> >>> Peter Saint-Andre wrote: >>> >>>> The problem is that the payload of the elements will >>>> presumably be >>>> qualified by a namespace that is yet to be defined (extensibility >>>> rocks) >>>> and therefore the attacker can simply feign ignorance and reply with a >>>> service unavailable error ("sorry, I don't understand that namespace"). >>>> >>> Perfect! That would be absolutely sufficient to thwart the attack. >>> >> >> Well, OK then. :-) >> >> BTW, in XMPP semantics, an entity MUST reply to the IQ request (with >> success or an error). Of course if the entity is an attacker then it >> could violate the semantics of the XMPP stanza, but there's not >> much we can do about that (though I suppose in that case the gateway >> could refuse to communicate with the attacker). >> > > That's the entire point: if the attacker fails to respond to the > stanza (i.e. isn't willing to do a commensurate amount of work), then > the gateway fails to refresh the subscription. That's what I meant by, > "As long as the gateway requires an ***EXCHANGE*** with the > subscribing user's XMPP server for each SIP SUBSCRIBE refresh, then > we're requiring any potential attacker to do the work on the same order > of magnitude as the gateway, which thwarts the amplification attack..." OK, I will write up some revised text sometime soon that incorporates this approach. Thanks! Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml --------------ms070505010201030806080007 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYVDCC B3AwggbZoAMCAQICAQkwDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0 MDUxNDUxMDNaFw0xMDA0MDQxNDUxMDNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVtYWlsIEZy ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAOOY75tn3YhiCOsNXQn9/4WfpNrX8HLIUlBTLrGtMINvcYJ0 3Nlr9kJyOF5Z8g+2G9Zg+zN8iWGBEpl37bgjYdea3q0AaO9uyZOMLa0rztjFeo7Uw8AjdDmW kaJQU1c6q9OoieOT6Tf4MvHMGqtbnaOL3Xvz4o6XnH+Ek9h8zPgYgiUw2tIF0ueLayTGiInH dWM5eYMoz7OnVlUeIurDweT4C9V1TtwplnhWZ7bilcuN4w3/8hndqryqqflbCMlLZWn+1uaT 21d12cdpjBOaqtg6hqiTY4S4+wVAmGrAiOPQ3Z574gljhUKf5ehz7p9xtsb+mjvM1I4yPP8/ vjKZoRUCAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud DgQWBBS4Zr17owi6irSy+USIcU+li0GzUTCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0 eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0 YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6 Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5 BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50 ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0 cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQDss9KK Fx/bCifYjAQTmBtRoHFsdR5ZQ1nlagXKoyJ+IwmdGdiYqAKeaDfjT6bTXHfQvK8kp5xSoz0I PcpSwztY7UKtylgJwplu1q6vjj4BGB621sD60qzirAhLSqxmpBgjl8HMMMoiM28DCLsshihl g7wG7Oi/rPIuR8dawiaDejCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STGCBCwwggQoAgEBMIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UE CBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2Vy dGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVt YWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAOhwMAkG BSsOAwIaBQCgggJJMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTA2MDcxOTE2Mjg0NVowIwYJKoZIhvcNAQkEMRYEFIsv13cXazPMHJBjGHOZZataKwsuMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHIBgkrBgEEAYI3EAQxgbowgbcwga8xCzAJ BgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAh BgNVBAsTGlNlY3VyZSBDZXJ0aWZpY2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBD bGFzcyAyIFByaW1hcnkgRW1haWwgRnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3Rh cnRjb20ub3JnAgMA6HAwgcoGCyqGSIb3DQEJEAILMYG6oIG3MIGvMQswCQYDVQQGEwJJTDEP MA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1 cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwID AOhwMA0GCSqGSIb3DQEBAQUABIIBAHvKEp+31pi15iZFk6+YCrgRI7SUcQmKRpcU935I0A4h JzCIjPIZ+1RT31T4DNbZPoJlknc8j8UxqoVbIOYGD4Mz6J77Ep1aXtPFDuzMGabKzrVY0pd0 domGQD/amLSI/jDxuTJama1obRqaqJt+fkvFEkEldsbv3rjM0h/qvDP9JD5CFM3BCUH5ZPFF H0Yw1YmvKbzHHtNBVOirYEcO92Cgot77AJNigsNE/ymybo9Jy5MIlMjW9vQJpaTPz/1FPpzi uMBhl2o6jy2KvIAp8azd1bB59IlGdeSyf6TpD8dT3Mfx43pUwO2ehca62YuAGiMKoeeisiBK WU6aj+EKEcwAAAAAAAA= --------------ms070505010201030806080007-- --===============1307410177== 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://www1.ietf.org/mailman/listinfo/simple --===============1307410177==-- From simple-bounces@ietf.org Wed Jul 19 13:04:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3FTV-00010E-KK; Wed, 19 Jul 2006 13:04:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3FTU-000109-A7 for simple@ietf.org; Wed, 19 Jul 2006 13:04:40 -0400 Received: from exchange.jabber.com ([207.182.164.133] helo=ossex1.jabber.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3FTS-0007NZ-TW for simple@ietf.org; Wed, 19 Jul 2006 13:04:40 -0400 Received: from [IPv6:::1] (gatekeeper-int.jabber.com [10.101.0.11]) by ossex1.jabber.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 34X9H7JX; Wed, 19 Jul 2006 11:05:08 -0600 In-Reply-To: <44BE5DBD.1060601@jabber.org> References: <44BC53F8.30205@jabber.org> <2AE988AC-28FD-418F-8826-D96122C4BA23@jabber.com> <44BE4E31.9010307@jabber.org> <44BE56EF.4030609@estacado.net> <44BE580A.3030207@jabber.org> <44BE593D.3000703@nostrum.com> <44BE5A61.4090602@jabber.org> <44BE5BF8.3040303@nostrum.com> <44BE5DBD.1060601@jabber.org> Mime-Version: 1.0 (Apple Message framework v752.2) Jabber-Id: jhildebrand@corp.jabber.com Message-Id: <04FC0039-1A6B-4BCE-9EE7-63E75CEC9CA9@jabber.com> From: Joe Hildebrand Subject: Re: [xmppwg] Re: [Simple] "last call" on SIMPLE-XMPP interworking I-D Date: Wed, 19 Jul 2006 11:04:36 -0600 To: Peter Saint-Andre X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: xmppwg@jabber.org, Adam Roach , Adam Roach , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 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="===============0563071514==" Errors-To: simple-bounces@ietf.org --===============0563071514== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-12--1072182138; protocol="application/pkcs7-signature" --Apple-Mail-12--1072182138 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed And you thereby made it so that existing clients cannot use the gateway. That doesn't sound too good to me, either. Would it be good enough to suggest that a gateway SHOULD send an existing, highly-implemented iq protocol, like a disco#info? (See http://www.jabber.org/jeps/jep-0030.html) On Jul 19, 2006, at 10:28 AM, Peter Saint-Andre wrote: > Adam Roach wrote: >> Peter Saint-Andre wrote: >>> Adam Roach wrote: >>> >>>> Peter Saint-Andre wrote: >>>> >>>>> The problem is that the payload of the elements will >>>>> presumably be >>>>> qualified by a namespace that is yet to be defined (extensibility >>>>> rocks) >>>>> and therefore the attacker can simply feign ignorance and reply >>>>> with a >>>>> service unavailable error ("sorry, I don't understand that >>>>> namespace"). >>>>> >>>> Perfect! That would be absolutely sufficient to thwart the attack. >>>> >>> >>> Well, OK then. :-) >>> >>> BTW, in XMPP semantics, an entity MUST reply to the IQ request (with >>> success or an error). Of course if the entity is an attacker then it >>> could violate the semantics of the XMPP stanza, but there's >>> not >>> much we can do about that (though I suppose in that case the gateway >>> could refuse to communicate with the attacker). >>> >> >> That's the entire point: if the attacker fails to respond to the >> >> stanza (i.e. isn't willing to do a commensurate amount of work), then >> the gateway fails to refresh the subscription. That's what I meant >> by, >> "As long as the gateway requires an ***EXCHANGE*** with the >> subscribing user's XMPP server for each SIP SUBSCRIBE refresh, then >> we're requiring any potential attacker to do the work on the same >> order >> of magnitude as the gateway, which thwarts the amplification >> attack..." > > OK, I will write up some revised text sometime soon that incorporates > this approach. > > Thanks! > > Peter > > -- > Peter Saint-Andre > Jabber Software Foundation > http://www.jabber.org/people/stpeter.shtml > --Apple-Mail-12--1072182138 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEdzCCBHMw ggJboAMCAQICAwFnvTANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTA4MjUxOTU2NDZaFw0w NjA4MjUxOTU2NDZaMEAxFzAVBgNVBAMTDkpvZSBIaWxkZWJyYW5kMSUwIwYJKoZIhvcNAQkBFhZq aGlsZGVicmFuZEBqYWJiZXIuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCq49BpJX8D ehvNyc0WzQCIau00T/do5DPCoavn3P+IpTyKGXwUzTTdoCNDvj8H6p4xLSUx5M8h3X6sFQ1/fz/j Qn4cUnCnCpPIA1XRTaudpY+Q8XVVK0txU5yOP5nGppMM0KaT7OqclF7bP6dfrD4nJo7I0D3Fl0th yEtnxlE+3QIDAQABo4HAMIG9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5 b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9y ZzAhBgNVHREEGjAYgRZqaGlsZGVicmFuZEBqYWJiZXIuY29tMA0GCSqGSIb3DQEBBAUAA4ICAQA0 rYT+WImu2hfUZBQ4a8Sys/11H2EjB8DqQdI5A7EJtHnQsR6nO2muym2k9fB8FRMf9BIzhsknGOB+ DqBgvqFn+KrFfVnty3zfHwl6ogbogk3eLiezbBtvsfB0pHfKiRos4P7ivzPNLdyNNjG2NF7bwCt9 vvHq2KEsTWX18BjVv5PezK//LngXt6EW4O61+aBGWgRiQ18vM9jAuEATMHMxyeIbCtBSLyv/St86 pB8oOrMYopOCtPKMqmzctIe1evPmro6FuQxvGtyWDd1rRdy40t6LhXEcDqDzsUfvtSOeRAvEf63g C2BQtWaw2jHmoIXigopZVs89ZWUsMkowEl2P7hQ5mffpQEDcfNcfDQ51yjHKfeSuOyFkj5hmnZpO TJMX9Ileo6A5MIdHcKwT6v6h6jfz/mH30XQYB0Wu+2vlPhBITBICubp68YL0BVf7BKFqANjMDfX+ QCGEUcpIzbnFHY+OHFiJFVs/nnYVRzGF8YaX8UFeSla4rYsyiOnyUOLNSKXdR4BM8SsIj2K/9IxL PQHG7xa3yDlQZ/11sPvDTfyEA/D/wDjDzobh/t0hED2og+tTqbno3JXVqY2YQKkiN+tjeD0z7FKf 0UZjg983pAW3wpFFc6PkihG6a2mZ15klMeub+hHhzaERMrXLekFi4Yn66QeksQUnKO2fQIviiTGC ArIwggKuAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2Fj ZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJ ARYSc3VwcG9ydEBjYWNlcnQub3JnAgMBZ70wCQYFKw4DAhoFAKCCAYcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwNzE5MTcwNDM3WjAjBgkqhkiG9w0BCQQxFgQU jnjSdEb77OraqaHIxODA9pDoQzcwgZEGCSsGAQQBgjcQBDGBgzCBgDB5MRAwDgYDVQQKEwdSb290 IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2ln bmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDAWe9MIGT BgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8v d3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkq hkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDAWe9MA0GCSqGSIb3DQEBAQUABIGASYtfwyFP X4Hk1HfoLcpl2URsC57VfT61fZrS31tQim2W5cHMLEyHWspE/ltDGwcrGM0EBf49NNMX/Pzt+NZQ xu6f6T379hrTF79dim61c0Z82TM/W9/ltyhhPZpErfKgaravfolSBLos8Z3LQLoDBGeJNPjYnwj4 ieDzlvKoByUAAAAAAAA= --Apple-Mail-12--1072182138-- --===============0563071514== 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://www1.ietf.org/mailman/listinfo/simple --===============0563071514==-- From simple-bounces@ietf.org Wed Jul 19 14:31:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3GpH-0008VR-By; Wed, 19 Jul 2006 14:31:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3GpF-0008UL-P4 for simple@ietf.org; Wed, 19 Jul 2006 14:31:13 -0400 Received: from corp-fw-main.jabber.com ([207.182.164.14] helo=wrk187.corp.jabber.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3DsX-00024r-1g for simple@ietf.org; Wed, 19 Jul 2006 11:22:28 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by wrk187.corp.jabber.com (Postfix) with ESMTP id 68E0F50A4FE; Wed, 19 Jul 2006 09:22:26 -0600 (MDT) Message-ID: <44BE4E31.9010307@jabber.org> Date: Wed, 19 Jul 2006 09:22:25 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.4) Gecko/20060530 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Joe Hildebrand Subject: Re: [Simple] "last call" on SIMPLE-XMPP interworking I-D References: <44BC53F8.30205@jabber.org> <2AE988AC-28FD-418F-8826-D96122C4BA23@jabber.com> In-Reply-To: <2AE988AC-28FD-418F-8826-D96122C4BA23@jabber.com> X-Enigmail-Version: 0.94.0.0 Jabber-ID: stpeter@jabber.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: xmppwg@jabber.org, Adam Roach , Adam Roach , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 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="===============1445753447==" Errors-To: simple-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1445753447== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070006010800080400090807" This is a cryptographically signed message in MIME format. --------------ms070006010800080400090807 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Joe Hildebrand wrote: > > stpeter writes: > >> Note: The XMPP-SIMPLE gateway MUST honor the short-lived subscription >> semantics of SIP presence subscriptions rather than the long-lived >> subscription semantics of XMPP presence subscriptions by passing along >> all subscription renewals (i.e., subsequent SUBSCRIBE requests) from the >> SIP user to the XMPP user in the form of XMPP presence stanzas of type >> "unsubscribe", thus forcing the XMPP user to resubscribe to the presence >> of the SIP user; this helps to avoid possible amplification attacks >> caused by the mismatch between long-lived XMPP subscriptions and >> short-lived SIP subscriptions. > > Whoa. Really? I can't imagine any of my users being willing to deploy > such a system. We can't change the existing clients to handle these > transparently, so this means their contacts on the other end of a SIMPLE > gateway are going to be continuously disappearing. That's true, from the XMPP side of things this results in client behavior that will seem very broken. You have three alternatives: (1) Accept the foregoing text and implement a non-conforming service. (2) Make a better argument than I did for saying that a gateway SHOULD honor short-lived subscriptions semantics on the XMPP side but MAY honor long-lived subscription semantics in certain circumstances. (3) Come up with another solution to the amplification attack scenario that Adam brought up. :-) Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml --------------ms070006010800080400090807 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYVDCC B3AwggbZoAMCAQICAQkwDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0 MDUxNDUxMDNaFw0xMDA0MDQxNDUxMDNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVtYWlsIEZy ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAOOY75tn3YhiCOsNXQn9/4WfpNrX8HLIUlBTLrGtMINvcYJ0 3Nlr9kJyOF5Z8g+2G9Zg+zN8iWGBEpl37bgjYdea3q0AaO9uyZOMLa0rztjFeo7Uw8AjdDmW kaJQU1c6q9OoieOT6Tf4MvHMGqtbnaOL3Xvz4o6XnH+Ek9h8zPgYgiUw2tIF0ueLayTGiInH dWM5eYMoz7OnVlUeIurDweT4C9V1TtwplnhWZ7bilcuN4w3/8hndqryqqflbCMlLZWn+1uaT 21d12cdpjBOaqtg6hqiTY4S4+wVAmGrAiOPQ3Z574gljhUKf5ehz7p9xtsb+mjvM1I4yPP8/ vjKZoRUCAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud DgQWBBS4Zr17owi6irSy+USIcU+li0GzUTCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0 eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0 YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6 Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5 BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50 ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0 cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQDss9KK Fx/bCifYjAQTmBtRoHFsdR5ZQ1nlagXKoyJ+IwmdGdiYqAKeaDfjT6bTXHfQvK8kp5xSoz0I PcpSwztY7UKtylgJwplu1q6vjj4BGB621sD60qzirAhLSqxmpBgjl8HMMMoiM28DCLsshihl g7wG7Oi/rPIuR8dawiaDejCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STGCBCwwggQoAgEBMIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UE CBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2Vy dGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVt YWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAOhwMAkG BSsOAwIaBQCgggJJMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTA2MDcxOTE1MjIyNVowIwYJKoZIhvcNAQkEMRYEFOihI8KQqGjTWDctvcnWVMDcQBofMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHIBgkrBgEEAYI3EAQxgbowgbcwga8xCzAJ BgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAh BgNVBAsTGlNlY3VyZSBDZXJ0aWZpY2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBD bGFzcyAyIFByaW1hcnkgRW1haWwgRnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3Rh cnRjb20ub3JnAgMA6HAwgcoGCyqGSIb3DQEJEAILMYG6oIG3MIGvMQswCQYDVQQGEwJJTDEP MA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1 cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwID AOhwMA0GCSqGSIb3DQEBAQUABIIBAGTm6BOTpDTBePTfHXsHMhZwSCGWpSvZMfB/djqvKIch 5j9QgY8Eg8MjzZsbMyVWwSFKziefWd1l8Q9BZKyeBUdp/qFfSEuzVNKDaUyVC2qEl2WGcVvo jzmdBS7LY8lqdDgeixpoplXAA68HMhaTT8AlzDIoIqDbwGojiRmCt2zxCzztedlQjCxcrZSm Fh3TnlXzqDbb56bhq7kv3M8EHLQNNxj1xMPE983fg5R/rL+YUHRCBZm0gj0dRKUDc8D6nyh5 /7puHl6hoowydPujXHN/w2kiVJTf17kXd63ZlZ6jk9j3o9mLiao6JsgIFjOYMUpvVzllB4zi x5ryJiGG/hcAAAAAAAA= --------------ms070006010800080400090807-- --===============1445753447== 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://www1.ietf.org/mailman/listinfo/simple --===============1445753447==-- From simple-bounces@ietf.org Wed Jul 19 15:06:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3HNS-00020U-Fy; Wed, 19 Jul 2006 15:06:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3HNQ-00020P-Tg for simple@ietf.org; Wed, 19 Jul 2006 15:06:32 -0400 Received: from corp-fw-main.jabber.com ([207.182.164.14] helo=wrk187.corp.jabber.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3HNO-0002St-8x for simple@ietf.org; Wed, 19 Jul 2006 15:06:32 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by wrk187.corp.jabber.com (Postfix) with ESMTP id 3D1B650A5B1; Wed, 19 Jul 2006 13:06:31 -0600 (MDT) Message-ID: <44BE82B6.3050604@jabber.org> Date: Wed, 19 Jul 2006 13:06:30 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.4) Gecko/20060530 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Mridul Muralidharan Subject: Re: [xmppwg] Re: [Simple] "last call" on SIMPLE-XMPP interworking I-D References: <44BC53F8.30205@jabber.org> <2AE988AC-28FD-418F-8826-D96122C4BA23@jabber.com> <44BE4E31.9010307@jabber.org> <44BE56EF.4030609@estacado.net> <44BE580A.3030207@jabber.org> <44BE593D.3000703@nostrum.com> <44BE5A61.4090602@jabber.org> <44BE70D6.90707@sun.com> In-Reply-To: <44BE70D6.90707@sun.com> X-Enigmail-Version: 0.94.0.0 Jabber-ID: stpeter@jabber.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Cc: Joe Hildebrand , xmppwg@jabber.org, Adam Roach , Adam Roach , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 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="===============0064495100==" Errors-To: simple-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0064495100== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000700070103050208070102" This is a cryptographically signed message in MIME format. --------------ms000700070103050208070102 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mridul Muralidharan wrote: > Peter Saint-Andre wrote: >> Adam Roach wrote: >> >>> Peter Saint-Andre wrote: >>> >>>> The problem is that the payload of the elements will >>>> presumably be >>>> qualified by a namespace that is yet to be defined (extensibility >>>> rocks) >>>> and therefore the attacker can simply feign ignorance and reply with a >>>> service unavailable error ("sorry, I don't understand that namespace"). >>>> >>> Perfect! That would be absolutely sufficient to thwart the attack. >>> >> >> Well, OK then. :-) >> >> BTW, in XMPP semantics, an entity MUST reply to the IQ request (with >> success or an error). Of course if the entity is an attacker then it >> could violate the semantics of the XMPP stanza, but there's not >> much we can do about that (though I suppose in that case the gateway >> could refuse to communicate with the attacker). >> >> Peter >> >> > Hi Peter, > > So the gateway will drop session's which do not respond within > reasonable time/reply with iq error ? > Is this going to be something that will be sent to the user or to the > hosting xmpp server ? > > If it is going to be sent to the user , then we are not going to get > much traction with this approach - most clients will drop it. Do most clients currently drop disco#info requests? RFC 3920 says you must at least respond with an error if you don't implement something (and disco#info is very widely implemented). > Even a server is not going to help much ... you will need a new breed of > SIP-SIMPLE/XMPP gateway aware servers before the gateway can 'talk' to > them. > If the intention is that the gateway wants to 'behave' as yet another > XMPP server then none of the existing XMPP server will interop with it > until they implement this required extension. > > Just a thought - instead of a iq extension , why not get the gateway to > probe for the presence status of the xmpp user ? Sure, that's another possibility -- it puts the onus on the server, not the client. My sense from Adam's original description of the attack was that he thought it would be launched from a rogue server, but if the attack were launched from zombie clients the server would take the hit here and it's up to the server admins to deal with their zombie users appropriately. /me ponders Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml --------------ms000700070103050208070102 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYVDCC B3AwggbZoAMCAQICAQkwDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0 MDUxNDUxMDNaFw0xMDA0MDQxNDUxMDNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVtYWlsIEZy ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAOOY75tn3YhiCOsNXQn9/4WfpNrX8HLIUlBTLrGtMINvcYJ0 3Nlr9kJyOF5Z8g+2G9Zg+zN8iWGBEpl37bgjYdea3q0AaO9uyZOMLa0rztjFeo7Uw8AjdDmW kaJQU1c6q9OoieOT6Tf4MvHMGqtbnaOL3Xvz4o6XnH+Ek9h8zPgYgiUw2tIF0ueLayTGiInH dWM5eYMoz7OnVlUeIurDweT4C9V1TtwplnhWZ7bilcuN4w3/8hndqryqqflbCMlLZWn+1uaT 21d12cdpjBOaqtg6hqiTY4S4+wVAmGrAiOPQ3Z574gljhUKf5ehz7p9xtsb+mjvM1I4yPP8/ vjKZoRUCAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud DgQWBBS4Zr17owi6irSy+USIcU+li0GzUTCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0 eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0 YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6 Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5 BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50 ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0 cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQDss9KK Fx/bCifYjAQTmBtRoHFsdR5ZQ1nlagXKoyJ+IwmdGdiYqAKeaDfjT6bTXHfQvK8kp5xSoz0I PcpSwztY7UKtylgJwplu1q6vjj4BGB621sD60qzirAhLSqxmpBgjl8HMMMoiM28DCLsshihl g7wG7Oi/rPIuR8dawiaDejCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STGCBCwwggQoAgEBMIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UE CBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2Vy dGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVt YWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAOhwMAkG BSsOAwIaBQCgggJJMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTA2MDcxOTE5MDYzMFowIwYJKoZIhvcNAQkEMRYEFBvi9sMA5KyMios5vxoW9oXJRtTzMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHIBgkrBgEEAYI3EAQxgbowgbcwga8xCzAJ BgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAh BgNVBAsTGlNlY3VyZSBDZXJ0aWZpY2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBD bGFzcyAyIFByaW1hcnkgRW1haWwgRnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3Rh cnRjb20ub3JnAgMA6HAwgcoGCyqGSIb3DQEJEAILMYG6oIG3MIGvMQswCQYDVQQGEwJJTDEP MA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1 cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwID AOhwMA0GCSqGSIb3DQEBAQUABIIBACdJE13DZZ/nanMUz8XvAeyssq/iTt/gkphigheQgh6I A/yMYQ0A4O05pbxvwKA8OrYjGhMsmO1mlCco5HFjO0ZVdCT1nI3ZKwyT30+wgl2GV9AoA6+h PEfUT8HPDIgOCvEdrf+D5H7u5a71Zeosgsx1a52wfbqDLaXwo9wtHpJ5x+3y+qe/mq+XNmPc 2BuEtGWWE0bYaKY0jTwOi/1jbpghdZqWFY6W/Ujq9i6gwq0JMjpt2QJtFYIpD8hVLJ1LZLVX YRhdg/U5vCuKQND4FH2vfsSr5+MmV3fMa/Gfveh+so24G9aZ/ZC1qjgcxtK9D8RchuJlxx9Y t3qTBjdmGm8AAAAAAAA= --------------ms000700070103050208070102-- --===============0064495100== 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://www1.ietf.org/mailman/listinfo/simple --===============0064495100==-- From simple-bounces@ietf.org Wed Jul 19 15:11:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3HSF-0002RR-KP; Wed, 19 Jul 2006 15:11:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3HSE-0002RJ-8C for simple@ietf.org; Wed, 19 Jul 2006 15:11:30 -0400 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3HSC-0003Ru-Pf for simple@ietf.org; Wed, 19 Jul 2006 15:11:30 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.50) id 1G3HSB-0002kN-UJ; Wed, 19 Jul 2006 19:11:28 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id B21C4498004; Wed, 19 Jul 2006 20:14:06 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26903-07; Wed, 19 Jul 2006 20:14:01 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id BCF26498002; Wed, 19 Jul 2006 20:14:01 +0100 (BST) Date: Wed, 19 Jul 2006 20:11:20 +0100 Subject: Re: [xmppwg] Re: [Simple] "last call" on SIMPLE-XMPP interworking I-D References: <44BC53F8.30205@jabber.org> <2AE988AC-28FD-418F-8826-D96122C4BA23@jabber.com> <29267.1153323628.817914@peirce.dave.cridland.net> <44BE55B8.8000909@jabber.org> In-Reply-To: <44BE55B8.8000909@jabber.org> MIME-Version: 1.0 Message-Id: <29267.1153336281.292141@peirce.dave.cridland.net> From: Dave Cridland To: Peter Saint-Andre Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Heisenberg-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: Joe Hildebrand , Mailing list of the IETF's XMPP Working Group , Adam Roach , Adam Roach , SIP for Instant Messaging and Presence Leveraging Extensions X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org On Wed Jul 19 16:54:32 2006, Peter Saint-Andre wrote: > Dave Cridland wrote: > > I suspect that the simplest method is to recommend restricting > access to > > the XMPP side of the XMPP/SIMPLE gateway to a single XMPP domain, > and > > recommending that sensible limits should be put on the number of > users > > allowed to connect to a server from the same address. > > > This, I think, forces such an attack to be done by the attacker > finding > > a bunch of zombie machines creating the users on the XMPP domain > (if > > possible), and performing the subscription. The thing is, why on > earth > > would you bother when you could just flood the SIP presence server > > directly with your zombie army? > > Because, according to Adam, the mismatch between SIP presence > subscriptions (short-lived) and XMPP presence subscriptions > (long-lived) > means that the attacker can save some bytes by attacking from the > XMPP > side of the wormhole rather than from the SIP side, thus presumably > making the attack less expensive in terms of bandwidth and > processor. Yes. Now re-read the paragraphs I've quoted of my own again, this time together as opposed to in isolation. A traditional "Jabber transport" would allow gatewaying through it from any Jid. If instead the XMPP/SIMPLE transport only allows gatewaying through it from its local XMPP domain, then in order to mount the attack, the attacker has to obtain several thousand accounts on that server. Now, this ought to be very easily detectable - a sudden surge of thousands of account creations is bound to raise some eyebrows, and if the accounts aren't created via JEP-0077, but via an "email the password" style mechanism, this is going to be considerably harder to manage. It'd be virtually impossible to do this anyway on a single machine - you'd need perhaps one machine for every five accounts within your control to hope not to be noticed or hit some limits. That's logistically quite a tall order, no matter how many zombies there are these days. Also, it means that in order to create the XMPP sessions, register the user, and so on, it's going to cost the attacker considerably more before the amplification attack starts to kick in - and since you require such a huge zombie army to mount the attack anyway, you might as well attack directly. But, if you can write yourself a few servers, instead of clients, to do this work, you need far fewer zombie machines, and much less resource, since you can more or less setup a dummy s2s and start spewing presence stanzas about. That's why I'm proposing that a large part of the solution - without crippling XMPP in the process - ought to involve prevention of this method. Of course, you could combine both Adam's proposal and this - only remote clients get the spurious hacks. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 19 15:11:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3HSH-0002Sv-23; Wed, 19 Jul 2006 15:11:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3HSG-0002Rm-36 for simple@ietf.org; Wed, 19 Jul 2006 15:11:32 -0400 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3HSE-0003S0-6N for simple@ietf.org; Wed, 19 Jul 2006 15:11:32 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.50) id 1G3HSD-0007Nf-Ew; Wed, 19 Jul 2006 19:11:29 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 448B1498002; Wed, 19 Jul 2006 20:14:08 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26970-06; Wed, 19 Jul 2006 20:14:04 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id F18BD498003; Wed, 19 Jul 2006 20:14:03 +0100 (BST) Date: Wed, 19 Jul 2006 20:11:23 +0100 Subject: Re: [xmppwg] Re: [Simple] "last call" on SIMPLE-XMPP interworking I-D References: <44BC53F8.30205@jabber.org> <2AE988AC-28FD-418F-8826-D96122C4BA23@jabber.com> <44BE4E31.9010307@jabber.org> <44BE56EF.4030609@estacado.net> <44BE580A.3030207@jabber.org> <44BE593D.3000703@nostrum.com> <44BE5A61.4090602@jabber.org> <44BE70D6.90707@sun.com> In-Reply-To: <44BE70D6.90707@sun.com> MIME-Version: 1.0 Message-Id: <29267.1153336283.535540@peirce.dave.cridland.net> From: Dave Cridland To: Mridul Muralidharan Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Pythagoras-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Joe Hildebrand , Mailing list of the IETF's XMPP Working Group , Adam Roach , SIP for Instant Messaging and Presence Leveraging Extensions X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org On Wed Jul 19 18:50:14 2006, Mridul Muralidharan wrote: > Peter Saint-Andre wrote: >> Adam Roach wrote: >>> Perfect! That would be absolutely sufficient to thwart the attack. >>> >> >> Well, OK then. :-) >> >> BTW, in XMPP semantics, an entity MUST reply to the IQ request >> (with >> success or an error). Of course if the entity is an attacker then >> it >> could violate the semantics of the XMPP stanza, but there's >> not >> much we can do about that (though I suppose in that case the >> gateway >> could refuse to communicate with the attacker). >> >> Peter >> >> > Hi Peter, > > So the gateway will drop session's which do not respond within > reasonable time/reply with iq error ? > Is this going to be something that will be sent to the user or to > the hosting xmpp server ? > > If it is going to be sent to the user , then we are not going to > get much traction with this approach - most clients will drop it. Well, quite possibly, yes. They'd be breaking XMPP, but they might drop it, and I know some clients do. > Even a server is not going to help much ... you will need a new > breed of SIP-SIMPLE/XMPP gateway aware servers before the gateway > can 'talk' to them. No, you need compliant XMPP clients. Nothing special needs to be done for this solution. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 19 15:49:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3I2w-0002UJ-8Z; Wed, 19 Jul 2006 15:49:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3I2v-0002UE-IN for simple@ietf.org; Wed, 19 Jul 2006 15:49:25 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3I2u-0002vJ-1e for simple@ietf.org; Wed, 19 Jul 2006 15:49:25 -0400 Received: from [192.168.0.102] (ppp-70-245-142-249.dsl.rcsntx.swbell.net [70.245.142.249]) (authenticated bits=0) by nostrum.com (8.13.6/8.13.6) with ESMTP id k6JJm3aW032286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jul 2006 14:48:03 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <44BE8C89.6080004@nostrum.com> Date: Wed, 19 Jul 2006 14:48:25 -0500 From: Adam Roach User-Agent: Thunderbird 1.5.0.4 (X11/20060614) MIME-Version: 1.0 To: Dave Cridland Subject: Re: [xmppwg] Re: [Simple] "last call" on SIMPLE-XMPP interworking I-D References: <44BC53F8.30205@jabber.org> <2AE988AC-28FD-418F-8826-D96122C4BA23@jabber.com> <29267.1153323628.817914@peirce.dave.cridland.net> <44BE55B8.8000909@jabber.org> <29267.1153336281.292141@peirce.dave.cridland.net> In-Reply-To: <29267.1153336281.292141@peirce.dave.cridland.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.245.142.249 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Joe Hildebrand , Mailing list of the IETF's XMPP Working Group , Adam Roach , SIP for Instant Messaging and Presence Leveraging Extensions X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Dave Cridland wrote: > A traditional "Jabber transport" would allow gatewaying through it > from any Jid. If instead the XMPP/SIMPLE transport only allows > gatewaying through it from its local XMPP domain, then in order to > mount the attack, the attacker has to obtain several thousand accounts > on that server. As far as I can tell, this solves the problem; however, I think it breaks the solution for most deployments as well. I foresee these gateways being deployed primarily by enterprises who are using one system (SIMPLE or XMPP) so that their users can communicate with enterprises using the other. Limiting interworking to local users makes such use impossible. > Of course, you could combine both Adam's proposal and this - only > remote clients get the spurious hacks. This sounds like a reasonable balance. I think you could extend it further and assert that the exchanges are required *except* for servers on a "known good" list provisioned by the gateway administrator. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 19 16:05:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3IIX-0007Fy-Ss; Wed, 19 Jul 2006 16:05:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3IIW-0007Ft-2b for simple@ietf.org; Wed, 19 Jul 2006 16:05:32 -0400 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3IIU-0006v6-PJ for simple@ietf.org; Wed, 19 Jul 2006 16:05:32 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.50) id 1G3IIU-0007Ko-36; Wed, 19 Jul 2006 20:05:30 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 2AA76498003; Wed, 19 Jul 2006 21:08:09 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27352-07; Wed, 19 Jul 2006 21:07:59 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 6C102498002; Wed, 19 Jul 2006 21:07:59 +0100 (BST) Date: Wed, 19 Jul 2006 21:05:17 +0100 Subject: Re: [xmppwg] Re: [Simple] "last call" on SIMPLE-XMPP interworking I-D References: <44BC53F8.30205@jabber.org> <2AE988AC-28FD-418F-8826-D96122C4BA23@jabber.com> <44BE4E31.9010307@jabber.org> <44BE56EF.4030609@estacado.net> <44BE580A.3030207@jabber.org> <44BE593D.3000703@nostrum.com> <44BE5A61.4090602@jabber.org> <44BE70D6.90707@sun.com> <29267.1153336283.535540@peirce.dave.cridland.net> <44BE907C.5060705@sun.com> In-Reply-To: <44BE907C.5060705@sun.com> MIME-Version: 1.0 Message-Id: <29267.1153339518.614506@peirce.dave.cridland.net> From: Dave Cridland To: Mridul Muralidharan Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Rutherford-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Joe Hildebrand , Mailing list of the IETF's XMPP Working Group , Adam Roach , SIP for Instant Messaging and Presence Leveraging Extensions X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org On Wed Jul 19 21:05:16 2006, Mridul Muralidharan wrote: > Hi Dave, > > By drop I was including both cases - ignoring the packet or sending > back an iq error. > In both cases , the required functionality is breaking I guess ? > > Adam's proposal treats an iq error as a satisfactory response. Dave -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 19 16:11:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3INz-0007rD-Uh; Wed, 19 Jul 2006 16:11:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3INy-0007r7-MV for simple@ietf.org; Wed, 19 Jul 2006 16:11:10 -0400 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3INw-0008IJ-J3 for simple@ietf.org; Wed, 19 Jul 2006 16:11:10 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.50) id 1G3INw-00013l-2b; Wed, 19 Jul 2006 20:11:08 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 78660498003; Wed, 19 Jul 2006 21:13:48 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27484-01; Wed, 19 Jul 2006 21:13:39 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 6B065498002; Wed, 19 Jul 2006 21:13:39 +0100 (BST) Date: Wed, 19 Jul 2006 21:10:58 +0100 Subject: Re: [xmppwg] Re: [Simple] "last call" on SIMPLE-XMPP interworking I-D References: <44BC53F8.30205@jabber.org> <2AE988AC-28FD-418F-8826-D96122C4BA23@jabber.com> <29267.1153323628.817914@peirce.dave.cridland.net> <44BE55B8.8000909@jabber.org> <29267.1153336281.292141@peirce.dave.cridland.net> <44BE8C89.6080004@nostrum.com> In-Reply-To: <44BE8C89.6080004@nostrum.com> MIME-Version: 1.0 Message-Id: <29267.1153339858.550339@peirce.dave.cridland.net> From: Dave Cridland To: Adam Roach Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Rutherford-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Joe Hildebrand , Mailing list of the IETF's XMPP Working Group , Adam Roach , SIP for Instant Messaging and Presence Leveraging Extensions X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org On Wed Jul 19 20:48:25 2006, Adam Roach wrote: > Dave Cridland wrote: >> A traditional "Jabber transport" would allow gatewaying through it >> from any Jid. If instead the XMPP/SIMPLE transport only allows >> gatewaying through it from its local XMPP domain, then in order to >> mount the attack, the attacker has to obtain several thousand >> accounts on that server. > > As far as I can tell, this solves the problem; however, I think it > breaks the solution for most deployments as well. I foresee these > gateways being deployed primarily by enterprises who are using one > system (SIMPLE or XMPP) so that their users can communicate with > enterprises using the other. Limiting interworking to local users > makes such use impossible. > > Ah... I'm just limiting XMPP usage to local XMPP users. Any SIMPLE user can use the gateway. So for enterprises using XMPP "natively", they would need to run an XMPP/SIMPLE gateway (or be on the known good list of another, to borrow your suggestion below, but I think in practise they'll want their own). SIMPLE enterprises don't have to run a gateway, although they may wish to if they want to ensure they have access to one. >> Of course, you could combine both Adam's proposal and this - only >> remote clients get the spurious hacks. > > This sounds like a reasonable balance. I think you could extend it > further and assert that the exchanges are required *except* > for servers on a "known good" list provisioned by the gateway > administrator. Yes, true. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 19 16:27:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Ie0-00017q-PH; Wed, 19 Jul 2006 16:27:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Idz-00017l-8H for simple@ietf.org; Wed, 19 Jul 2006 16:27:43 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3Idy-0000qG-0J for simple@ietf.org; Wed, 19 Jul 2006 16:27:43 -0400 Received: from [192.168.0.102] (ppp-70-245-142-249.dsl.rcsntx.swbell.net [70.245.142.249]) (authenticated bits=0) by nostrum.com (8.13.6/8.13.6) with ESMTP id k6JKQNiM034128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jul 2006 15:26:24 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <44BE9586.4000908@nostrum.com> Date: Wed, 19 Jul 2006 15:26:46 -0500 From: Adam Roach User-Agent: Thunderbird 1.5.0.4 (X11/20060614) MIME-Version: 1.0 To: Dave Cridland Subject: Re: [xmppwg] Re: [Simple] "last call" on SIMPLE-XMPP interworking I-D References: <44BC53F8.30205@jabber.org> <2AE988AC-28FD-418F-8826-D96122C4BA23@jabber.com> <29267.1153323628.817914@peirce.dave.cridland.net> <44BE55B8.8000909@jabber.org> <29267.1153336281.292141@peirce.dave.cridland.net> <44BE8C89.6080004@nostrum.com> <29267.1153339858.550339@peirce.dave.cridland.net> In-Reply-To: <29267.1153339858.550339@peirce.dave.cridland.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.245.142.249 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Joe Hildebrand , Mailing list of the IETF's XMPP Working Group , SIP for Instant Messaging and Presence Leveraging Extensions X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Dave Cridland wrote: > Ah... I'm just limiting XMPP usage to local XMPP users. Any SIMPLE > user can use the gateway. > > So for enterprises using XMPP "natively", they would need to run an > XMPP/SIMPLE gateway (or be on the known good list of another, to > borrow your suggestion below, but I think in practise they'll want > their own). > > SIMPLE enterprises don't have to run a gateway, although they may wish > to if they want to ensure they have access to one. While this is a valid deployment model, it is not the one supported by the name resolution procedures currently in Peter's draft. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 19 18:46:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Ko8-000876-Mk; Wed, 19 Jul 2006 18:46:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Ko6-00086P-Sc; Wed, 19 Jul 2006 18:46:18 -0400 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3Ko5-0000m3-KR; Wed, 19 Jul 2006 18:46:18 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k6JMkB3i017697; Wed, 19 Jul 2006 17:46:12 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k6JMkAC24682; Wed, 19 Jul 2006 17:46:10 -0500 (CDT) Message-ID: <44BEB632.9020006@lucent.com> Date: Wed, 19 Jul 2006 17:46:10 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Froment Subject: Re: [Simple] UDP - what if response is bigger than 1500 bytes (ethernet MTU)? References: <3ACC9A25264A684F82C71840111F979801EC5E54@carrera.eu.tieto.com> <44BE3426.3050502@alcatel.fr> In-Reply-To: <44BE3426.3050502@alcatel.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: sip@ietf.org, Milan.Kunc@tietoenator.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Thomas Froment wrote: > This is a good question: I think it was mentionned in last SIP WG IETF > meeting that having responses greater than path MTU (-200 bytes) > in SIP was not currently well specified. It was an open issue on > draft-ietf-sip-hop-limit-diagnostics-03.txt which raises this problem > since it leads naturally to send big SIP responses. > SIP WG people may probably answer you if something is planned to handle > this problem... This remains a problem; I have had a quick chat with Scott Lawrence on it and we'll be submitting a draft latter part of next week on one way to deal with this. Thanks. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 20 04:55:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3UJi-0002gl-8s; Thu, 20 Jul 2006 04:55:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3UJg-0002gc-IC for simple@ietf.org; Thu, 20 Jul 2006 04:55:32 -0400 Received: from mga06.intel.com ([134.134.136.21] helo=orsmga101.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3UJe-0001ST-PR for simple@ietf.org; Thu, 20 Jul 2006 04:55:32 -0400 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 20 Jul 2006 01:55:28 -0700 Received: from azsmsx334.amr.corp.intel.com ([10.2.121.57]) by orsmga001.jf.intel.com with ESMTP; 20 Jul 2006 01:54:54 -0700 X-IronPort-AV: i="4.07,160,1151910000"; d="p7s'?scan'208"; a="67955620:sNHT2719996580" Received: from azsmsx331.amr.corp.intel.com ([10.2.161.41]) by azsmsx334.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 01:54:53 -0700 Received: from mail pickup service by azsmsx331.amr.corp.intel.com with Microsoft SMTPSVC; Thu, 20 Jul 2006 01:54:52 -0700 Received: from azsmsx333.amr.corp.intel.com ([10.2.121.77]) by azsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 12:42:06 -0700 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmsx333.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 12:33:54 -0700 Received: from azsmga101.ch.intel.com ([10.2.16.36]) by azsmga001.ch.intel.com with ESMTP; 19 Jul 2006 12:10:11 -0700 Received: from atlas.jabber.org ([208.245.212.69]) by azsmga101.ch.intel.com with ESMTP; 19 Jul 2006 12:09:52 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,260,1149490800"; d="p7s'?scan'208"; a="89583971:sNHT291467344" Received: from atlas.jabber.org (localhost [127.0.0.1]) by atlas.jabber.org (Postfix) with ESMTP id 3A3EE21A904; Wed, 19 Jul 2006 14:09:18 -0500 (CDT) X-Original-To: xmppwg@jabber.org Delivered-To: xmppwg@jabber.org Received: from wrk187.corp.jabber.com (corp-fw-main.jabber.com [207.182.164.14]) by atlas.jabber.org (Postfix) with ESMTP id 8C68421A288 for ; Wed, 19 Jul 2006 14:06:29 -0500 (CDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by wrk187.corp.jabber.com (Postfix) with ESMTP id 3D1B650A5B1; Wed, 19 Jul 2006 13:06:31 -0600 (MDT) Message-ID: <44BE82B6.3050604@jabber.org> Date: Wed, 19 Jul 2006 13:06:30 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.4) Gecko/20060530 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Mridul Muralidharan Subject: Re: [xmppwg] Re: [Simple] "last call" on SIMPLE-XMPP interworking I-D References: <44BC53F8.30205@jabber.org> <2AE988AC-28FD-418F-8826-D96122C4BA23@jabber.com> <44BE4E31.9010307@jabber.org> <44BE56EF.4030609@estacado.net> <44BE580A.3030207@jabber.org> <44BE593D.3000703@nostrum.com> <44BE5A61.4090602@jabber.org> <44BE70D6.90707@sun.com> In-Reply-To: <44BE70D6.90707@sun.com> X-Enigmail-Version: 0.94.0.0 Jabber-ID: stpeter@jabber.org X-Mailman-Approved-At: Wed, 19 Jul 2006 14:09:15 -0500 X-BeenThere: xmppwg@jabber.org X-Mailman-Version: 2.1.5 Precedence: list X-OriginalArrivalTime: 19 Jul 2006 19:33:54.0434 (UTC) FILETIME=[454F3620:01C6AB6A] X-Spam-Score: 0.0 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Cc: Joe Hildebrand , xmppwg@jabber.org, Adam Roach , simple@ietf.org X-BeenThere: simple@ietf.org 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="===============1258263636==" Errors-To: simple-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1258263636== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000700070103050208070102" This is a cryptographically signed message in MIME format. --------------ms000700070103050208070102 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mridul Muralidharan wrote: > Peter Saint-Andre wrote: >> Adam Roach wrote: >> >>> Peter Saint-Andre wrote: >>> >>>> The problem is that the payload of the elements will >>>> presumably be >>>> qualified by a namespace that is yet to be defined (extensibility >>>> rocks) >>>> and therefore the attacker can simply feign ignorance and reply with a >>>> service unavailable error ("sorry, I don't understand that namespace"). >>>> >>> Perfect! That would be absolutely sufficient to thwart the attack. >>> >> >> Well, OK then. :-) >> >> BTW, in XMPP semantics, an entity MUST reply to the IQ request (with >> success or an error). Of course if the entity is an attacker then it >> could violate the semantics of the XMPP stanza, but there's not >> much we can do about that (though I suppose in that case the gateway >> could refuse to communicate with the attacker). >> >> Peter >> >> > Hi Peter, > > So the gateway will drop session's which do not respond within > reasonable time/reply with iq error ? > Is this going to be something that will be sent to the user or to the > hosting xmpp server ? > > If it is going to be sent to the user , then we are not going to get > much traction with this approach - most clients will drop it. Do most clients currently drop disco#info requests? RFC 3920 says you must at least respond with an error if you don't implement something (and disco#info is very widely implemented). > Even a server is not going to help much ... you will need a new breed of > SIP-SIMPLE/XMPP gateway aware servers before the gateway can 'talk' to > them. > If the intention is that the gateway wants to 'behave' as yet another > XMPP server then none of the existing XMPP server will interop with it > until they implement this required extension. > > Just a thought - instead of a iq extension , why not get the gateway to > probe for the presence status of the xmpp user ? Sure, that's another possibility -- it puts the onus on the server, not the client. My sense from Adam's original description of the attack was that he thought it would be launched from a rogue server, but if the attack were launched from zombie clients the server would take the hit here and it's up to the server admins to deal with their zombie users appropriately. /me ponders Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml --------------ms000700070103050208070102 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYVDCC B3AwggbZoAMCAQICAQkwDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0 MDUxNDUxMDNaFw0xMDA0MDQxNDUxMDNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVtYWlsIEZy ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAOOY75tn3YhiCOsNXQn9/4WfpNrX8HLIUlBTLrGtMINvcYJ0 3Nlr9kJyOF5Z8g+2G9Zg+zN8iWGBEpl37bgjYdea3q0AaO9uyZOMLa0rztjFeo7Uw8AjdDmW kaJQU1c6q9OoieOT6Tf4MvHMGqtbnaOL3Xvz4o6XnH+Ek9h8zPgYgiUw2tIF0ueLayTGiInH dWM5eYMoz7OnVlUeIurDweT4C9V1TtwplnhWZ7bilcuN4w3/8hndqryqqflbCMlLZWn+1uaT 21d12cdpjBOaqtg6hqiTY4S4+wVAmGrAiOPQ3Z574gljhUKf5ehz7p9xtsb+mjvM1I4yPP8/ vjKZoRUCAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud DgQWBBS4Zr17owi6irSy+USIcU+li0GzUTCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0 eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0 YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6 Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5 BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50 ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0 cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQDss9KK Fx/bCifYjAQTmBtRoHFsdR5ZQ1nlagXKoyJ+IwmdGdiYqAKeaDfjT6bTXHfQvK8kp5xSoz0I PcpSwztY7UKtylgJwplu1q6vjj4BGB621sD60qzirAhLSqxmpBgjl8HMMMoiM28DCLsshihl g7wG7Oi/rPIuR8dawiaDejCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STGCBCwwggQoAgEBMIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UE CBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2Vy dGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVt YWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAOhwMAkG BSsOAwIaBQCgggJJMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTA2MDcxOTE5MDYzMFowIwYJKoZIhvcNAQkEMRYEFBvi9sMA5KyMios5vxoW9oXJRtTzMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHIBgkrBgEEAYI3EAQxgbowgbcwga8xCzAJ BgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAh BgNVBAsTGlNlY3VyZSBDZXJ0aWZpY2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBD bGFzcyAyIFByaW1hcnkgRW1haWwgRnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3Rh cnRjb20ub3JnAgMA6HAwgcoGCyqGSIb3DQEJEAILMYG6oIG3MIGvMQswCQYDVQQGEwJJTDEP MA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1 cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwID AOhwMA0GCSqGSIb3DQEBAQUABIIBACdJE13DZZ/nanMUz8XvAeyssq/iTt/gkphigheQgh6I A/yMYQ0A4O05pbxvwKA8OrYjGhMsmO1mlCco5HFjO0ZVdCT1nI3ZKwyT30+wgl2GV9AoA6+h PEfUT8HPDIgOCvEdrf+D5H7u5a71Zeosgsx1a52wfbqDLaXwo9wtHpJ5x+3y+qe/mq+XNmPc 2BuEtGWWE0bYaKY0jTwOi/1jbpghdZqWFY6W/Ujq9i6gwq0JMjpt2QJtFYIpD8hVLJ1LZLVX YRhdg/U5vCuKQND4FH2vfsSr5+MmV3fMa/Gfveh+so24G9aZ/ZC1qjgcxtK9D8RchuJlxx9Y t3qTBjdmGm8AAAAAAAA= --------------ms000700070103050208070102-- --===============1258263636== 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://www1.ietf.org/mailman/listinfo/simple --===============1258263636==-- From simple-bounces@ietf.org Thu Jul 20 09:33:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Yek-0007Kh-9f; Thu, 20 Jul 2006 09:33:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Yei-0007K2-JF for Simple@ietf.org; Thu, 20 Jul 2006 09:33:32 -0400 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3Yeh-0007jF-4B for Simple@ietf.org; Thu, 20 Jul 2006 09:33:32 -0400 Received: by ug-out-1314.google.com with SMTP id m2so827039uge for ; Thu, 20 Jul 2006 06:33:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=ctzX9aGXLbYdW+LOirC4uvTuOf0A8RfA8PJ+U6sxpuc95dLa67SoblwxOG/ZUHbiibrmmry6CeE9kT9MxeDMBb1MUj14Qz0HYJy2apybHWebDya/87YklOeZMSzg+97LZmu/XxBDvrzcxnD1RiLYcHzlnBUicUXCXd2SQPxo2MQ= Received: by 10.67.19.13 with SMTP id w13mr1904534ugi; Thu, 20 Jul 2006 06:33:28 -0700 (PDT) Received: by 10.67.20.20 with HTTP; Thu, 20 Jul 2006 06:33:27 -0700 (PDT) Message-ID: <44781c350607200633i3aa04d39k3a65313043ea7402@mail.gmail.com> Date: Thu, 20 Jul 2006 16:33:27 +0300 From: "Noga Tor" To: "Tschofenig, Hannes" Subject: Re: [Simple] Applying the Policy Authorization Rules In-Reply-To: MIME-Version: 1.0 References: X-Spam-Score: 0.1 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: Simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 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="===============0700799228==" Errors-To: simple-bounces@ietf.org --===============0700799228== Content-Type: multipart/alternative; boundary="----=_Part_161797_8176968.1153402407865" ------=_Part_161797_8176968.1153402407865 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I mean Main Uri ====== pres:Alice@example.com Alias Uri ====== im:Alice@im.com a subscription is generated: FROM: im:Alice@im.com TO: im:Bob@im.com while the Bob's Authorization policy contains a rule referring pres:Alice@example.com On 7/20/06, Tschofenig, Hannes wrote: > > Hi Noga, > > you seem to be talking about the common policy draft. > > What is an "alias" for you when it comes to an authenticated identity? > > Ciao > Hannes > > > > ------------------------------ > *Von:* Noga Tor [mailto:noga.tor@gmail.com] > *Gesendet:* Donnerstag, 20. Juli 2006 13:20 > *An:* Simple@ietf.org > *Betreff:* [Simple] Applying the Policy Authorization Rules > > > > Hi > > I have a question regarding the Policy Authorization Rules: > > If we match a rule's identity (,) against the wacther identity, > how do we handle aliases: > 1) do we consider the rule matched only if the common-policy document > contains a uri that equals exactly to the alias used by the watcher? > 2) do we need to determine the global uri of the watcher and/or the global > uri of the policy's rule and see if they both refer to the same Presentity? > > > Thanks > Noga > > ------=_Part_161797_8176968.1153402407865 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I mean
 
Main Uri
======
 
Alias Uri
======
 
a subscription is generated:
 
while the Bob's Authorization policy contains a rule referring pres:Alice@example.com
 
 


 
On 7/20/06, Tschofenig, Hannes <hannes.tschofenig@siemens.com> wrote:
Hi Noga,
 
you seem to be talking about the common policy draft.
 
What is an "alias" for you when it comes to an authenticated identity?
 
Ciao
Hannes
 
 

Von: Noga Tor [mailto:noga.tor@gmail.com ]
Gesendet: Donnerstag, 20. Juli 2006 13:20
An: Simple@ietf.org
Betreff: [Simple] Applying the Policy Authorization Rules

 
Hi
 
I have a question regarding the Policy Authorization Rules:
 
If we match a rule's identity (<one>,<id>) against the wacther identity, how do we handle aliases:
1) do we consider the rule matched only if the common-policy document contains a uri that equals exactly to the alias used by the watcher?
2) do we need to determine the global uri of the watcher and/or the global uri of the policy's rule and see if they both refer to the same Presentity?
 
 
Thanks
Noga

------=_Part_161797_8176968.1153402407865-- --===============0700799228== 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://www1.ietf.org/mailman/listinfo/simple --===============0700799228==-- From simple-bounces@ietf.org Thu Jul 20 09:57:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Z2C-0008PT-Lf; Thu, 20 Jul 2006 09:57:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Z2B-0008Of-5c for Simple@ietf.org; Thu, 20 Jul 2006 09:57:47 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3Z2B-0001et-4A for Simple@ietf.org; Thu, 20 Jul 2006 09:57:47 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G3Z0x-0003Mb-2f for Simple@ietf.org; Thu, 20 Jul 2006 09:56:36 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k6KDuRgM031411; Thu, 20 Jul 2006 15:56:27 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k6KDuREC013297; Thu, 20 Jul 2006 15:56:27 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 15:56:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: AW: [Simple] Applying the Policy Authorization Rules Date: Thu, 20 Jul 2006 15:56:23 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Applying the Policy Authorization Rules thread-index: AcasAR5aDYHwtmscTH+OzC1FaB2fawAAt6NQ From: "Tschofenig, Hannes" To: "Noga Tor" X-OriginalArrivalTime: 20 Jul 2006 13:56:27.0275 (UTC) FILETIME=[4B79ADB0:01C6AC04] X-Spam-Score: -2.6 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: Simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi Noga,=20 =20 if the authorization policies indicate Alice@example.com and someone shows up with Alice@im.com then the rules do not fire. You need to list both identities in the authorization policies.=20 You would have todo this anyway even with an alias since otherwise there wouldn't be a way for the server to figure out what todo.=20 =20 Ciao Hannes =20 ________________________________ Von: Noga Tor [mailto:noga.tor@gmail.com]=20 Gesendet: Donnerstag, 20. Juli 2006 15:33 An: Tschofenig, Hannes Cc: Simple@ietf.org Betreff: Re: [Simple] Applying the Policy Authorization Rules =09 =09 I mean=20 =20 Main Uri =3D=3D=3D=3D=3D=3D pres:Alice@example.com =20 Alias Uri =3D=3D=3D=3D=3D=3D im:Alice@im.com =20 a subscription is generated: FROM: im:Alice@im.com=20 TO: im:Bob@im.com =20 while the Bob's Authorization policy contains a rule referring pres:Alice@example.com =20 =20 =20 On 7/20/06, Tschofenig, Hannes wrote:=20 Hi Noga,=20 =20 you seem to be talking about the common policy draft.=20 =20 What is an "alias" for you when it comes to an authenticated identity? =20 Ciao Hannes =20 =20 =09 =09 ________________________________ Von: Noga Tor [mailto:noga.tor@gmail.com ]=20 Gesendet: Donnerstag, 20. Juli 2006 13:20 An: Simple@ietf.org=20 Betreff: [Simple] Applying the Policy Authorization Rules =09 =20 Hi =20 I have a question regarding the Policy Authorization Rules: =20 If we match a rule's identity (,) against the wacther identity, how do we handle aliases: 1) do we consider the rule matched only if the common-policy document contains a uri that equals exactly to the alias used by the watcher? 2) do we need to determine the global uri of the watcher and/or the global uri of the policy's rule and see if they both refer to the same Presentity? =20 =20 Thanks Noga =09 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 20 18:50:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3hLp-0001xr-Ev; Thu, 20 Jul 2006 18:50:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3hLn-0001wR-DF; Thu, 20 Jul 2006 18:50:35 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3hLF-0000JS-Ps; Thu, 20 Jul 2006 18:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k6KMo1p0013895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Jul 2006 22:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G3hLF-00055P-F2; Thu, 20 Jul 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 20 Jul 2006 18:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-partial-publish-05.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 : Publication of Partial Presence Information Author(s) : M. Lonnfors, et al. Filename : draft-ietf-simple-partial-publish-05.txt Pages : 16 Date : 2006-7-20 The Session Initiation Protocol (SIP) Extension for Event State Publication describes a mechanism with which a presence user agent is able to publish presence information to a presence agent. Using the Presence Information Data Format (PIDF), each presence publication contains full state, regardless of how much of that information has actually changed since the previous update. As a consequence, updating a sizeable presence document with small changes bear a considerable overhead and is therefore inefficient. Especially with low bandwidth and high latency links, this can constitue a considerable burden to the system. This memo defines a solution that aids in reducing the impact of those constraints and increases transport efficiency by introducing a mechanism that allows for publication of partial presence information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-publish-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-partial-publish-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-partial-publish-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-7-20150100.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-partial-publish-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-partial-publish-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-7-20150100.I-D@ietf.org> --OtherAccess-- --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://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Fri Jul 21 04:09:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3q3j-0007rZ-B1; Fri, 21 Jul 2006 04:08:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3q3W-0007gq-H3; Fri, 21 Jul 2006 04:08:18 -0400 Received: from jes-fe1.zx.nl ([194.187.76.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3puz-0007DH-UP; Fri, 21 Jul 2006 03:59:31 -0400 Received: from Inbox ([89.205.129.36]) by jes-fe1.zx.nl (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTP id <0J2Q0094IWRMZQ40@jes-fe1.zx.nl>; Fri, 21 Jul 2006 09:55:06 +0100 (WEST) Date: Fri, 21 Jul 2006 09:59:48 +0200 From: Jeroen Van Bemmel Subject: RE: [Simple] I-D ACTION:draft-ietf-simple-partial-publish-05.txt To: Internet-Drafts@ietf.org, i-d-announce@ietf.org Message-id: <0J2Q0094JWROZQ40@jes-fe1.zx.nl> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal X-Priority: 3 X-Spam-Score: 1.2 (+) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Authors, A question or comment: why use pidf-full instead of simply pidf for initial= / full state publications? I don't see a benefit, only drawbacks (duplicate definition,risk that UAS d= oes not support it) Why not use pidf, and have the server respond with accepted: pidf-diff if s= upported? Regards, Jeroen -----Oorspronkelijk bericht ----- Van: Internet-Drafts@ietf.org Aan: i-d-announce@ietf.org CC: simple@ietf.org Verzonden: 21-7-06 00:50 Onderwerp: [Simple] I-D ACTION:draft-ietf-simple-partial-publish-05.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP for Instant Messaging and Presence Lev= eraging Extensions Working Group of the IETF. Title : Publication of Partial Presence Information Author(s) : M. Lonnfors, et al. Filename : draft-ietf-simple-partial-publish-05.txt Pages : 16 Date : 2006-7-20 =09 The Session Initiation Protocol (SIP) Extension for Event State Publication describes a mechanism with which a presence user agent is able to publish presence information to a presence agent. Using the Presence Information Data Format (PIDF), each presence publication contains full state, regardless of how much of that information has actually changed since the previous update. As a consequence, updating a sizeable presence document with small changes bear a considerable overhead and is therefore inefficient. Especially with low bandwidth and high latency links, this can constitue a considerable burden to the system. This memo defines a solution that aids in reducing the impact of those constraints and increases transport efficiency by introducing a mechanism that allows for publication of partial presence information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-publish-05.tx= t To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of the = message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the usernam= e "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-partial-publish-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-partial-publish-05.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 21 06:19:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3s6R-0006dO-SB; Fri, 21 Jul 2006 06:19:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3s6P-0006ca-Ik; Fri, 21 Jul 2006 06:19:25 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3s0W-0005DZ-MN; Fri, 21 Jul 2006 06:13:22 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6L9DG0s005571; Fri, 21 Jul 2006 12:13:19 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Jul 2006 13:12:15 +0300 Received: from esdhcp034253.research.nokia.com ([172.21.34.253]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 21 Jul 2006 13:12:14 +0300 Subject: RE: [Simple] I-D ACTION:draft-ietf-simple-partial-publish-05.txt From: Aki Niemi To: ext Jeroen Van Bemmel In-Reply-To: <0J2Q0094JWROZQ40@jes-fe1.zx.nl> References: <0J2Q0094JWROZQ40@jes-fe1.zx.nl> Content-Type: text/plain Organization: Nokia-NRC/Helsinki Date: Fri, 21 Jul 2006 13:12:08 +0300 Message-Id: <1153476729.5891.19.camel@macbuster.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jul 2006 10:12:14.0776 (UTC) FILETIME=[2392FB80:01C6ACAE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Internet-Drafts@ietf.org, simple@ietf.org, i-d-announce@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org On pe, 2006-07-21 at 09:59 +0200, ext Jeroen Van Bemmel wrote: > Authors, > > A question or comment: why use pidf-full instead of simply pidf for > initial / full state publications? Good question. Originally it was simply so that publish and notify sides were aligned in their use of pidf-diff. And in the notifications, using pidf-full is needed because of versioning support (allowing the recipient to know against which state to patch the incoming diff state). Also there, the SUBSCRIBE would already carry pidf-diff as allowed content type, since it's a "pull". But we actually dropped the version attribute from partial-publish a while back because PUBLISH already takes care of versioning (and this is mentioned in the draft). However, we never went back to change principle flow. > I don't see a benefit, only drawbacks (duplicate definition,risk that > UAS does not support it) I think I agree. In fact, starting off with pidf, and in case Accept coming back from the server lists pidf-diff, switching to partial has another important benefit. In case the server gets upgraded at some point, the client needs to find out it can start using patches. In the current flow, this would require a pidf-full publication and an error response *every time* the client starts its presence engine, all the way up until the point that the server adds support. This may be forever, too, although I strongly hope it won't be. :) > Why not use pidf, and have the server respond with accepted: pidf-diff > if supported? I think this is a reasonable thing to do, and I'd be willing to make the change. Although not a huge change in principle (basically only the initial publication is affected, and there, only the content type), in practice there are a few places in the text that would need to change. Cheers, Aki -- Aki Niemi Nokia Research Center _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 21 06:35:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3sMG-0000xj-4X; Fri, 21 Jul 2006 06:35:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3sMF-0000xJ-8i for simple@ietf.org; Fri, 21 Jul 2006 06:35:47 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3sCR-0006Ox-8d for simple@ietf.org; Fri, 21 Jul 2006 06:25:40 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6L9Pc4k012110; Fri, 21 Jul 2006 12:25:38 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Jul 2006 13:25:38 +0300 Received: from esdhcp034253.research.nokia.com ([172.21.34.253]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 21 Jul 2006 13:25:38 +0300 Subject: RE: [Simple] I-D ACTION:draft-ietf-simple-partial-publish-05.txt From: Aki Niemi To: ext Jeroen Van Bemmel In-Reply-To: <1153476729.5891.19.camel@macbuster.research.nokia.com> References: <0J2Q0094JWROZQ40@jes-fe1.zx.nl> <1153476729.5891.19.camel@macbuster.research.nokia.com> Content-Type: text/plain Organization: Nokia-NRC/Helsinki Date: Fri, 21 Jul 2006 13:25:32 +0300 Message-Id: <1153477532.5891.27.camel@macbuster.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jul 2006 10:25:38.0167 (UTC) FILETIME=[026EB870:01C6ACB0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org On pe, 2006-07-21 at 13:12 +0300, Aki Niemi wrote: > I think this is a reasonable thing to do, and I'd be willing to make the > change. Although not a huge change in principle (basically only the > initial publication is affected, and there, only the content type), in > practice there are a few places in the text that would need to change. ...except of course that, as Jari just pointed out, Accept is marked as '-' meaning not applicable in RFC 3903, as well as RFC 3265. Which kind of makes sense, in a weird way, as normally you really want to put Accept in a request anyway. That's how it is in HTTP. But of course, we could define Accpet's applicability to PUBLISH 2xx in partial-publish. Cheers, Aki P.S. I had a feeling there was some "real" reason for not doing it like Jeroen suggested, which arguably is a better way. ;) -- Aki Niemi Nokia Research Center _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 21 06:53:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3sdi-0003wA-F7; Fri, 21 Jul 2006 06:53:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3sdg-0003tk-GG for simple@ietf.org; Fri, 21 Jul 2006 06:53:48 -0400 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3sWw-00006V-80 for simple@ietf.org; Fri, 21 Jul 2006 06:46:51 -0400 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id A0EF8194487 for ; Fri, 21 Jul 2006 12:46:48 +0200 (CEST) Received: from [192.168.1.14] ([192.168.1.14]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Jul 2006 12:45:53 +0200 In-Reply-To: <1153476729.5891.19.camel@macbuster.research.nokia.com> References: <0J2Q0094JWROZQ40@jes-fe1.zx.nl> <1153476729.5891.19.camel@macbuster.research.nokia.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-partial-publish-05.txt Date: Fri, 21 Jul 2006 12:47:13 +0200 To: Aki Niemi X-Mailer: Apple Mail (2.624) X-OriginalArrivalTime: 21 Jul 2006 10:45:53.0546 (UTC) FILETIME=[D6DAD6A0:01C6ACB2] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: 'simple@ietf.org'WG, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org This draft has passed WGLC and was only revised due to chair request for fixing some NITs. The fix below is a significant one and will require a WGLC to be issued again. Do you see a flaw in the current mechanism that requires fixing or is this proposal just a "looks better" thing? one comment inline... On Jul 21, 2006, at 12:12 PM, Aki Niemi wrote: > On pe, 2006-07-21 at 09:59 +0200, ext Jeroen Van Bemmel wrote: >> Authors, >> >> A question or comment: why use pidf-full instead of simply pidf for >> initial / full state publications? > > Good question. Originally it was simply so that publish and notify > sides > were aligned in their use of pidf-diff. And in the notifications, using > pidf-full is needed because of versioning support (allowing the > recipient to know against which state to patch the incoming diff > state). > Also there, the SUBSCRIBE would already carry pidf-diff as allowed > content type, since it's a "pull". > > But we actually dropped the version attribute from partial-publish a > while back because PUBLISH already takes care of versioning (and this > is > mentioned in the draft). > > However, we never went back to change principle flow. > >> I don't see a benefit, only drawbacks (duplicate definition,risk that >> UAS does not support it) > > I think I agree. In fact, starting off with pidf, and in case Accept > coming back from the server lists pidf-diff, switching to partial has > another important benefit. > > In case the server gets upgraded at some point, the client needs to > find > out it can start using patches. In the current flow, this would require > a pidf-full publication and an error response *every time* the client > starts its presence engine, all the way up until the point that the > server adds support. This may be forever, too, although I strongly hope > it won't be. :) This sounds like a flaw to me and an interoperability issue. Can you summarise the changes that need to be made, in detail? Thanks, Hisham > >> Why not use pidf, and have the server respond with accepted: pidf-diff >> if supported? > > I think this is a reasonable thing to do, and I'd be willing to make > the > change. Although not a huge change in principle (basically only the > initial publication is affected, and there, only the content type), in > practice there are a few places in the text that would need to change. > > Cheers, > Aki > > -- > Aki Niemi > Nokia Research Center > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 21 09:25:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3v0n-0006kj-DM; Fri, 21 Jul 2006 09:25:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3v0m-0006ec-9u for simple@ietf.org; Fri, 21 Jul 2006 09:25:48 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3tWR-0004ig-0J for simple@ietf.org; Fri, 21 Jul 2006 07:50:23 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G3tQf-0005WR-34 for simple@ietf.org; Fri, 21 Jul 2006 07:44:25 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6LAiL3N029638; Fri, 21 Jul 2006 13:44:23 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Jul 2006 14:43:21 +0300 Received: from esdhcp034253.research.nokia.com ([172.21.34.253]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 21 Jul 2006 14:43:21 +0300 Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-partial-publish-05.txt From: Aki Niemi To: ext Hisham Khartabil In-Reply-To: References: <0J2Q0094JWROZQ40@jes-fe1.zx.nl> <1153476729.5891.19.camel@macbuster.research.nokia.com> Content-Type: text/plain Organization: Nokia-NRC/Helsinki Date: Fri, 21 Jul 2006 14:43:14 +0300 Message-Id: <1153482194.5891.55.camel@macbuster.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jul 2006 11:43:21.0085 (UTC) FILETIME=[DDBF8AD0:01C6ACBA] X-Spam-Score: -2.5 (--) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: "'simple@ietf.org' WG" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org On pe, 2006-07-21 at 12:47 +0200, ext Hisham Khartabil wrote: > > In case the server gets upgraded at some point, the client needs to > > find > > out it can start using patches. In the current flow, this would require > > a pidf-full publication and an error response *every time* the client > > starts its presence engine, all the way up until the point that the > > server adds support. This may be forever, too, although I strongly hope > > it won't be. :) > > This sounds like a flaw to me and an interoperability issue. Can you > summarise the changes that need to be made, in detail? Well, I wouldn't say it's a flaw, really, or if it is then I'm not sure we can address it in partial-publish. The underlying issue is that Accept in 2xx is not allowed in RFC3903. This means that using Accept doesn't actually work. Perhaps it's best if we just leave it alone. Regarding the interop, this is the same issue as with any extension we make to SIP. If a domain doesn't support the foobar event package, then there is no mechanism apart from OPTIONS to tell you, a priori, that the SUBSCRIBE is going to fail. You just have to use trial-and-error, which is how it currently works for partial-publish. Cheers, Aki -- Aki Niemi Nokia Research Center _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 21 15:57:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G417S-0002Kv-9I; Fri, 21 Jul 2006 15:57:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G416d-0001t5-FT; Fri, 21 Jul 2006 15:56:15 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G410c-0001uF-54; Fri, 21 Jul 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k6LJo1p0005452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jul 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G410b-0003A6-JA; Fri, 21 Jul 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 21 Jul 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-partial-pidf-format-07.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 : Presence Information Data format (PIDF) Extension for Partial Presence Author(s) : M. Lonnfors, et al. Filename : draft-ietf-simple-partial-pidf-format-07.txt Pages : 17 Date : 2006-7-21 The Presence Information Document Format (PIDF) specifies the baseline XML based format for describing presence information. One of the characteristic of the PIDF is that the document always needs to carry all presence information available for the presentity. In some environments where low bandwidth and high latency links can exist it is often beneficial to limit the amount of transported information over the network. This document introduces a new MIME type which enables transporting of either only the changed parts or the full PIDF based presence information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-pidf-format-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-partial-pidf-format-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-partial-pidf-format-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-7-21125338.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-partial-pidf-format-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-partial-pidf-format-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-7-21125338.I-D@ietf.org> --OtherAccess-- --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://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Mon Jul 24 15:50:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G56RS-0001wC-Rh; Mon, 24 Jul 2006 15:50:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G56RG-0001jQ-NP; Mon, 24 Jul 2006 15:50:03 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G56RG-0007uF-7d; Mon, 24 Jul 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k6OJo1p0006974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Jul 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G56RF-0005HO-S4; Mon, 24 Jul 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 24 Jul 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-partial-notify-08.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 : Session Initiation Protocol (SIP) extension for Partial Notification of Presence Information Author(s) : M. Lonnfors, et al. Filename : draft-ietf-simple-partial-notify-08.txt Pages : 15 Date : 2006-7-24 By default, presence delivered using the Presence Event Package for the Session Initiation Protocol is represented in the Presence Information Data Format (PIDF). A PIDF document contains a set of elements, each representing a different aspect of the presence being reported. When any subset of the elements change, even just a single element, a new document containing the full set of elements is delivered. This memo defines an extension allowing delivery of only the presence data that has actually changed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-notify-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-partial-notify-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-partial-notify-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-7-24131605.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-partial-notify-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-partial-notify-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-7-24131605.I-D@ietf.org> --OtherAccess-- --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://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Tue Jul 25 16:40:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Thp-0006h5-Ma; Tue, 25 Jul 2006 16:40:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Tho-0006g8-4T; Tue, 25 Jul 2006 16:40:40 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Thm-0001Zb-UD; Tue, 25 Jul 2006 16:40:40 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k6PKecp0008140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jul 2006 20:40:38 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G5Thm-00069d-5T; Tue, 25 Jul 2006 16:40:38 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Tue, 25 Jul 2006 16:40:38 -0400 X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: simple@ietf.org Subject: [Simple] Last Call: 'The Message Session Relay Protocol' to Proposed Standard (draft-ietf-simple-message-sessions) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org The IESG has received a request from the SIP for Instant Messaging and Presence Leveraging Extensions WG to consider the following documents: - 'Relay Extensions for the Message Sessions Relay Protocol (MSRP) ' as a Proposed Standard - 'The Message Session Relay Protocol ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-08-08. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-simple-msrp-relays-08.txt http://www.ietf.org/internet-drafts/draft-ietf-simple-message-sessions-15.txt _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 27 03:00:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5zr9-00053d-Cy; Thu, 27 Jul 2006 03:00:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5zr8-000537-7i; Thu, 27 Jul 2006 03:00:26 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5yIj-0008En-5h; Thu, 27 Jul 2006 01:20:49 -0400 Received: from smtp3.infineon.com ([203.126.106.229]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G5y3l-0001Cb-L6; Thu, 27 Jul 2006 01:05:26 -0400 Received: from unknown (HELO sinse212.ap.infineon.com) ([172.17.65.148]) by smtp3.infineon.com with ESMTP; 27 Jul 2006 13:05:09 +0800 X-SBRS: None Received: from blrse201.ap.infineon.com ([172.20.20.12]) by sinse212.ap.infineon.com over TLS secured channel with Microsoft SMTPSVC(5.0.2195.6713); Thu, 27 Jul 2006 13:05:09 +0800 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 27 Jul 2006 10:35:06 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] File transfer when one device is cpim compatible Thread-Index: Acaw1ZhfnAOBGcbqSvG8OKMgcL7cGwAV0nzw From: To: X-OriginalArrivalTime: 27 Jul 2006 05:05:09.0385 (UTC) FILETIME=[3BA9EF90:01C6B13A] X-Spam-Score: -2.2 (--) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: mmusic@ietf.org, miguel.an.garcia@nokia.com, Gonzalo.Camarillo@ericsson.com, simple@ietf.org, Salvatore.Loreto@ericsson.com Subject: [Simple] RE: [MMUSIC] File transfer when one device is cpim compatible X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi, It means MSRP should differentiate between "instant message" and "file transfer" sessions.=20 Regards, Amit -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com]=20 Sent: Wednesday, July 26, 2006 8:03 PM To: Goel Amitkumar (IFIN SW WS) Cc: mmusic@ietf.org; Salvatore.Loreto@ericsson.com; miguel.an.garcia@nokia.com; Gonzalo.Camarillo@ericsson.com Subject: Re: [MMUSIC] File transfer when one device is cpim compatible I suspect that the file transfer would not be considered an "instant message" and thus would not be wrapped. On Jul 24, 2006, at 9:12 PM, wrote: > Hi All, > > According to MSRP draft "when one endpoint of the session is a CPIM=20 > gateway, instant messages SHOULD be wrapped in "message/cpim" [12]=20 > bodies". > So my question is how the example given in section 7 of=20 > "draft-garcia-mmusic-file-transfer-mech-00.txt" looks when any one of=20 > the device participating in file transfer is CPIM compatible? > > Regards, > Amit > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 27 12:22:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G68dD-0003YW-07; Thu, 27 Jul 2006 12:22:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G68dB-0003YB-KH; Thu, 27 Jul 2006 12:22:37 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G68dA-0005Y5-9J; Thu, 27 Jul 2006 12:22:37 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 27 Jul 2006 12:22:36 -0400 X-IronPort-AV: i="4.07,189,1151899200"; d="scan'208"; a="94138046:sNHT26454996" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6RGMaUu013753; Thu, 27 Jul 2006 12:22:36 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6RGMZdU016438; Thu, 27 Jul 2006 12:22:35 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 12:22:35 -0400 Received: from [161.44.79.104] ([161.44.79.104]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 12:22:35 -0400 Message-ID: <44C8E84A.2010404@cisco.com> Date: Thu, 27 Jul 2006 12:22:34 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Amitkumar.Goel@infineon.com Subject: Re: [Simple] RE: [MMUSIC] File transfer when one device is cpim compatible References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jul 2006 16:22:35.0184 (UTC) FILETIME=[DE72AB00:01C6B198] DKIM-Signature: a=rsa-sha1; q=dns; l=2152; t=1154017356; x=1154881356; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Simple]=20RE=3A=20[MMUSIC]=20File=20transfer=20when=20one=20dev ice=20is=20cpim=09compatible |To:Amitkumar.Goel@infineon.com; X=v=3Dcisco.com=3B=20h=3D7p9z//ZrK8VQ09XCOhutMn58E98=3D; b=FzPZSl9eBBrSxdHHSv1IR8j10nixfcoTJedLIdCDfN1I3hMLSbEf7amRMcw8DZo7pwQW6OeX Dvt7f52qiSbdbKW2w0Bioj7JHfUazKftYDzYBlF4KPcLM1uRWl3VMY+x; Authentication-Results: rtp-dkim-1.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: fluffy@cisco.com, mmusic@ietf.org, miguel.an.garcia@nokia.com, Gonzalo.Camarillo@ericsson.com, simple@ietf.org, Salvatore.Loreto@ericsson.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Some disjoint thoughts on this subject: I don't think *MSRP* should differentiate between IM and file transfer. MSRP has plenty of ways to identify and categorize the content that may be used by the applications on top of MSRP to do that differentiation. Since other IM protocols do support file transfer, perhaps CPIM should be allowed for file transfer. It occurs to me that MIME provides some useful tools that might be applicable here. In particular, Content-Disposition might be of use. A Content-Disposition of "render" would be a real IM. Some other disposition (e.g. "attachment") could be used for a message containing a file being transferred. Paul Amitkumar.Goel@infineon.com wrote: > Hi, > > It means MSRP should differentiate between "instant message" and "file > transfer" sessions. > > Regards, > Amit > > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Wednesday, July 26, 2006 8:03 PM > To: Goel Amitkumar (IFIN SW WS) > Cc: mmusic@ietf.org; Salvatore.Loreto@ericsson.com; > miguel.an.garcia@nokia.com; Gonzalo.Camarillo@ericsson.com > Subject: Re: [MMUSIC] File transfer when one device is cpim compatible > > > I suspect that the file transfer would not be considered an "instant > message" and thus would not be wrapped. > > > On Jul 24, 2006, at 9:12 PM, > wrote: > >> Hi All, >> >> According to MSRP draft "when one endpoint of the session is a CPIM >> gateway, instant messages SHOULD be wrapped in "message/cpim" [12] >> bodies". >> So my question is how the example given in section 7 of >> "draft-garcia-mmusic-file-transfer-mech-00.txt" looks when any one of >> the device participating in file transfer is CPIM compatible? >> >> Regards, >> Amit >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 27 15:04:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6B9x-0004cp-Mp; Thu, 27 Jul 2006 15:04:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6B9w-0004cj-KX for simple@ietf.org; Thu, 27 Jul 2006 15:04:36 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6B9v-0004QT-Sg for simple@ietf.org; Thu, 27 Jul 2006 15:04:36 -0400 Received: from [192.168.111.90] (c-67-172-208-127.hsd1.tx.comcast.net [67.172.208.127]) (authenticated bits=0) by vicuna.estacado.net (8.13.6/8.13.4) with ESMTP id k6RIxi47048228 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 27 Jul 2006 14:00:11 -0500 (CDT) (envelope-from emcmurry@estacado.net) Mime-Version: 1.0 (Apple Message framework v752.2) To: Hisham Khartabil , Eric Burger Message-Id: <7231458A-3F8C-41F5-9EFD-DFCCEA200F72@estacado.net> From: Eric McMurry Date: Thu, 27 Jul 2006 14:00:09 -0500 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.8 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Cc: simple@ietf.org Subject: [Simple] Comments on draft-ietf-simple-imdn-00.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 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="===============1474801193==" Errors-To: simple-bounces@ietf.org --===============1474801193== Content-Type: multipart/alternative; boundary=Apple-Mail-19--374049591 --Apple-Mail-19--374049591 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I understand that a rewrite is being considered, so I'll hold off on editorial comments. 1) I'm struggling a bit with the application of this to MSRP. DNs in general seem to make more sense for non-realtime applications (like page-mode messaging). For realtime, session-mode, applications, the session protocol ensures that messages are delivered. Also, sessions tend to be interactive which I think greatly lessens the value of read notifications. Perhaps someone has a use case for this to make the value more clear? 2) The available disposition states ("delivered", "read") are suited for responses from the target UA, but not so much for intermediaries. I think reintroducing something like the "processed" state, but more specific, may be in order. Take, for example, the store-and-forward case. An intermediary strictly following the current spec would return a negative delivery notification when it was not able to reach a target. If the intermediary provides store-and-forward service though, this results in a less than ideal experience for the user requesting the IMDN. They would almost immediately receive an indication that their message was not delivered. Some time later (assuming that the message was subsequently successfully delivered), they would receive another IMDN for the same message indicating success (this one is a bit fuzzier I think). The net is that it is confusing to the user. I would suggest adding a "stored" state to handle this. It would be sent by an intermediary providing store-and-forward service and would provide the sender with a much more accurate view of what the intermediate disposition of their message was. 3) "Future extensions" are mentioned in several places, but no extension mechanism is specified. Perhaps a mechanism for vendor specific extensions should be specified to avoid collisions with future versions of this spec. 4) The example of an IM body with an IMDN request (section 4.1) has not caught up with the addition of a CPIM namespace to the specification. 5) In section 4.4 "Keeping State", second paragraph, perhaps the phase "user choice" should read "local policy" (okay, that was a bit editorial :-) 6) Description of use of the Original-To header should spell out that this header should only be added if it does not already exist. It is possible that there will be multiple intermediaries in the path, and only the first one should do this. 7) I agreed with Miguel Garcia's comment on Really-To and Really-From in another email, but allow me to reiterate. This is a Via-like mechanism and would be less confusing (at least to me) if it were named as such. 8) Aggregation. Let's start with a scenario. Say there's a request to a list exploder with a local policy on the requested list to not reveal the list members. Let's also say that the exploder is going to aggregate IMDNs either by policy or request. So the request is exploded, and time passes. The exploder collects some IMDNs and decides it's time to send an aggregate response. Since the local policy is to not reveal list members, it strips this info from all of the IMDNs. Then it prepares and sends the aggregated IMDN. The UA that originated the request to the list exploder then receives a list of IMDNs with no user information in them. Now, how will this be presented to the user? The client only knows that some number of users on the list received the message, some number didn't, and an unknown number did or didn't receive it. The number of aggregated IMDNs could be large as well and may require multiple messages (only 1300 bytes available for MESSAGE) to send. I would suggest that aggregated IMDNs don't make sense if the policy of the aggregator is to strip the recipient info. The most useful piece of delivery information that can probably be obtained in this scenario is that the message was delivered successfully or not to the list server. This could be accomplished by sending a "delivered" state IMDN from the list server, or if something more explicit is desired, another intermediate state, such as "exploded" (okay, that was just for fun, but it conveys the status) could be defined. 9) I'm sure this would have been covered in the next version, but just in case: the text for the IANA registration of the Content- Disposition header (13.5) is missing. Thanks, Eric ----- Eric McMurry Estacado Systems --Apple-Mail-19--374049591 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 I understand that a rewrite is = being considered, so I'll hold off on editorial comments.


1)=A0I'm struggling a bit = with the application of this to MSRP.=A0 DNs in general seem to make = more sense for non-realtime applications (like page-mode messaging).=A0 = For realtime, session-mode, applications, the session protocol ensures = that messages are delivered.=A0 Also, sessions tend to be interactive = which I think greatly lessens the value of read notifications.=A0 = Perhaps someone has a use case for this to make the value more = clear?


2) The available = disposition states ("delivered", "read") are suited for responses from = the target UA, but not so much for intermediaries.=A0 I think = reintroducing=A0something like the "processed" state, but more specific, = may be in order.=A0 Take, for example, the store-and-forward = case.

An = intermediary strictly following the current spec would return a negative = delivery notification when it was not able to reach a target.=A0 If the = intermediary provides store-and-forward service though, this results in = a less than ideal experience for the user requesting the IMDN.=A0 They = would almost=A0immediately receive an indication that their message was = not delivered.=A0 Some time later (assuming that the message was = subsequently successfully delivered), they would receive another IMDN = for the same message indicating success (this one is a bit fuzzier I = think).

The = net is that it is confusing to the user.=A0 I would suggest adding a = "stored" state to handle this.=A0 It would be sent by an intermediary = providing store-and-forward service and would provide the sender with a = much more accurate view of what the intermediate disposition of their = message was.


3) "Future extensions" are = mentioned in several places, but no extension mechanism is = specified.=A0=A0Perhaps a mechanism for vendor specific = extensions should be specified to avoid collisions with future versions = of this spec. =A0


4) The example of an IM = body with an IMDN request (section 4.1) has not caught up with the = addition of a CPIM namespace to the specification.


5) In section 4.4 "Keeping = State", second paragraph, perhaps the phase "user choice" should read = "local policy" (okay, that was a bit editorial :-)


6)=A0 Description of use of = the Original-To header should spell out that this header should only be = added if it does not already exist.=A0 It is possible that there will be = multiple intermediaries in the path, and only the first one should do = this.


7) I agreed with Miguel = Garcia's comment on Really-To and Really-=46rom in another email, but = allow me to reiterate.=A0 This is a Via-like mechanism and would be less = confusing (at least to me) if it were named as such.


8) Aggregation.=A0 Let's = start with a scenario.=A0 Say there's a request to a list exploder with = a local policy on the requested list to not reveal the list members.=A0 = Let's also say that the exploder is going to aggregate IMDNs either by = policy or request.

So the request is exploded, = and time passes.=A0 The exploder collects some IMDNs and decides it's = time to send an aggregate response.=A0 Since the local policy is to not = reveal list members, it strips this info from all of the IMDNs.=A0 Then = it prepares and sends the aggregated IMDN.

The UA that originated the = request to the list exploder then receives a list of IMDNs with no user = information in them.=A0 Now, how will this be presented to the user?=A0 = The client only knows that some number of users on the list received the = message, some number didn't, and an unknown number did or didn't receive = it.

The = number of aggregated IMDNs could be large as well and may require = multiple messages (only 1300 bytes available for MESSAGE) to send.=A0 I = would suggest that aggregated IMDNs don't make sense if the policy of = the aggregator is to strip the recipient info.=A0 The most useful piece = of delivery information that can probably be obtained in this scenario = is that the message was delivered successfully or not to the list = server.=A0 This could be accomplished by sending a "delivered" state = IMDN from the list server, or if something more explicit is desired, = another intermediate state, such as "exploded" (okay, that was just for = fun, but it conveys the status) could be defined.


9) I'm sure this=A0would = have been covered in the next version, but just in case:=A0 the text for = the IANA registration of the Content-Disposition=A0header (13.5) is = missing.



Thanks,

Eric

-----
Eric = McMurry
Estacado Systems

= --Apple-Mail-19--374049591-- --===============1474801193== 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://www1.ietf.org/mailman/listinfo/simple --===============1474801193==-- From simple-bounces@ietf.org Thu Jul 27 15:04:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6B9w-0004cJ-75; Thu, 27 Jul 2006 15:04:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6B9u-0004cE-V7 for simple@ietf.org; Thu, 27 Jul 2006 15:04:34 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6B9s-0004QD-8b for simple@ietf.org; Thu, 27 Jul 2006 15:04:34 -0400 Received: from [192.168.111.90] (c-67-172-208-127.hsd1.tx.comcast.net [67.172.208.127]) (authenticated bits=0) by vicuna.estacado.net (8.13.6/8.13.4) with ESMTP id k6RIxi46048228 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 27 Jul 2006 13:59:45 -0500 (CDT) (envelope-from emcmurry@estacado.net) In-Reply-To: <44AE619F.1000900@nokia.com> References: <44AE619F.1000900@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Eric McMurry Subject: Re: [Simple] Comments to draft-ietf-simple-imdn-00.txt Date: Thu, 27 Jul 2006 13:59:36 -0500 To: Miguel Garcia X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd Cc: simple@ietf.org, Eric Burger X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org These are good comments. I'll second the entire list. I've embedded =20= a few additional comments on them. Thanks, Eric ------ Eric McMurry Estacado Systems On Jul 7, 2006, at 8:29 AM, Miguel Garcia wrote: > Hi: > > Here are some comments to the IMDN draft. > > 1) I think the draft is desperately looking for a terminology =20 > section within Section 2. I think we ought to define the following =20 > terms (this my understanding): > > IM or Instant Message: a SIP or MSRP message that contains a =20 > message/cpim body since the goal is to have this be transport independent and SIP and =20 MSRP are ostensibly used as examples, perhaps the definition should =20 leave out the transports. > > IMDN: a SIP or MSRP message that contains an IMDN document How about: a message that contains a message/cpim body that contains =20 an IMDN document > > IMDN document: an XML document that complies with the Schema of =20 > Section 9.3 > > message/cpim body: a document that complies with RFC 3862. It can =20 > also contain the extensions defined in this document. > > > So, notice that we have definitions of SIP/MSRP carrying either a =20 > regular IM or an IMDN. We have a name for the XML part of the IMDN, =20= > and a name for the document part of a regular IM. Don't know if =20 > this fits with your intention, I hope so. > > Then please stick to the terminology: avoid terms like 'Message/=20 > CPIM IM'. > > 2) In Section 3, Overview, I am missing an overview description of =20 > the Aggregation feature. > > 3) Make sure that it is always spelled out if you are referring to =20 > the Content-Type header in SIP or MSRP, or the Content-Type header =20 > that goes into the message/cpim body > > 4) The text in Section 4.1 reads: > > In this extension, the Message/CPIM IM MAY contain a Message-ID > header field if an IMDN is requested. The Message-ID field is > populated with a value that is unique in space and time. This =20 > header > field enables the message sender to match any notifications with > their corresponding IMs. This header need not be present if the > instant message sender is not requesting any IMDNs or if no =20 > state of > any kind is kept for an IM. > > First, I don't know what "In this extension" means... I guess it =20 > should be "Implementations according with this specification..." > > Then I think we should encourage implementations to include a =20 > Message-ID header whenever they are requesting IMDN, even when they =20= > do not keep state... It may help when debugging, for example. > I'll make a stronger version of this statement. I think that this =20 should be a MUST. This is not that onerous even for a client that =20 doesn=92t keep state and it makes dealing with the requests easier for =20= intermediaries that need to correlate IMs to IMDNs. > 5) Section 4.1, third paragraph: there seems to be a repetition for =20= > the justification of the timestamp: > > It is therefore necessary to add a time stamp in the IM to indicate > when it was sent in order to enable the human user to correlate the > IM with the IMDN. This time stamp is returned in the IMDN in order > to enable the user to correlate the IM with the IMDN at the human > level. > > 6) I would suggest renaming Section 4.1 as "Requesting Disposition =20 > Notifications". > > 7) Section 4.2. I am missing to put a context to IMDNs. =20 > Specifically, the text should answer to the question: "is the IMDN =20 > XML stuff inserted as SIP/MSRP payload or as message/cpim payload?. =20= > So I would start this section with some text along these lines =20 > (according to the suggested terminology in my first bullet point). > > "An IMDN is a SIP or MSRP message that contains a message/cpim body =20= > whose payload is an IMDN document compliant with the XML schema of =20 > Section 9.3." > > 8) The last paragraph in Section 4.2 starts speaking about the =20 > "Really-From" header like if the reader were familiar with it, but =20 > this is the first occurrence of this header. So I would suggest to =20 > add a couple of sentence that describes what this header is all =20 > about right before this paragraph. > > 9) The titles in Sections 4.2 and 4.3 are very similar... With the =20 > terminology suggestion I made in my first bullet point, Section 4.3 =20= > will become "Constructing an IMDN document". > > 10) Sections 4.2.1 and 4.2.2 should describe how to populate all =20 > the elements of the IMDN XML document, but they are not described. =20 > Instead, The Content-Disposition header is described, but that one =20 > falls into Section 4.2, not 4.2.1. > > 11) Section 4.2.2 reads: > > There are situations where the recipient user agent cannot =20 > determine > if or when the message has been read. The recipient user agent in > this case generates a read notification with a value of > "error" to indicate an internal error by the server. > > If the status is unknown, why don't you choose "unknown" as the =20 > value, rather than "error"? > > 12) Is '"aggregate" a parameter of the whole header field or a =20 > parameter of a value. I think of the latter, the text first says =20 > the former, and then indicates that the latter can be done.... Take =20= > a look at the following sentences included in the first paragraph =20 > in Section 4.3: > > The endpoint does so by adding the Disposition-Notification header > field parameter "aggregate". > > So the above clearly says that 'aggregate' is a parameter of the =20 > whole header, not of the individual values. But the text then reads: > > For example, a IM sender > can request delivery notification to be aggregated but read reports > to be sent individually. For example: > > Disposition-Notification: positive-delivery;aggregate, read > > So I believe the example is correct, and the first sentence should =20 > read: > > The endpoint does so by adding a parameter "aggregate" close to the > value of the Disposition-Notification header that requires > aggregation. The "aggregate" parameter affects each value > independently. > > 13) In Section 4.4 I found the term "Requesting endpoint". Perhaps =20 > it is good to include it in the definitions, I guess it is not the =20 > "sender". > > 14) Section 5, second paragraph, I guess the 'may' is really a 'MAY': > > An intermediary that forwards an IM may change the recipient =20 > address... > > 15) I found a bit weird a paragraph in Section 5 that speaks about =20 > procedures that an intermediary can do when it does not support =20 > this specification. So, if the intermediary does not support the =20 > specification, it will not insert any "Really-From" header either. =20 > This is the text I am referring to: > > An intermediary MAY choose to remain on the path of IMDNs for a > specific IM. It can do so by adding a CPIM Really-=46rom header =20= > field > as the top Really-=46rom header and populating it with its own =20 > address. > This works well with intermediaries that don't support this =20 > extension > in that IMDNs would therefore traverse directly from receiver to > sender or to intermediaries that do support the extension. > > 16) I hate the names of these headers "Really-From", "Really-To". I =20= > would suggest something more meaningful, for examlpe "Reply-Via" =20 > and "Via", respectively. > > 17) I don't understand this text in Section 9.1.4, looks like a =20 > contradiction that the contains the URI of =20= > the final recipient rather than that of the original recipient. > > The element is optional and carries the =20= > URI > of the final recipient. > > 18) Section 9.2, first paragraph reads: > > The SIP > [9] MESSAGE request [10] or the MSRP SEND request [11] that is used > to carry the IMDN that also carries payload type information MUST > identify the payload as MIME type "message/imdn+xml" in the =20 > Content- > Type header field. > > Ouch, didn't we say that the IMDN document goes into message/cpim =20 > body? At least the examples in 4.2.1 and 4.2.2 indicate it that =20 > way. Also the above text contradicts most of the text around =20 > Section 10.1 > > > NITS: > > - Missing full stop at the end of the paragraph in Section 3.1. > - s/Recipient/recipient > - s/content-type/Content-Type (or is true that the message/cpim =20 > header is typically spelled as Content-type? RFC 3862 spells it =20 > like that...) > - Extra space in before the DateTime header at the end of Section 4.1 > - The examples in 4.2.1 and 4.2.2 show a couple of identities in =20 > the and elements, but they =20= > do not look like URIs, since they don't contain a URI scheme. I =20 > guess they should be prepended with "im:" > - The first paragraph in Section 4.3 contains twice "it does so". =20 > Can we please spell out what is "so", because it may be misleading =20 > when you have previously said that there are two options to do =20 > something. > - Extra ";" at the end of elements in the titles of Sections 9.1.3, =20= > 9.1.4, and 9.1.5. > > > /Miguel > > --=20 > Miguel A. Garcia tel:+358-50-4804586 > sip:miguel.an.garcia@openlaboratory.net > Nokia Research Center Helsinki, Finland > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 28 03:31:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6MoX-0007bg-8v; Fri, 28 Jul 2006 03:31:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6MoW-0007bb-5e for simple@ietf.org; Fri, 28 Jul 2006 03:31:16 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6MoT-0005Xp-N5 for simple@ietf.org; Fri, 28 Jul 2006 03:31:16 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6S7VCnM002170; Fri, 28 Jul 2006 10:31:12 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Jul 2006 10:31:12 +0300 Received: from esdhcp0358.research.nokia.com ([172.21.35.8]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 28 Jul 2006 10:31:11 +0300 Subject: RE: [Simple] I-D ACTION:draft-ietf-simple-partial-publish-05.txt From: Aki Niemi To: ext Jeroen van Bemmel In-Reply-To: <000001c6acef$bbf7fab0$6602a8c0@laptopbem> References: <000001c6acef$bbf7fab0$6602a8c0@laptopbem> Content-Type: text/plain Organization: Nokia-NRC/Helsinki Date: Fri, 28 Jul 2006 10:31:06 +0300 Message-Id: <1154071866.21805.9.camel@macbuster.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jul 2006 07:31:11.0905 (UTC) FILETIME=[CCF22110:01C6B217] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org On pe, 2006-07-21 at 20:01 +0200, ext Jeroen van Bemmel wrote: > Aki, > > I think you should drop pidf-full altogether (remove it completely), and > only use pidf and pidf-diff. For versioning of notifications you can simply > use the CSeq number (initial NOTIFY MUST be pidf) This is a pretty substantial change. It affects not only partial-publish but -format and -notify as well. And is more of a complete rewrite. I'm wondering if this is all that much better, or just different. You still require a new, separate content type. The 'version' attribute still needs to be there in pidf-diff (to account for partial traversing CPP gateways) and so on. Is there something obvious that makes the current mechanism broken? If not, can you live with what's there now? > Even if Allow is not allowed in 2xx to PUBLISH, it is still better to use > pidf in the initial PUBLISH. If a subsequent pidf-diff fails because of UAS > not supporting, the wasted effort is less. I think you mean Accept, but how much 'better' is it really. You still don't save a round trip, since in your proposal, the first partial update would still fail, requiring a resend. Cheers, Aki -- Aki Niemi Nokia Research Center _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 28 07:43:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Qkn-0003QM-8h; Fri, 28 Jul 2006 07:43:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Qkl-0003QE-IY; Fri, 28 Jul 2006 07:43:39 -0400 Received: from mtagate5.de.ibm.com ([195.212.29.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6Qkj-0001OR-1S; Fri, 28 Jul 2006 07:43:39 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate5.de.ibm.com (8.13.7/8.13.7) with ESMTP id k6SBhVmM023350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 28 Jul 2006 11:43:33 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k6SBkoVQ147446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Jul 2006 13:46:51 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k6SBhS0X000875; Fri, 28 Jul 2006 13:43:28 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k6SBhSmZ000872; Fri, 28 Jul 2006 13:43:28 +0200 In-Reply-To: <44C8E84A.2010404@cisco.com> To: Paul Kyzivat Subject: Re: [Simple] RE: [MMUSIC] File transfer when one device is cpim compatible MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 From: Avshalom Houri Message-ID: Date: Fri, 28 Jul 2006 14:46:47 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.1HF269 | June 22, 2006) at 28/07/2006 14:46:48, Serialize complete at 28/07/2006 14:46:48 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: fluffy@cisco.com, mmusic@ietf.org, miguel.an.garcia@nokia.com, Gonzalo.Camarillo@ericsson.com, Amitkumar.Goel@infineon.com, simple@ietf.org, Salvatore.Loreto@ericsson.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org There may be security issues that may necessitate to know that an MSRP session is actually a file transfer like virus scanning. However, I agree with Paul that we should not differentiate file transfer from IM as these kind of protections should be in the application level. --Avshalom Paul Kyzivat 27/07/2006 19:22 To Amitkumar.Goel@infineon.com cc fluffy@cisco.com, mmusic@ietf.org, miguel.an.garcia@nokia.com, Gonzalo.Camarillo@ericsson.com, simple@ietf.org, Salvatore.Loreto@ericsson.com Subject Re: [Simple] RE: [MMUSIC] File transfer when one device is cpim compatible Some disjoint thoughts on this subject: I don't think *MSRP* should differentiate between IM and file transfer. MSRP has plenty of ways to identify and categorize the content that may be used by the applications on top of MSRP to do that differentiation. Since other IM protocols do support file transfer, perhaps CPIM should be allowed for file transfer. It occurs to me that MIME provides some useful tools that might be applicable here. In particular, Content-Disposition might be of use. A Content-Disposition of "render" would be a real IM. Some other disposition (e.g. "attachment") could be used for a message containing a file being transferred. Paul Amitkumar.Goel@infineon.com wrote: > Hi, > > It means MSRP should differentiate between "instant message" and "file > transfer" sessions. > > Regards, > Amit > > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Wednesday, July 26, 2006 8:03 PM > To: Goel Amitkumar (IFIN SW WS) > Cc: mmusic@ietf.org; Salvatore.Loreto@ericsson.com; > miguel.an.garcia@nokia.com; Gonzalo.Camarillo@ericsson.com > Subject: Re: [MMUSIC] File transfer when one device is cpim compatible > > > I suspect that the file transfer would not be considered an "instant > message" and thus would not be wrapped. > > > On Jul 24, 2006, at 9:12 PM, > wrote: > >> Hi All, >> >> According to MSRP draft "when one endpoint of the session is a CPIM >> gateway, instant messages SHOULD be wrapped in "message/cpim" [12] >> bodies". >> So my question is how the example given in section 7 of >> "draft-garcia-mmusic-file-transfer-mech-00.txt" looks when any one of >> the device participating in file transfer is CPIM compatible? >> >> Regards, >> Amit >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 28 07:52:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6QtZ-0006bM-G3; Fri, 28 Jul 2006 07:52:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6QtY-0006aW-HN for simple@ietf.org; Fri, 28 Jul 2006 07:52:44 -0400 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6QtV-0003iU-Gu for simple@ietf.org; Fri, 28 Jul 2006 07:52:44 -0400 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 65CF11944A1 for ; Fri, 28 Jul 2006 13:52:40 +0200 (CEST) Received: from [192.168.1.11] ([192.168.1.11]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Jul 2006 13:51:43 +0200 In-Reply-To: <58357EDC7884E24BAD684C1B2D91F96D0380009D@trebe101.NOE.Nokia.com> References: <58357EDC7884E24BAD684C1B2D91F96D0380009D@trebe101.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-imdn-00.txt Date: Fri, 28 Jul 2006 13:53:07 +0200 To: X-Mailer: Apple Mail (2.624) X-OriginalArrivalTime: 28 Jul 2006 11:51:43.0529 (UTC) FILETIME=[321EA990:01C6B23C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi Eva, Thanks for the comments and apologies for the late reply. Comments inline... On Jul 7, 2006, at 2:03 PM, wrote: > Hi, > > I read the draft, and have a couple of comments as follows: > > - it is said in section 5/ 2nd paragraph that "In this case, the > intermediary MUST add a CPIM Original-To header to the CPIM message > populating it with the address of the sender.". Shouldn't the header > field rather be populated with the address of the original recipient > (which is basically the address of the intermediary as well as the > address of the entity forwarding the message)? You are correct, there was a typo. It is now fixed to say the the Original-To header is populated with the intermediary address. > If there are several > intermediaries, is the Original-To header set by the first one? Yes. I added text saying that an intermediary MUST NOT add an Original-To header if one already existed. > > - 9.1.4. : it is said that this carries the URI > of the final recipient. Shouldn't this be the URI of the recipient in > the originated IM? Again you are correct. copy/paste error. > > - 10.2. (Intermediary behaviour): it is said for the read notification > that the intermediary forwards it. Shouldn't similar text be written > for > "positive-delivery" notifications (generated by an endpoint)? Yes. Text added. > > - 10.2. If the intermediary generates the IMDN then also other > quidelines should be given than only how the is > populated, e.g. reference to the subsection 4.2.1. The text already references 4.2.1. Thanks, Hisham > > > BR, Eva > >> -----Original Message----- >> From: ext Hisham Khartabil [mailto:hisham.khartabil@telio.no] >> Sent: 14 June, 2006 16:06 >> To: 'simple@ietf.org' WG >> Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-imdn-00.txt >> >> This version of the Instant Messaging Disposition Notification draft >> represents consensus from the design team (with very few open issues). >> The authors would appreciate some review and comments before the next >> IETF meeting in Montreal in order to allow us to properly discuss any >> open issues that are raised. >> >> Thanks, >> Hisham >> >> On May 31, 2006, at 12:50 AM, Internet-Drafts@ietf.org wrote: >> >>> 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-00.txt >>> Pages : 27 >>> Date : 2006-5-30 >>> >>> Instant Messaging (IM) refers to the transfer of messages between >>> users in real-time. >>> >>> This document extends Message/CPIM message format to enable endpoints >>> to request, create and send IM Disposition Notifications (IMDN), >>> including delivery and read notifications, for page-mode as well as >>> session mode instant messages. This document also describes how SIP >>> and MSRP entities behave using this extension. >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-simple-imdn-00.txt >>> >>> To remove yourself from the I-D Announcement list, send a message to >>> i-d-announce-request@ietf.org with the word unsubscribe in >> the body of >>> the message. >>> You can also visit >> https://www1.ietf.org/mailman/listinfo/I-D-announce >>> to change your subscription settings. >>> >>> >>> Internet-Drafts are also available by anonymous FTP. Login with the >>> username >>> "anonymous" and a password of your e-mail address. After logging in, >>> type "cd internet-drafts" and then >>> "get draft-ietf-simple-imdn-00.txt". >>> >>> A list of Internet-Drafts directories can be found in >>> http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> >>> Internet-Drafts can also be obtained by e-mail. >>> >>> Send a message to: >>> mailserv@ietf.org. >>> In the body type: >>> "FILE /internet-drafts/draft-ietf-simple-imdn-00.txt". >>> >>> NOTE: The mail server at ietf.org can return the document in >>> MIME-encoded form by using the "mpack" utility. To use this >>> feature, insert the command "ENCODING mime" before the "FILE" >>> command. To decode the response(s), you will need "munpack" or >>> a MIME-compliant mail reader. Different MIME-compliant >> mail readers >>> exhibit different behavior, especially when dealing with >>> "multipart" MIME messages (i.e. documents which have been split >>> up into multiple messages), so check your local documentation on >>> how to manipulate these messages. >>> >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> Content-Type: text/plain >>> Content-ID: <2006-5-30162236.I-D@ietf.org> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 28 09:33:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6SSw-0002pw-Qd; Fri, 28 Jul 2006 09:33:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6SSv-0002pq-Es for simple@ietf.org; Fri, 28 Jul 2006 09:33:21 -0400 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6SSs-0003yX-QL for simple@ietf.org; Fri, 28 Jul 2006 09:33:21 -0400 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id D270E19449D for ; Fri, 28 Jul 2006 15:33:17 +0200 (CEST) Received: from [192.168.1.11] ([192.168.1.11]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Jul 2006 15:32:20 +0200 In-Reply-To: <7231458A-3F8C-41F5-9EFD-DFCCEA200F72@estacado.net> References: <7231458A-3F8C-41F5-9EFD-DFCCEA200F72@estacado.net> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <02d75c0e201940d469d209c90655f3cf@telio.no> Content-Transfer-Encoding: quoted-printable From: Hisham Khartabil Date: Fri, 28 Jul 2006 15:33:44 +0200 To: Eric McMurry X-Mailer: Apple Mail (2.624) X-OriginalArrivalTime: 28 Jul 2006 13:32:20.0578 (UTC) FILETIME=[407B3C20:01C6B24A] X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 Cc: simple@ietf.org, Eric Burger Subject: [Simple] Re: Comments on draft-ietf-simple-imdn-00.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi, Thanks for the comments. Responses inline... On Jul 27, 2006, at 9:00 PM, Eric McMurry wrote: > I understand that a rewrite is being considered, so I'll hold off on=20= > editorial comments. > > > 1)=A0I'm struggling a bit with the application of this to MSRP.=A0 DNs = in=20 > general seem to make more sense for non-realtime applications (like=20 > page-mode messaging).=A0 For realtime, session-mode, applications, the=20= > session protocol ensures that messages are delivered.=A0 Also, = sessions=20 > tend to be interactive which I think greatly lessens the value of read=20= > notifications.=A0 Perhaps someone has a use case for this to make the=20= > value more clear? Having a message session with a machine the requires delivery of IMs in=20= proper sequence and therefore need a delivery notification before=20 sending the next one. > > > 2) The available disposition states ("delivered", "read") are suited=20= > for responses from the target UA, but not so much for intermediaries.=A0= =20 > I think reintroducing=A0something like the "processed" state, but more=20= > specific, may be in order.=A0 Take, for example, the store-and-forward=20= > case. We have deliberately limited it to delivered and read. Future=20 extensions can define something like "processed" > > An intermediary strictly following the current spec would return a=20 > negative delivery notification when it was not able to reach a=20 > target.=A0 If the intermediary provides store-and-forward service=20 > though, this results in a less than ideal experience for the user=20 > requesting the IMDN.=A0 They would almost=A0immediately receive an=20 > indication that their message was not delivered. No. They wouldn't receive anything. The message is still to be=20 delivered. > =A0 Some time later (assuming that the message was subsequently=20 > successfully delivered), they would receive another IMDN for the same=20= > message indicating success (this one is a bit fuzzier I think). This would be the first one they get. > > The net is that it is confusing to the user.=A0 I would suggest adding = a=20 > "stored" state to handle this.=A0 It would be sent by an intermediary=20= > providing store-and-forward service and would provide the sender with=20= > a much more accurate view of what the intermediate disposition of=20 > their message was. > > > 3) "Future extensions" are mentioned in several places, but no=20 > extension mechanism is specified.=A0=A0Perhaps a mechanism for vendor=20= > specific extensions should be specified to avoid collisions with=20 > future versions of this spec. =A0 Added text in section 9.1 suggesting future extensions must be in an=20 RFC. > > > 4) The example of an IM body with an IMDN request (section 4.1) has=20 > not caught up with the addition of a CPIM namespace to the=20 > specification. I actually forgot this was there. I removed the definition of the new=20 namespace and referred to the default namespace instead. > > > 5) In section 4.4 "Keeping State", second paragraph, perhaps the phase=20= > "user choice" should read "local policy" (okay, that was a bit=20 > editorial :-) I actually prefer user choice since it clearly states that the user=20 makes that choice and not the implementer. > > > 6)=A0 Description of use of the Original-To header should spell out = that=20 > this header should only be added if it does not already exist.=A0 It = is=20 > possible that there will be multiple intermediaries in the path, and=20= > only the first one should do this. Yes. This is done already in my local copy of the next version. > > > 7) I agreed with Miguel Garcia's comment on Really-To and Really-=46rom=20= > in another email, but allow me to reiterate.=A0 This is a Via-like=20 > mechanism and would be less confusing (at least to me) if it were=20 > named as such. I'll make that change. > > > 8) Aggregation.=A0 Let's start with a scenario.=A0 Say there's a = request=20 > to a list exploder with a local policy on the requested list to not=20 > reveal the list members.=A0 Let's also say that the exploder is going = to=20 > aggregate IMDNs either by policy or request. > > So the request is exploded, and time passes.=A0 The exploder collects=20= > some IMDNs and decides it's time to send an aggregate response.=A0 = Since=20 > the local policy is to not reveal list members, it strips this info=20 > from all of the IMDNs.=A0 Then it prepares and sends the aggregated=20 > IMDN. A list server can send *ONE* imdn indicating "delivered" after is has=20 received some or all of the IMDNs. This is only an option of course. > > The UA that originated the request to the list exploder then receives=20= > a list of IMDNs with no user information in them.=A0 Now, how will = this=20 > be presented to the user?=A0 "x users received the message" is one example. This is an=20 implementation choice > The client only knows that some number of users on the list received=20= > the message, some number didn't, and an unknown number did or didn't=20= > receive it. That acceptable, imo. > > The number of aggregated IMDNs could be large as well and may require=20= > multiple messages (only 1300 bytes available for MESSAGE) to send.=A0 = I=20 > would suggest that aggregated IMDNs don't make sense if the policy of=20= > the aggregator is to strip the recipient info. I disagree. I think it does make sense. Sometimes I am interested that=20= enough people received the message, not who. > =A0 The most useful piece of delivery information that can probably be=20= > obtained in this scenario is that the message was delivered=20 > successfully or not to the list server.=A0 This could be accomplished = by=20 > sending a "delivered" state IMDN from the list server, or if something=20= > more explicit is desired, another intermediate state, such as=20 > "exploded" (okay, that was just for fun, but it conveys the status)=20 > could be defined. > > > 9) I'm sure this=A0would have been covered in the next version, but = just=20 > in case:=A0 the text for the IANA registration of the=20 > Content-Disposition=A0header (13.5) is missing. Yes. Added. Thanks, Hisham > > > > Thanks, > > Eric > > ----- > Eric McMurry > Estacado Systems > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 28 09:55:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Snv-0007wM-MG; Fri, 28 Jul 2006 09:55:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Snu-0007w1-BJ; Fri, 28 Jul 2006 09:55:02 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6Sns-0008SR-Ss; Fri, 28 Jul 2006 09:55:02 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 28 Jul 2006 06:55:00 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6SDt03R026392; Fri, 28 Jul 2006 06:55:00 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6SDsxJi002648; Fri, 28 Jul 2006 06:54:59 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Jul 2006 09:54:59 -0400 Received: from [161.44.79.104] ([161.44.79.104]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Jul 2006 09:54:58 -0400 Message-ID: <44CA1732.4070008@cisco.com> Date: Fri, 28 Jul 2006 09:54:58 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Avshalom Houri Subject: Re: [Simple] RE: [MMUSIC] File transfer when one device is cpim compatible References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jul 2006 13:54:58.0754 (UTC) FILETIME=[6A047220:01C6B24D] DKIM-Signature: a=rsa-sha1; q=dns; l=3359; t=1154094900; x=1154958900; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Simple]=20RE=3A=20[MMUSIC]=20File=20transfer=20when=20one=20dev ice=20is=09cpim=09compatible; X=v=3Dcisco.com=3B=20h=3D7p9z//ZrK8VQ09XCOhutMn58E98=3D; b=eRQa4PddkkTK7xeG9KrKEWXsxvsM4XStu+Vql+6AbC95j0E8jZe16/HNIFpdo2A3cwtE6rMr ViebZHDwD9gowSC9ol4y3HL223GyR9kmaNlU9dlw6nuL5BKE/PDSM2k0; Authentication-Results: sj-dkim-4.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: fluffy@cisco.com, mmusic@ietf.org, miguel.an.garcia@nokia.com, Gonzalo.Camarillo@ericsson.com, Amitkumar.Goel@infineon.com, simple@ietf.org, Salvatore.Loreto@ericsson.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Avshalom Houri wrote: > There may be security issues that may necessitate to know that > an MSRP session is actually a file transfer like virus scanning. I don't see how such a distinction would be helpful. It is possible to use a "conversational" MSRP session to transfer files as well. So if you care about such things you should be scanning all MSRP traffic in any case. Paul > However, I agree with Paul that we should not differentiate file > transfer from IM as these kind of protections should be in the > application level. > --Avshalom > > > > > > Paul Kyzivat > 27/07/2006 19:22 > > To > Amitkumar.Goel@infineon.com > cc > fluffy@cisco.com, mmusic@ietf.org, miguel.an.garcia@nokia.com, > Gonzalo.Camarillo@ericsson.com, simple@ietf.org, > Salvatore.Loreto@ericsson.com > Subject > Re: [Simple] RE: [MMUSIC] File transfer when one device is cpim > compatible > > > > > > > Some disjoint thoughts on this subject: > > I don't think *MSRP* should differentiate between IM and file transfer. > MSRP has plenty of ways to identify and categorize the content that may > be used by the applications on top of MSRP to do that differentiation. > > Since other IM protocols do support file transfer, perhaps CPIM should > be allowed for file transfer. > > It occurs to me that MIME provides some useful tools that might be > applicable here. In particular, Content-Disposition might be of use. A > Content-Disposition of "render" would be a real IM. Some other > disposition (e.g. "attachment") could be used for a message containing a > file being transferred. > > Paul > > Amitkumar.Goel@infineon.com wrote: >> Hi, >> >> It means MSRP should differentiate between "instant message" and "file >> transfer" sessions. >> >> Regards, >> Amit >> >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: Wednesday, July 26, 2006 8:03 PM >> To: Goel Amitkumar (IFIN SW WS) >> Cc: mmusic@ietf.org; Salvatore.Loreto@ericsson.com; >> miguel.an.garcia@nokia.com; Gonzalo.Camarillo@ericsson.com >> Subject: Re: [MMUSIC] File transfer when one device is cpim compatible >> >> >> I suspect that the file transfer would not be considered an "instant >> message" and thus would not be wrapped. >> >> >> On Jul 24, 2006, at 9:12 PM, >> wrote: >> >>> Hi All, >>> >>> According to MSRP draft "when one endpoint of the session is a CPIM >>> gateway, instant messages SHOULD be wrapped in "message/cpim" [12] >>> bodies". >>> So my question is how the example given in section 7 of >>> "draft-garcia-mmusic-file-transfer-mech-00.txt" looks when any one of >>> the device participating in file transfer is CPIM compatible? >>> >>> Regards, >>> Amit >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mmusic >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 28 10:25:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6TGz-0002U9-2b; Fri, 28 Jul 2006 10:25:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6TGx-0002Tn-9X; Fri, 28 Jul 2006 10:25:03 -0400 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6TGv-0003Z1-OD; Fri, 28 Jul 2006 10:25:03 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.7/8.13.7) with ESMTP id k6SEP08P149268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 28 Jul 2006 14:25:00 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k6SESK48067882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Jul 2006 16:28:20 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k6SEOwnE006357; Fri, 28 Jul 2006 16:24:59 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k6SEOwTu006352; Fri, 28 Jul 2006 16:24:58 +0200 In-Reply-To: <44CA1732.4070008@cisco.com> To: Paul Kyzivat Subject: Re: [Simple] RE: [MMUSIC] File transfer when one device is cpim compatible MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 From: Avshalom Houri Message-ID: Date: Fri, 28 Jul 2006 17:28:17 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.1HF269 | June 22, 2006) at 28/07/2006 17:28:19, Serialize complete at 28/07/2006 17:28:19 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: fluffy@cisco.com, mmusic@ietf.org, miguel.an.garcia@nokia.com, Gonzalo.Camarillo@ericsson.com, Amitkumar.Goel@infineon.com, simple@ietf.org, Salvatore.Loreto@ericsson.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org I agree but there is a distinction here since sending file over the IM chat will require an application that will cooperate and convert file to/from IM. Anyway, I do not think that we need to differentiate IM from file. --Avshalom Paul Kyzivat 28/07/2006 16:54 To Avshalom Houri/Haifa/IBM@IBMIL cc Amitkumar.Goel@infineon.com, fluffy@cisco.com, Gonzalo.Camarillo@ericsson.com, miguel.an.garcia@nokia.com, mmusic@ietf.org, Salvatore.Loreto@ericsson.com, simple@ietf.org Subject Re: [Simple] RE: [MMUSIC] File transfer when one device is cpim compatible Avshalom Houri wrote: > There may be security issues that may necessitate to know that > an MSRP session is actually a file transfer like virus scanning. I don't see how such a distinction would be helpful. It is possible to use a "conversational" MSRP session to transfer files as well. So if you care about such things you should be scanning all MSRP traffic in any case. Paul > However, I agree with Paul that we should not differentiate file > transfer from IM as these kind of protections should be in the > application level. > --Avshalom > > > > > > Paul Kyzivat > 27/07/2006 19:22 > > To > Amitkumar.Goel@infineon.com > cc > fluffy@cisco.com, mmusic@ietf.org, miguel.an.garcia@nokia.com, > Gonzalo.Camarillo@ericsson.com, simple@ietf.org, > Salvatore.Loreto@ericsson.com > Subject > Re: [Simple] RE: [MMUSIC] File transfer when one device is cpim > compatible > > > > > > > Some disjoint thoughts on this subject: > > I don't think *MSRP* should differentiate between IM and file transfer. > MSRP has plenty of ways to identify and categorize the content that may > be used by the applications on top of MSRP to do that differentiation. > > Since other IM protocols do support file transfer, perhaps CPIM should > be allowed for file transfer. > > It occurs to me that MIME provides some useful tools that might be > applicable here. In particular, Content-Disposition might be of use. A > Content-Disposition of "render" would be a real IM. Some other > disposition (e.g. "attachment") could be used for a message containing a > file being transferred. > > Paul > > Amitkumar.Goel@infineon.com wrote: >> Hi, >> >> It means MSRP should differentiate between "instant message" and "file >> transfer" sessions. >> >> Regards, >> Amit >> >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: Wednesday, July 26, 2006 8:03 PM >> To: Goel Amitkumar (IFIN SW WS) >> Cc: mmusic@ietf.org; Salvatore.Loreto@ericsson.com; >> miguel.an.garcia@nokia.com; Gonzalo.Camarillo@ericsson.com >> Subject: Re: [MMUSIC] File transfer when one device is cpim compatible >> >> >> I suspect that the file transfer would not be considered an "instant >> message" and thus would not be wrapped. >> >> >> On Jul 24, 2006, at 9:12 PM, >> wrote: >> >>> Hi All, >>> >>> According to MSRP draft "when one endpoint of the session is a CPIM >>> gateway, instant messages SHOULD be wrapped in "message/cpim" [12] >>> bodies". >>> So my question is how the example given in section 7 of >>> "draft-garcia-mmusic-file-transfer-mech-00.txt" looks when any one of >>> the device participating in file transfer is CPIM compatible? >>> >>> Regards, >>> Amit >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mmusic >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 28 11:06:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Tv1-0007aI-4H; Fri, 28 Jul 2006 11:06:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Tuz-0007Xx-9P for simple@ietf.org; Fri, 28 Jul 2006 11:06:25 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6Tux-0001Td-VM for simple@ietf.org; Fri, 28 Jul 2006 11:06:25 -0400 Received: from [172.17.2.115] ([172.17.2.115]) (authenticated bits=0) by vicuna.estacado.net (8.13.6/8.13.4) with ESMTP id k6SF55Dk071314 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 28 Jul 2006 10:05:05 -0500 (CDT) (envelope-from ben@estacado.net) In-Reply-To: <02d75c0e201940d469d209c90655f3cf@telio.no> References: <7231458A-3F8C-41F5-9EFD-DFCCEA200F72@estacado.net> <02d75c0e201940d469d209c90655f3cf@telio.no> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2BE2B128-D245-4E2A-8509-41DBCCD274A3@estacado.net> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] Re: Comments on draft-ietf-simple-imdn-00.txt Date: Fri, 28 Jul 2006 10:04:59 -0500 To: Hisham Khartabil X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 Cc: simple@ietf.org, Eric Burger X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org On Jul 28, 2006, at 8:33 AM, Hisham Khartabil wrote: > Hi, > > Thanks for the comments. Responses inline... > > On Jul 27, 2006, at 9:00 PM, Eric McMurry wrote: > >> I understand that a rewrite is being considered, so I'll hold off >> on editorial comments. >> >> >> 1) I'm struggling a bit with the application of this to MSRP. DNs >> in general seem to make more sense for non-realtime applications >> (like page-mode messaging). For realtime, session-mode, >> applications, the session protocol ensures that messages are >> delivered. Also, sessions tend to be interactive which I think >> greatly lessens the value of read notifications. Perhaps someone >> has a use case for this to make the value more clear? > > Having a message session with a machine the requires delivery of > IMs in proper sequence and therefore need a delivery notification > before sending the next one. > I'm not sure I buy this example. I can use the built in notification mechanism in MSRP to accomplish the same thing. The only use cases I can think of involve messages that cross session "boundaries", i.e. when some sort of MSRP B2BUA is involved. I've mentioned before that I think it makes more sense to leave such specification on how we use IMDN fpr MSRP until we define such applications. Or at least spec out some agreed requirements for IMDN in MSRP--right now we are speculating on how it might be used. I am not at all confident our speculation will turn out to be true. >> >> >> 2) The available disposition states ("delivered", "read") are >> suited for responses from the target UA, but not so much for >> intermediaries. I think reintroducing something like the >> "processed" state, but more specific, may be in order. Take, for >> example, the store-and-forward case. > > We have deliberately limited it to delivered and read. Future > extensions can define something like "processed" On reflection, when using SIP, I think receiving a 202 to a MESSAGE is means the same thing that Eric is asking for. It may be worth considering whether we want to have that concept in IMDN. (I lean towards "no"-We have a slippery slope here on adding too much transport functionality to IMDN.) > >> >> An intermediary strictly following the current spec would return a >> negative delivery notification when it was not able to reach a >> target. If the intermediary provides store-and-forward service >> though, this results in a less than ideal experience for the user >> requesting the IMDN. They would almost immediately receive an >> indication that their message was not delivered. > > No. They wouldn't receive anything. The message is still to be > delivered. When I first read Hisham's response, I thought he was saying nothing would be sent unless delivery succeeded. But I think he means that the intermediary should not return a failure IMDN until it had exhausted all opportunities to deliver the message. If so, then I think I agree. > >> Some time later (assuming that the message was subsequently >> successfully delivered), they would receive another IMDN for the >> same message indicating success (this one is a bit fuzzier I think). > > This would be the first one they get. > >> >> The net is that it is confusing to the user. I would suggest >> adding a "stored" state to handle this. It would be sent by an >> intermediary providing store-and-forward service and would provide >> the sender with a much more accurate view of what the intermediate >> disposition of their message was. >> >> >> 3) "Future extensions" are mentioned in several places, but no >> extension mechanism is specified. Perhaps a mechanism for vendor >> specific extensions should be specified to avoid collisions with >> future versions of this spec. > > Added text in section 9.1 suggesting future extensions must be in > an RFC. > >> >> >> 4) The example of an IM body with an IMDN request (section 4.1) >> has not caught up with the addition of a CPIM namespace to the >> specification. > > I actually forgot this was there. I removed the definition of the > new namespace and referred to the default namespace instead. We are taking the namespace out? Why? Or did I misread your intent? Namespaces are the defined mechanism for extending CPIM. > >> >> >> 5) In section 4.4 "Keeping State", second paragraph, perhaps the >> phase "user choice" should read "local policy" (okay, that was a >> bit editorial :-) > > I actually prefer user choice since it clearly states that the user > makes that choice and not the implementer. > If that is the intent, we need more normative language to say the implementation MUST or SHOULD let the user decide. But in this case, I do think this is more an implementation choice than a user choice. I don't see an end-user being in a position to decide whether they want to keep state or not. This is more a matter of the type of device, it's memory constraints, the intended user experience, etc. >> >> >> 6) Description of use of the Original-To header should spell out >> that this header should only be added if it does not already >> exist. It is possible that there will be multiple intermediaries >> in the path, and only the first one should do this. > > Yes. This is done already in my local copy of the next version. > >> >> >> 7) I agreed with Miguel Garcia's comment on Really-To and Really- >> From in another email, but allow me to reiterate. This is a Via- >> like mechanism and would be less confusing (at least to me) if it >> were named as such. > > I'll make that change. > By the way, we got feedback on MSRP to try to avoid having different header names start with the same several letters. It makes parsing harder. >> >> >> 8) Aggregation. Let's start with a scenario. Say there's a >> request to a list exploder with a local policy on the requested >> list to not reveal the list members. Let's also say that the >> exploder is going to aggregate IMDNs either by policy or request. >> >> So the request is exploded, and time passes. The exploder >> collects some IMDNs and decides it's time to send an aggregate >> response. Since the local policy is to not reveal list members, >> it strips this info from all of the IMDNs. Then it prepares and >> sends the aggregated IMDN. > > A list server can send *ONE* imdn indicating "delivered" after is > has received some or all of the IMDNs. This is only an option of > course. > >> >> The UA that originated the request to the list exploder then >> receives a list of IMDNs with no user information in them. Now, >> how will this be presented to the user? > > "x users received the message" is one example. This is an > implementation choice > >> The client only knows that some number of users on the list >> received the message, some number didn't, and an unknown number >> did or didn't receive it. > > That acceptable, imo. Acceptable, maybe. Can we describe a use case for which it is _useful_. > >> >> The number of aggregated IMDNs could be large as well and may >> require multiple messages (only 1300 bytes available for MESSAGE) >> to send. I would suggest that aggregated IMDNs don't make sense >> if the policy of the aggregator is to strip the recipient info. > > I disagree. I think it does make sense. Sometimes I am interested > that enough people received the message, not who. > >> The most useful piece of delivery information that can probably >> be obtained in this scenario is that the message was delivered >> successfully or not to the list server. This could be >> accomplished by sending a "delivered" state IMDN from the list >> server, or if something more explicit is desired, another >> intermediate state, such as "exploded" (okay, that was just for >> fun, but it conveys the status) could be defined. > > >> >> >> 9) I'm sure this would have been covered in the next version, but >> just in case: the text for the IANA registration of the Content- >> Disposition header (13.5) is missing. > > Yes. Added. > > Thanks, > Hisham > > >> >> >> >> Thanks, >> >> Eric >> >> ----- >> Eric McMurry >> Estacado Systems >> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 28 11:25:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6UDF-0002JD-Ep; Fri, 28 Jul 2006 11:25:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6UDE-0002J8-OL for simple@ietf.org; Fri, 28 Jul 2006 11:25:16 -0400 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6UDB-0005HS-KE for simple@ietf.org; Fri, 28 Jul 2006 11:25:16 -0400 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 75D6319448B for ; Fri, 28 Jul 2006 17:25:12 +0200 (CEST) Received: from [192.168.1.11] ([192.168.1.11]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Jul 2006 17:24:15 +0200 In-Reply-To: <2BE2B128-D245-4E2A-8509-41DBCCD274A3@estacado.net> References: <7231458A-3F8C-41F5-9EFD-DFCCEA200F72@estacado.net> <02d75c0e201940d469d209c90655f3cf@telio.no> <2BE2B128-D245-4E2A-8509-41DBCCD274A3@estacado.net> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] Re: Comments on draft-ietf-simple-imdn-00.txt Date: Fri, 28 Jul 2006 17:25:39 +0200 To: Ben Campbell X-Mailer: Apple Mail (2.624) X-OriginalArrivalTime: 28 Jul 2006 15:24:15.0715 (UTC) FILETIME=[E303D330:01C6B259] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 Cc: simple@ietf.org, Eric Burger X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi Ben, Comments inline... On Jul 28, 2006, at 5:04 PM, Ben Campbell wrote: > > On Jul 28, 2006, at 8:33 AM, Hisham Khartabil wrote: > >> Hi, >> >> Thanks for the comments. Responses inline... >> >> On Jul 27, 2006, at 9:00 PM, Eric McMurry wrote: >> >>> I understand that a rewrite is being considered, so I'll hold off on >>> editorial comments. >>> >>> >>> 1) I'm struggling a bit with the application of this to MSRP. DNs >>> in general seem to make more sense for non-realtime applications >>> (like page-mode messaging). For realtime, session-mode, >>> applications, the session protocol ensures that messages are >>> delivered. Also, sessions tend to be interactive which I think >>> greatly lessens the value of read notifications. Perhaps someone >>> has a use case for this to make the value more clear? >> >> Having a message session with a machine the requires delivery of IMs >> in proper sequence and therefore need a delivery notification before >> sending the next one. >> > > I'm not sure I buy this example. I can use the built in notification > mechanism in MSRP to accomplish the same thing. > > The only use cases I can think of involve messages that cross session > "boundaries", i.e. when some sort of MSRP B2BUA is involved. > > I've mentioned before that I think it makes more sense to leave such > specification on how we use IMDN fpr MSRP until we define such > applications. Or at least spec out some agreed requirements for IMDN > in MSRP--right now we are speculating on how it might be used. I am > not at all confident our speculation will turn out to be true. I used a bad example here. The draft actually says that for MSRP, delivery notification are not relevant since MRSP has that built in. The draft stresses that read notifications and any other future extensions might be useful. I don't agree that we need an application to define this. Companies might have use cases for this that they don't want to make public yet that uses on IMDNs for MSRP. Why make them wait 2 years to get an RFC where the text in the current draft is not damaging? > > > >>> >>> >>> 2) The available disposition states ("delivered", "read") are suited >>> for responses from the target UA, but not so much for >>> intermediaries. I think reintroducing something like the >>> "processed" state, but more specific, may be in order. Take, for >>> example, the store-and-forward case. >> >> We have deliberately limited it to delivered and read. Future >> extensions can define something like "processed" > > On reflection, when using SIP, I think receiving a 202 to a MESSAGE is > means the same thing that Eric is asking for. It may be worth > considering whether we want to have that concept in IMDN. (I lean > towards "no"-We have a slippery slope here on adding too much > transport functionality to IMDN.) > >> >>> >>> An intermediary strictly following the current spec would return a >>> negative delivery notification when it was not able to reach a >>> target. If the intermediary provides store-and-forward service >>> though, this results in a less than ideal experience for the user >>> requesting the IMDN. They would almost immediately receive an >>> indication that their message was not delivered. >> >> No. They wouldn't receive anything. The message is still to be >> delivered. > > When I first read Hisham's response, I thought he was saying nothing > would be sent unless delivery succeeded. But I think he means that the > intermediary should not return a failure IMDN until it had exhausted > all opportunities to deliver the message. If so, then I think I agree. Yes thats what I meant. > >> >>> Some time later (assuming that the message was subsequently >>> successfully delivered), they would receive another IMDN for the >>> same message indicating success (this one is a bit fuzzier I think). >> >> This would be the first one they get. >> >>> >>> The net is that it is confusing to the user. I would suggest adding >>> a "stored" state to handle this. It would be sent by an >>> intermediary providing store-and-forward service and would provide >>> the sender with a much more accurate view of what the intermediate >>> disposition of their message was. >>> >>> >>> 3) "Future extensions" are mentioned in several places, but no >>> extension mechanism is specified. Perhaps a mechanism for vendor >>> specific extensions should be specified to avoid collisions with >>> future versions of this spec. >> >> Added text in section 9.1 suggesting future extensions must be in an >> RFC. >> >>> >>> >>> 4) The example of an IM body with an IMDN request (section 4.1) has >>> not caught up with the addition of a CPIM namespace to the >>> specification. >> >> I actually forgot this was there. I removed the definition of the new >> namespace and referred to the default namespace instead. > > We are taking the namespace out? Why? Or did I misread your intent? > > Namespaces are the defined mechanism for extending CPIM. I believe using the default namespace is allowed. You can define a new namespace for new headers if you are worried about header name clashes. Or am I wrong? > > >> >>> >>> >>> 5) In section 4.4 "Keeping State", second paragraph, perhaps the >>> phase "user choice" should read "local policy" (okay, that was a bit >>> editorial :-) >> >> I actually prefer user choice since it clearly states that the user >> makes that choice and not the implementer. >> > > If that is the intent, we need more normative language to say the > implementation MUST or SHOULD let the user decide. But in this case, I > do think this is more an implementation choice than a user choice. I > don't see an end-user being in a position to decide whether they want > to keep state or not. This is more a matter of the type of device, > it's memory constraints, the intended user experience, etc. > This is the text in the draft "How long to keep items in the "Sent Items" box is a user choice." It is not about keeping state, it is about keeping items in the sent items box. This is not an implementer choice. I would smash the phone if it removed things from my "Sent Items" box without me doing it deliberately :) We are not discussing how to implement a "Sent Items" box anyhow in this draft. > > >>> >>> >>> 6) Description of use of the Original-To header should spell out >>> that this header should only be added if it does not already exist. >>> It is possible that there will be multiple intermediaries in the >>> path, and only the first one should do this. >> >> Yes. This is done already in my local copy of the next version. >> >>> >>> >>> 7) I agreed with Miguel Garcia's comment on Really-To and >>> Really-From in another email, but allow me to reiterate. This is a >>> Via-like mechanism and would be less confusing (at least to me) if >>> it were named as such. >> >> I'll make that change. >> > > By the way, we got feedback on MSRP to try to avoid having different > header names start with the same several letters. It makes parsing > harder. > >>> >>> >>> 8) Aggregation. Let's start with a scenario. Say there's a request >>> to a list exploder with a local policy on the requested list to not >>> reveal the list members. Let's also say that the exploder is going >>> to aggregate IMDNs either by policy or request. >>> >>> So the request is exploded, and time passes. The exploder collects >>> some IMDNs and decides it's time to send an aggregate response. >>> Since the local policy is to not reveal list members, it strips this >>> info from all of the IMDNs. Then it prepares and sends the >>> aggregated IMDN. >> >> A list server can send *ONE* imdn indicating "delivered" after is has >> received some or all of the IMDNs. This is only an option of course. >> >>> >>> The UA that originated the request to the list exploder then >>> receives a list of IMDNs with no user information in them. Now, how >>> will this be presented to the user? >> >> "x users received the message" is one example. This is an >> implementation choice >> >>> The client only knows that some number of users on the list >>> received the message, some number didn't, and an unknown number did >>> or didn't receive it. >> >> That acceptable, imo. > > Acceptable, maybe. Can we describe a use case for which it is _useful_. What are you suggesting? Are you suggesting that no aggregation is done for private lists? or should the list server reject the IM? I can't think of a use case now, but I don't think we should add complications by forbidding something. This is implementation choice. Thanks, Hisham > > >> >>> >>> The number of aggregated IMDNs could be large as well and may >>> require multiple messages (only 1300 bytes available for MESSAGE) to >>> send. I would suggest that aggregated IMDNs don't make sense if the >>> policy of the aggregator is to strip the recipient info. >> >> I disagree. I think it does make sense. Sometimes I am interested >> that enough people received the message, not who. >> >>> The most useful piece of delivery information that can probably be >>> obtained in this scenario is that the message was delivered >>> successfully or not to the list server. This could be accomplished >>> by sending a "delivered" state IMDN from the list server, or if >>> something more explicit is desired, another intermediate state, such >>> as "exploded" (okay, that was just for fun, but it conveys the >>> status) could be defined. >> >> >>> >>> >>> 9) I'm sure this would have been covered in the next version, but >>> just in case: the text for the IANA registration of the >>> Content-Disposition header (13.5) is missing. >> >> Yes. Added. >> >> Thanks, >> Hisham >> >> >>> >>> >>> >>> Thanks, >>> >>> Eric >>> >>> ----- >>> Eric McMurry >>> Estacado Systems >>> >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 28 11:50:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Ubb-0003YE-RR; Fri, 28 Jul 2006 11:50:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Ubb-0003XM-94 for simple@ietf.org; Fri, 28 Jul 2006 11:50:27 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6Uba-00040H-NK for simple@ietf.org; Fri, 28 Jul 2006 11:50:27 -0400 X-IronPort-AV: i="4.07,193,1151899200"; d="scan'208"; a="35903770:sNHT36158456" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Re: Comments on draft-ietf-simple-imdn-00.txt Date: Fri, 28 Jul 2006 11:50:22 -0400 Message-ID: <330A23D8336C0346B5C1A5BB196666470356A5B9@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Re: Comments on draft-ietf-simple-imdn-00.txt Thread-Index: AcayWmT0wRbKJ07qQumovDMyIEvpvgAAXCZg From: "Burger, Eric" To: "Hisham Khartabil" , "Ben Campbell" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3b8eea209b62bd15620865bc4fbef8cd Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Mine, too (inline): > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: Friday, July 28, 2006 11:26 AM > To: Ben Campbell > Cc: Eric McMurry; simple@ietf.org; Burger, Eric > Subject: Re: [Simple] Re: Comments on draft-ietf-simple-imdn-00.txt >=20 > Hi Ben, >=20 > Comments inline... >=20 > On Jul 28, 2006, at 5:04 PM, Ben Campbell wrote: >=20 > > > > On Jul 28, 2006, at 8:33 AM, Hisham Khartabil wrote: > > > >> Hi, > >> > >> Thanks for the comments. Responses inline... > >> > >> On Jul 27, 2006, at 9:00 PM, Eric McMurry wrote: > >> > >>> I understand that a rewrite is being considered, so I'll hold off on=20 > >>> editorial comments. > >>> > >>> > >>> 1) I'm struggling a bit with the application of this to MSRP. DNs > >>> in general seem to make more sense for non-realtime applications=20 > >>> (like page-mode messaging). For realtime, session-mode,=20 > >>> applications, the session protocol ensures that messages are=20 > >>> delivered. Also, sessions tend to be interactive which I think=20 > >>> greatly lessens the value of read notifications. Perhaps someone=20 > >>> has a use case for this to make the value more clear? > >> > >> Having a message session with a machine the requires delivery of IMs=20 > >> in proper sequence and therefore need a delivery notification before=20 > >> sending the next one. > >> > > > > I'm not sure I buy this example. I can use the built in notification > > mechanism in MSRP to accomplish the same thing. > > > > The only use cases I can think of involve messages that cross session=20 > > "boundaries", i.e. when some sort of MSRP B2BUA is involved. > > > > I've mentioned before that I think it makes more sense to leave such > > specification on how we use IMDN fpr MSRP until we define such=20 > > applications. Or at least spec out some agreed requirements for IMDN > > in MSRP--right now we are speculating on how it might be used. I am=20 > > not at all confident our speculation will turn out to be true. >=20 > I used a bad example here. The draft actually says that for MSRP,=20 > delivery notification are not relevant since MRSP has that built in.=20 > The draft stresses that read notifications and any other future=20 > extensions might be useful. >=20 > I don't agree that we need an application to define this. Companies=20 > might have use cases for this that they don't want to make public yet=20 > that uses on IMDNs for MSRP. Why make them wait 2 years to get an RFC=20 > where the text in the current draft is not damaging? I can go either way on this one. > >>> 2) The available disposition states ("delivered", "read") are suited=20 > >>> for responses from the target UA, but not so much for=20 > >>> intermediaries. I think reintroducing something like the=20 > >>> "processed" state, but more specific, may be in order. Take, for=20 > >>> example, the store-and-forward case. > >> > >> We have deliberately limited it to delivered and read. Future=20 > >> extensions can define something like "processed" > > > > On reflection, when using SIP, I think receiving a 202 to a MESSAGE is=20 > > means the same thing that Eric is asking for. It may be worth=20 > > considering whether we want to have that concept in IMDN. (I lean=20 > > towards "no"-We have a slippery slope here on adding too much=20 > > transport functionality to IMDN.) > > > >> > >>> > >>> An intermediary strictly following the current spec would return a > >>> negative delivery notification when it was not able to reach a=20 > >>> target. If the intermediary provides store-and-forward service=20 > >>> though, this results in a less than ideal experience for the user=20 > >>> requesting the IMDN. They would almost immediately receive an=20 > >>> indication that their message was not delivered. > >> > >> No. They wouldn't receive anything. The message is still to be=20 > >> delivered. > > > > When I first read Hisham's response, I thought he was saying nothing > > would be sent unless delivery succeeded. But I think he means that the=20 > > intermediary should not return a failure IMDN until it had exhausted > > all opportunities to deliver the message. If so, then I think I agree. >=20 > Yes thats what I meant. > > >>> Some time later (assuming that the message was subsequently=20 > >>> successfully delivered), they would receive another IMDN for the=20 > >>> same message indicating success (this one is a bit fuzzier I think). > >> > >> This would be the first one they get. > >> > >>> > >>> The net is that it is confusing to the user. I would suggest adding=20 > >>> a "stored" state to handle this. It would be sent by an=20 > >>> intermediary providing store-and-forward service and would provide > >>> the sender with a much more accurate view of what the intermediate > >>> disposition of their message was. I really, really would rather have the "processed" state. Let the protocol say what it is really doing, not what it thinks might be possibly going on. The B2BUA receives a message: it is being processed, so tell the UAC so. A later delivery message should work just fine. The B2BUA doesn't get the message, or it can't process the message: send a failure report. I don't like "stored", because that is only relevant to store-and-forward. IMDN should work for any B2BUA, not just a store-and-forward B2BUA. Note that having the hint to the B2BUA that the UAC is looking for the fate of the B2BUA's handling of the message, rather than the endpoints handling of the message, removes the ambiguity of who should generate the IMDN and what the IMDN means. > >>> 3) "Future extensions" are mentioned in several places, but no=20 > >>> extension mechanism is specified. Perhaps a mechanism for vendor=20 > >>> specific extensions should be specified to avoid collisions with=20 > >>> future versions of this spec. > >> > >> Added text in section 9.1 suggesting future extensions must be in an=20 > >> RFC. > >> > >>> > >>> > >>> 4) The example of an IM body with an IMDN request (section 4.1) has=20 > >>> not caught up with the addition of a CPIM namespace to the=20 > >>> specification. > >> > >> I actually forgot this was there. I removed the definition of the new=20 > >> namespace and referred to the default namespace instead. > > > > We are taking the namespace out? Why? Or did I misread your intent? > > > > Namespaces are the defined mechanism for extending CPIM. >=20 > I believe using the default namespace is allowed. You can define a new > namespace for new headers if you are worried about header name clashes.=20 > Or am I wrong? Namespaces are also used for capabilities negotiation, so it really should be included. > >>> 5) In section 4.4 "Keeping State", second paragraph, perhaps the=20 > >>> phase "user choice" should read "local policy" (okay, that was a bit=20 > >>> editorial :-) > >> > >> I actually prefer user choice since it clearly states that the user > >> makes that choice and not the implementer. > >> > > > > If that is the intent, we need more normative language to say the=20 > > implementation MUST or SHOULD let the user decide. But in this case, I=20 > > do think this is more an implementation choice than a user choice. I > > don't see an end-user being in a position to decide whether they want=20 > > to keep state or not. This is more a matter of the type of device,=20 > > it's memory constraints, the intended user experience, etc. > > > This is the text in the draft "How long to keep items in the "Sent=20 > Items" box is a user choice." It is not about keeping state, it is=20 > about keeping items in the sent items box. >=20 > This is not an implementer choice. I would smash the phone if it=20 > removed things from my "Sent Items" box without me doing it=20 > deliberately :) We are not discussing how to implement a "Sent Items"=20 > box anyhow in this draft. Which is also why it isn't really user choice... > >>> 6) Description of use of the Original-To header should spell out=20 > >>> that this header should only be added if it does not already exist. =20 > >>> It is possible that there will be multiple intermediaries in the=20 > >>> path, and only the first one should do this. > >> > >> Yes. This is done already in my local copy of the next version. > >> > >>> > >>> > >>> 7) I agreed with Miguel Garcia's comment on Really-To and=20 > >>> Really-From in another email, but allow me to reiterate. This is a=20 > >>> Via-like mechanism and would be less confusing (at least to me) if > >>> it were named as such. > >> > >> I'll make that change. > >> > > > > By the way, we got feedback on MSRP to try to avoid having different > > header names start with the same several letters. It makes parsing=20 > > harder. A LONG, SLOW PAINFUL DEATH TO IMPLEMENTORS THAT DO NOT BUILD A REAL PARSER THAT FOLLOWS THE FULL SPECIFICATION. We first tear out their fingers so they can no longer inflict "almost compatible" implementations that we later have to work around. GIVE ME A BREAK. Too bad if my 12 character string starts with the same 6 characters! If they are not reading the entire string, they have blown it already. > >>> 8) Aggregation. Let's start with a scenario. Say there's a request=20 > >>> to a list exploder with a local policy on the requested list to not=20 > >>> reveal the list members. Let's also say that the exploder is going=20 > >>> to aggregate IMDNs either by policy or request. > >>> > >>> So the request is exploded, and time passes. The exploder collects=20 > >>> some IMDNs and decides it's time to send an aggregate response. =20 > >>> Since the local policy is to not reveal list members, it strips this=20 > >>> info from all of the IMDNs. Then it prepares and sends the=20 > >>> aggregated IMDN. > >> > >> A list server can send *ONE* imdn indicating "delivered" after is has=20 > >> received some or all of the IMDNs. This is only an option of course. > >> > >>> > >>> The UA that originated the request to the list exploder then=20 > >>> receives a list of IMDNs with no user information in them. Now, how=20 > >>> will this be presented to the user? > >> > >> "x users received the message" is one example. This is an=20 > >> implementation choice > >> > >>> The client only knows that some number of users on the list=20 > >>> received the message, some number didn't, and an unknown number did=20 > >>> or didn't receive it. > >> > >> That acceptable, imo. > > > > Acceptable, maybe. Can we describe a use case for which it is _useful_. >=20 > What are you suggesting? Are you suggesting that no aggregation is done=20 > for private lists? or should the list server reject the IM? I can't=20 > think of a use case now, but I don't think we should add complications > by forbidding something. This is implementation choice. Agreed (with Hisham) > >>> The number of aggregated IMDNs could be large as well and may=20 > >>> require multiple messages (only 1300 bytes available for MESSAGE) to=20 > >>> send. I would suggest that aggregated IMDNs don't make sense if the=20 > >>> policy of the aggregator is to strip the recipient info. > >> > >> I disagree. I think it does make sense. Sometimes I am interested=20 > >> that enough people received the message, not who. > >> > >>> The most useful piece of delivery information that can probably be=20 > >>> obtained in this scenario is that the message was delivered=20 > >>> successfully or not to the list server. This could be accomplished=20 > >>> by sending a "delivered" state IMDN from the list server, or if=20 > >>> something more explicit is desired, another intermediate state, such=20 > >>> as "exploded" (okay, that was just for fun, but it conveys the=20 > >>> status) could be defined. This would be handled by the UAC giving the B2BUA the hint that the IMDN is for the B2BUA to generate (in its role as a UAS) and not for down-stream nodes to generate. > >>> 9) I'm sure this would have been covered in the next version, but=20 > >>> just in case: the text for the IANA registration of the=20 > >>> Content-Disposition header (13.5) is missing. > >> > >> Yes. Added. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 28 12:57:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Ve3-0008HW-L7; Fri, 28 Jul 2006 12:57:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Ve2-0008HR-Js for simple@ietf.org; Fri, 28 Jul 2006 12:57:02 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6Ve1-0004oe-PX for simple@ietf.org; Fri, 28 Jul 2006 12:57:02 -0400 Received: from [172.17.2.233] ([172.17.2.233]) (authenticated bits=0) by vicuna.estacado.net (8.13.6/8.13.4) with ESMTP id k6SGtecb082719 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 28 Jul 2006 11:55:40 -0500 (CDT) (envelope-from emcmurry@estacado.net) In-Reply-To: <330A23D8336C0346B5C1A5BB196666470356A5B9@ATLANTIS.Brooktrout.com> References: <330A23D8336C0346B5C1A5BB196666470356A5B9@ATLANTIS.Brooktrout.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Eric McMurry Subject: Re: [Simple] Re: Comments on draft-ietf-simple-imdn-00.txt Date: Fri, 28 Jul 2006 11:55:31 -0500 To: "Burger, Eric" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: efb5d987e2484f3d9a304cc31a003441 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org also inline... On Jul 28, 2006, at 10:50 AM, Burger, Eric wrote: > Mine, too (inline): > >> -----Original Message----- >> From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] >> Sent: Friday, July 28, 2006 11:26 AM >> To: Ben Campbell >> Cc: Eric McMurry; simple@ietf.org; Burger, Eric >> Subject: Re: [Simple] Re: Comments on draft-ietf-simple-imdn-00.txt >> >> Hi Ben, >> >> Comments inline... >> >> On Jul 28, 2006, at 5:04 PM, Ben Campbell wrote: >> >>> >>> On Jul 28, 2006, at 8:33 AM, Hisham Khartabil wrote: >>> >>>> Hi, >>>> >>>> Thanks for the comments. Responses inline... >>>> >>>> On Jul 27, 2006, at 9:00 PM, Eric McMurry wrote: >>>> >>>>> I understand that a rewrite is being considered, so I'll hold off > on >>>>> editorial comments. >>>>> >>>>> >>>>> 1) I'm struggling a bit with the application of this to MSRP. DNs > >>>>> in general seem to make more sense for non-realtime applications >>>>> (like page-mode messaging). For realtime, session-mode, >>>>> applications, the session protocol ensures that messages are >>>>> delivered. Also, sessions tend to be interactive which I think >>>>> greatly lessens the value of read notifications. Perhaps someone >>>>> has a use case for this to make the value more clear? >>>> >>>> Having a message session with a machine the requires delivery of > IMs >>>> in proper sequence and therefore need a delivery notification > before >>>> sending the next one. >>>> >>> >>> I'm not sure I buy this example. I can use the built in notification > >>> mechanism in MSRP to accomplish the same thing. >>> >>> The only use cases I can think of involve messages that cross > session >>> "boundaries", i.e. when some sort of MSRP B2BUA is involved. >>> >>> I've mentioned before that I think it makes more sense to leave such > >>> specification on how we use IMDN fpr MSRP until we define such >>> applications. Or at least spec out some agreed requirements for IMDN > >>> in MSRP--right now we are speculating on how it might be used. I am >>> not at all confident our speculation will turn out to be true. >> >> I used a bad example here. The draft actually says that for MSRP, >> delivery notification are not relevant since MRSP has that built in. >> The draft stresses that read notifications and any other future >> extensions might be useful. >> >> I don't agree that we need an application to define this. Companies >> might have use cases for this that they don't want to make public yet >> that uses on IMDNs for MSRP. Why make them wait 2 years to get an RFC >> where the text in the current draft is not damaging? > > I can go either way on this one. I'll buy the hidden use case and I'll also buy that there could easily be one I haven't thought of. What I was hoping to get from my question though was someone saying that they needed this (and better still, why). > > >>>>> 2) The available disposition states ("delivered", "read") are > suited >>>>> for responses from the target UA, but not so much for >>>>> intermediaries. I think reintroducing something like the >>>>> "processed" state, but more specific, may be in order. Take, for >>>>> example, the store-and-forward case. >>>> >>>> We have deliberately limited it to delivered and read. Future >>>> extensions can define something like "processed" >>> >>> On reflection, when using SIP, I think receiving a 202 to a MESSAGE > is >>> means the same thing that Eric is asking for. It may be worth >>> considering whether we want to have that concept in IMDN. (I lean >>> towards "no"-We have a slippery slope here on adding too much >>> transport functionality to IMDN.) >>> >>>> >>>>> >>>>> An intermediary strictly following the current spec would return a > >>>>> negative delivery notification when it was not able to reach a >>>>> target. If the intermediary provides store-and-forward service >>>>> though, this results in a less than ideal experience for the user >>>>> requesting the IMDN. They would almost immediately receive an >>>>> indication that their message was not delivered. >>>> >>>> No. They wouldn't receive anything. The message is still to be >>>> delivered. >>> >>> When I first read Hisham's response, I thought he was saying nothing > >>> would be sent unless delivery succeeded. But I think he means that > the >>> intermediary should not return a failure IMDN until it had exhausted > >>> all opportunities to deliver the message. If so, then I think I > agree. >> >> Yes thats what I meant. and I agree that that interpretation makes more sense. I was just being strict on how I read "final response" >> >>>>> Some time later (assuming that the message was subsequently >>>>> successfully delivered), they would receive another IMDN for the >>>>> same message indicating success (this one is a bit fuzzier I > think). >>>> >>>> This would be the first one they get. >>>> >>>>> >>>>> The net is that it is confusing to the user. I would suggest > adding >>>>> a "stored" state to handle this. It would be sent by an >>>>> intermediary providing store-and-forward service and would provide > >>>>> the sender with a much more accurate view of what the intermediate > >>>>> disposition of their message was. > > I really, really would rather have the "processed" state. Let the > protocol say what it is really doing, not what it thinks might be > possibly going on. The B2BUA receives a message: it is being > processed, > so tell the UAC so. A later delivery message should work just fine. > The B2BUA doesn't get the message, or it can't process the message: > send > a failure report. > > I don't like "stored", because that is only relevant to > store-and-forward. IMDN should work for any B2BUA, not just a > store-and-forward B2BUA. > > Note that having the hint to the B2BUA that the UAC is looking for the > fate of the B2BUA's handling of the message, rather than the endpoints > handling of the message, removes the ambiguity of who should generate > the IMDN and what the IMDN means. I'm also strongly in favor of allowing the protocol to have reporting of intermediate states. This allows for more descriptive status to be presented to the user. I still like "stored", but not as the only option. I was suggesting that a one example of a category of states of the "processed" ilk. However, I'm okay with using "processed" for this since we have the Note field for the intermediary to provide more descriptive information in. The drawback to this is that we lack a standard way of conveying the more descriptive information. The use of the hint to the intermediary is new to me. Are you suggesting that in this case, only the B2BUA would generate an IMDN? I was thinking more along the lines that the IMDN generated by the B2BUA would be an intermediate response, and that the final endpoint would also generate one. I think this would be true for both "processed" and "stored" types of states. > >>>>> 3) "Future extensions" are mentioned in several places, but no >>>>> extension mechanism is specified. Perhaps a mechanism for vendor >>>>> specific extensions should be specified to avoid collisions with >>>>> future versions of this spec. >>>> >>>> Added text in section 9.1 suggesting future extensions must be in > an >>>> RFC. >>>> >>>>> >>>>> >>>>> 4) The example of an IM body with an IMDN request (section 4.1) > has >>>>> not caught up with the addition of a CPIM namespace to the >>>>> specification. >>>> >>>> I actually forgot this was there. I removed the definition of the > new >>>> namespace and referred to the default namespace instead. >>> >>> We are taking the namespace out? Why? Or did I misread your intent? >>> >>> Namespaces are the defined mechanism for extending CPIM. >> >> I believe using the default namespace is allowed. You can define a >> new > >> namespace for new headers if you are worried about header name > clashes. >> Or am I wrong? > > Namespaces are also used for capabilities negotiation, so it really > should be included. > >>>>> 5) In section 4.4 "Keeping State", second paragraph, perhaps the >>>>> phase "user choice" should read "local policy" (okay, that was a > bit >>>>> editorial :-) >>>> >>>> I actually prefer user choice since it clearly states that the user > >>>> makes that choice and not the implementer. >>>> >>> >>> If that is the intent, we need more normative language to say the >>> implementation MUST or SHOULD let the user decide. But in this case, > I >>> do think this is more an implementation choice than a user choice. I > >>> don't see an end-user being in a position to decide whether they > want >>> to keep state or not. This is more a matter of the type of device, >>> it's memory constraints, the intended user experience, etc. >>> >> This is the text in the draft "How long to keep items in the "Sent >> Items" box is a user choice." It is not about keeping state, it is >> about keeping items in the sent items box. >> >> This is not an implementer choice. I would smash the phone if it >> removed things from my "Sent Items" box without me doing it >> deliberately :) We are not discussing how to implement a "Sent Items" >> box anyhow in this draft. > > Which is also why it isn't really user choice... I can't imagine a client not giving this choice to the user (except perhaps in the case of limited client resources). That said, I think this should be left up to the implementor since it is a UI feature. > >>>>> 6) Description of use of the Original-To header should spell out >>>>> that this header should only be added if it does not already > exist. >>>>> It is possible that there will be multiple intermediaries in the >>>>> path, and only the first one should do this. >>>> >>>> Yes. This is done already in my local copy of the next version. >>>> >>>>> >>>>> >>>>> 7) I agreed with Miguel Garcia's comment on Really-To and >>>>> Really-From in another email, but allow me to reiterate. This is > a >>>>> Via-like mechanism and would be less confusing (at least to me) if > >>>>> it were named as such. >>>> >>>> I'll make that change. >>>> >>> >>> By the way, we got feedback on MSRP to try to avoid having different > >>> header names start with the same several letters. It makes parsing >>> harder. > > A LONG, SLOW PAINFUL DEATH TO IMPLEMENTORS THAT DO NOT BUILD A REAL > PARSER THAT FOLLOWS THE FULL SPECIFICATION. We first tear out their > fingers so they can no longer inflict "almost compatible" > implementations that we later have to work around. > > GIVE ME A BREAK. Too bad if my 12 character string starts with the > same > 6 characters! If they are not reading the entire string, they have > blown it already. I wasn't going to be quite so violent in my response, but I agree :-) > > >>>>> 8) Aggregation. Let's start with a scenario. Say there's a > request >>>>> to a list exploder with a local policy on the requested list to > not >>>>> reveal the list members. Let's also say that the exploder is > going >>>>> to aggregate IMDNs either by policy or request. >>>>> >>>>> So the request is exploded, and time passes. The exploder > collects >>>>> some IMDNs and decides it's time to send an aggregate response. >>>>> Since the local policy is to not reveal list members, it strips > this >>>>> info from all of the IMDNs. Then it prepares and sends the >>>>> aggregated IMDN. >>>> >>>> A list server can send *ONE* imdn indicating "delivered" after is > has >>>> received some or all of the IMDNs. This is only an option of > course. >>>> >>>>> >>>>> The UA that originated the request to the list exploder then >>>>> receives a list of IMDNs with no user information in them. Now, > how >>>>> will this be presented to the user? >>>> >>>> "x users received the message" is one example. This is an >>>> implementation choice >>>> >>>>> The client only knows that some number of users on the list >>>>> received the message, some number didn't, and an unknown number > did >>>>> or didn't receive it. >>>> >>>> That acceptable, imo. >>> >>> Acceptable, maybe. Can we describe a use case for which it is > _useful_. >> >> What are you suggesting? Are you suggesting that no aggregation is > done >> for private lists? or should the list server reject the IM? I can't >> think of a use case now, but I don't think we should add >> complications > >> by forbidding something. This is implementation choice. > > Agreed (with Hisham) So, a list server can then potentially: ((ignore the IMDN request) or ((optionally generate a "processed" type IMDN when the list is exploded) and (optionally generate one "delivered" IMDN when it receives some number of IMDNs from the recipients) or (optionally generate some number of aggregated IMDNs with the recipient info stripped)) and the client would then have to savvy any combination of these if it wanted to send to a list. Maybe this is reasonable, but it seems as if we've come up with several ways to skin a cat, when it may be that we really had a porcupine (and who wants to skin a porcupine?). I'll have to give this some more thought. > >>>>> The number of aggregated IMDNs could be large as well and may >>>>> require multiple messages (only 1300 bytes available for MESSAGE) > to >>>>> send. I would suggest that aggregated IMDNs don't make sense if > the >>>>> policy of the aggregator is to strip the recipient info. >>>> >>>> I disagree. I think it does make sense. Sometimes I am interested >>>> that enough people received the message, not who. >>>> >>>>> The most useful piece of delivery information that can probably > be >>>>> obtained in this scenario is that the message was delivered >>>>> successfully or not to the list server. This could be > accomplished >>>>> by sending a "delivered" state IMDN from the list server, or if >>>>> something more explicit is desired, another intermediate state, > such >>>>> as "exploded" (okay, that was just for fun, but it conveys the >>>>> status) could be defined. > > This would be handled by the UAC giving the B2BUA the hint that the > IMDN > is for the B2BUA to generate (in its role as a UAS) and not for > down-stream nodes to generate. > > >>>>> 9) I'm sure this would have been covered in the next version, but >>>>> just in case: the text for the IANA registration of the >>>>> Content-Disposition header (13.5) is missing. >>>> >>>> Yes. Added. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 28 13:51:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6WUO-0000ky-Ev; Fri, 28 Jul 2006 13:51:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6WUN-0000kt-De for simple@ietf.org; Fri, 28 Jul 2006 13:51:07 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6WUM-0001Dm-OV for simple@ietf.org; Fri, 28 Jul 2006 13:51:07 -0400 X-IronPort-AV: i="4.07,193,1151899200"; d="scan'208"; a="35907326:sNHT52751424" Content-class: urn:content-classes:message Subject: RE: [Simple] Re: Comments on draft-ietf-simple-imdn-00.txt Date: Fri, 28 Jul 2006 13:51:02 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <330A23D8336C0346B5C1A5BB196666470356A65C@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-TNEF-Correlator: Thread-Topic: [Simple] Re: Comments on draft-ietf-simple-imdn-00.txt Thread-Index: AcayZwTvqpFKF9lTSC2umlj036+WZAABxHYA From: "Burger, Eric" To: "Eric McMurry" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4c463dcf97e2b913ab242796279c24d2 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org The hint is actually old, from draft-burger-simple-imdn: To request the generation of an IMDN, the Requesting UAC MUST include the Disposition-Notification and Message-ID headers. The Requesting UAC MAY also include a List-Action header to provide down-stream B2BUA's with the user's desire for IMDN reporting by the final target of B2BUA expansion or the B2BUA itself. B2BUA's SHOULD include the Original-From header, with the value of the inbound From header, unless privacy considerations require the B2BUA to not transmit the Original-From header. Likewise, B2BUA's SHOULD copy the value of the inbound Message-ID into the outbound Original-Message-Id header. -----Original Message----- From: Eric McMurry [mailto:emcmurry@estacado.net]=20 Sent: Friday, July 28, 2006 12:56 PM To: Burger, Eric Cc: Hisham Khartabil; Ben Campbell; simple@ietf.org Subject: Re: [Simple] Re: Comments on draft-ietf-simple-imdn-00.txt also inline... On Jul 28, 2006, at 10:50 AM, Burger, Eric wrote: > Mine, too (inline): > >> -----Original Message----- >> From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] >> Sent: Friday, July 28, 2006 11:26 AM >> To: Ben Campbell >> Cc: Eric McMurry; simple@ietf.org; Burger, Eric >> Subject: Re: [Simple] Re: Comments on draft-ietf-simple-imdn-00.txt >> >> Hi Ben, >> >> Comments inline... >> >> On Jul 28, 2006, at 5:04 PM, Ben Campbell wrote: >> >>> >>> On Jul 28, 2006, at 8:33 AM, Hisham Khartabil wrote: >>> >>>> Hi, >>>> >>>> Thanks for the comments. Responses inline... >>>> >>>> On Jul 27, 2006, at 9:00 PM, Eric McMurry wrote: >>>> >>>>> I understand that a rewrite is being considered, so I'll hold off > on >>>>> editorial comments. >>>>> >>>>> >>>>> 1) I'm struggling a bit with the application of this to MSRP. DNs > >>>>> in general seem to make more sense for non-realtime applications >>>>> (like page-mode messaging). For realtime, session-mode, >>>>> applications, the session protocol ensures that messages are >>>>> delivered. Also, sessions tend to be interactive which I think >>>>> greatly lessens the value of read notifications. Perhaps someone >>>>> has a use case for this to make the value more clear? >>>> >>>> Having a message session with a machine the requires delivery of > IMs >>>> in proper sequence and therefore need a delivery notification > before >>>> sending the next one. >>>> >>> >>> I'm not sure I buy this example. I can use the built in notification > >>> mechanism in MSRP to accomplish the same thing. >>> >>> The only use cases I can think of involve messages that cross > session >>> "boundaries", i.e. when some sort of MSRP B2BUA is involved. >>> >>> I've mentioned before that I think it makes more sense to leave such > >>> specification on how we use IMDN fpr MSRP until we define such >>> applications. Or at least spec out some agreed requirements for IMDN > >>> in MSRP--right now we are speculating on how it might be used. I am >>> not at all confident our speculation will turn out to be true. >> >> I used a bad example here. The draft actually says that for MSRP, >> delivery notification are not relevant since MRSP has that built in. >> The draft stresses that read notifications and any other future >> extensions might be useful. >> >> I don't agree that we need an application to define this. Companies >> might have use cases for this that they don't want to make public yet >> that uses on IMDNs for MSRP. Why make them wait 2 years to get an RFC >> where the text in the current draft is not damaging? > > I can go either way on this one. I'll buy the hidden use case and I'll also buy that there could =20 easily be one I haven't thought of. What I was hoping to get from my =20 question though was someone saying that they needed this (and better =20 still, why). > > >>>>> 2) The available disposition states ("delivered", "read") are > suited >>>>> for responses from the target UA, but not so much for >>>>> intermediaries. I think reintroducing something like the >>>>> "processed" state, but more specific, may be in order. Take, for >>>>> example, the store-and-forward case. >>>> >>>> We have deliberately limited it to delivered and read. Future >>>> extensions can define something like "processed" >>> >>> On reflection, when using SIP, I think receiving a 202 to a MESSAGE > is >>> means the same thing that Eric is asking for. It may be worth >>> considering whether we want to have that concept in IMDN. (I lean >>> towards "no"-We have a slippery slope here on adding too much >>> transport functionality to IMDN.) >>> >>>> >>>>> >>>>> An intermediary strictly following the current spec would return a > >>>>> negative delivery notification when it was not able to reach a >>>>> target. If the intermediary provides store-and-forward service >>>>> though, this results in a less than ideal experience for the user >>>>> requesting the IMDN. They would almost immediately receive an >>>>> indication that their message was not delivered. >>>> >>>> No. They wouldn't receive anything. The message is still to be >>>> delivered. >>> >>> When I first read Hisham's response, I thought he was saying nothing > >>> would be sent unless delivery succeeded. But I think he means that > the >>> intermediary should not return a failure IMDN until it had exhausted > >>> all opportunities to deliver the message. If so, then I think I > agree. >> >> Yes thats what I meant. and I agree that that interpretation makes more sense. I was just =20 being strict on how I read "final response" >> >>>>> Some time later (assuming that the message was subsequently >>>>> successfully delivered), they would receive another IMDN for the >>>>> same message indicating success (this one is a bit fuzzier I > think). >>>> >>>> This would be the first one they get. >>>> >>>>> >>>>> The net is that it is confusing to the user. I would suggest > adding >>>>> a "stored" state to handle this. It would be sent by an >>>>> intermediary providing store-and-forward service and would provide > >>>>> the sender with a much more accurate view of what the intermediate > >>>>> disposition of their message was. > > I really, really would rather have the "processed" state. Let the > protocol say what it is really doing, not what it thinks might be > possibly going on. The B2BUA receives a message: it is being =20 > processed, > so tell the UAC so. A later delivery message should work just fine. > The B2BUA doesn't get the message, or it can't process the message: =20 > send > a failure report. > > I don't like "stored", because that is only relevant to > store-and-forward. IMDN should work for any B2BUA, not just a > store-and-forward B2BUA. > > Note that having the hint to the B2BUA that the UAC is looking for the > fate of the B2BUA's handling of the message, rather than the endpoints > handling of the message, removes the ambiguity of who should generate > the IMDN and what the IMDN means. I'm also strongly in favor of allowing the protocol to have reporting =20 of intermediate states. This allows for more descriptive status to =20 be presented to the user. I still like "stored", but not as the only option. I was suggesting =20 that a one example of a category of states of the "processed" ilk. =20 However, I'm okay with using "processed" for this since we have the =20 Note field for the intermediary to provide more descriptive =20 information in. The drawback to this is that we lack a standard way =20 of conveying the more descriptive information. The use of the hint to the intermediary is new to me. Are you =20 suggesting that in this case, only the B2BUA would generate an IMDN? =20 I was thinking more along the lines that the IMDN generated by the =20 B2BUA would be an intermediate response, and that the final endpoint =20 would also generate one. I think this would be true for both =20 "processed" and "stored" types of states. > >>>>> 3) "Future extensions" are mentioned in several places, but no >>>>> extension mechanism is specified. Perhaps a mechanism for vendor >>>>> specific extensions should be specified to avoid collisions with >>>>> future versions of this spec. >>>> >>>> Added text in section 9.1 suggesting future extensions must be in > an >>>> RFC. >>>> >>>>> >>>>> >>>>> 4) The example of an IM body with an IMDN request (section 4.1) > has >>>>> not caught up with the addition of a CPIM namespace to the >>>>> specification. >>>> >>>> I actually forgot this was there. I removed the definition of the > new >>>> namespace and referred to the default namespace instead. >>> >>> We are taking the namespace out? Why? Or did I misread your intent? >>> >>> Namespaces are the defined mechanism for extending CPIM. >> >> I believe using the default namespace is allowed. You can define a =20 >> new > >> namespace for new headers if you are worried about header name > clashes. >> Or am I wrong? > > Namespaces are also used for capabilities negotiation, so it really > should be included. > >>>>> 5) In section 4.4 "Keeping State", second paragraph, perhaps the >>>>> phase "user choice" should read "local policy" (okay, that was a > bit >>>>> editorial :-) >>>> >>>> I actually prefer user choice since it clearly states that the user > >>>> makes that choice and not the implementer. >>>> >>> >>> If that is the intent, we need more normative language to say the >>> implementation MUST or SHOULD let the user decide. But in this case, > I >>> do think this is more an implementation choice than a user choice. I > >>> don't see an end-user being in a position to decide whether they > want >>> to keep state or not. This is more a matter of the type of device, >>> it's memory constraints, the intended user experience, etc. >>> >> This is the text in the draft "How long to keep items in the "Sent >> Items" box is a user choice." It is not about keeping state, it is >> about keeping items in the sent items box. >> >> This is not an implementer choice. I would smash the phone if it >> removed things from my "Sent Items" box without me doing it >> deliberately :) We are not discussing how to implement a "Sent Items" >> box anyhow in this draft. > > Which is also why it isn't really user choice... I can't imagine a client not giving this choice to the user (except =20 perhaps in the case of limited client resources). That said, I think =20 this should be left up to the implementor since it is a UI feature. > >>>>> 6) Description of use of the Original-To header should spell out >>>>> that this header should only be added if it does not already > exist. >>>>> It is possible that there will be multiple intermediaries in the >>>>> path, and only the first one should do this. >>>> >>>> Yes. This is done already in my local copy of the next version. >>>> >>>>> >>>>> >>>>> 7) I agreed with Miguel Garcia's comment on Really-To and >>>>> Really-From in another email, but allow me to reiterate. This is > a >>>>> Via-like mechanism and would be less confusing (at least to me) if > >>>>> it were named as such. >>>> >>>> I'll make that change. >>>> >>> >>> By the way, we got feedback on MSRP to try to avoid having different > >>> header names start with the same several letters. It makes parsing >>> harder. > > A LONG, SLOW PAINFUL DEATH TO IMPLEMENTORS THAT DO NOT BUILD A REAL > PARSER THAT FOLLOWS THE FULL SPECIFICATION. We first tear out their > fingers so they can no longer inflict "almost compatible" > implementations that we later have to work around. > > GIVE ME A BREAK. Too bad if my 12 character string starts with the =20 > same > 6 characters! If they are not reading the entire string, they have > blown it already. I wasn't going to be quite so violent in my response, but I agree :-) > > >>>>> 8) Aggregation. Let's start with a scenario. Say there's a > request >>>>> to a list exploder with a local policy on the requested list to > not >>>>> reveal the list members. Let's also say that the exploder is > going >>>>> to aggregate IMDNs either by policy or request. >>>>> >>>>> So the request is exploded, and time passes. The exploder > collects >>>>> some IMDNs and decides it's time to send an aggregate response. >>>>> Since the local policy is to not reveal list members, it strips > this >>>>> info from all of the IMDNs. Then it prepares and sends the >>>>> aggregated IMDN. >>>> >>>> A list server can send *ONE* imdn indicating "delivered" after is > has >>>> received some or all of the IMDNs. This is only an option of > course. >>>> >>>>> >>>>> The UA that originated the request to the list exploder then >>>>> receives a list of IMDNs with no user information in them. Now, > how >>>>> will this be presented to the user? >>>> >>>> "x users received the message" is one example. This is an >>>> implementation choice >>>> >>>>> The client only knows that some number of users on the list >>>>> received the message, some number didn't, and an unknown number > did >>>>> or didn't receive it. >>>> >>>> That acceptable, imo. >>> >>> Acceptable, maybe. Can we describe a use case for which it is > _useful_. >> >> What are you suggesting? Are you suggesting that no aggregation is > done >> for private lists? or should the list server reject the IM? I can't >> think of a use case now, but I don't think we should add =20 >> complications > >> by forbidding something. This is implementation choice. > > Agreed (with Hisham) So, a list server can then potentially: ((ignore the IMDN request) or ((optionally generate a "processed" =20 type IMDN when the list is exploded) and (optionally generate one =20 "delivered" IMDN when it receives some number of IMDNs from the =20 recipients) or (optionally generate some number of aggregated IMDNs =20 with the recipient info stripped)) and the client would then have to savvy any combination of these if =20 it wanted to send to a list. Maybe this is reasonable, but it seems =20 as if we've come up with several ways to skin a cat, when it may be =20 that we really had a porcupine (and who wants to skin a porcupine?). =20 I'll have to give this some more thought. > >>>>> The number of aggregated IMDNs could be large as well and may >>>>> require multiple messages (only 1300 bytes available for MESSAGE) > to >>>>> send. I would suggest that aggregated IMDNs don't make sense if > the >>>>> policy of the aggregator is to strip the recipient info. >>>> >>>> I disagree. I think it does make sense. Sometimes I am interested >>>> that enough people received the message, not who. >>>> >>>>> The most useful piece of delivery information that can probably > be >>>>> obtained in this scenario is that the message was delivered >>>>> successfully or not to the list server. This could be > accomplished >>>>> by sending a "delivered" state IMDN from the list server, or if >>>>> something more explicit is desired, another intermediate state, > such >>>>> as "exploded" (okay, that was just for fun, but it conveys the >>>>> status) could be defined. > > This would be handled by the UAC giving the B2BUA the hint that the =20 > IMDN > is for the B2BUA to generate (in its role as a UAS) and not for > down-stream nodes to generate. > > >>>>> 9) I'm sure this would have been covered in the next version, but >>>>> just in case: the text for the IANA registration of the >>>>> Content-Disposition header (13.5) is missing. >>>> >>>> Yes. Added. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 28 14:53:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6XSA-00005J-8b; Fri, 28 Jul 2006 14:52:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6XS9-0008Ss-3Z for simple@ietf.org; Fri, 28 Jul 2006 14:52:53 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6XS6-0008HJ-5E for simple@ietf.org; Fri, 28 Jul 2006 14:52:53 -0400 Received: from [172.17.2.233] ([172.17.2.233]) (authenticated bits=0) by vicuna.estacado.net (8.13.6/8.13.4) with ESMTP id k6SIpSMK094161 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 28 Jul 2006 13:51:29 -0500 (CDT) (envelope-from emcmurry@estacado.net) In-Reply-To: <330A23D8336C0346B5C1A5BB196666470356A65C@ATLANTIS.Brooktrout.com> References: <330A23D8336C0346B5C1A5BB196666470356A65C@ATLANTIS.Brooktrout.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6E1D9412-C25F-44EE-9A9B-BAEBA052CA2A@estacado.net> Content-Transfer-Encoding: 7bit From: Eric McMurry Subject: Re: [Simple] Re: Comments on draft-ietf-simple-imdn-00.txt Date: Fri, 28 Jul 2006 13:51:21 -0500 To: "Burger, Eric" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 6e8a3b85ef670172081194f0b0f68e6f Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org thanks for the reference. I still think it is useful though to have the possibility of IMDNs generated at both an intermediary and the final recipient. For store- and-forward, I can see the user wanting to know that the message was stored, and later, that it was delivered. For a list, I can see the user wanting to know that the list server processed the message, and later, that recipients received/read it. On Jul 28, 2006, at 12:51 PM, Burger, Eric wrote: > The hint is actually old, from draft-burger-simple-imdn: > > To request the generation of an IMDN, the Requesting UAC MUST > include > the Disposition-Notification and Message-ID headers. The > Requesting > UAC MAY also include a List-Action header to provide down-stream > B2BUA's with the user's desire for IMDN reporting by the final > target > of B2BUA expansion or the B2BUA itself. B2BUA's SHOULD include the > Original-From header, with the value of the inbound From header, > unless privacy considerations require the B2BUA to not transmit the > Original-From header. Likewise, B2BUA's SHOULD copy the value > of the > inbound Message-ID into the outbound Original-Message-Id header. > > > > -----Original Message----- > From: Eric McMurry [mailto:emcmurry@estacado.net] > Sent: Friday, July 28, 2006 12:56 PM > To: Burger, Eric > Cc: Hisham Khartabil; Ben Campbell; simple@ietf.org > Subject: Re: [Simple] Re: Comments on draft-ietf-simple-imdn-00.txt > > also inline... > > On Jul 28, 2006, at 10:50 AM, Burger, Eric wrote: > >> Mine, too (inline): >> >>> -----Original Message----- >>> From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] >>> Sent: Friday, July 28, 2006 11:26 AM >>> To: Ben Campbell >>> Cc: Eric McMurry; simple@ietf.org; Burger, Eric >>> Subject: Re: [Simple] Re: Comments on draft-ietf-simple-imdn-00.txt >>> >>> Hi Ben, >>> >>> Comments inline... >>> >>> On Jul 28, 2006, at 5:04 PM, Ben Campbell wrote: >>> >>>> >>>> On Jul 28, 2006, at 8:33 AM, Hisham Khartabil wrote: >>>> >>>>> Hi, >>>>> >>>>> Thanks for the comments. Responses inline... >>>>> >>>>> On Jul 27, 2006, at 9:00 PM, Eric McMurry wrote: >>>>> >>>>>> I understand that a rewrite is being considered, so I'll hold off >> on >>>>>> editorial comments. >>>>>> >>>>>> >>>>>> 1) I'm struggling a bit with the application of this to MSRP. >>>>>> DNs >> >>>>>> in general seem to make more sense for non-realtime applications >>>>>> (like page-mode messaging). For realtime, session-mode, >>>>>> applications, the session protocol ensures that messages are >>>>>> delivered. Also, sessions tend to be interactive which I think >>>>>> greatly lessens the value of read notifications. Perhaps someone >>>>>> has a use case for this to make the value more clear? >>>>> >>>>> Having a message session with a machine the requires delivery of >> IMs >>>>> in proper sequence and therefore need a delivery notification >> before >>>>> sending the next one. >>>>> >>>> >>>> I'm not sure I buy this example. I can use the built in >>>> notification >> >>>> mechanism in MSRP to accomplish the same thing. >>>> >>>> The only use cases I can think of involve messages that cross >> session >>>> "boundaries", i.e. when some sort of MSRP B2BUA is involved. >>>> >>>> I've mentioned before that I think it makes more sense to leave >>>> such >> >>>> specification on how we use IMDN fpr MSRP until we define such >>>> applications. Or at least spec out some agreed requirements for >>>> IMDN >> >>>> in MSRP--right now we are speculating on how it might be used. I am >>>> not at all confident our speculation will turn out to be true. >>> >>> I used a bad example here. The draft actually says that for MSRP, >>> delivery notification are not relevant since MRSP has that built in. >>> The draft stresses that read notifications and any other future >>> extensions might be useful. >>> >>> I don't agree that we need an application to define this. Companies >>> might have use cases for this that they don't want to make public >>> yet >>> that uses on IMDNs for MSRP. Why make them wait 2 years to get an >>> RFC >>> where the text in the current draft is not damaging? >> >> I can go either way on this one. > > I'll buy the hidden use case and I'll also buy that there could > easily be one I haven't thought of. What I was hoping to get from my > question though was someone saying that they needed this (and better > still, why). > >> >> >>>>>> 2) The available disposition states ("delivered", "read") are >> suited >>>>>> for responses from the target UA, but not so much for >>>>>> intermediaries. I think reintroducing something like the >>>>>> "processed" state, but more specific, may be in order. Take, for >>>>>> example, the store-and-forward case. >>>>> >>>>> We have deliberately limited it to delivered and read. Future >>>>> extensions can define something like "processed" >>>> >>>> On reflection, when using SIP, I think receiving a 202 to a MESSAGE >> is >>>> means the same thing that Eric is asking for. It may be worth >>>> considering whether we want to have that concept in IMDN. (I lean >>>> towards "no"-We have a slippery slope here on adding too much >>>> transport functionality to IMDN.) >>>> >>>>> >>>>>> >>>>>> An intermediary strictly following the current spec would >>>>>> return a >> >>>>>> negative delivery notification when it was not able to reach a >>>>>> target. If the intermediary provides store-and-forward service >>>>>> though, this results in a less than ideal experience for the user >>>>>> requesting the IMDN. They would almost immediately receive an >>>>>> indication that their message was not delivered. >>>>> >>>>> No. They wouldn't receive anything. The message is still to be >>>>> delivered. >>>> >>>> When I first read Hisham's response, I thought he was saying >>>> nothing >> >>>> would be sent unless delivery succeeded. But I think he means that >> the >>>> intermediary should not return a failure IMDN until it had >>>> exhausted >> >>>> all opportunities to deliver the message. If so, then I think I >> agree. >>> >>> Yes thats what I meant. > > and I agree that that interpretation makes more sense. I was just > being strict on how I read "final response" > >>> >>>>>> Some time later (assuming that the message was subsequently >>>>>> successfully delivered), they would receive another IMDN for the >>>>>> same message indicating success (this one is a bit fuzzier I >> think). >>>>> >>>>> This would be the first one they get. >>>>> >>>>>> >>>>>> The net is that it is confusing to the user. I would suggest >> adding >>>>>> a "stored" state to handle this. It would be sent by an >>>>>> intermediary providing store-and-forward service and would >>>>>> provide >> >>>>>> the sender with a much more accurate view of what the >>>>>> intermediate >> >>>>>> disposition of their message was. >> >> I really, really would rather have the "processed" state. Let the >> protocol say what it is really doing, not what it thinks might be >> possibly going on. The B2BUA receives a message: it is being >> processed, >> so tell the UAC so. A later delivery message should work just fine. >> The B2BUA doesn't get the message, or it can't process the message: >> send >> a failure report. >> >> I don't like "stored", because that is only relevant to >> store-and-forward. IMDN should work for any B2BUA, not just a >> store-and-forward B2BUA. >> >> Note that having the hint to the B2BUA that the UAC is looking for >> the >> fate of the B2BUA's handling of the message, rather than the >> endpoints >> handling of the message, removes the ambiguity of who should generate >> the IMDN and what the IMDN means. > > > I'm also strongly in favor of allowing the protocol to have reporting > of intermediate states. This allows for more descriptive status to > be presented to the user. > > I still like "stored", but not as the only option. I was suggesting > that a one example of a category of states of the "processed" ilk. > However, I'm okay with using "processed" for this since we have the > Note field for the intermediary to provide more descriptive > information in. The drawback to this is that we lack a standard way > of conveying the more descriptive information. > > The use of the hint to the intermediary is new to me. Are you > suggesting that in this case, only the B2BUA would generate an IMDN? > I was thinking more along the lines that the IMDN generated by the > B2BUA would be an intermediate response, and that the final endpoint > would also generate one. I think this would be true for both > "processed" and "stored" types of states. > > >> >>>>>> 3) "Future extensions" are mentioned in several places, but no >>>>>> extension mechanism is specified. Perhaps a mechanism for vendor >>>>>> specific extensions should be specified to avoid collisions with >>>>>> future versions of this spec. >>>>> >>>>> Added text in section 9.1 suggesting future extensions must be in >> an >>>>> RFC. >>>>> >>>>>> >>>>>> >>>>>> 4) The example of an IM body with an IMDN request (section 4.1) >> has >>>>>> not caught up with the addition of a CPIM namespace to the >>>>>> specification. >>>>> >>>>> I actually forgot this was there. I removed the definition of the >> new >>>>> namespace and referred to the default namespace instead. >>>> >>>> We are taking the namespace out? Why? Or did I misread your intent? >>>> >>>> Namespaces are the defined mechanism for extending CPIM. >>> >>> I believe using the default namespace is allowed. You can define a >>> new >> >>> namespace for new headers if you are worried about header name >> clashes. >>> Or am I wrong? >> >> Namespaces are also used for capabilities negotiation, so it really >> should be included. >> >>>>>> 5) In section 4.4 "Keeping State", second paragraph, perhaps the >>>>>> phase "user choice" should read "local policy" (okay, that was a >> bit >>>>>> editorial :-) >>>>> >>>>> I actually prefer user choice since it clearly states that the >>>>> user >> >>>>> makes that choice and not the implementer. >>>>> >>>> >>>> If that is the intent, we need more normative language to say the >>>> implementation MUST or SHOULD let the user decide. But in this >>>> case, >> I >>>> do think this is more an implementation choice than a user >>>> choice. I >> >>>> don't see an end-user being in a position to decide whether they >> want >>>> to keep state or not. This is more a matter of the type of device, >>>> it's memory constraints, the intended user experience, etc. >>>> >>> This is the text in the draft "How long to keep items in the "Sent >>> Items" box is a user choice." It is not about keeping state, it is >>> about keeping items in the sent items box. >>> >>> This is not an implementer choice. I would smash the phone if it >>> removed things from my "Sent Items" box without me doing it >>> deliberately :) We are not discussing how to implement a "Sent >>> Items" >>> box anyhow in this draft. >> >> Which is also why it isn't really user choice... > > I can't imagine a client not giving this choice to the user (except > perhaps in the case of limited client resources). That said, I think > this should be left up to the implementor since it is a UI feature. > >> >>>>>> 6) Description of use of the Original-To header should spell out >>>>>> that this header should only be added if it does not already >> exist. >>>>>> It is possible that there will be multiple intermediaries in the >>>>>> path, and only the first one should do this. >>>>> >>>>> Yes. This is done already in my local copy of the next version. >>>>> >>>>>> >>>>>> >>>>>> 7) I agreed with Miguel Garcia's comment on Really-To and >>>>>> Really-From in another email, but allow me to reiterate. This is >> a >>>>>> Via-like mechanism and would be less confusing (at least to >>>>>> me) if >> >>>>>> it were named as such. >>>>> >>>>> I'll make that change. >>>>> >>>> >>>> By the way, we got feedback on MSRP to try to avoid having >>>> different >> >>>> header names start with the same several letters. It makes parsing >>>> harder. >> >> A LONG, SLOW PAINFUL DEATH TO IMPLEMENTORS THAT DO NOT BUILD A REAL >> PARSER THAT FOLLOWS THE FULL SPECIFICATION. We first tear out their >> fingers so they can no longer inflict "almost compatible" >> implementations that we later have to work around. >> >> GIVE ME A BREAK. Too bad if my 12 character string starts with the >> same >> 6 characters! If they are not reading the entire string, they have >> blown it already. > > I wasn't going to be quite so violent in my response, but I agree :-) > >> >> >>>>>> 8) Aggregation. Let's start with a scenario. Say there's a >> request >>>>>> to a list exploder with a local policy on the requested list to >> not >>>>>> reveal the list members. Let's also say that the exploder is >> going >>>>>> to aggregate IMDNs either by policy or request. >>>>>> >>>>>> So the request is exploded, and time passes. The exploder >> collects >>>>>> some IMDNs and decides it's time to send an aggregate response. >>>>>> Since the local policy is to not reveal list members, it strips >> this >>>>>> info from all of the IMDNs. Then it prepares and sends the >>>>>> aggregated IMDN. >>>>> >>>>> A list server can send *ONE* imdn indicating "delivered" after is >> has >>>>> received some or all of the IMDNs. This is only an option of >> course. >>>>> >>>>>> >>>>>> The UA that originated the request to the list exploder then >>>>>> receives a list of IMDNs with no user information in them. Now, >> how >>>>>> will this be presented to the user? >>>>> >>>>> "x users received the message" is one example. This is an >>>>> implementation choice >>>>> >>>>>> The client only knows that some number of users on the list >>>>>> received the message, some number didn't, and an unknown number >> did >>>>>> or didn't receive it. >>>>> >>>>> That acceptable, imo. >>>> >>>> Acceptable, maybe. Can we describe a use case for which it is >> _useful_. >>> >>> What are you suggesting? Are you suggesting that no aggregation is >> done >>> for private lists? or should the list server reject the IM? I can't >>> think of a use case now, but I don't think we should add >>> complications >> >>> by forbidding something. This is implementation choice. >> >> Agreed (with Hisham) > > So, a list server can then potentially: > > ((ignore the IMDN request) or ((optionally generate a "processed" > type IMDN when the list is exploded) and (optionally generate one > "delivered" IMDN when it receives some number of IMDNs from the > recipients) or (optionally generate some number of aggregated IMDNs > with the recipient info stripped)) > > and the client would then have to savvy any combination of these if > it wanted to send to a list. Maybe this is reasonable, but it seems > as if we've come up with several ways to skin a cat, when it may be > that we really had a porcupine (and who wants to skin a porcupine?). > I'll have to give this some more thought. > >> >>>>>> The number of aggregated IMDNs could be large as well and may >>>>>> require multiple messages (only 1300 bytes available for MESSAGE) >> to >>>>>> send. I would suggest that aggregated IMDNs don't make sense if >> the >>>>>> policy of the aggregator is to strip the recipient info. >>>>> >>>>> I disagree. I think it does make sense. Sometimes I am interested >>>>> that enough people received the message, not who. >>>>> >>>>>> The most useful piece of delivery information that can probably >> be >>>>>> obtained in this scenario is that the message was delivered >>>>>> successfully or not to the list server. This could be >> accomplished >>>>>> by sending a "delivered" state IMDN from the list server, or if >>>>>> something more explicit is desired, another intermediate state, >> such >>>>>> as "exploded" (okay, that was just for fun, but it conveys the >>>>>> status) could be defined. >> >> This would be handled by the UAC giving the B2BUA the hint that the >> IMDN >> is for the B2BUA to generate (in its role as a UAS) and not for >> down-stream nodes to generate. >> >> >>>>>> 9) I'm sure this would have been covered in the next version, but >>>>>> just in case: the text for the IANA registration of the >>>>>> Content-Disposition header (13.5) is missing. >>>>> >>>>> Yes. Added. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 28 14:54:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6XTo-0005da-5W; Fri, 28 Jul 2006 14:54:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6XTm-0005OO-F7 for simple@ietf.org; Fri, 28 Jul 2006 14:54:34 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6XTk-0008Md-N0 for simple@ietf.org; Fri, 28 Jul 2006 14:54:34 -0400 X-IronPort-AV: i="4.07,193,1151899200"; d="scan'208"; a="35908969:sNHT53641512" Content-class: urn:content-classes:message Subject: RE: [Simple] Re: Comments on draft-ietf-simple-imdn-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 28 Jul 2006 14:54:28 -0400 Message-ID: <330A23D8336C0346B5C1A5BB196666470356A6B7@ATLANTIS.Brooktrout.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Re: Comments on draft-ietf-simple-imdn-00.txt Thread-Index: AcaydzHDSCgT1CihRwacBDH/C4lTWQAAC4kw From: "Burger, Eric" To: "Eric McMurry" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2f0065339d489fe5a2873ea9ad776d1a Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org How would the sender have a clue that they are sending their message to a store-and-forward server? I'm sending you an IM because my presence info is out of date. Your friendly in-the-network B2BUA picks up the message, accepts it (as a UAS), and now holds it for you. I certainly didn't think I was talking to a B2BUA when I initiated the session. -----Original Message----- From: Eric McMurry [mailto:emcmurry@estacado.net]=20 Sent: Friday, July 28, 2006 2:51 PM To: Burger, Eric Cc: simple@ietf.org Subject: Re: [Simple] Re: Comments on draft-ietf-simple-imdn-00.txt thanks for the reference. I still think it is useful though to have the possibility of IMDNs =20 generated at both an intermediary and the final recipient. For store-=20 and-forward, I can see the user wanting to know that the message was =20 stored, and later, that it was delivered. For a list, I can see the =20 user wanting to know that the list server processed the message, and =20 later, that recipients received/read it. On Jul 28, 2006, at 12:51 PM, Burger, Eric wrote: > The hint is actually old, from draft-burger-simple-imdn: > > To request the generation of an IMDN, the Requesting UAC MUST =20 > include > the Disposition-Notification and Message-ID headers. The =20 > Requesting > UAC MAY also include a List-Action header to provide down-stream > B2BUA's with the user's desire for IMDN reporting by the final =20 > target > of B2BUA expansion or the B2BUA itself. B2BUA's SHOULD include the > Original-From header, with the value of the inbound From header, > unless privacy considerations require the B2BUA to not transmit the > Original-From header. Likewise, B2BUA's SHOULD copy the value =20 > of the > inbound Message-ID into the outbound Original-Message-Id header. > > > > -----Original Message----- > From: Eric McMurry [mailto:emcmurry@estacado.net] > Sent: Friday, July 28, 2006 12:56 PM > To: Burger, Eric > Cc: Hisham Khartabil; Ben Campbell; simple@ietf.org > Subject: Re: [Simple] Re: Comments on draft-ietf-simple-imdn-00.txt > > also inline... > > On Jul 28, 2006, at 10:50 AM, Burger, Eric wrote: > >> Mine, too (inline): >> >>> -----Original Message----- >>> From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] >>> Sent: Friday, July 28, 2006 11:26 AM >>> To: Ben Campbell >>> Cc: Eric McMurry; simple@ietf.org; Burger, Eric >>> Subject: Re: [Simple] Re: Comments on draft-ietf-simple-imdn-00.txt >>> >>> Hi Ben, >>> >>> Comments inline... >>> >>> On Jul 28, 2006, at 5:04 PM, Ben Campbell wrote: >>> >>>> >>>> On Jul 28, 2006, at 8:33 AM, Hisham Khartabil wrote: >>>> >>>>> Hi, >>>>> >>>>> Thanks for the comments. Responses inline... >>>>> >>>>> On Jul 27, 2006, at 9:00 PM, Eric McMurry wrote: >>>>> >>>>>> I understand that a rewrite is being considered, so I'll hold off >> on >>>>>> editorial comments. >>>>>> >>>>>> >>>>>> 1) I'm struggling a bit with the application of this to MSRP. =20 >>>>>> DNs >> >>>>>> in general seem to make more sense for non-realtime applications >>>>>> (like page-mode messaging). For realtime, session-mode, >>>>>> applications, the session protocol ensures that messages are >>>>>> delivered. Also, sessions tend to be interactive which I think >>>>>> greatly lessens the value of read notifications. Perhaps someone >>>>>> has a use case for this to make the value more clear? >>>>> >>>>> Having a message session with a machine the requires delivery of >> IMs >>>>> in proper sequence and therefore need a delivery notification >> before >>>>> sending the next one. >>>>> >>>> >>>> I'm not sure I buy this example. I can use the built in =20 >>>> notification >> >>>> mechanism in MSRP to accomplish the same thing. >>>> >>>> The only use cases I can think of involve messages that cross >> session >>>> "boundaries", i.e. when some sort of MSRP B2BUA is involved. >>>> >>>> I've mentioned before that I think it makes more sense to leave =20 >>>> such >> >>>> specification on how we use IMDN fpr MSRP until we define such >>>> applications. Or at least spec out some agreed requirements for =20 >>>> IMDN >> >>>> in MSRP--right now we are speculating on how it might be used. I am >>>> not at all confident our speculation will turn out to be true. >>> >>> I used a bad example here. The draft actually says that for MSRP, >>> delivery notification are not relevant since MRSP has that built in. >>> The draft stresses that read notifications and any other future >>> extensions might be useful. >>> >>> I don't agree that we need an application to define this. Companies >>> might have use cases for this that they don't want to make public =20 >>> yet >>> that uses on IMDNs for MSRP. Why make them wait 2 years to get an =20 >>> RFC >>> where the text in the current draft is not damaging? >> >> I can go either way on this one. > > I'll buy the hidden use case and I'll also buy that there could > easily be one I haven't thought of. What I was hoping to get from my > question though was someone saying that they needed this (and better > still, why). > >> >> >>>>>> 2) The available disposition states ("delivered", "read") are >> suited >>>>>> for responses from the target UA, but not so much for >>>>>> intermediaries. I think reintroducing something like the >>>>>> "processed" state, but more specific, may be in order. Take, for >>>>>> example, the store-and-forward case. >>>>> >>>>> We have deliberately limited it to delivered and read. Future >>>>> extensions can define something like "processed" >>>> >>>> On reflection, when using SIP, I think receiving a 202 to a MESSAGE >> is >>>> means the same thing that Eric is asking for. It may be worth >>>> considering whether we want to have that concept in IMDN. (I lean >>>> towards "no"-We have a slippery slope here on adding too much >>>> transport functionality to IMDN.) >>>> >>>>> >>>>>> >>>>>> An intermediary strictly following the current spec would =20 >>>>>> return a >> >>>>>> negative delivery notification when it was not able to reach a >>>>>> target. If the intermediary provides store-and-forward service >>>>>> though, this results in a less than ideal experience for the user >>>>>> requesting the IMDN. They would almost immediately receive an >>>>>> indication that their message was not delivered. >>>>> >>>>> No. They wouldn't receive anything. The message is still to be >>>>> delivered. >>>> >>>> When I first read Hisham's response, I thought he was saying =20 >>>> nothing >> >>>> would be sent unless delivery succeeded. But I think he means that >> the >>>> intermediary should not return a failure IMDN until it had =20 >>>> exhausted >> >>>> all opportunities to deliver the message. If so, then I think I >> agree. >>> >>> Yes thats what I meant. > > and I agree that that interpretation makes more sense. I was just > being strict on how I read "final response" > >>> >>>>>> Some time later (assuming that the message was subsequently >>>>>> successfully delivered), they would receive another IMDN for the >>>>>> same message indicating success (this one is a bit fuzzier I >> think). >>>>> >>>>> This would be the first one they get. >>>>> >>>>>> >>>>>> The net is that it is confusing to the user. I would suggest >> adding >>>>>> a "stored" state to handle this. It would be sent by an >>>>>> intermediary providing store-and-forward service and would =20 >>>>>> provide >> >>>>>> the sender with a much more accurate view of what the =20 >>>>>> intermediate >> >>>>>> disposition of their message was. >> >> I really, really would rather have the "processed" state. Let the >> protocol say what it is really doing, not what it thinks might be >> possibly going on. The B2BUA receives a message: it is being >> processed, >> so tell the UAC so. A later delivery message should work just fine. >> The B2BUA doesn't get the message, or it can't process the message: >> send >> a failure report. >> >> I don't like "stored", because that is only relevant to >> store-and-forward. IMDN should work for any B2BUA, not just a >> store-and-forward B2BUA. >> >> Note that having the hint to the B2BUA that the UAC is looking for =20 >> the >> fate of the B2BUA's handling of the message, rather than the =20 >> endpoints >> handling of the message, removes the ambiguity of who should generate >> the IMDN and what the IMDN means. > > > I'm also strongly in favor of allowing the protocol to have reporting > of intermediate states. This allows for more descriptive status to > be presented to the user. > > I still like "stored", but not as the only option. I was suggesting > that a one example of a category of states of the "processed" ilk. > However, I'm okay with using "processed" for this since we have the > Note field for the intermediary to provide more descriptive > information in. The drawback to this is that we lack a standard way > of conveying the more descriptive information. > > The use of the hint to the intermediary is new to me. Are you > suggesting that in this case, only the B2BUA would generate an IMDN? > I was thinking more along the lines that the IMDN generated by the > B2BUA would be an intermediate response, and that the final endpoint > would also generate one. I think this would be true for both > "processed" and "stored" types of states. > > >> >>>>>> 3) "Future extensions" are mentioned in several places, but no >>>>>> extension mechanism is specified. Perhaps a mechanism for vendor >>>>>> specific extensions should be specified to avoid collisions with >>>>>> future versions of this spec. >>>>> >>>>> Added text in section 9.1 suggesting future extensions must be in >> an >>>>> RFC. >>>>> >>>>>> >>>>>> >>>>>> 4) The example of an IM body with an IMDN request (section 4.1) >> has >>>>>> not caught up with the addition of a CPIM namespace to the >>>>>> specification. >>>>> >>>>> I actually forgot this was there. I removed the definition of the >> new >>>>> namespace and referred to the default namespace instead. >>>> >>>> We are taking the namespace out? Why? Or did I misread your intent? >>>> >>>> Namespaces are the defined mechanism for extending CPIM. >>> >>> I believe using the default namespace is allowed. You can define a >>> new >> >>> namespace for new headers if you are worried about header name >> clashes. >>> Or am I wrong? >> >> Namespaces are also used for capabilities negotiation, so it really >> should be included. >> >>>>>> 5) In section 4.4 "Keeping State", second paragraph, perhaps the >>>>>> phase "user choice" should read "local policy" (okay, that was a >> bit >>>>>> editorial :-) >>>>> >>>>> I actually prefer user choice since it clearly states that the =20 >>>>> user >> >>>>> makes that choice and not the implementer. >>>>> >>>> >>>> If that is the intent, we need more normative language to say the >>>> implementation MUST or SHOULD let the user decide. But in this =20 >>>> case, >> I >>>> do think this is more an implementation choice than a user =20 >>>> choice. I >> >>>> don't see an end-user being in a position to decide whether they >> want >>>> to keep state or not. This is more a matter of the type of device, >>>> it's memory constraints, the intended user experience, etc. >>>> >>> This is the text in the draft "How long to keep items in the "Sent >>> Items" box is a user choice." It is not about keeping state, it is >>> about keeping items in the sent items box. >>> >>> This is not an implementer choice. I would smash the phone if it >>> removed things from my "Sent Items" box without me doing it >>> deliberately :) We are not discussing how to implement a "Sent =20 >>> Items" >>> box anyhow in this draft. >> >> Which is also why it isn't really user choice... > > I can't imagine a client not giving this choice to the user (except > perhaps in the case of limited client resources). That said, I think > this should be left up to the implementor since it is a UI feature. > >> >>>>>> 6) Description of use of the Original-To header should spell out >>>>>> that this header should only be added if it does not already >> exist. >>>>>> It is possible that there will be multiple intermediaries in the >>>>>> path, and only the first one should do this. >>>>> >>>>> Yes. This is done already in my local copy of the next version. >>>>> >>>>>> >>>>>> >>>>>> 7) I agreed with Miguel Garcia's comment on Really-To and >>>>>> Really-From in another email, but allow me to reiterate. This is >> a >>>>>> Via-like mechanism and would be less confusing (at least to =20 >>>>>> me) if >> >>>>>> it were named as such. >>>>> >>>>> I'll make that change. >>>>> >>>> >>>> By the way, we got feedback on MSRP to try to avoid having =20 >>>> different >> >>>> header names start with the same several letters. It makes parsing >>>> harder. >> >> A LONG, SLOW PAINFUL DEATH TO IMPLEMENTORS THAT DO NOT BUILD A REAL >> PARSER THAT FOLLOWS THE FULL SPECIFICATION. We first tear out their >> fingers so they can no longer inflict "almost compatible" >> implementations that we later have to work around. >> >> GIVE ME A BREAK. Too bad if my 12 character string starts with the >> same >> 6 characters! If they are not reading the entire string, they have >> blown it already. > > I wasn't going to be quite so violent in my response, but I agree :-) > >> >> >>>>>> 8) Aggregation. Let's start with a scenario. Say there's a >> request >>>>>> to a list exploder with a local policy on the requested list to >> not >>>>>> reveal the list members. Let's also say that the exploder is >> going >>>>>> to aggregate IMDNs either by policy or request. >>>>>> >>>>>> So the request is exploded, and time passes. The exploder >> collects >>>>>> some IMDNs and decides it's time to send an aggregate response. >>>>>> Since the local policy is to not reveal list members, it strips >> this >>>>>> info from all of the IMDNs. Then it prepares and sends the >>>>>> aggregated IMDN. >>>>> >>>>> A list server can send *ONE* imdn indicating "delivered" after is >> has >>>>> received some or all of the IMDNs. This is only an option of >> course. >>>>> >>>>>> >>>>>> The UA that originated the request to the list exploder then >>>>>> receives a list of IMDNs with no user information in them. Now, >> how >>>>>> will this be presented to the user? >>>>> >>>>> "x users received the message" is one example. This is an >>>>> implementation choice >>>>> >>>>>> The client only knows that some number of users on the list >>>>>> received the message, some number didn't, and an unknown number >> did >>>>>> or didn't receive it. >>>>> >>>>> That acceptable, imo. >>>> >>>> Acceptable, maybe. Can we describe a use case for which it is >> _useful_. >>> >>> What are you suggesting? Are you suggesting that no aggregation is >> done >>> for private lists? or should the list server reject the IM? I can't >>> think of a use case now, but I don't think we should add >>> complications >> >>> by forbidding something. This is implementation choice. >> >> Agreed (with Hisham) > > So, a list server can then potentially: > > ((ignore the IMDN request) or ((optionally generate a "processed" > type IMDN when the list is exploded) and (optionally generate one > "delivered" IMDN when it receives some number of IMDNs from the > recipients) or (optionally generate some number of aggregated IMDNs > with the recipient info stripped)) > > and the client would then have to savvy any combination of these if > it wanted to send to a list. Maybe this is reasonable, but it seems > as if we've come up with several ways to skin a cat, when it may be > that we really had a porcupine (and who wants to skin a porcupine?). > I'll have to give this some more thought. > >> >>>>>> The number of aggregated IMDNs could be large as well and may >>>>>> require multiple messages (only 1300 bytes available for MESSAGE) >> to >>>>>> send. I would suggest that aggregated IMDNs don't make sense if >> the >>>>>> policy of the aggregator is to strip the recipient info. >>>>> >>>>> I disagree. I think it does make sense. Sometimes I am interested >>>>> that enough people received the message, not who. >>>>> >>>>>> The most useful piece of delivery information that can probably >> be >>>>>> obtained in this scenario is that the message was delivered >>>>>> successfully or not to the list server. This could be >> accomplished >>>>>> by sending a "delivered" state IMDN from the list server, or if >>>>>> something more explicit is desired, another intermediate state, >> such >>>>>> as "exploded" (okay, that was just for fun, but it conveys the >>>>>> status) could be defined. >> >> This would be handled by the UAC giving the B2BUA the hint that the >> IMDN >> is for the B2BUA to generate (in its role as a UAS) and not for >> down-stream nodes to generate. >> >> >>>>>> 9) I'm sure this would have been covered in the next version, but >>>>>> just in case: the text for the IANA registration of the >>>>>> Content-Disposition header (13.5) is missing. >>>>> >>>>> Yes. Added. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 28 15:00:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6XZK-0000hF-QM; Fri, 28 Jul 2006 15:00:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6XZI-0000hA-VW for simple@ietf.org; Fri, 28 Jul 2006 15:00:16 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6XZI-0000N4-0p for simple@ietf.org; Fri, 28 Jul 2006 15:00:16 -0400 Received: from [172.17.2.233] ([172.17.2.233]) (authenticated bits=0) by vicuna.estacado.net (8.13.6/8.13.4) with ESMTP id k6SIwv9Z094740 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 28 Jul 2006 13:58:57 -0500 (CDT) (envelope-from emcmurry@estacado.net) In-Reply-To: <330A23D8336C0346B5C1A5BB196666470356A6B7@ATLANTIS.Brooktrout.com> References: <330A23D8336C0346B5C1A5BB196666470356A6B7@ATLANTIS.Brooktrout.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <12FBE95E-4069-41D9-8543-BCDD874566D7@estacado.net> Content-Transfer-Encoding: 7bit From: Eric McMurry Subject: Re: [Simple] Re: Comments on draft-ietf-simple-imdn-00.txt Date: Fri, 28 Jul 2006 13:58:50 -0500 To: "Burger, Eric" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 4a96669441ad70ecf6aebb4b47b971cd Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org This sound like a great reason to have a separate IMDN state for processed/stored to me. In this case, the B2BUA acting as a store- and-forward server could send an IMDN indicating that the message was stored. Now the user knows explicitly what happened. Later, when the message was finally delivered, they could get another IMDN indicating that. On Jul 28, 2006, at 1:54 PM, Burger, Eric wrote: > How would the sender have a clue that they are sending their > message to > a store-and-forward server? > > I'm sending you an IM because my presence info is out of date. Your > friendly in-the-network B2BUA picks up the message, accepts it (as a > UAS), and now holds it for you. I certainly didn't think I was > talking > to a B2BUA when I initiated the session. > > -----Original Message----- > From: Eric McMurry [mailto:emcmurry@estacado.net] > Sent: Friday, July 28, 2006 2:51 PM > To: Burger, Eric > Cc: simple@ietf.org > Subject: Re: [Simple] Re: Comments on draft-ietf-simple-imdn-00.txt > > thanks for the reference. > > I still think it is useful though to have the possibility of IMDNs > generated at both an intermediary and the final recipient. For store- > and-forward, I can see the user wanting to know that the message was > stored, and later, that it was delivered. For a list, I can see the > user wanting to know that the list server processed the message, and > later, that recipients received/read it. > > > > On Jul 28, 2006, at 12:51 PM, Burger, Eric wrote: > >> The hint is actually old, from draft-burger-simple-imdn: >> >> To request the generation of an IMDN, the Requesting UAC MUST >> include >> the Disposition-Notification and Message-ID headers. The >> Requesting >> UAC MAY also include a List-Action header to provide down-stream >> B2BUA's with the user's desire for IMDN reporting by the final >> target >> of B2BUA expansion or the B2BUA itself. B2BUA's SHOULD include >> the >> Original-From header, with the value of the inbound From header, >> unless privacy considerations require the B2BUA to not transmit >> the >> Original-From header. Likewise, B2BUA's SHOULD copy the value >> of the >> inbound Message-ID into the outbound Original-Message-Id header. >> >> >> >> -----Original Message----- >> From: Eric McMurry [mailto:emcmurry@estacado.net] >> Sent: Friday, July 28, 2006 12:56 PM >> To: Burger, Eric >> Cc: Hisham Khartabil; Ben Campbell; simple@ietf.org >> Subject: Re: [Simple] Re: Comments on draft-ietf-simple-imdn-00.txt >> >> also inline... >> >> On Jul 28, 2006, at 10:50 AM, Burger, Eric wrote: >> >>> Mine, too (inline): >>> >>>> -----Original Message----- >>>> From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] >>>> Sent: Friday, July 28, 2006 11:26 AM >>>> To: Ben Campbell >>>> Cc: Eric McMurry; simple@ietf.org; Burger, Eric >>>> Subject: Re: [Simple] Re: Comments on draft-ietf-simple-imdn-00.txt >>>> >>>> Hi Ben, >>>> >>>> Comments inline... >>>> >>>> On Jul 28, 2006, at 5:04 PM, Ben Campbell wrote: >>>> >>>>> >>>>> On Jul 28, 2006, at 8:33 AM, Hisham Khartabil wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> Thanks for the comments. Responses inline... >>>>>> >>>>>> On Jul 27, 2006, at 9:00 PM, Eric McMurry wrote: >>>>>> >>>>>>> I understand that a rewrite is being considered, so I'll hold >>>>>>> off >>> on >>>>>>> editorial comments. >>>>>>> >>>>>>> >>>>>>> 1) I'm struggling a bit with the application of this to MSRP. >>>>>>> DNs >>> >>>>>>> in general seem to make more sense for non-realtime applications >>>>>>> (like page-mode messaging). For realtime, session-mode, >>>>>>> applications, the session protocol ensures that messages are >>>>>>> delivered. Also, sessions tend to be interactive which I think >>>>>>> greatly lessens the value of read notifications. Perhaps >>>>>>> someone >>>>>>> has a use case for this to make the value more clear? >>>>>> >>>>>> Having a message session with a machine the requires delivery of >>> IMs >>>>>> in proper sequence and therefore need a delivery notification >>> before >>>>>> sending the next one. >>>>>> >>>>> >>>>> I'm not sure I buy this example. I can use the built in >>>>> notification >>> >>>>> mechanism in MSRP to accomplish the same thing. >>>>> >>>>> The only use cases I can think of involve messages that cross >>> session >>>>> "boundaries", i.e. when some sort of MSRP B2BUA is involved. >>>>> >>>>> I've mentioned before that I think it makes more sense to leave >>>>> such >>> >>>>> specification on how we use IMDN fpr MSRP until we define such >>>>> applications. Or at least spec out some agreed requirements for >>>>> IMDN >>> >>>>> in MSRP--right now we are speculating on how it might be used. >>>>> I am >>>>> not at all confident our speculation will turn out to be true. >>>> >>>> I used a bad example here. The draft actually says that for MSRP, >>>> delivery notification are not relevant since MRSP has that built >>>> in. >>>> The draft stresses that read notifications and any other future >>>> extensions might be useful. >>>> >>>> I don't agree that we need an application to define this. Companies >>>> might have use cases for this that they don't want to make public >>>> yet >>>> that uses on IMDNs for MSRP. Why make them wait 2 years to get an >>>> RFC >>>> where the text in the current draft is not damaging? >>> >>> I can go either way on this one. >> >> I'll buy the hidden use case and I'll also buy that there could >> easily be one I haven't thought of. What I was hoping to get from my >> question though was someone saying that they needed this (and better >> still, why). >> >>> >>> >>>>>>> 2) The available disposition states ("delivered", "read") are >>> suited >>>>>>> for responses from the target UA, but not so much for >>>>>>> intermediaries. I think reintroducing something like the >>>>>>> "processed" state, but more specific, may be in order. Take, >>>>>>> for >>>>>>> example, the store-and-forward case. >>>>>> >>>>>> We have deliberately limited it to delivered and read. Future >>>>>> extensions can define something like "processed" >>>>> >>>>> On reflection, when using SIP, I think receiving a 202 to a >>>>> MESSAGE >>> is >>>>> means the same thing that Eric is asking for. It may be worth >>>>> considering whether we want to have that concept in IMDN. (I lean >>>>> towards "no"-We have a slippery slope here on adding too much >>>>> transport functionality to IMDN.) >>>>> >>>>>> >>>>>>> >>>>>>> An intermediary strictly following the current spec would >>>>>>> return a >>> >>>>>>> negative delivery notification when it was not able to reach a >>>>>>> target. If the intermediary provides store-and-forward service >>>>>>> though, this results in a less than ideal experience for the >>>>>>> user >>>>>>> requesting the IMDN. They would almost immediately receive an >>>>>>> indication that their message was not delivered. >>>>>> >>>>>> No. They wouldn't receive anything. The message is still to be >>>>>> delivered. >>>>> >>>>> When I first read Hisham's response, I thought he was saying >>>>> nothing >>> >>>>> would be sent unless delivery succeeded. But I think he means that >>> the >>>>> intermediary should not return a failure IMDN until it had >>>>> exhausted >>> >>>>> all opportunities to deliver the message. If so, then I think I >>> agree. >>>> >>>> Yes thats what I meant. >> >> and I agree that that interpretation makes more sense. I was just >> being strict on how I read "final response" >> >>>> >>>>>>> Some time later (assuming that the message was subsequently >>>>>>> successfully delivered), they would receive another IMDN for the >>>>>>> same message indicating success (this one is a bit fuzzier I >>> think). >>>>>> >>>>>> This would be the first one they get. >>>>>> >>>>>>> >>>>>>> The net is that it is confusing to the user. I would suggest >>> adding >>>>>>> a "stored" state to handle this. It would be sent by an >>>>>>> intermediary providing store-and-forward service and would >>>>>>> provide >>> >>>>>>> the sender with a much more accurate view of what the >>>>>>> intermediate >>> >>>>>>> disposition of their message was. >>> >>> I really, really would rather have the "processed" state. Let the >>> protocol say what it is really doing, not what it thinks might be >>> possibly going on. The B2BUA receives a message: it is being >>> processed, >>> so tell the UAC so. A later delivery message should work just fine. >>> The B2BUA doesn't get the message, or it can't process the message: >>> send >>> a failure report. >>> >>> I don't like "stored", because that is only relevant to >>> store-and-forward. IMDN should work for any B2BUA, not just a >>> store-and-forward B2BUA. >>> >>> Note that having the hint to the B2BUA that the UAC is looking for >>> the >>> fate of the B2BUA's handling of the message, rather than the >>> endpoints >>> handling of the message, removes the ambiguity of who should >>> generate >>> the IMDN and what the IMDN means. >> >> >> I'm also strongly in favor of allowing the protocol to have reporting >> of intermediate states. This allows for more descriptive status to >> be presented to the user. >> >> I still like "stored", but not as the only option. I was suggesting >> that a one example of a category of states of the "processed" ilk. >> However, I'm okay with using "processed" for this since we have the >> Note field for the intermediary to provide more descriptive >> information in. The drawback to this is that we lack a standard way >> of conveying the more descriptive information. >> >> The use of the hint to the intermediary is new to me. Are you >> suggesting that in this case, only the B2BUA would generate an IMDN? >> I was thinking more along the lines that the IMDN generated by the >> B2BUA would be an intermediate response, and that the final endpoint >> would also generate one. I think this would be true for both >> "processed" and "stored" types of states. >> >> >>> >>>>>>> 3) "Future extensions" are mentioned in several places, but no >>>>>>> extension mechanism is specified. Perhaps a mechanism for >>>>>>> vendor >>>>>>> specific extensions should be specified to avoid collisions with >>>>>>> future versions of this spec. >>>>>> >>>>>> Added text in section 9.1 suggesting future extensions must be in >>> an >>>>>> RFC. >>>>>> >>>>>>> >>>>>>> >>>>>>> 4) The example of an IM body with an IMDN request (section 4.1) >>> has >>>>>>> not caught up with the addition of a CPIM namespace to the >>>>>>> specification. >>>>>> >>>>>> I actually forgot this was there. I removed the definition of the >>> new >>>>>> namespace and referred to the default namespace instead. >>>>> >>>>> We are taking the namespace out? Why? Or did I misread your >>>>> intent? >>>>> >>>>> Namespaces are the defined mechanism for extending CPIM. >>>> >>>> I believe using the default namespace is allowed. You can define a >>>> new >>> >>>> namespace for new headers if you are worried about header name >>> clashes. >>>> Or am I wrong? >>> >>> Namespaces are also used for capabilities negotiation, so it really >>> should be included. >>> >>>>>>> 5) In section 4.4 "Keeping State", second paragraph, perhaps the >>>>>>> phase "user choice" should read "local policy" (okay, that was a >>> bit >>>>>>> editorial :-) >>>>>> >>>>>> I actually prefer user choice since it clearly states that the >>>>>> user >>> >>>>>> makes that choice and not the implementer. >>>>>> >>>>> >>>>> If that is the intent, we need more normative language to say the >>>>> implementation MUST or SHOULD let the user decide. But in this >>>>> case, >>> I >>>>> do think this is more an implementation choice than a user >>>>> choice. I >>> >>>>> don't see an end-user being in a position to decide whether they >>> want >>>>> to keep state or not. This is more a matter of the type of device, >>>>> it's memory constraints, the intended user experience, etc. >>>>> >>>> This is the text in the draft "How long to keep items in the "Sent >>>> Items" box is a user choice." It is not about keeping state, it is >>>> about keeping items in the sent items box. >>>> >>>> This is not an implementer choice. I would smash the phone if it >>>> removed things from my "Sent Items" box without me doing it >>>> deliberately :) We are not discussing how to implement a "Sent >>>> Items" >>>> box anyhow in this draft. >>> >>> Which is also why it isn't really user choice... >> >> I can't imagine a client not giving this choice to the user (except >> perhaps in the case of limited client resources). That said, I think >> this should be left up to the implementor since it is a UI feature. >> >>> >>>>>>> 6) Description of use of the Original-To header should spell >>>>>>> out >>>>>>> that this header should only be added if it does not already >>> exist. >>>>>>> It is possible that there will be multiple intermediaries in the >>>>>>> path, and only the first one should do this. >>>>>> >>>>>> Yes. This is done already in my local copy of the next version. >>>>>> >>>>>>> >>>>>>> >>>>>>> 7) I agreed with Miguel Garcia's comment on Really-To and >>>>>>> Really-From in another email, but allow me to reiterate. >>>>>>> This is >>> a >>>>>>> Via-like mechanism and would be less confusing (at least to >>>>>>> me) if >>> >>>>>>> it were named as such. >>>>>> >>>>>> I'll make that change. >>>>>> >>>>> >>>>> By the way, we got feedback on MSRP to try to avoid having >>>>> different >>> >>>>> header names start with the same several letters. It makes parsing >>>>> harder. >>> >>> A LONG, SLOW PAINFUL DEATH TO IMPLEMENTORS THAT DO NOT BUILD A REAL >>> PARSER THAT FOLLOWS THE FULL SPECIFICATION. We first tear out their >>> fingers so they can no longer inflict "almost compatible" >>> implementations that we later have to work around. >>> >>> GIVE ME A BREAK. Too bad if my 12 character string starts with the >>> same >>> 6 characters! If they are not reading the entire string, they have >>> blown it already. >> >> I wasn't going to be quite so violent in my response, but I agree :-) >> >>> >>> >>>>>>> 8) Aggregation. Let's start with a scenario. Say there's a >>> request >>>>>>> to a list exploder with a local policy on the requested list to >>> not >>>>>>> reveal the list members. Let's also say that the exploder is >>> going >>>>>>> to aggregate IMDNs either by policy or request. >>>>>>> >>>>>>> So the request is exploded, and time passes. The exploder >>> collects >>>>>>> some IMDNs and decides it's time to send an aggregate response. >>>>>>> Since the local policy is to not reveal list members, it strips >>> this >>>>>>> info from all of the IMDNs. Then it prepares and sends the >>>>>>> aggregated IMDN. >>>>>> >>>>>> A list server can send *ONE* imdn indicating "delivered" after is >>> has >>>>>> received some or all of the IMDNs. This is only an option of >>> course. >>>>>> >>>>>>> >>>>>>> The UA that originated the request to the list exploder then >>>>>>> receives a list of IMDNs with no user information in them. Now, >>> how >>>>>>> will this be presented to the user? >>>>>> >>>>>> "x users received the message" is one example. This is an >>>>>> implementation choice >>>>>> >>>>>>> The client only knows that some number of users on the list >>>>>>> received the message, some number didn't, and an unknown number >>> did >>>>>>> or didn't receive it. >>>>>> >>>>>> That acceptable, imo. >>>>> >>>>> Acceptable, maybe. Can we describe a use case for which it is >>> _useful_. >>>> >>>> What are you suggesting? Are you suggesting that no aggregation is >>> done >>>> for private lists? or should the list server reject the IM? I can't >>>> think of a use case now, but I don't think we should add >>>> complications >>> >>>> by forbidding something. This is implementation choice. >>> >>> Agreed (with Hisham) >> >> So, a list server can then potentially: >> >> ((ignore the IMDN request) or ((optionally generate a "processed" >> type IMDN when the list is exploded) and (optionally generate one >> "delivered" IMDN when it receives some number of IMDNs from the >> recipients) or (optionally generate some number of aggregated IMDNs >> with the recipient info stripped)) >> >> and the client would then have to savvy any combination of these if >> it wanted to send to a list. Maybe this is reasonable, but it seems >> as if we've come up with several ways to skin a cat, when it may be >> that we really had a porcupine (and who wants to skin a porcupine?). >> I'll have to give this some more thought. >> >>> >>>>>>> The number of aggregated IMDNs could be large as well and may >>>>>>> require multiple messages (only 1300 bytes available for >>>>>>> MESSAGE) >>> to >>>>>>> send. I would suggest that aggregated IMDNs don't make sense if >>> the >>>>>>> policy of the aggregator is to strip the recipient info. >>>>>> >>>>>> I disagree. I think it does make sense. Sometimes I am interested >>>>>> that enough people received the message, not who. >>>>>> >>>>>>> The most useful piece of delivery information that can >>>>>>> probably >>> be >>>>>>> obtained in this scenario is that the message was delivered >>>>>>> successfully or not to the list server. This could be >>> accomplished >>>>>>> by sending a "delivered" state IMDN from the list server, or if >>>>>>> something more explicit is desired, another intermediate state, >>> such >>>>>>> as "exploded" (okay, that was just for fun, but it conveys the >>>>>>> status) could be defined. >>> >>> This would be handled by the UAC giving the B2BUA the hint that the >>> IMDN >>> is for the B2BUA to generate (in its role as a UAS) and not for >>> down-stream nodes to generate. >>> >>> >>>>>>> 9) I'm sure this would have been covered in the next version, >>>>>>> but >>>>>>> just in case: the text for the IANA registration of the >>>>>>> Content-Disposition header (13.5) is missing. >>>>>> >>>>>> Yes. Added. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 28 15:04:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Xd4-0002lf-49; Fri, 28 Jul 2006 15:04:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Xd2-0002lW-CM for simple@ietf.org; Fri, 28 Jul 2006 15:04:08 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6Xd1-0000lz-KX for simple@ietf.org; Fri, 28 Jul 2006 15:04:08 -0400 X-IronPort-AV: i="4.07,193,1151899200"; d="scan'208"; a="35909265:sNHT57783528" Content-class: urn:content-classes:message Subject: RE: [Simple] Re: Comments on draft-ietf-simple-imdn-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 28 Jul 2006 15:04:05 -0400 Message-ID: <330A23D8336C0346B5C1A5BB196666470356A6C6@ATLANTIS.Brooktrout.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Re: Comments on draft-ietf-simple-imdn-00.txt Thread-Index: AcayeDzmJapshecaQembhL5+5KzEAgAADqRQ From: "Burger, Eric" To: "Eric McMurry" X-Spam-Score: 0.0 (/) X-Scan-Signature: c8d1e86bb8f49de8156b6392faa4a63b Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Given the message is likely to be processed by the UAC *automaton*, I will agree. If the user will see the message, then I'm less happy with that. We would figure it out, but Joe Six-pack would be mystified. -----Original Message----- From: Eric McMurry [mailto:emcmurry@estacado.net]=20 Sent: Friday, July 28, 2006 2:59 PM To: Burger, Eric Cc: simple@ietf.org Subject: Re: [Simple] Re: Comments on draft-ietf-simple-imdn-00.txt This sound like a great reason to have a separate IMDN state for =20 processed/stored to me. In this case, the B2BUA acting as a store-=20 and-forward server could send an IMDN indicating that the message was =20 stored. Now the user knows explicitly what happened. Later, when the message was finally delivered, they could get another =20 IMDN indicating that. On Jul 28, 2006, at 1:54 PM, Burger, Eric wrote: > How would the sender have a clue that they are sending their =20 > message to > a store-and-forward server? > > I'm sending you an IM because my presence info is out of date. Your > friendly in-the-network B2BUA picks up the message, accepts it (as a > UAS), and now holds it for you. I certainly didn't think I was =20 > talking > to a B2BUA when I initiated the session. > > -----Original Message----- > From: Eric McMurry [mailto:emcmurry@estacado.net] > Sent: Friday, July 28, 2006 2:51 PM > To: Burger, Eric > Cc: simple@ietf.org > Subject: Re: [Simple] Re: Comments on draft-ietf-simple-imdn-00.txt > > thanks for the reference. > > I still think it is useful though to have the possibility of IMDNs > generated at both an intermediary and the final recipient. For store- > and-forward, I can see the user wanting to know that the message was > stored, and later, that it was delivered. For a list, I can see the > user wanting to know that the list server processed the message, and > later, that recipients received/read it. > > > > On Jul 28, 2006, at 12:51 PM, Burger, Eric wrote: > >> The hint is actually old, from draft-burger-simple-imdn: >> >> To request the generation of an IMDN, the Requesting UAC MUST >> include >> the Disposition-Notification and Message-ID headers. The >> Requesting >> UAC MAY also include a List-Action header to provide down-stream >> B2BUA's with the user's desire for IMDN reporting by the final >> target >> of B2BUA expansion or the B2BUA itself. B2BUA's SHOULD include =20 >> the >> Original-From header, with the value of the inbound From header, >> unless privacy considerations require the B2BUA to not transmit =20 >> the >> Original-From header. Likewise, B2BUA's SHOULD copy the value >> of the >> inbound Message-ID into the outbound Original-Message-Id header. >> >> >> >> -----Original Message----- >> From: Eric McMurry [mailto:emcmurry@estacado.net] >> Sent: Friday, July 28, 2006 12:56 PM >> To: Burger, Eric >> Cc: Hisham Khartabil; Ben Campbell; simple@ietf.org >> Subject: Re: [Simple] Re: Comments on draft-ietf-simple-imdn-00.txt >> >> also inline... >> >> On Jul 28, 2006, at 10:50 AM, Burger, Eric wrote: >> >>> Mine, too (inline): >>> >>>> -----Original Message----- >>>> From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] >>>> Sent: Friday, July 28, 2006 11:26 AM >>>> To: Ben Campbell >>>> Cc: Eric McMurry; simple@ietf.org; Burger, Eric >>>> Subject: Re: [Simple] Re: Comments on draft-ietf-simple-imdn-00.txt >>>> >>>> Hi Ben, >>>> >>>> Comments inline... >>>> >>>> On Jul 28, 2006, at 5:04 PM, Ben Campbell wrote: >>>> >>>>> >>>>> On Jul 28, 2006, at 8:33 AM, Hisham Khartabil wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> Thanks for the comments. Responses inline... >>>>>> >>>>>> On Jul 27, 2006, at 9:00 PM, Eric McMurry wrote: >>>>>> >>>>>>> I understand that a rewrite is being considered, so I'll hold =20 >>>>>>> off >>> on >>>>>>> editorial comments. >>>>>>> >>>>>>> >>>>>>> 1) I'm struggling a bit with the application of this to MSRP. >>>>>>> DNs >>> >>>>>>> in general seem to make more sense for non-realtime applications >>>>>>> (like page-mode messaging). For realtime, session-mode, >>>>>>> applications, the session protocol ensures that messages are >>>>>>> delivered. Also, sessions tend to be interactive which I think >>>>>>> greatly lessens the value of read notifications. Perhaps =20 >>>>>>> someone >>>>>>> has a use case for this to make the value more clear? >>>>>> >>>>>> Having a message session with a machine the requires delivery of >>> IMs >>>>>> in proper sequence and therefore need a delivery notification >>> before >>>>>> sending the next one. >>>>>> >>>>> >>>>> I'm not sure I buy this example. I can use the built in >>>>> notification >>> >>>>> mechanism in MSRP to accomplish the same thing. >>>>> >>>>> The only use cases I can think of involve messages that cross >>> session >>>>> "boundaries", i.e. when some sort of MSRP B2BUA is involved. >>>>> >>>>> I've mentioned before that I think it makes more sense to leave >>>>> such >>> >>>>> specification on how we use IMDN fpr MSRP until we define such >>>>> applications. Or at least spec out some agreed requirements for >>>>> IMDN >>> >>>>> in MSRP--right now we are speculating on how it might be used. =20 >>>>> I am >>>>> not at all confident our speculation will turn out to be true. >>>> >>>> I used a bad example here. The draft actually says that for MSRP, >>>> delivery notification are not relevant since MRSP has that built =20 >>>> in. >>>> The draft stresses that read notifications and any other future >>>> extensions might be useful. >>>> >>>> I don't agree that we need an application to define this. Companies >>>> might have use cases for this that they don't want to make public >>>> yet >>>> that uses on IMDNs for MSRP. Why make them wait 2 years to get an >>>> RFC >>>> where the text in the current draft is not damaging? >>> >>> I can go either way on this one. >> >> I'll buy the hidden use case and I'll also buy that there could >> easily be one I haven't thought of. What I was hoping to get from my >> question though was someone saying that they needed this (and better >> still, why). >> >>> >>> >>>>>>> 2) The available disposition states ("delivered", "read") are >>> suited >>>>>>> for responses from the target UA, but not so much for >>>>>>> intermediaries. I think reintroducing something like the >>>>>>> "processed" state, but more specific, may be in order. Take, =20 >>>>>>> for >>>>>>> example, the store-and-forward case. >>>>>> >>>>>> We have deliberately limited it to delivered and read. Future >>>>>> extensions can define something like "processed" >>>>> >>>>> On reflection, when using SIP, I think receiving a 202 to a =20 >>>>> MESSAGE >>> is >>>>> means the same thing that Eric is asking for. It may be worth >>>>> considering whether we want to have that concept in IMDN. (I lean >>>>> towards "no"-We have a slippery slope here on adding too much >>>>> transport functionality to IMDN.) >>>>> >>>>>> >>>>>>> >>>>>>> An intermediary strictly following the current spec would >>>>>>> return a >>> >>>>>>> negative delivery notification when it was not able to reach a >>>>>>> target. If the intermediary provides store-and-forward service >>>>>>> though, this results in a less than ideal experience for the =20 >>>>>>> user >>>>>>> requesting the IMDN. They would almost immediately receive an >>>>>>> indication that their message was not delivered. >>>>>> >>>>>> No. They wouldn't receive anything. The message is still to be >>>>>> delivered. >>>>> >>>>> When I first read Hisham's response, I thought he was saying >>>>> nothing >>> >>>>> would be sent unless delivery succeeded. But I think he means that >>> the >>>>> intermediary should not return a failure IMDN until it had >>>>> exhausted >>> >>>>> all opportunities to deliver the message. If so, then I think I >>> agree. >>>> >>>> Yes thats what I meant. >> >> and I agree that that interpretation makes more sense. I was just >> being strict on how I read "final response" >> >>>> >>>>>>> Some time later (assuming that the message was subsequently >>>>>>> successfully delivered), they would receive another IMDN for the >>>>>>> same message indicating success (this one is a bit fuzzier I >>> think). >>>>>> >>>>>> This would be the first one they get. >>>>>> >>>>>>> >>>>>>> The net is that it is confusing to the user. I would suggest >>> adding >>>>>>> a "stored" state to handle this. It would be sent by an >>>>>>> intermediary providing store-and-forward service and would >>>>>>> provide >>> >>>>>>> the sender with a much more accurate view of what the >>>>>>> intermediate >>> >>>>>>> disposition of their message was. >>> >>> I really, really would rather have the "processed" state. Let the >>> protocol say what it is really doing, not what it thinks might be >>> possibly going on. The B2BUA receives a message: it is being >>> processed, >>> so tell the UAC so. A later delivery message should work just fine. >>> The B2BUA doesn't get the message, or it can't process the message: >>> send >>> a failure report. >>> >>> I don't like "stored", because that is only relevant to >>> store-and-forward. IMDN should work for any B2BUA, not just a >>> store-and-forward B2BUA. >>> >>> Note that having the hint to the B2BUA that the UAC is looking for >>> the >>> fate of the B2BUA's handling of the message, rather than the >>> endpoints >>> handling of the message, removes the ambiguity of who should =20 >>> generate >>> the IMDN and what the IMDN means. >> >> >> I'm also strongly in favor of allowing the protocol to have reporting >> of intermediate states. This allows for more descriptive status to >> be presented to the user. >> >> I still like "stored", but not as the only option. I was suggesting >> that a one example of a category of states of the "processed" ilk. >> However, I'm okay with using "processed" for this since we have the >> Note field for the intermediary to provide more descriptive >> information in. The drawback to this is that we lack a standard way >> of conveying the more descriptive information. >> >> The use of the hint to the intermediary is new to me. Are you >> suggesting that in this case, only the B2BUA would generate an IMDN? >> I was thinking more along the lines that the IMDN generated by the >> B2BUA would be an intermediate response, and that the final endpoint >> would also generate one. I think this would be true for both >> "processed" and "stored" types of states. >> >> >>> >>>>>>> 3) "Future extensions" are mentioned in several places, but no >>>>>>> extension mechanism is specified. Perhaps a mechanism for =20 >>>>>>> vendor >>>>>>> specific extensions should be specified to avoid collisions with >>>>>>> future versions of this spec. >>>>>> >>>>>> Added text in section 9.1 suggesting future extensions must be in >>> an >>>>>> RFC. >>>>>> >>>>>>> >>>>>>> >>>>>>> 4) The example of an IM body with an IMDN request (section 4.1) >>> has >>>>>>> not caught up with the addition of a CPIM namespace to the >>>>>>> specification. >>>>>> >>>>>> I actually forgot this was there. I removed the definition of the >>> new >>>>>> namespace and referred to the default namespace instead. >>>>> >>>>> We are taking the namespace out? Why? Or did I misread your =20 >>>>> intent? >>>>> >>>>> Namespaces are the defined mechanism for extending CPIM. >>>> >>>> I believe using the default namespace is allowed. You can define a >>>> new >>> >>>> namespace for new headers if you are worried about header name >>> clashes. >>>> Or am I wrong? >>> >>> Namespaces are also used for capabilities negotiation, so it really >>> should be included. >>> >>>>>>> 5) In section 4.4 "Keeping State", second paragraph, perhaps the >>>>>>> phase "user choice" should read "local policy" (okay, that was a >>> bit >>>>>>> editorial :-) >>>>>> >>>>>> I actually prefer user choice since it clearly states that the >>>>>> user >>> >>>>>> makes that choice and not the implementer. >>>>>> >>>>> >>>>> If that is the intent, we need more normative language to say the >>>>> implementation MUST or SHOULD let the user decide. But in this >>>>> case, >>> I >>>>> do think this is more an implementation choice than a user >>>>> choice. I >>> >>>>> don't see an end-user being in a position to decide whether they >>> want >>>>> to keep state or not. This is more a matter of the type of device, >>>>> it's memory constraints, the intended user experience, etc. >>>>> >>>> This is the text in the draft "How long to keep items in the "Sent >>>> Items" box is a user choice." It is not about keeping state, it is >>>> about keeping items in the sent items box. >>>> >>>> This is not an implementer choice. I would smash the phone if it >>>> removed things from my "Sent Items" box without me doing it >>>> deliberately :) We are not discussing how to implement a "Sent >>>> Items" >>>> box anyhow in this draft. >>> >>> Which is also why it isn't really user choice... >> >> I can't imagine a client not giving this choice to the user (except >> perhaps in the case of limited client resources). That said, I think >> this should be left up to the implementor since it is a UI feature. >> >>> >>>>>>> 6) Description of use of the Original-To header should spell =20 >>>>>>> out >>>>>>> that this header should only be added if it does not already >>> exist. >>>>>>> It is possible that there will be multiple intermediaries in the >>>>>>> path, and only the first one should do this. >>>>>> >>>>>> Yes. This is done already in my local copy of the next version. >>>>>> >>>>>>> >>>>>>> >>>>>>> 7) I agreed with Miguel Garcia's comment on Really-To and >>>>>>> Really-From in another email, but allow me to reiterate. =20 >>>>>>> This is >>> a >>>>>>> Via-like mechanism and would be less confusing (at least to >>>>>>> me) if >>> >>>>>>> it were named as such. >>>>>> >>>>>> I'll make that change. >>>>>> >>>>> >>>>> By the way, we got feedback on MSRP to try to avoid having >>>>> different >>> >>>>> header names start with the same several letters. It makes parsing >>>>> harder. >>> >>> A LONG, SLOW PAINFUL DEATH TO IMPLEMENTORS THAT DO NOT BUILD A REAL >>> PARSER THAT FOLLOWS THE FULL SPECIFICATION. We first tear out their >>> fingers so they can no longer inflict "almost compatible" >>> implementations that we later have to work around. >>> >>> GIVE ME A BREAK. Too bad if my 12 character string starts with the >>> same >>> 6 characters! If they are not reading the entire string, they have >>> blown it already. >> >> I wasn't going to be quite so violent in my response, but I agree :-) >> >>> >>> >>>>>>> 8) Aggregation. Let's start with a scenario. Say there's a >>> request >>>>>>> to a list exploder with a local policy on the requested list to >>> not >>>>>>> reveal the list members. Let's also say that the exploder is >>> going >>>>>>> to aggregate IMDNs either by policy or request. >>>>>>> >>>>>>> So the request is exploded, and time passes. The exploder >>> collects >>>>>>> some IMDNs and decides it's time to send an aggregate response. >>>>>>> Since the local policy is to not reveal list members, it strips >>> this >>>>>>> info from all of the IMDNs. Then it prepares and sends the >>>>>>> aggregated IMDN. >>>>>> >>>>>> A list server can send *ONE* imdn indicating "delivered" after is >>> has >>>>>> received some or all of the IMDNs. This is only an option of >>> course. >>>>>> >>>>>>> >>>>>>> The UA that originated the request to the list exploder then >>>>>>> receives a list of IMDNs with no user information in them. Now, >>> how >>>>>>> will this be presented to the user? >>>>>> >>>>>> "x users received the message" is one example. This is an >>>>>> implementation choice >>>>>> >>>>>>> The client only knows that some number of users on the list >>>>>>> received the message, some number didn't, and an unknown number >>> did >>>>>>> or didn't receive it. >>>>>> >>>>>> That acceptable, imo. >>>>> >>>>> Acceptable, maybe. Can we describe a use case for which it is >>> _useful_. >>>> >>>> What are you suggesting? Are you suggesting that no aggregation is >>> done >>>> for private lists? or should the list server reject the IM? I can't >>>> think of a use case now, but I don't think we should add >>>> complications >>> >>>> by forbidding something. This is implementation choice. >>> >>> Agreed (with Hisham) >> >> So, a list server can then potentially: >> >> ((ignore the IMDN request) or ((optionally generate a "processed" >> type IMDN when the list is exploded) and (optionally generate one >> "delivered" IMDN when it receives some number of IMDNs from the >> recipients) or (optionally generate some number of aggregated IMDNs >> with the recipient info stripped)) >> >> and the client would then have to savvy any combination of these if >> it wanted to send to a list. Maybe this is reasonable, but it seems >> as if we've come up with several ways to skin a cat, when it may be >> that we really had a porcupine (and who wants to skin a porcupine?). >> I'll have to give this some more thought. >> >>> >>>>>>> The number of aggregated IMDNs could be large as well and may >>>>>>> require multiple messages (only 1300 bytes available for =20 >>>>>>> MESSAGE) >>> to >>>>>>> send. I would suggest that aggregated IMDNs don't make sense if >>> the >>>>>>> policy of the aggregator is to strip the recipient info. >>>>>> >>>>>> I disagree. I think it does make sense. Sometimes I am interested >>>>>> that enough people received the message, not who. >>>>>> >>>>>>> The most useful piece of delivery information that can =20 >>>>>>> probably >>> be >>>>>>> obtained in this scenario is that the message was delivered >>>>>>> successfully or not to the list server. This could be >>> accomplished >>>>>>> by sending a "delivered" state IMDN from the list server, or if >>>>>>> something more explicit is desired, another intermediate state, >>> such >>>>>>> as "exploded" (okay, that was just for fun, but it conveys the >>>>>>> status) could be defined. >>> >>> This would be handled by the UAC giving the B2BUA the hint that the >>> IMDN >>> is for the B2BUA to generate (in its role as a UAS) and not for >>> down-stream nodes to generate. >>> >>> >>>>>>> 9) I'm sure this would have been covered in the next version, =20 >>>>>>> but >>>>>>> just in case: the text for the IANA registration of the >>>>>>> Content-Disposition header (13.5) is missing. >>>>>> >>>>>> Yes. Added. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From 1Cehaqrokt@mail.ru Sun Jul 30 06:48:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G78qT-0004PX-BQ for simple-archive@lists.ietf.org; Sun, 30 Jul 2006 06:48:29 -0400 Received: from [194.97.163.119] (helo=mxs.mail.ru) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G78qR-000316-Os for simple-archive@lists.ietf.org; Sun, 30 Jul 2006 06:48:29 -0400 Date: Sun, 30 Jul 2006 10:48:27 -0060 From: "Bernardo Sargent" X-Mailer: The Bat! (v2.04.7) CD5BF9353B3B7091 Reply-To: "Bernardo Sargent" X-Priority: 3 (Normal) Message-ID: <284719077.20060730104827@mail.ru> To: simple-archive@lists.ietf.org Subject: Your money, palm worm MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 4.6 (++++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Even if you have no erectin problems SOFT CIA6LIS would help you to make BETTER SE6X MORE OFTEN! and to bring unimagnable plesure to her. Just disolve half a pil under your tongue and get ready for action in 15 minutes. The tests showed that the majority of men after taking this medic ation were able to have PERFECT ER6ECTION during 36 hours! VISIT US, AND GET OUR SPECIAL 70% DISC3OUNT OFER! http://oucswt.climbagain.info/?35419351 ========== By sunup, Jonathan Gull was practicing again. From five thousand feet I won't take Tender along. What do you think, Red? Maybe I shouldn't take limit that would take great effort to crack. In heaven, he thought, there the controls without my orders, no matter what, even if the earth catches special and gifted and divine? No more than you are, no more than I am. looked like a plum, I had really given him a solid punch. I lowered the thought an image of the great gull flocks on the shore of another time, in silence. I was sorry for him, of course, and I felt bad that things From simple-bounces@ietf.org Sun Jul 30 12:50:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7EUB-0002ke-RY; Sun, 30 Jul 2006 12:49:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7EUA-0002kW-DM for simple@ietf.org; Sun, 30 Jul 2006 12:49:50 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7EU7-0004Kt-Vh for simple@ietf.org; Sun, 30 Jul 2006 12:49:50 -0400 Received: (qmail 24133 invoked by uid 0); 30 Jul 2006 16:49:46 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 30 Jul 2006 16:49:46 -0000 Message-ID: <006c01c6b3f8$2552ea10$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Aki Niemi" References: <000001c6acef$bbf7fab0$6602a8c0@laptopbem> <1154071866.21805.9.camel@macbuster.research.nokia.com> Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-partial-publish-05.txt Date: Sun, 30 Jul 2006 18:49:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi Aki, see inline Regards, Jeroen > On pe, 2006-07-21 at 20:01 +0200, ext Jeroen van Bemmel wrote: >> Aki, >> >> I think you should drop pidf-full altogether (remove it completely), and >> only use pidf and pidf-diff. For versioning of notifications you can >> simply >> use the CSeq number (initial NOTIFY MUST be pidf) > > This is a pretty substantial change. It affects not only partial-publish > but -format and -notify as well. And is more of a complete rewrite. > > I'm wondering if this is all that much better, or just different. You > still require a new, separate content type. The 'version' attribute > still needs to be there in pidf-diff (to account for partial traversing > CPP gateways) and so on. > > Is there something obvious that makes the current mechanism broken? If > not, can you live with what's there now? > It is mostly that pidf-full seems to add unnecessary overhead and complexity. Given that the purpose of this draft is reduction of message size, it would be odd to introduce inefficiencies, in particular if the view now is that the original reason for introducing pidf-full (versioning) is not needed. I do see that it is quite some effort to rewrite the whole "package" of drafts, but the alternative is that implementors get to spend more effort on implementation, and those implementations get to waste cpu cycles converting between pidf-full and pidf. Moreover, I have searched but did not find any XML MIME types that use 2 distinct roots for their XML documents. There seems to be nothing that prohibits it, but a unique root is again more simple. >> Even if Allow is not allowed in 2xx to PUBLISH, it is still better to use >> pidf in the initial PUBLISH. If a subsequent pidf-diff fails because of >> UAS >> not supporting, the wasted effort is less. > > I think you mean Accept, but how much 'better' is it really. You still > don't save a round trip, since in your proposal, the first partial > update would still fail, requiring a resend. Yes, I meant Accept. With pidf-full, it's likely that the document will require TCP for transmission (due to size). If the server does not support pidf-full, it will send an error response, and probably close the connection. Sending regular pidf is better, because less wasted bytes are transmitted, and because the potential error is postponed (if there are no updates, it never occurs). Moreover, the pidf-diff can likely be sent over UDP, avoiding a possibly wasteful extra TCP connection setup Again, given that the goal of the draft is optimization of presence traffic, it doesn't make sense to me to not use regular pidf here > > Cheers, > Aki > > -- > Aki Niemi > Nokia Research Center > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 31 03:15:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7RzV-0005Vh-73; Mon, 31 Jul 2006 03:15:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7RzS-0005UJ-Tq for simple@ietf.org; Mon, 31 Jul 2006 03:15:02 -0400 Received: from [202.54.64.17] (helo=hclnpd.hclt-ntl.co.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7RzQ-0008In-VM for simple@ietf.org; Mon, 31 Jul 2006 03:15:02 -0400 Received: from npd-mail1.hclt-ntl.co.in ([10.105.1.106]) by hclnpd.hclt-ntl.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id L8ZN68M2; Mon, 31 Jul 2006 12:42:47 +0530 X-MessageTextProcessor: DisclaimIt (2.50.252) [HCL Technologies Ltd., Chennai, India] Content-Class: urn:content-classes:message Received: from npd-mail.hclt-ntl.co.in ([10.105.1.104]) by npd-mail1.hclt-ntl.co.in with Microsoft SMTPSVC(5.0.2195.6713); Mon, 31 Jul 2006 12:44:58 +0530 Received: by npd-mail.hclt-ntl.co.in with Internet Mail Service (5.5.2657.72) id ; Mon, 31 Jul 2006 12:44:58 +0530 Message-ID: <4B1D6623CCBD79489DE28D1CA062A47E021DF9D6@npd-mail.hclt-ntl.co.in> From: "Jayantheesh Sirmushnam - NPD, Chennai" To: Date: Mon, 31 Jul 2006 12:44:57 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-OriginalArrivalTime: 31 Jul 2006 07:14:58.0519 (UTC) FILETIME=[08007670:01C6B471] X-Spam-Score: 0.1 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Subject: [Simple] Regarding Parsing of partial pidf document X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 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="===============1079938234==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1079938234== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6B471.07903BF8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6B471.07903BF8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="Windows-1252" Hi, In Partial-PIDF draft 07, nowhere specified about any rules for parsing partial PIDF document. Could anyone please tell me, how to parse the below partial PIDF elements. =20 "open =20 =20 0.7" =20 Are there any specific rules to parse the PPIDF document? =20 =20 Thanks in advance, Jayantheesh Disclaimer: This message and any attachment(s) contained here are information that = is confidential, proprietary to HCL Technologies and its customers, = privileged or otherwise protected by law. The information is solely = intended for the individual or the entity it is addressed to. If you are = not the intended recipient of this message, you are not authorized to = read, forward, print, retain, copy or disseminate this message or any = part of it. If you have received this e-mail in error, please notify the = sender immediately by return e-mail and delete it from your computer. ------_=_NextPart_001_01C6B471.07903BF8 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi,

      = ; In Partial-PIDF draft 07, nowhere specified about any rules for parsing = partial PIDF document.

      = ; Could anyone please tell me, how to parse the below partial PIDF = elements.

 

=

   =    “<p:replace sel=3D"*/tuple[@id=3D'r1230d']/status/basic/text()"<= o:p>

      >open</p:replace>

 

      <p:remove sel=3D"*/d:person/r:activities/r:busy" = ws=3D"after"/>

 

      <p:replace sel=3D"*/tuple[@id=3D'cg231jcr']/contact/@priority"<= /span>

       >0.7</p:replace>”

 

      = ; Are there any specific rules to parse the PPIDF document? =   

 

=

Thanks in = advance,

Jayantheesh

Disclaimer: This message and any attachment(s) contained here are information that = is confidential, proprietary to HCL Technologies and its customers, = privileged or otherwise protected by law. The information is solely = intended for the individual or the entity it is addressed to. If you are = not the intended recipient of this message, you are not authorized to = read, forward, print, retain, copy or disseminate this message or any = part of it. If you have received this e-mail in error, please notify the = sender immediately by return e-mail and delete it from your computer.

------_=_NextPart_001_01C6B471.07903BF8-- --===============1079938234== 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://www1.ietf.org/mailman/listinfo/simple --===============1079938234==-- From simple-bounces@ietf.org Mon Jul 31 04:57:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7TZk-0005cF-8M; Mon, 31 Jul 2006 04:56:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7TZj-0005cA-5f for simple@ietf.org; Mon, 31 Jul 2006 04:56:35 -0400 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7TZf-0005eZ-Qr for simple@ietf.org; Mon, 31 Jul 2006 04:56:35 -0400 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 800A6194485 for ; Mon, 31 Jul 2006 10:56:30 +0200 (CEST) Received: from [192.168.1.40] ([192.168.1.40]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 10:55:30 +0200 In-Reply-To: <330A23D8336C0346B5C1A5BB196666470356A6C6@ATLANTIS.Brooktrout.com> References: <330A23D8336C0346B5C1A5BB196666470356A6C6@ATLANTIS.Brooktrout.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] Re: Comments on draft-ietf-simple-imdn-00.txt Date: Mon, 31 Jul 2006 10:56:57 +0200 To: "Burger, Eric" X-Mailer: Apple Mail (2.624) X-OriginalArrivalTime: 31 Jul 2006 08:55:30.0488 (UTC) FILETIME=[1355E380:01C6B47F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 539f8b288ab42db633e5c7cf1c34fca1 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Note here that the sender of the IM is the one that requests any type of IMDN. So, through the UI, the user has to answer all the following questions for every IM: - Do I want to know if the IM is delivered - Do I want to know if the IM has failed - Do I want to know if the IM is read and the new states you are asking for: - Do I want to know if the IM is processed - Do I want to know if the IM is stored Of course these can be global settings, but still, too many. My opinion is to leave those out for the future. I am outvoted 2 to 1 here on "processed", but not "stored". Hisham On Jul 28, 2006, at 9:04 PM, Burger, Eric wrote: > Given the message is likely to be processed by the UAC *automaton*, I > will agree. If the user will see the message, then I'm less happy with > that. We would figure it out, but Joe Six-pack would be mystified. > > -----Original Message----- > From: Eric McMurry [mailto:emcmurry@estacado.net] > Sent: Friday, July 28, 2006 2:59 PM > To: Burger, Eric > Cc: simple@ietf.org > Subject: Re: [Simple] Re: Comments on draft-ietf-simple-imdn-00.txt > > This sound like a great reason to have a separate IMDN state for > processed/stored to me. In this case, the B2BUA acting as a store- > and-forward server could send an IMDN indicating that the message was > stored. Now the user knows explicitly what happened. > > Later, when the message was finally delivered, they could get another > IMDN indicating that. > > > On Jul 28, 2006, at 1:54 PM, Burger, Eric wrote: > >> How would the sender have a clue that they are sending their >> message to >> a store-and-forward server? >> >> I'm sending you an IM because my presence info is out of date. Your >> friendly in-the-network B2BUA picks up the message, accepts it (as a >> UAS), and now holds it for you. I certainly didn't think I was >> talking >> to a B2BUA when I initiated the session. >> >> -----Original Message----- >> From: Eric McMurry [mailto:emcmurry@estacado.net] >> Sent: Friday, July 28, 2006 2:51 PM >> To: Burger, Eric >> Cc: simple@ietf.org >> Subject: Re: [Simple] Re: Comments on draft-ietf-simple-imdn-00.txt >> >> thanks for the reference. >> >> I still think it is useful though to have the possibility of IMDNs >> generated at both an intermediary and the final recipient. For store- >> and-forward, I can see the user wanting to know that the message was >> stored, and later, that it was delivered. For a list, I can see the >> user wanting to know that the list server processed the message, and >> later, that recipients received/read it. >> >> >> >> On Jul 28, 2006, at 12:51 PM, Burger, Eric wrote: >> >>> The hint is actually old, from draft-burger-simple-imdn: >>> >>> To request the generation of an IMDN, the Requesting UAC MUST >>> include >>> the Disposition-Notification and Message-ID headers. The >>> Requesting >>> UAC MAY also include a List-Action header to provide down-stream >>> B2BUA's with the user's desire for IMDN reporting by the final >>> target >>> of B2BUA expansion or the B2BUA itself. B2BUA's SHOULD include >>> the >>> Original-From header, with the value of the inbound From header, >>> unless privacy considerations require the B2BUA to not transmit >>> the >>> Original-From header. Likewise, B2BUA's SHOULD copy the value >>> of the >>> inbound Message-ID into the outbound Original-Message-Id header. >>> >>> >>> >>> -----Original Message----- >>> From: Eric McMurry [mailto:emcmurry@estacado.net] >>> Sent: Friday, July 28, 2006 12:56 PM >>> To: Burger, Eric >>> Cc: Hisham Khartabil; Ben Campbell; simple@ietf.org >>> Subject: Re: [Simple] Re: Comments on draft-ietf-simple-imdn-00.txt >>> >>> also inline... >>> >>> On Jul 28, 2006, at 10:50 AM, Burger, Eric wrote: >>> >>>> Mine, too (inline): >>>> >>>>> -----Original Message----- >>>>> From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] >>>>> Sent: Friday, July 28, 2006 11:26 AM >>>>> To: Ben Campbell >>>>> Cc: Eric McMurry; simple@ietf.org; Burger, Eric >>>>> Subject: Re: [Simple] Re: Comments on draft-ietf-simple-imdn-00.txt >>>>> >>>>> Hi Ben, >>>>> >>>>> Comments inline... >>>>> >>>>> On Jul 28, 2006, at 5:04 PM, Ben Campbell wrote: >>>>> >>>>>> >>>>>> On Jul 28, 2006, at 8:33 AM, Hisham Khartabil wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Thanks for the comments. Responses inline... >>>>>>> >>>>>>> On Jul 27, 2006, at 9:00 PM, Eric McMurry wrote: >>>>>>> >>>>>>>> I understand that a rewrite is being considered, so I'll hold >>>>>>>> off >>>> on >>>>>>>> editorial comments. >>>>>>>> >>>>>>>> >>>>>>>> 1) I'm struggling a bit with the application of this to MSRP. >>>>>>>> DNs >>>> >>>>>>>> in general seem to make more sense for non-realtime applications >>>>>>>> (like page-mode messaging). For realtime, session-mode, >>>>>>>> applications, the session protocol ensures that messages are >>>>>>>> delivered. Also, sessions tend to be interactive which I think >>>>>>>> greatly lessens the value of read notifications. Perhaps >>>>>>>> someone >>>>>>>> has a use case for this to make the value more clear? >>>>>>> >>>>>>> Having a message session with a machine the requires delivery of >>>> IMs >>>>>>> in proper sequence and therefore need a delivery notification >>>> before >>>>>>> sending the next one. >>>>>>> >>>>>> >>>>>> I'm not sure I buy this example. I can use the built in >>>>>> notification >>>> >>>>>> mechanism in MSRP to accomplish the same thing. >>>>>> >>>>>> The only use cases I can think of involve messages that cross >>>> session >>>>>> "boundaries", i.e. when some sort of MSRP B2BUA is involved. >>>>>> >>>>>> I've mentioned before that I think it makes more sense to leave >>>>>> such >>>> >>>>>> specification on how we use IMDN fpr MSRP until we define such >>>>>> applications. Or at least spec out some agreed requirements for >>>>>> IMDN >>>> >>>>>> in MSRP--right now we are speculating on how it might be used. >>>>>> I am >>>>>> not at all confident our speculation will turn out to be true. >>>>> >>>>> I used a bad example here. The draft actually says that for MSRP, >>>>> delivery notification are not relevant since MRSP has that built >>>>> in. >>>>> The draft stresses that read notifications and any other future >>>>> extensions might be useful. >>>>> >>>>> I don't agree that we need an application to define this. Companies >>>>> might have use cases for this that they don't want to make public >>>>> yet >>>>> that uses on IMDNs for MSRP. Why make them wait 2 years to get an >>>>> RFC >>>>> where the text in the current draft is not damaging? >>>> >>>> I can go either way on this one. >>> >>> I'll buy the hidden use case and I'll also buy that there could >>> easily be one I haven't thought of. What I was hoping to get from my >>> question though was someone saying that they needed this (and better >>> still, why). >>> >>>> >>>> >>>>>>>> 2) The available disposition states ("delivered", "read") are >>>> suited >>>>>>>> for responses from the target UA, but not so much for >>>>>>>> intermediaries. I think reintroducing something like the >>>>>>>> "processed" state, but more specific, may be in order. Take, >>>>>>>> for >>>>>>>> example, the store-and-forward case. >>>>>>> >>>>>>> We have deliberately limited it to delivered and read. Future >>>>>>> extensions can define something like "processed" >>>>>> >>>>>> On reflection, when using SIP, I think receiving a 202 to a >>>>>> MESSAGE >>>> is >>>>>> means the same thing that Eric is asking for. It may be worth >>>>>> considering whether we want to have that concept in IMDN. (I lean >>>>>> towards "no"-We have a slippery slope here on adding too much >>>>>> transport functionality to IMDN.) >>>>>> >>>>>>> >>>>>>>> >>>>>>>> An intermediary strictly following the current spec would >>>>>>>> return a >>>> >>>>>>>> negative delivery notification when it was not able to reach a >>>>>>>> target. If the intermediary provides store-and-forward service >>>>>>>> though, this results in a less than ideal experience for the >>>>>>>> user >>>>>>>> requesting the IMDN. They would almost immediately receive an >>>>>>>> indication that their message was not delivered. >>>>>>> >>>>>>> No. They wouldn't receive anything. The message is still to be >>>>>>> delivered. >>>>>> >>>>>> When I first read Hisham's response, I thought he was saying >>>>>> nothing >>>> >>>>>> would be sent unless delivery succeeded. But I think he means that >>>> the >>>>>> intermediary should not return a failure IMDN until it had >>>>>> exhausted >>>> >>>>>> all opportunities to deliver the message. If so, then I think I >>>> agree. >>>>> >>>>> Yes thats what I meant. >>> >>> and I agree that that interpretation makes more sense. I was just >>> being strict on how I read "final response" >>> >>>>> >>>>>>>> Some time later (assuming that the message was subsequently >>>>>>>> successfully delivered), they would receive another IMDN for the >>>>>>>> same message indicating success (this one is a bit fuzzier I >>>> think). >>>>>>> >>>>>>> This would be the first one they get. >>>>>>> >>>>>>>> >>>>>>>> The net is that it is confusing to the user. I would suggest >>>> adding >>>>>>>> a "stored" state to handle this. It would be sent by an >>>>>>>> intermediary providing store-and-forward service and would >>>>>>>> provide >>>> >>>>>>>> the sender with a much more accurate view of what the >>>>>>>> intermediate >>>> >>>>>>>> disposition of their message was. >>>> >>>> I really, really would rather have the "processed" state. Let the >>>> protocol say what it is really doing, not what it thinks might be >>>> possibly going on. The B2BUA receives a message: it is being >>>> processed, >>>> so tell the UAC so. A later delivery message should work just fine. >>>> The B2BUA doesn't get the message, or it can't process the message: >>>> send >>>> a failure report. >>>> >>>> I don't like "stored", because that is only relevant to >>>> store-and-forward. IMDN should work for any B2BUA, not just a >>>> store-and-forward B2BUA. >>>> >>>> Note that having the hint to the B2BUA that the UAC is looking for >>>> the >>>> fate of the B2BUA's handling of the message, rather than the >>>> endpoints >>>> handling of the message, removes the ambiguity of who should >>>> generate >>>> the IMDN and what the IMDN means. >>> >>> >>> I'm also strongly in favor of allowing the protocol to have reporting >>> of intermediate states. This allows for more descriptive status to >>> be presented to the user. >>> >>> I still like "stored", but not as the only option. I was suggesting >>> that a one example of a category of states of the "processed" ilk. >>> However, I'm okay with using "processed" for this since we have the >>> Note field for the intermediary to provide more descriptive >>> information in. The drawback to this is that we lack a standard way >>> of conveying the more descriptive information. >>> >>> The use of the hint to the intermediary is new to me. Are you >>> suggesting that in this case, only the B2BUA would generate an IMDN? >>> I was thinking more along the lines that the IMDN generated by the >>> B2BUA would be an intermediate response, and that the final endpoint >>> would also generate one. I think this would be true for both >>> "processed" and "stored" types of states. >>> >>> >>>> >>>>>>>> 3) "Future extensions" are mentioned in several places, but no >>>>>>>> extension mechanism is specified. Perhaps a mechanism for >>>>>>>> vendor >>>>>>>> specific extensions should be specified to avoid collisions with >>>>>>>> future versions of this spec. >>>>>>> >>>>>>> Added text in section 9.1 suggesting future extensions must be in >>>> an >>>>>>> RFC. >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 4) The example of an IM body with an IMDN request (section 4.1) >>>> has >>>>>>>> not caught up with the addition of a CPIM namespace to the >>>>>>>> specification. >>>>>>> >>>>>>> I actually forgot this was there. I removed the definition of the >>>> new >>>>>>> namespace and referred to the default namespace instead. >>>>>> >>>>>> We are taking the namespace out? Why? Or did I misread your >>>>>> intent? >>>>>> >>>>>> Namespaces are the defined mechanism for extending CPIM. >>>>> >>>>> I believe using the default namespace is allowed. You can define a >>>>> new >>>> >>>>> namespace for new headers if you are worried about header name >>>> clashes. >>>>> Or am I wrong? >>>> >>>> Namespaces are also used for capabilities negotiation, so it really >>>> should be included. >>>> >>>>>>>> 5) In section 4.4 "Keeping State", second paragraph, perhaps the >>>>>>>> phase "user choice" should read "local policy" (okay, that was a >>>> bit >>>>>>>> editorial :-) >>>>>>> >>>>>>> I actually prefer user choice since it clearly states that the >>>>>>> user >>>> >>>>>>> makes that choice and not the implementer. >>>>>>> >>>>>> >>>>>> If that is the intent, we need more normative language to say the >>>>>> implementation MUST or SHOULD let the user decide. But in this >>>>>> case, >>>> I >>>>>> do think this is more an implementation choice than a user >>>>>> choice. I >>>> >>>>>> don't see an end-user being in a position to decide whether they >>>> want >>>>>> to keep state or not. This is more a matter of the type of device, >>>>>> it's memory constraints, the intended user experience, etc. >>>>>> >>>>> This is the text in the draft "How long to keep items in the "Sent >>>>> Items" box is a user choice." It is not about keeping state, it is >>>>> about keeping items in the sent items box. >>>>> >>>>> This is not an implementer choice. I would smash the phone if it >>>>> removed things from my "Sent Items" box without me doing it >>>>> deliberately :) We are not discussing how to implement a "Sent >>>>> Items" >>>>> box anyhow in this draft. >>>> >>>> Which is also why it isn't really user choice... >>> >>> I can't imagine a client not giving this choice to the user (except >>> perhaps in the case of limited client resources). That said, I think >>> this should be left up to the implementor since it is a UI feature. >>> >>>> >>>>>>>> 6) Description of use of the Original-To header should spell >>>>>>>> out >>>>>>>> that this header should only be added if it does not already >>>> exist. >>>>>>>> It is possible that there will be multiple intermediaries in the >>>>>>>> path, and only the first one should do this. >>>>>>> >>>>>>> Yes. This is done already in my local copy of the next version. >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 7) I agreed with Miguel Garcia's comment on Really-To and >>>>>>>> Really-From in another email, but allow me to reiterate. >>>>>>>> This is >>>> a >>>>>>>> Via-like mechanism and would be less confusing (at least to >>>>>>>> me) if >>>> >>>>>>>> it were named as such. >>>>>>> >>>>>>> I'll make that change. >>>>>>> >>>>>> >>>>>> By the way, we got feedback on MSRP to try to avoid having >>>>>> different >>>> >>>>>> header names start with the same several letters. It makes parsing >>>>>> harder. >>>> >>>> A LONG, SLOW PAINFUL DEATH TO IMPLEMENTORS THAT DO NOT BUILD A REAL >>>> PARSER THAT FOLLOWS THE FULL SPECIFICATION. We first tear out their >>>> fingers so they can no longer inflict "almost compatible" >>>> implementations that we later have to work around. >>>> >>>> GIVE ME A BREAK. Too bad if my 12 character string starts with the >>>> same >>>> 6 characters! If they are not reading the entire string, they have >>>> blown it already. >>> >>> I wasn't going to be quite so violent in my response, but I agree :-) >>> >>>> >>>> >>>>>>>> 8) Aggregation. Let's start with a scenario. Say there's a >>>> request >>>>>>>> to a list exploder with a local policy on the requested list to >>>> not >>>>>>>> reveal the list members. Let's also say that the exploder is >>>> going >>>>>>>> to aggregate IMDNs either by policy or request. >>>>>>>> >>>>>>>> So the request is exploded, and time passes. The exploder >>>> collects >>>>>>>> some IMDNs and decides it's time to send an aggregate response. >>>>>>>> Since the local policy is to not reveal list members, it strips >>>> this >>>>>>>> info from all of the IMDNs. Then it prepares and sends the >>>>>>>> aggregated IMDN. >>>>>>> >>>>>>> A list server can send *ONE* imdn indicating "delivered" after is >>>> has >>>>>>> received some or all of the IMDNs. This is only an option of >>>> course. >>>>>>> >>>>>>>> >>>>>>>> The UA that originated the request to the list exploder then >>>>>>>> receives a list of IMDNs with no user information in them. Now, >>>> how >>>>>>>> will this be presented to the user? >>>>>>> >>>>>>> "x users received the message" is one example. This is an >>>>>>> implementation choice >>>>>>> >>>>>>>> The client only knows that some number of users on the list >>>>>>>> received the message, some number didn't, and an unknown number >>>> did >>>>>>>> or didn't receive it. >>>>>>> >>>>>>> That acceptable, imo. >>>>>> >>>>>> Acceptable, maybe. Can we describe a use case for which it is >>>> _useful_. >>>>> >>>>> What are you suggesting? Are you suggesting that no aggregation is >>>> done >>>>> for private lists? or should the list server reject the IM? I can't >>>>> think of a use case now, but I don't think we should add >>>>> complications >>>> >>>>> by forbidding something. This is implementation choice. >>>> >>>> Agreed (with Hisham) >>> >>> So, a list server can then potentially: >>> >>> ((ignore the IMDN request) or ((optionally generate a "processed" >>> type IMDN when the list is exploded) and (optionally generate one >>> "delivered" IMDN when it receives some number of IMDNs from the >>> recipients) or (optionally generate some number of aggregated IMDNs >>> with the recipient info stripped)) >>> >>> and the client would then have to savvy any combination of these if >>> it wanted to send to a list. Maybe this is reasonable, but it seems >>> as if we've come up with several ways to skin a cat, when it may be >>> that we really had a porcupine (and who wants to skin a porcupine?). >>> I'll have to give this some more thought. >>> >>>> >>>>>>>> The number of aggregated IMDNs could be large as well and may >>>>>>>> require multiple messages (only 1300 bytes available for >>>>>>>> MESSAGE) >>>> to >>>>>>>> send. I would suggest that aggregated IMDNs don't make sense if >>>> the >>>>>>>> policy of the aggregator is to strip the recipient info. >>>>>>> >>>>>>> I disagree. I think it does make sense. Sometimes I am interested >>>>>>> that enough people received the message, not who. >>>>>>> >>>>>>>> The most useful piece of delivery information that can >>>>>>>> probably >>>> be >>>>>>>> obtained in this scenario is that the message was delivered >>>>>>>> successfully or not to the list server. This could be >>>> accomplished >>>>>>>> by sending a "delivered" state IMDN from the list server, or if >>>>>>>> something more explicit is desired, another intermediate state, >>>> such >>>>>>>> as "exploded" (okay, that was just for fun, but it conveys the >>>>>>>> status) could be defined. >>>> >>>> This would be handled by the UAC giving the B2BUA the hint that the >>>> IMDN >>>> is for the B2BUA to generate (in its role as a UAS) and not for >>>> down-stream nodes to generate. >>>> >>>> >>>>>>>> 9) I'm sure this would have been covered in the next version, >>>>>>>> but >>>>>>>> just in case: the text for the IANA registration of the >>>>>>>> Content-Disposition header (13.5) is missing. >>>>>>> >>>>>>> Yes. Added. > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 31 05:44:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7UJi-0001q1-6d; Mon, 31 Jul 2006 05:44:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7UJg-0001lK-Uo for simple@ietf.org; Mon, 31 Jul 2006 05:44:04 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7UJg-0003QV-SE for simple@ietf.org; Mon, 31 Jul 2006 05:44:04 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G7UHO-00028M-9m for simple@ietf.org; Mon, 31 Jul 2006 05:41:43 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6V9faWM019024; Mon, 31 Jul 2006 12:41:38 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 12:41:33 +0300 Received: from esdhcp035194.research.nokia.com ([172.21.35.194]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 31 Jul 2006 12:41:33 +0300 Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-partial-publish-05.txt From: Aki Niemi To: ext Jeroen van Bemmel In-Reply-To: <006c01c6b3f8$2552ea10$31713b51@BEMBUSTER> References: <000001c6acef$bbf7fab0$6602a8c0@laptopbem> <1154071866.21805.9.camel@macbuster.research.nokia.com> <006c01c6b3f8$2552ea10$31713b51@BEMBUSTER> Content-Type: text/plain Organization: Nokia-NRC/Helsinki Date: Mon, 31 Jul 2006 12:41:08 +0300 Message-Id: <1154338868.5830.44.camel@macbuster.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jul 2006 09:41:33.0563 (UTC) FILETIME=[8241ACB0:01C6B485] X-Spam-Score: -2.5 (--) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org On su, 2006-07-30 at 18:49 +0200, ext Jeroen van Bemmel wrote: > > Is there something obvious that makes the current mechanism broken? If > > not, can you live with what's there now? > > > > It is mostly that pidf-full seems to add unnecessary overhead and > complexity. The overhead in this case being that the root element is named instead of , no? As for complexity, it depends. If your code uses the MIME type to switch processing modes, then having both full and diff versions as part of the same MIME type of 'application/pidf-diff+xml' may actually be less complex to write. (Namely, you would only need to match this new MIME type, and dump all partial code under that.) > Given that the purpose of this draft is reduction of message > size, it would be odd to introduce inefficiencies, in particular if the view > now is that the original reason for introducing pidf-full (versioning) is > not needed. I do see that it is quite some effort to rewrite the whole > "package" of drafts, but the alternative is that implementors get to spend > more effort on implementation, and those implementations get to waste cpu > cycles converting between pidf-full and pidf. I don't understand what you're saying here. In fact, from the implementation point of view, I'd argue that mixing 'application/pidf +xml' and 'application/pidf-diff+xml' in the same subscription dialog or publication stream may require more effort than the current approach, and make it more error prone as well. Also, there is no "conversion" between the formats. The partial-pidf format's XML Schema directly imports the PIDF Schema, so "converting" from one to the other requires changing the root element from to , and replacing one namespace declaration. Hardly a processor intensive task, if you wanted the conversion in the first place (and I don't think you do). > Moreover, I have searched but did not find any XML MIME types that use 2 > distinct roots for their XML documents. There seems to be nothing that > prohibits it, but a unique root is again more simple. Like I said above, this mainly affects how you structure the code processing these messages. I'd personally prefer switching modes between notification/publication type (full vs. partial) using the MIME type. Then switch between a full replacement and patching using the XML root element (full vs. diff). YMMV, but I think from implementation POV, this current approach is actually cleaner. > >> Even if Allow is not allowed in 2xx to PUBLISH, it is still better to use > >> pidf in the initial PUBLISH. If a subsequent pidf-diff fails because of > >> UAS > >> not supporting, the wasted effort is less. > > > > I think you mean Accept, but how much 'better' is it really. You still > > don't save a round trip, since in your proposal, the first partial > > update would still fail, requiring a resend. > > Yes, I meant Accept. > > With pidf-full, it's likely that the document will require TCP for > transmission (due to size). By default, the size difference between a pidf and a pidf-full is 21 bytes: - extra '-diff' in the Content-Type - extra '-diff' in the namespace declaration - extra '-diff' in the root element With the example presence document in pidf-format, which is (even without prettyprint) around 1300 bytes, then using pidf-full might just tip the scales enough that TCP gets used. Then again it might not. However, I think that always using TCP would be a feature and not a bug. :) > If the server does not support pidf-full, it > will send an error response, and probably close the connection. Sending > regular pidf is better, because less wasted bytes are transmitted, and > because the potential error is postponed (if there are no updates, it never > occurs). Right, but only postponed. You haven't actually made the error go away, which would've convinced me that we should go back and change the draft(s). > Moreover, the pidf-diff can likely be sent over UDP, avoiding a > possibly wasteful extra TCP connection setup I think this problem spans way past the discussion of pidf vs. pidf-diff alone. IMHO, sending anything over UDP is a bad idea, especially presence traffic. I'm really not convinced that this mixing of TCP and UDP is a good idea either (e.g., send initial SUBSCRIBE-200-NOTIFY-200 over TCP but then switch to UDP). Cheers, Aki -- Aki Niemi Nokia Research Center _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 31 06:44:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7VG5-0003vb-QL; Mon, 31 Jul 2006 06:44:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7VG4-0003vW-BJ for simple@ietf.org; Mon, 31 Jul 2006 06:44:24 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7VG2-0002DL-TF for simple@ietf.org; Mon, 31 Jul 2006 06:44:24 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6VAiLSZ007491; Mon, 31 Jul 2006 13:44:21 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 13:44:21 +0300 Received: from esdhcp035194.research.nokia.com ([172.21.35.194]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 31 Jul 2006 13:44:20 +0300 Subject: Re: [Simple] Regarding Parsing of partial pidf document From: Aki Niemi To: "ext Jayantheesh Sirmushnam - NPD, Chennai" In-Reply-To: <4B1D6623CCBD79489DE28D1CA062A47E021DF9D6@npd-mail.hclt-ntl.co.in> References: <4B1D6623CCBD79489DE28D1CA062A47E021DF9D6@npd-mail.hclt-ntl.co.in> Content-Type: text/plain Organization: Nokia-NRC/Helsinki Date: Mon, 31 Jul 2006 13:43:55 +0300 Message-Id: <1154342635.5830.64.camel@macbuster.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jul 2006 10:44:20.0543 (UTC) FILETIME=[478D34F0:01C6B48E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org On ma, 2006-07-31 at 12:44 +0530, ext Jayantheesh Sirmushnam - NPD, Chennai wrote: > Hi, > > In Partial-PIDF draft 07, nowhere specified about any rules for > parsing partial PIDF document. > > Could anyone please tell me, how to parse the below partial > PIDF elements. Please take a look at the patch operations framework: http://www.ietf.org/internet-drafts/draft-ietf-simple-xml-patch-ops-02.txt Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 31 06:54:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7VPM-0006F0-Nz; Mon, 31 Jul 2006 06:54:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7VPL-0006Ev-KE for simple@ietf.org; Mon, 31 Jul 2006 06:53:59 -0400 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7VPI-00046l-5L for simple@ietf.org; Mon, 31 Jul 2006 06:53:59 -0400 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 3BA47194495 for ; Mon, 31 Jul 2006 12:53:53 +0200 (CEST) Received: from [192.168.1.40] ([192.168.1.40]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 12:52:53 +0200 In-Reply-To: <44AE619F.1000900@nokia.com> References: <44AE619F.1000900@nokia.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Date: Mon, 31 Jul 2006 12:54:21 +0200 To: Miguel Garcia X-Mailer: Apple Mail (2.624) X-OriginalArrivalTime: 31 Jul 2006 10:52:53.0854 (UTC) FILETIME=[79823FE0:01C6B48F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: "'simple@ietf.org'" , Eric Burger Subject: [Simple] Really-From (was: Re: Comments to draft-ietf-simple-imdn-00.txt) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org On Jul 7, 2006, at 3:29 PM, Miguel Garcia wrote: > > > 16) I hate the names of these headers "Really-From", "Really-To". I > would suggest something more meaningful, for examlpe "Reply-Via" and > "Via", respectively. > These headers will be used solely for routing IMDNs. How about "IMDN-Via" when in an IM and "Via" when in an IMDN? Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 31 07:13:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7ViS-0001vk-59; Mon, 31 Jul 2006 07:13:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7ViQ-0001vO-OO; Mon, 31 Jul 2006 07:13:42 -0400 Received: from smtp3.infineon.com ([203.126.106.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7ViO-0000HK-JP; Mon, 31 Jul 2006 07:13:42 -0400 Received: from unknown (HELO sinse211.ap.infineon.com) ([172.17.65.149]) by smtp3.infineon.com with ESMTP; 31 Jul 2006 19:13:36 +0800 X-SBRS: None Received: from blrse201.ap.infineon.com ([172.20.20.12]) by sinse211.ap.infineon.com over TLS secured channel with Microsoft SMTPSVC(5.0.2195.6713); Mon, 31 Jul 2006 19:13:36 +0800 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] RE: [MMUSIC] File transfer when one device is cpim compatible Date: Mon, 31 Jul 2006 16:43:34 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] RE: [MMUSIC] File transfer when one device is cpim compatible Thread-Index: AcayUa3DYbvXhHbTSwO1GYo5mnP8xQCAKMwg From: To: , X-OriginalArrivalTime: 31 Jul 2006 11:13:36.0169 (UTC) FILETIME=[5DFC7990:01C6B492] X-Spam-Score: 0.2 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: fluffy@cisco.com, mmusic@ietf.org, miguel.an.garcia@nokia.com, Gonzalo.Camarillo@ericsson.com, simple@ietf.org, Salvatore.Loreto@ericsson.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org I also think that MSRP should not differentiate IM from file. This issue(differentiate IM from file)arries when any one of the device participating in file transfer is CPIM compatible.=20 So both the issues can be address in draft-garcia-mmusic-file-transfer-mech-00.txt by adding some text. As per all the discussion, I am proposing to add the following text to the draft. "If device is CPIM compatible,it should not add "message/cpim" as a entry in the SDP accept type." If acceptable, Kindly add this to the draft. Regards, Amit -----Original Message----- From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com]=20 Sent: Friday, July 28, 2006 7:58 PM To: Paul Kyzivat Cc: Goel Amitkumar (IFIN SW WS); fluffy@cisco.com; Gonzalo.Camarillo@ericsson.com; miguel.an.garcia@nokia.com; mmusic@ietf.org; Salvatore.Loreto@ericsson.com; simple@ietf.org Subject: Re: [Simple] RE: [MMUSIC] File transfer when one device is cpim compatible I agree but there is a distinction here since sending file over the IM chat will require an application that will cooperate and convert file to/from IM. Anyway, I do not think that we need to differentiate IM from file. --Avshalom =20 Paul Kyzivat 28/07/2006 16:54 To Avshalom Houri/Haifa/IBM@IBMIL cc Amitkumar.Goel@infineon.com, fluffy@cisco.com, Gonzalo.Camarillo@ericsson.com, miguel.an.garcia@nokia.com, mmusic@ietf.org, Salvatore.Loreto@ericsson.com, simple@ietf.org Subject Re: [Simple] RE: [MMUSIC] File transfer when one device is cpim=20 compatible Avshalom Houri wrote: > There may be security issues that may necessitate to know that an MSRP > session is actually a file transfer like virus scanning. I don't see how such a distinction would be helpful. It is possible to use a "conversational" MSRP session to transfer files as well. So if you care about such things you should be scanning all MSRP traffic in any case. Paul > However, I agree with Paul that we should not differentiate file=20 > transfer from IM as these kind of protections should be in the=20 > application level. > --Avshalom >=20 >=20 >=20 >=20 >=20 > Paul Kyzivat > 27/07/2006 19:22 >=20 > To > Amitkumar.Goel@infineon.com > cc > fluffy@cisco.com, mmusic@ietf.org, miguel.an.garcia@nokia.com,=20 > Gonzalo.Camarillo@ericsson.com, simple@ietf.org,=20 > Salvatore.Loreto@ericsson.com Subject > Re: [Simple] RE: [MMUSIC] File transfer when one device is cpim=20 > compatible >=20 >=20 >=20 >=20 >=20 >=20 > Some disjoint thoughts on this subject: >=20 > I don't think *MSRP* should differentiate between IM and file transfer.=20 > MSRP has plenty of ways to identify and categorize the content that=20 > may be used by the applications on top of MSRP to do that differentiation. >=20 > Since other IM protocols do support file transfer, perhaps CPIM should > be allowed for file transfer. >=20 > It occurs to me that MIME provides some useful tools that might be=20 > applicable here. In particular, Content-Disposition might be of use. A > Content-Disposition of "render" would be a real IM. Some other=20 > disposition (e.g. "attachment") could be used for a message containing > a > file being transferred. >=20 > Paul >=20 > Amitkumar.Goel@infineon.com wrote: >> Hi, >> >> It means MSRP should differentiate between "instant message" and=20 >> "file transfer" sessions. >> >> Regards, >> Amit >> >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: Wednesday, July 26, 2006 8:03 PM >> To: Goel Amitkumar (IFIN SW WS) >> Cc: mmusic@ietf.org; Salvatore.Loreto@ericsson.com;=20 >> miguel.an.garcia@nokia.com; Gonzalo.Camarillo@ericsson.com >> Subject: Re: [MMUSIC] File transfer when one device is cpim=20 >> compatible >> >> >> I suspect that the file transfer would not be considered an "instant=20 >> message" and thus would not be wrapped. >> >> >> On Jul 24, 2006, at 9:12 PM, =20 >> wrote: >> >>> Hi All, >>> >>> According to MSRP draft "when one endpoint of the session is a CPIM=20 >>> gateway, instant messages SHOULD be wrapped in "message/cpim" [12]=20 >>> bodies". >>> So my question is how the example given in section 7 of=20 >>> "draft-garcia-mmusic-file-transfer-mech-00.txt" looks when any one=20 >>> of the device participating in file transfer is CPIM compatible? >>> >>> Regards, >>> Amit >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mmusic >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 31 07:32:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7W08-00062A-8R; Mon, 31 Jul 2006 07:32:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7W06-000625-JZ for simple@ietf.org; Mon, 31 Jul 2006 07:31:58 -0400 Received: from [202.54.64.17] (helo=hclnpd.hclt-ntl.co.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7W04-0002yM-1C for simple@ietf.org; Mon, 31 Jul 2006 07:31:58 -0400 Received: from npd-mail1.hclt-ntl.co.in ([10.105.1.106]) by hclnpd.hclt-ntl.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id L8ZN7A27; Mon, 31 Jul 2006 16:59:42 +0530 Content-Class: urn:content-classes:message X-MessageTextProcessor: DisclaimIt (2.50.252) [HCL Technologies Ltd., Chennai, India] Received: from npd-mail.hclt-ntl.co.in ([10.105.1.104]) by npd-mail1.hclt-ntl.co.in with Microsoft SMTPSVC(5.0.2195.6713); Mon, 31 Jul 2006 17:01:53 +0530 Received: by npd-mail.hclt-ntl.co.in with Internet Mail Service (5.5.2657.72) id ; Mon, 31 Jul 2006 17:01:53 +0530 Message-ID: <4B1D6623CCBD79489DE28D1CA062A47E021DFAB1@npd-mail.hclt-ntl.co.in> From: "Jayantheesh Sirmushnam - NPD, Chennai" To: Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Regarding Parsing of partial pidf document Date: Mon, 31 Jul 2006 17:01:53 +0530 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 31 Jul 2006 11:31:53.0863 (UTC) FILETIME=[EC434970:01C6B494] X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Aki Niemi X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi, I would be better, if the draft = "draft-ietf-simple-xml-patch-ops-02.txt" is specified in the Partial PIDF draft ,since this draft contains the information regarding the ,, elements. Thanks, Jayantheesh -----Original Message----- From: Aki Niemi [mailto:aki.niemi@nokia.com]=20 Sent: Monday, July 31, 2006 4:14 PM To: ext Jayantheesh Sirmushnam - NPD, Chennai Cc: simple@ietf.org Subject: Re: [Simple] Regarding Parsing of partial pidf document On ma, 2006-07-31 at 12:44 +0530, ext Jayantheesh Sirmushnam - NPD, Chennai wrote: > Hi, >=20 > In Partial-PIDF draft 07, nowhere specified about any rules for > parsing partial PIDF document. >=20 > Could anyone please tell me, how to parse the below partial > PIDF elements. Please take a look at the patch operations framework: http://www.ietf.org/internet-drafts/draft-ietf-simple-xml-patch-ops-02.tx= t Cheers, Aki Disclaimer: This message and any attachment(s) contained here are information that = is confidential, proprietary to HCL Technologies and its customers, = privileged or otherwise protected by law. The information is solely = intended for the individual or the entity it is addressed to. If you are = not the intended recipient of this message, you are not authorized to = read, forward, print, retain, copy or disseminate this message or any = part of it. If you have received this e-mail in error, please notify the = sender immediately by return e-mail and delete it from your computer. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 31 07:51:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7WJ2-0005Sb-Oo; Mon, 31 Jul 2006 07:51:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7WJ1-0005ST-3v for simple@ietf.org; Mon, 31 Jul 2006 07:51:31 -0400 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7WIz-00051t-Al for simple@ietf.org; Mon, 31 Jul 2006 07:51:30 -0400 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 7B86719449D for ; Mon, 31 Jul 2006 13:51:28 +0200 (CEST) Received: from [192.168.1.40] ([192.168.1.40]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 13:50:25 +0200 In-Reply-To: <330A23D8336C0346B5C1A5BB196666470356A5B9@ATLANTIS.Brooktrout.com> References: <330A23D8336C0346B5C1A5BB196666470356A5B9@ATLANTIS.Brooktrout.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <07e9626f920cb8f8f9a555d348bbedab@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] Re: Comments on draft-ietf-simple-imdn-00.txt Date: Mon, 31 Jul 2006 13:51:55 +0200 To: "Burger, Eric" X-Mailer: Apple Mail (2.624) X-OriginalArrivalTime: 31 Jul 2006 11:50:25.0821 (UTC) FILETIME=[830A9CD0:01C6B497] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org On Jul 28, 2006, at 5:50 PM, Burger, Eric wrote: >>>> >>>> >>>>> >>>>> >>>>> 4) The example of an IM body with an IMDN request (section 4.1) > has >>>>> not caught up with the addition of a CPIM namespace to the >>>>> specification. >>>> >>>> I actually forgot this was there. I removed the definition of the > new >>>> namespace and referred to the default namespace instead. >>> >>> We are taking the namespace out? Why? Or did I misread your intent? >>> >>> Namespaces are the defined mechanism for extending CPIM. >> >> I believe using the default namespace is allowed. You can define a new > >> namespace for new headers if you are worried about header name > clashes. >> Or am I wrong? > > Namespaces are also used for capabilities negotiation, so it really > should be included. What capability negotiation? I really think this is out of scope. Again, I'm not convinced that the complexity is worth it here. Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 31 08:28:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7Wsc-0006BV-NU; Mon, 31 Jul 2006 08:28:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7Wsb-0006BQ-MA for simple@ietf.org; Mon, 31 Jul 2006 08:28:17 -0400 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7WsZ-00016X-Uu for simple@ietf.org; Mon, 31 Jul 2006 08:28:17 -0400 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id C30E819448B for ; Mon, 31 Jul 2006 14:28:14 +0200 (CEST) Received: from [192.168.1.40] ([192.168.1.40]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 14:27:13 +0200 In-Reply-To: References: <44AE619F.1000900@nokia.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <83b991c1c24a8f5bf10b95e158ada689@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] Really-From (was: Re: Comments to draft-ietf-simple-imdn-00.txt) Date: Mon, 31 Jul 2006 14:28:43 +0200 To: Hisham Khartabil X-Mailer: Apple Mail (2.624) X-OriginalArrivalTime: 31 Jul 2006 12:27:13.0742 (UTC) FILETIME=[A7109EE0:01C6B49C] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Miguel Garcia , "'simple@ietf.org'" , Eric Burger X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org On Jul 31, 2006, at 12:54 PM, Hisham Khartabil wrote: > > On Jul 7, 2006, at 3:29 PM, Miguel Garcia wrote: > >> >> >> 16) I hate the names of these headers "Really-From", "Really-To". I >> would suggest something more meaningful, for examlpe "Reply-Via" and >> "Via", respectively. >> > > These headers will be used solely for routing IMDNs. How about > "IMDN-Via" when in an IM and "Via" when in an IMDN? Actually now that I think about it a little more, I don't like "IMDN-Via" and "Via". In SIP "Via" is used to route responses and IMDNs are not responses. They are requests. This will confuse some people. I now prefer "IMDN-Record-Route" and "IMDN-Route". Comments? Hisham > > Hisham > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 31 09:30:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7Xr4-00087B-Ri; Mon, 31 Jul 2006 09:30:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7Xr3-000875-Ew for simple@ietf.org; Mon, 31 Jul 2006 09:30:45 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7Xr2-0001Ts-3T for simple@ietf.org; Mon, 31 Jul 2006 09:30:45 -0400 Received: from [192.168.1.102] (c-67-174-92-207.hsd1.tx.comcast.net [67.174.92.207]) (authenticated bits=0) by vicuna.estacado.net (8.13.6/8.13.4) with ESMTP id k6VDStsm001490 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 31 Jul 2006 08:29:00 -0500 (CDT) (envelope-from ben@estacado.net) In-Reply-To: <07e9626f920cb8f8f9a555d348bbedab@telio.no> References: <330A23D8336C0346B5C1A5BB196666470356A5B9@ATLANTIS.Brooktrout.com> <07e9626f920cb8f8f9a555d348bbedab@telio.no> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <20D01EEF-F6A9-46DB-A266-173E6AD2AD8B@estacado.net> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] Re: Comments on draft-ietf-simple-imdn-00.txt Date: Mon, 31 Jul 2006 08:28:52 -0500 To: Hisham Khartabil X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org On Jul 31, 2006, at 6:51 AM, Hisham Khartabil wrote: > > On Jul 28, 2006, at 5:50 PM, Burger, Eric wrote: > >>>>> >>>>> >>>>>> >>>>>> >>>>>> 4) The example of an IM body with an IMDN request (section 4.1) >> has >>>>>> not caught up with the addition of a CPIM namespace to the >>>>>> specification. >>>>> >>>>> I actually forgot this was there. I removed the definition of the >> new >>>>> namespace and referred to the default namespace instead. >>>> >>>> We are taking the namespace out? Why? Or did I misread your intent? >>>> >>>> Namespaces are the defined mechanism for extending CPIM. >>> >>> I believe using the default namespace is allowed. You can define >>> a new >> >>> namespace for new headers if you are worried about header name >> clashes. >>> Or am I wrong? >> >> Namespaces are also used for capabilities negotiation, so it really >> should be included. > > What capability negotiation? I really think this is out of scope. > Again, I'm not convinced that the complexity is worth it here. > Even without capablity negotiation, the presence of a namespace can be useful from an implementation perspective. For example, If I do not see the "IMDN" namespace, I do not have to bother looking for IMDN related headers headers. Also, section 3.4 of IET 3862 says the following: > > NOTE: This section defines a framework for header extensibility > whose > use is optional. If no header extensions are allowed by an > application then these structures may never be used. I read that to mean that, in spirit, the "optionality" of supporting namespaces is contingent on not supporting any extensions. This is certainly an extension. But then, the IANA registry does allow extensions without namespaces. I'd be curious to hear the opinions of the RFC3862 authors on this. > Hisham > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 31 09:33:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7Xtm-0001t3-HD; Mon, 31 Jul 2006 09:33:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7Xtl-0001sv-CJ for simple@ietf.org; Mon, 31 Jul 2006 09:33:33 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7Xtj-00028y-VL for simple@ietf.org; Mon, 31 Jul 2006 09:33:33 -0400 Received: from [192.168.1.102] (c-67-174-92-207.hsd1.tx.comcast.net [67.174.92.207]) (authenticated bits=0) by vicuna.estacado.net (8.13.6/8.13.4) with ESMTP id k6VDW8HJ001982 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 31 Jul 2006 08:32:13 -0500 (CDT) (envelope-from ben@estacado.net) In-Reply-To: <83b991c1c24a8f5bf10b95e158ada689@telio.no> References: <44AE619F.1000900@nokia.com> <83b991c1c24a8f5bf10b95e158ada689@telio.no> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9AE889B9-D436-41FE-8789-EEA444EB2342@estacado.net> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] Really-From (was: Re: Comments to draft-ietf-simple-imdn-00.txt) Date: Mon, 31 Jul 2006 08:32:04 -0500 To: Hisham Khartabil X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Miguel Garcia , "'simple@ietf.org'" , Eric Burger X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org On Jul 31, 2006, at 7:28 AM, Hisham Khartabil wrote: > > On Jul 31, 2006, at 12:54 PM, Hisham Khartabil wrote: > >> >> On Jul 7, 2006, at 3:29 PM, Miguel Garcia wrote: >> >>> >>> >>> 16) I hate the names of these headers "Really-From", "Really-To". >>> I would suggest something more meaningful, for examlpe "Reply- >>> Via" and "Via", respectively. >>> >> >> These headers will be used solely for routing IMDNs. How about >> "IMDN-Via" when in an IM and "Via" when in an IMDN? > > Actually now that I think about it a little more, I don't like > "IMDN-Via" and "Via". In SIP "Via" is used to route responses and > IMDNs are not responses. They are requests. This will confuse some > people. I now prefer "IMDN-Record-Route" and "IMDN-Route". > As I mentioned previously, it would be better to choose something that does not use the same several-character opening sequence. But more to the point, the fact that we seem to want to relate this to one SIP mechanism or another makes me nervous. How much of SIP are we going to recreate? How long until someone asks for a loose-routing mechanism, or maybe retransmissions? > Comments? > > Hisham > >> >> Hisham >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 31 09:50:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7YA0-0001P3-0b; Mon, 31 Jul 2006 09:50:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7Y9z-0001Ow-0H for simple@ietf.org; Mon, 31 Jul 2006 09:50:19 -0400 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7Y9w-0004Rt-Bm for simple@ietf.org; Mon, 31 Jul 2006 09:50:18 -0400 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 548F819447F for ; Mon, 31 Jul 2006 15:50:15 +0200 (CEST) Received: from [192.168.1.40] ([192.168.1.40]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 15:49:14 +0200 In-Reply-To: <9AE889B9-D436-41FE-8789-EEA444EB2342@estacado.net> References: <44AE619F.1000900@nokia.com> <83b991c1c24a8f5bf10b95e158ada689@telio.no> <9AE889B9-D436-41FE-8789-EEA444EB2342@estacado.net> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3ec66e4038549f1934f2b00b27dd9e29@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] Really-From (was: Re: Comments to draft-ietf-simple-imdn-00.txt) Date: Mon, 31 Jul 2006 15:50:43 +0200 To: Ben Campbell X-Mailer: Apple Mail (2.624) X-OriginalArrivalTime: 31 Jul 2006 13:49:14.0410 (UTC) FILETIME=[1C02F8A0:01C6B4A8] X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: Miguel Garcia , "'simple@ietf.org'" , Eric Burger X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org On Jul 31, 2006, at 3:32 PM, Ben Campbell wrote: > > On Jul 31, 2006, at 7:28 AM, Hisham Khartabil wrote: > >> >> On Jul 31, 2006, at 12:54 PM, Hisham Khartabil wrote: >> >>> >>> On Jul 7, 2006, at 3:29 PM, Miguel Garcia wrote: >>> >>>> >>>> >>>> 16) I hate the names of these headers "Really-From", "Really-To". I >>>> would suggest something more meaningful, for examlpe "Reply-Via" >>>> and "Via", respectively. >>>> >>> >>> These headers will be used solely for routing IMDNs. How about >>> "IMDN-Via" when in an IM and "Via" when in an IMDN? >> >> Actually now that I think about it a little more, I don't like >> "IMDN-Via" and "Via". In SIP "Via" is used to route responses and >> IMDNs are not responses. They are requests. This will confuse some >> people. I now prefer "IMDN-Record-Route" and "IMDN-Route". >> > > As I mentioned previously, it would be better to choose something that > does not use the same several-character opening sequence. > > But more to the point, the fact that we seem to want to relate this to > one SIP mechanism or another makes me nervous. How much of SIP are we > going to recreate? How long until someone asks for a loose-routing > mechanism, or maybe retransmissions? There is a specific reason for doing this, and that is *some* intermediaries need to see IMDNs. Information in the To and From headers are not enough. Hisham > > > >> Comments? >> >> Hisham >> >>> >>> Hisham >>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >>> >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 31 10:29:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7YmC-0006Ci-ST; Mon, 31 Jul 2006 10:29:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7YmC-00068v-0h for simple@ietf.org; Mon, 31 Jul 2006 10:29:48 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7YmA-0000Hf-6y for simple@ietf.org; Mon, 31 Jul 2006 10:29:47 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3A0368E0002 for ; Mon, 31 Jul 2006 16:28:52 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 16:28:51 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 16:28:51 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id BF94424C5; Mon, 31 Jul 2006 17:28:51 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 83F2A4DB94; Mon, 31 Jul 2006 17:28:51 +0300 (EEST) Received: from localhost.localdomain (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E439C4DB4E; Mon, 31 Jul 2006 17:28:50 +0300 (EEST) From: "Salvatore Loreto (JO/LMF)" To: simple@ietf.org Content-Type: text/plain Date: Mon, 31 Jul 2006 17:28:49 +0300 Message-Id: <1154356130.3460.5.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-4.fc4) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 31 Jul 2006 14:28:51.0860 (UTC) FILETIME=[A5150D40:01C6B4AD] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ingemar.lindgren@ericsson.com Subject: [Simple] problem in draft-ietf-simple-xcap-list-usage-05 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi all, Hi OMA found a problem in the draft draft-ietf-simple-xcap-list-usage-05, specifically in chapter 3.2 that defines resource-list schema as next: There is no definition of minOccurs so default value is 1. This cause the problem when client want to delete the last URI List from the index document. In this case server will raise "schema-validation-error". So, it is not possible to have empty index document for resource-lists. rls-services and common-policy schema allow document to be created without service and rule elements (allow empty documents) because they specified minOccurs="0". I'd like know your opinion about this. thank you in advance Sal _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 31 14:17:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7cKH-0008Sq-QX; Mon, 31 Jul 2006 14:17:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7cKG-0008Sk-6H for simple@ietf.org; Mon, 31 Jul 2006 14:17:12 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7cKF-0002eI-78 for simple@ietf.org; Mon, 31 Jul 2006 14:17:12 -0400 Received: (qmail 14572 invoked by uid 0); 31 Jul 2006 18:17:09 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 31 Jul 2006 18:17:09 -0000 Message-ID: <001001c6b4cd$84ab44f0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Aki Niemi" References: <000001c6acef$bbf7fab0$6602a8c0@laptopbem><1154071866.21805.9.camel@macbuster.research.nokia.com><006c01c6b3f8$2552ea10$31713b51@BEMBUSTER> <1154338868.5830.44.camel@macbuster.research.nokia.com> Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-partial-publish-05.txt Date: Mon, 31 Jul 2006 20:17:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-2"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Aki, OK, so how about a compromise: make pidf-full support optional for publisher and notify receiver, and mandatory for presence server to receive. For NOTIFY, server MUST check accept: in SUBSCRIBE before sending pidf-full Regards, Jeroen ----- Original Message ----- From: "Aki Niemi" To: "ext Jeroen van Bemmel" Cc: Sent: Monday, July 31, 2006 11:41 AM Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-partial-publish-05.txt > On su, 2006-07-30 at 18:49 +0200, ext Jeroen van Bemmel wrote: >> > Is there something obvious that makes the current mechanism broken? If >> > not, can you live with what's there now? >> > >> >> It is mostly that pidf-full seems to add unnecessary overhead and >> complexity. > > The overhead in this case being that the root element is named > instead of , no? > > As for complexity, it depends. If your code uses the MIME type to switch > processing modes, then having both full and diff versions as part of the > same MIME type of 'application/pidf-diff+xml' may actually be less > complex to write. (Namely, you would only need to match this new MIME > type, and dump all partial code under that.) > >> Given that the purpose of this draft is reduction of message >> size, it would be odd to introduce inefficiencies, in particular if the >> view >> now is that the original reason for introducing pidf-full (versioning) is >> not needed. I do see that it is quite some effort to rewrite the whole >> "package" of drafts, but the alternative is that implementors get to >> spend >> more effort on implementation, and those implementations get to waste cpu >> cycles converting between pidf-full and pidf. > > I don't understand what you're saying here. In fact, from the > implementation point of view, I'd argue that mixing 'application/pidf > +xml' and 'application/pidf-diff+xml' in the same subscription dialog or > publication stream may require more effort than the current approach, > and make it more error prone as well. > > Also, there is no "conversion" between the formats. The partial-pidf > format's XML Schema directly imports the PIDF Schema, so "converting" > from one to the other requires changing the root element from > to , and replacing one namespace declaration. Hardly a > processor intensive task, if you wanted the conversion in the first > place (and I don't think you do). > >> Moreover, I have searched but did not find any XML MIME types that use 2 >> distinct roots for their XML documents. There seems to be nothing that >> prohibits it, but a unique root is again more simple. > > Like I said above, this mainly affects how you structure the code > processing these messages. I'd personally prefer switching modes between > notification/publication type (full vs. partial) using the MIME type. > > Then switch between a full replacement and patching using the XML root > element (full vs. diff). YMMV, but I think from implementation POV, this > current approach is actually cleaner. > >> >> Even if Allow is not allowed in 2xx to PUBLISH, it is still better to >> >> use >> >> pidf in the initial PUBLISH. If a subsequent pidf-diff fails because >> >> of >> >> UAS >> >> not supporting, the wasted effort is less. >> > >> > I think you mean Accept, but how much 'better' is it really. You still >> > don't save a round trip, since in your proposal, the first partial >> > update would still fail, requiring a resend. >> >> Yes, I meant Accept. >> >> With pidf-full, it's likely that the document will require TCP for >> transmission (due to size). > > By default, the size difference between a pidf and a pidf-full is 21 > bytes: > - extra '-diff' in the Content-Type > - extra '-diff' in the namespace declaration > - extra '-diff' in the root element > > With the example presence document in pidf-format, which is (even > without prettyprint) around 1300 bytes, then using pidf-full might just > tip the scales enough that TCP gets used. Then again it might not. > > However, I think that always using TCP would be a feature and not a > bug. :) > >> If the server does not support pidf-full, it >> will send an error response, and probably close the connection. Sending >> regular pidf is better, because less wasted bytes are transmitted, and >> because the potential error is postponed (if there are no updates, it >> never >> occurs). > > Right, but only postponed. You haven't actually made the error go away, > which would've convinced me that we should go back and change the > draft(s). > >> Moreover, the pidf-diff can likely be sent over UDP, avoiding a >> possibly wasteful extra TCP connection setup > > I think this problem spans way past the discussion of pidf vs. pidf-diff > alone. IMHO, sending anything over UDP is a bad idea, especially > presence traffic. I'm really not convinced that this mixing of TCP and > UDP is a good idea either (e.g., send initial SUBSCRIBE-200-NOTIFY-200 > over TCP but then switch to UDP). > > Cheers, > Aki > > -- > Aki Niemi > Nokia Research Center > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple